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

David Benjamin <> Thu, 07 June 2018 21:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB46B130DD2 for <>; Thu, 7 Jun 2018 14:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.95
X-Spam-Status: No, score=-9.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xMSX0d3pRuAP for <>; Thu, 7 Jun 2018 14:51:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0CAD130DD1 for <>; Thu, 7 Jun 2018 14:51:05 -0700 (PDT)
Received: by with SMTP id d130-v6so7588832qkc.2 for <>; Thu, 07 Jun 2018 14:51:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sWNw3PgBsTqk0IoXrvSNIE+/POLbT1CBQiVW9iivztY=; b=O5/xEJrHqFKKF6DtcqDAiVOccXC4bHZhjQxfysElJJXYGY7Le2oqmErkR1tGOCkJyN zR4C7bLhFSufWkfve/fEqenCw7OPCr1OYBKhSj9WJ+eJ925ado0IaLVf0n55fSQKUMzb wUTVHA9dxdFfglnzgO/hrSqg+ihUP7lfjdO5M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sWNw3PgBsTqk0IoXrvSNIE+/POLbT1CBQiVW9iivztY=; b=IEco5AyTc+5bXyeNy+m0WTTwf/YlTbqJoIXjB0CZ/PlRHADjyXGffTKQFPtEeu4Gcf +yFm77G4TMgDNh0b7Nq2/xP+g/ELYJl7UFUuQ/SFkteDu3066l03acwWX4lCiOfhrMu6 kWfbGkZZndHQjVK4qfArdo/rUvZEMnt6Ndrq4xAEgQ4sRcXFupuuswhBwZ4zHMmyT7Al DUsSgkAZ4vAfdwT9NKAyr9F3jYpy+S+aQ7taPnSfRXiqd48DI/+G+kC9bKAvkww0FipY TzirAv5unUh0nudsw8npOxDFdBJJZ/FqbqYNSvd7e6pmXGENPv/dAQaUhXMYvSU5JkBf yHtQ==
X-Gm-Message-State: APt69E3TOK26N/Am9fGDWYKqLIhsCZfqsO6A6tUGZKrk4ZMiIg6lFVzN b5bPCvteqGIzGrtc0Q0xA89Vii35Gtdl+AGgVplD
X-Google-Smtp-Source: ADUXVKK1Az5guso9Lmfce2pYUVIbrseIRDBz08X0e83zF/VECmn51n8IH89281eQ0uF2RtgNwawkbbQflrTdUSYipxI=
X-Received: by 2002:ae9:dc81:: with SMTP id q123-v6mr3307533qkf.318.1528408264582; Thu, 07 Jun 2018 14:51:04 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: David Benjamin <>
Date: Thu, 7 Jun 2018 17:50:52 -0400
Message-ID: <>
To: "David A. Cooper" <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000af6cfb056e144788"
Archived-At: <>
Subject: Re: [TLS] draft-ietf-tls-grease and RFC 7919
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jun 2018 21:51:11 -0000

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:

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.


On Thu, Jun 7, 2018 at 4:17 PM David A. Cooper <>

> 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
> these are the values in the specified range that are currently unassigned).
> Thank you,
> David
> _______________________________________________
> TLS mailing list