I don't understand this. I have no problems with a recommendation (i.e., SHOULD), but you will find that many implementations will not comply with these requirements when pushed.
On 8 November 2016 at 14:09, Daniel Migault <daniel.miga...@ericsson.com> wrote: > 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. This is two statements: 1. The PRF hash for these suites is SHA-256. That's not a requirement, you just define it, no 2119 language. 2. Using a weak key negotiation means that your key negotiation is the weak point. Here, my preference is to avoid stating a requirement, but that's only because it's very hard to get right. Otherwise, use a SHOULD and copy from HTTP/2: "When choosing these cipher suites, servers SHOULD select a key exchange that is at least 2048 bits for cipher suites that use ephemeral finite field Diffie-Hellman (DHE) [TLS12] and 224 bits for cipher suites that use ephemeral elliptic curve Diffie-Hellman (ECDHE) [RFC4492]." Getting into the exact number of bits is a bit self-defeating. 4Q isn't 255 bits. 25519 isn't either if you count them all. Both seem to be more than adequate in strength though. > 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. As above, but with bigger numbers. > 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. Nits: 'enables'; there is a space between "TLS" and the version number. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
