Hi, My understanding is that the updated version should not introduce any profile. Am I correct ?
BR, Daniel On Mon, Oct 17, 2016 at 1:16 PM, Daniel Migault <daniel.miga...@ericsson.com > wrote: > Hi, > > I am not very clear on how to update the text of the draft. The problem > seems to me that code point restriction are hard to implement. As a result, > the session is aborted with - insufficient_security(71) or equivalent - > when the code point does not match the security strength. I am encline to > think that we should also provide some profiles that achieve 128/256 bit > security. These profiles may be described in this document or in another > document more related to cryptographic recommendation. What would be the > most appropriated way to move forward ? > > BR, > Daniel > > > > On Sun, Oct 9, 2016 at 2:59 AM, John Mattsson <john.matts...@ericsson.com> > wrote: > >> 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-aT299BYrl >> BKvZs0BOQ >> >> >> >> Cheers, >> John >> >> >> On 11/07/16 22:26, "TLS on behalf of Dan Harkins" <tls-boun...@ietf.org >> on >> behalf of dhark...@lounge.org> 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 >> >><peter.dett...@bouncycastle.org> >> >> 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 >> >TLS@ietf.org >> >https://www.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
