Hi Dan, Sean, Nikos, First, let me state that I think requiring 128-bit key management for AES-128 is quite reasonable.
HTTP/2 [RFC7540] also has some related text in Section 9.2.1 that applies when TLS is used for HTTP/2. "Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a connection error (Section 5.4.1 <https://tools.ietf.org/html/rfc7540#section-5.4.1>) of type INADEQUATE_SECURITY." I think this is a question for TLS in general, draft-ietf-tls-ecdhe-psk-aead should just follow what the TLS WG decides as the general way forward. Wether that is MAY/SHOULD/SHALL treat groups with insufficient security as an error. I think the real problem here are TLS libraries supporting 1024 MODP and 160 ECC at all, support for these should have been removed before 2010. Nikos [0] recommends a RCF forbidding weak elliptic curves from TLS 1.2 (i.e. WeakDH DieDieDie!!!). I think this is a great idea and much better than bundling it into a code-point assignment RFC. (My current plans for the next update of 3GPP’s TLS and DTLS profiles is simply to forbid support of anything weaker than 2048 MODP and 255-bit ECC). [0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ Cheers, John On 11/07/16 22:26, "TLS on behalf of Dan Harkins" <[email protected] on behalf of [email protected]> wrote: > > I'm glad I have to opportunity to make you happy Sean :-) > >On Mon, July 11, 2016 7:40 am, Sean Turner wrote: >> I think I can take this bit: >> >> On Jul 10, 2016, at 06:51, Peter Dettman >><[email protected]> >> wrote: >>> >>> I'm also curious whether there is a precedent in other RFCs for an >>> explicit minimum curve bits, or perhaps a de facto implementer's rule? >> >> I'd be happy to be wrong here. but to my knowledge no there's not been >> an explicit minimum for curve bits. There have however been similar (at >> least in my non-cryptographer mind) for RSA key sizes so if we wanted to >> define an explicit minimum curve bits then we could. > > draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensuring >the curves used provide commensurate strength with the ciphersuite >negotiated. Section 10, "Implementation Considerations", says: > > It is RECOMMENDED that implementations take note of the strength > estimates of particular groups and to select a ciphersuite providing > commensurate security with its hash and encryption algorithms. A > ciphersuite whose encryption algorithm has a keylength less than the > strength estimate, or whose hash algorithm has a blocksize that is > less than twice the strength estimate SHOULD NOT be used. > > And I would like to take this opportunity to remind everyone that >the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 >and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resistant >to dictionary attack and the former is not. > > regards, > > Dan. > > > >_______________________________________________ >TLS mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
