Re: [TLS] draft-ietf-tls-grease and RFC 7919

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.cooper@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
>