Re: [TLS] draft-davidben-tls-grease-01

David Benjamin <> Mon, 05 September 2016 14:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 245B012B232 for <>; Mon, 5 Sep 2016 07:49:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Status: No, score=-4.207 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] 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 9eSlqrjUgMW4 for <>; Mon, 5 Sep 2016 07:49:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0CC812B226 for <>; Mon, 5 Sep 2016 07:49:07 -0700 (PDT)
Received: by with SMTP id i184so149904060itf.1 for <>; Mon, 05 Sep 2016 07:49:07 -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=laM6IOzg0/2ubU4d70ath8zTDch2tBhwN0Uecepk0M0=; b=YySWA42+VfKAYvDgI+jHCUJtFGC53ksgi0EYNL1C2lUDQhiuUCh7Dg46/0L1Gqmi5D Hgic+4/BbQvXuCOTNtFjwCVk77FY1jMq9OiL5q3wxA5aIrazU8XQsXPSJqFkZzXzD48M WcIqME8DHQ0QIkkVbeFKBuyHAbJRqHzW0SrU4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=laM6IOzg0/2ubU4d70ath8zTDch2tBhwN0Uecepk0M0=; b=col1y3W8162ovzrcbNUU2nkQmP72QvsbjnpmHrX2K6p69qYt2VYc42a0D3NMTtLD1a +x5trZJAa5/Lv8Eoi+ALdtedwhqkko7b6tbUXF+30YwALxvtvWnIKWMcsSBsZrhAe+Kb x7beuXqaiDNTzkQqEaOUzCAk9ixWoWaCGDMv+0J/Wk+XofdUpkvQRwQO6sjbZoD0O+bS PHJGp2DQIMiOr3Vb+3wz36SiVDB7xdnj5GSVEJALrl2bCnqqpF1Yy2+IvvW2LlwePdMt T18aC77ZOGKsTgI5aXp8lnGl+wF4V0ZofDW4Bucu/SmQSXU3Y939SL/F0T5/Qb8+Xu7P YK3Q==
X-Gm-Message-State: AE9vXwM1Bcaz7+SHG6xbyFLbXq5Fw+iz+TFLkWMjnA9yn5sxPFOybOlVFndtgZdAvGgcR8qWU4GNxE6ASC9i1vfa
X-Received: by with SMTP id x65mr24581240itf.54.1473086947018; Mon, 05 Sep 2016 07:49:07 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Mon, 05 Sep 2016 14:48:55 +0000
Message-ID: <>
To: Hubert Kario <>,
Content-Type: multipart/alternative; boundary=94eb2c05bce833915d053bc3c831
Archived-At: <>
Subject: Re: [TLS] draft-davidben-tls-grease-01
X-Mailman-Version: 2.1.17
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: Mon, 05 Sep 2016 14:49:10 -0000

On Mon, Sep 5, 2016 at 7:07 AM Hubert Kario <> wrote:

> On Friday, 2 September 2016 18:53:45 CEST David Benjamin wrote:
> > I've finally gotten to uploading
> > which hopefully
> > resolves the procedural issues (thanks again!). I've also revised the
> text
> > slightly after some off-list feedback about the risks of
> non-deterministic
> > failures.
>    Clients SHOULD balance diversity in GREASE advertisements with
>    determinism.  For example, a client which randomly varies GREASE
>    value positions for each connection may only fail against a broken
>    server with some probability.  This risks the failure being masked by
>    automatic retries.  A client which positions GREASE values
>    deterministically over a period of time (such as a single software
>    release) stresses fewer cases but is more likely to detect bugs from
>    those cases.
> How about adding "In particular, it is RECOMMENDED that for a given
> browsing
> session, used GREASE values for a given server are constant."?

So, at least the naive way of doing that gives a blatant tracking vector,
which is pretty bad. Hence the example of varying over software versions.
We already assume those are distinguishable because everyone offers
different things and we keep tweaking them. (Apart from clients which try
to mimic other software's ClientHello, but those weren't going to play this
game anyway.)

I guess this is an obvious thing to toss into security considerations. Will
add it to the next iteration.

I think it's actually fine to vary the values per connection. I want it to
be immediately obvious that ClientHellos are allowed to vary so do not
special-case the one GREASE value we picked. This was meant to be a
replacement for the old text. I'd previously envisioned going at the front
or back with 50% probability which I'm not sure would work well?

I dunno. One can just freely toy around with dumb ideas and see what works.
:-) Spec-wise, the only thing of substance in this document is burning a
bunch of values.

>    Clients MUST reject GREASE values when negotiated by the server.
>    When processing a ServerHello containing a GREASE value in the
>    ServerHello.cipher_suite or ServerHello.extensions fields, the client
>    MUST fail the connection.  When processing an ECParameters structure
>    with a GREASE value in the ECParameter.namedcurve field, the client
>    MUST fail the connection.
>    Note that this requires no special processing on the client.  Clients
>    are already required to reject unknown values selected by the server.
> Don't the other RFCs just say that clients should reject values not
> advertised
> by client? Since GREASE values are advertised by clients, I don't think the
> "no special processing" applies. As such, handling how connections in which
> server selects GREASE values should be specified precisely.
> (I haven't checked the RFCs for that so I may be mistaken, but still is a
> bit
> dicey to say that programmers don't need to check error handling in their
> code...)

Right. That's why this one says "no special processing" rather than
"restatements or corollaries of existing [client] requirements" as in the
server section. In the implementation I've tossed together, this never
makes it into the list of values the client believes it has advertised. The
serialization code just adds some u16s without remembering them anywhere.
As a result, all the existing logic works just fine.