Hi, Please find the text I propose. Let me know if you have any comment regarding the proposed text. Unless I receive comment on it, the text will be publish as soon as draft submission is possible.
Yours, Daniel The cipher suites defined in this document are based on the AES-GCM and AES-CCM Authenticated Encryption with Associated Data (AEAD) algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_CCM defined in [RFC5116], AEAD_AES_128_CCM_8 and AEAD_AES_256_CCM_8 defined in [RFC6655]. For the AES-128 cipher suites, the TLS Pseudorandom Function (PRF) with SHA-256 as the hash function SHALL be used and Clients and Servers MUST NOT negotiate curves of less than 255 bits. For the AES-256 cipher suites, the TLS PRF with SHA-384 as the hash function SHALL be used and Clients and Servers MUST NOT negotiate curves of less than 384 bits. TLS enable curve negotiation but not for code point. This makes restrictions on code points hard to implement. As a result Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a connection error of type insufficient_security(71) for TLS1.2 and TLS1.3. On Mon, Oct 24, 2016 at 11:22 AM, Daniel Migault < daniel.miga...@ericsson.com> wrote: > 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
