If I understand correctly, you recommend something that is of the flavor in the security recommendation section:
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 TLS 1.2 and TLS 1.3. If that is correct I will propose some better text explaining why we can hardly provide some better text, including the one provided by HTTP2. Yours, Daniel On Tue, Nov 8, 2016 at 4:49 AM, Nikos Mavrogiannopoulos <n...@redhat.com> wrote: > On Tue, 2016-11-08 at 03:50 -0500, Daniel Migault wrote: > > > Regarding Niko, my understanding is that the WG preferred not to have > > the definition of profiles in this document. I am not sure you wanted > > the text to be removed as MUST NOT was to normative or if you would > > like no recommendation at all. The reason I would rather advocate for > > recommendation is that ECDHE does not specify an algorithm with a > > specific security. As a result, I would rather provide some guide > > lines to avoid weak authentication being used with high long AES > > keys. > > That's a valid concern, but TLS doesn't have the notion of a security > level, and I am not sure that you can easily introduce it with a > ciphersuite point assignment rfc. With TLS you can easily use AES-256 > with DHE-RSA with DH parameters of 4096-bits, signed with an RSA > certificate of 32-bits. One can use your draft with a 8-bit PSK, and > still be insecure despite the fact that you force a 256-bit curve or > better. When trying to ensure a consistent level you may likely need to > adjust the finished message size as well. > > Nevertheless, I think to cover your goal, a security considerations > addition that makes apparent that in addition to the ciphersuite > parameters, the TLS protocol finished message size, the elliptic curves > used, and the size of the selected key define the security level of the > session. > > regards, > Nikos > > _______________________________________________ > 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
