This value would be kind of weird because this part of RFC 7919 is quite complex. But if there's interest, I don't mind adding some.
But I think the TLS 1.2 bits of RFC 7919, particularly the rule you refer to, were a mistake and are best ignored. The benefits of that document are unrealizable to a client. This was pointed out here: https://www.ietf.org/mail-archive/web/tls/current/msg18697.html RFC 7919 mistakenly reused the existing DHE cipher suite values rather than defining new ones. There is no way to safely advertise that you support named FFDHE but not legacy server-selected DHE. A client advertising DHE ciphers with an FFDHE group list, when talking to a legacy pre-7919 server, would get back a random DHE group, when picking a different cipher suite would be preferable. This brings the client back to the same problem as before 7919. Section 3.1 attempts to touch on this and advocates a fallback, conditioned on checking the signature, but this is unsafe. The ServerKeyExchange signature does not include the full ClientHello, just the randoms, so an attacker may have just changed the ClientHello to induce a fallback trigger. The rule you refer to in section 4 appears to be so that, were a client to behave in such an undeployable way, post-7919 servers would be fine because they use the existence of *any* [256, 512) code point as an indicator of FFDHE support. That means a client that does not support RFC 7919 cannot include this GREASE value in its rotation. A client which does support RFC 7919 may find allocations valuable. It would not test that behavior (most likely you have a group in common), but it would test that that behavior did not induce a different bug by recommending servers treat unknown code points special. As that link above noted, we just removed DHE ciphers in Chrome altogether. We generally favor ECDHE anyway, but, if we wanted to revive FFDHE, I expect this problem would have been a deal-breaker. This could have been avoided if RFC 7919 allocated its own cipher suites, but it's long published now and with TLS 1.3 nearly done, we may as well now forget about the 1.2 portions of that spec. David On Thu, Jun 7, 2018 at 4:17 PM David A. Cooper <david.coo...@nist.gov> wrote: > I would like to suggest that one additional value be added to the list > of GREASE values for named groups. > > Section 2 of RFC 7919 says: > > Codepoints in the "Supported Groups Registry" with a high byte of > 0x01 (that is, between 256 and 511, inclusive) are set aside for > FFDHE groups. > > Section 4 of RFC 7919 says: > > If a compatible TLS server receives a Supported Groups extension from > a client that includes any FFDHE group (i.e., any codepoint between > 256 and 511, inclusive, even if unknown to the server), and if none > of the client-proposed FFDHE groups are known and acceptable to the > server, then the server MUST NOT select an FFDHE cipher suite. > > > So, it would be helpful in testing this requirement of RFC 7919 if there > were one GREASE value for named groups between 261 and 507 (according to > > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8, > > these are the values in the specified range that are currently unassigned). > > Thank you, > > David > > _______________________________________________ > 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
