Re: TLS cipersuites for Rserpool
Qiaobing Xie <[email protected]>
| Newsgroups | gmane.ietf.rserpool |
|---|---|
| Message-ID | <[email protected]> |
I guess this must have been talked about by others but I am just not well informed about the answer - will there be any IPR ramifications when we say RSERPOOL MUST use certain ciphersuite? My impression is that a lot of ciphers contain IPR. If that is the case, does the "MUST" imply that RSERPOOL can not be implemented without tripping over some cipher IPR? regards, -Qiaobing [email protected] wrote: > > Although we have reached consensus on TLS for securing the Rserpool > infrastructure, we have not discussed TLS cipher suites. TLS has a very > long and growing list of ciphersuites. They vary in strength. Security > experts want strong security. Application developers worry about > interoperability. The answer to this is for applications to mandate a > ciphersuite along with one or more shoulds for backward compatibility. > > I am including the SIP RFC 3261 security section as an example. > In the SIP specification there is the following text: > > The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at > a minimum by implementers when TLS is used in a SIP application. For > purposes of backwards compatibility, proxy servers, redirect servers, > and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. > Implementers MAY also support any other ciphersuite. > > For Rserpool we need to secure the following: > > PU <----> ENRP Server > PE <----> ENRP Server > ENRP server <-----> ENRP Server > > I recommend Rserpool security text as follows (for ENRP and ASAP security > sections): > > The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a minimum > by implementers of TLS for Rserpool. For purposes of backwards > compatibility, ENRP SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. > Implementers MAY also support any other ciphersuite. > > I'll get Eric Rescorla's advice about this TLS cipher suite being the right one > to make mandatory to support and also his take on backward compatibility. We might not need > this in ENRP assuming that everyone will write new code for Rserpool > infrastructure. > > Any comments? > > -- maureen > > _______________________________________________ > rserpool mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/rserpool