Subject: Re: [TLS] Keeping TLS extension points working

From: David Benjamin <[email-masked]>
Date: Fri, 02 Sep 2016 18:53:45 +0000

I've finally gotten to uploading
https://tools.ietf.org/html/draft-davidben-tls-grease-01 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.

I didn't add text about what middleboxes are allowed to do since I wasn't
sure what text would be useful. Looking at all the changes we've done in
TLS 1.3, they can do is syntax-check the ClientHello. Anything beyond that
we've been considering fair game to change. TLS 1.3's ServerHello is not
compatible with TLS 1.2's ServerHello. The first message may even not be
ServerHello and instead HelloRetryRequest.

David

On Wed, Jul 27, 2016 at 4:02 PM Sean Turner <[email-masked]> wrote:

>
> > On Jul 26, 2016, at 11:11, David Benjamin <[email-masked]> wrote:
> >
> > 1) “Updates: 5246 (if approved)” because typically extension documents
> don’t “update” the base specification.  If you are suggesting that all
> implementations must support these values then an updates header makes
> sense.  Note I’m sure somewhere along the way an extension that isn’t
> expected to be supported by all implementation has an updates header but
> what I described is how we’re doing it now.
> >
> > I wasn't sure and mimicked RFC 7507 and RFC 7685 which both did this.
> >
> > I expect that all servers will "support" this specification in so far as
> it says nothing useful for servers. TLS servers are supposed to ignore
> unknown values. I would certainly like for as many clients to do it as
> possible so the ecosystem effects work out, but I certainly don't intend
> for it to be any kind of requirement. (I suppose the text says MAY so
> existing clients also "support" it by default.)
> >
> > Is it better to remove that line in this case? Happy to do whatever
> works.
>
> I’d probably lean towards removing it.
>
> spt

---

From: Hubert Kario <[email-masked]>
Date: Mon, 05 Sep 2016 13:07:40 +0200

> slightly after some off-list feedback about the risks of non-deterministic

   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."?

   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...)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: David Benjamin <[email-masked]>
Date: Mon, 05 Sep 2016 14:48:55 +0000

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

> dicey to say that programmers don't need to check error handling in their

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.

David

---

From: Hubert Kario <[email-masked]>
Date: Mon, 05 Sep 2016 16:59:23 +0200

On Monday, 5 September 2016 14:48:55 CEST David Benjamin wrote:
> > > resolves the procedural issues (thanks again!). I've also revised the

> As a result, all the existing logic works just fine.

On the other hand, the implementation I work on keeps the sent Client Hello on 
hand and checks the server response against the exact values it sent.

So for it, server selecting GREASE value would be fine, it would fail at key 
exchange processing time.

Keeping the Client Hello in case server asks for certificate verification is 
not entirely unheard of either.

So I think it's best to keep the specification implementation agnostic, 
without any assumptions about how the code is written, and describe just the 
externally visible behaviour. But describe it fully.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: David Benjamin <[email-masked]>
Date: Mon, 05 Sep 2016 15:55:49 +0000

On Mon, Sep 5, 2016 at 10:59 AM Hubert Kario <[email-masked]> wrote:

> > > (I haven't checked the RFCs for that so I may be mistaken, but still
> is a
> > > bit

The document does that, no? Or are you simply asking that I remove the "no
special processing sentence. Happy to do that.

(I'm assuming your implementation then handles the renegotiate_info SCSV
and FALLBACK_SCSV similarly special? It's the same story with those two.)

David

---

From: Hubert Kario <[email-masked]>
Date: Mon, 05 Sep 2016 18:09:08 +0200

> and FALLBACK_SCSV similarly special? It's the same story with those two.)

yes, it handles them specially, but that's actually by a happy coincidence: 
client needs to verify that the ciphersuite can be negotiated with a TLS 
version selected by server and you can't negotiate those two ciphers with any 
version (in other words, this is a result of self-consistency check on server 
hello, not explicit check against them)