Subject: [TLS] GREASE and TLS 1.3

From: David Benjamin <[email-masked]>
Date: Wed, 18 Jan 2017 22:49:17 +0000

So, having uploaded draft-ietf-tls-grease-00, I would now like to rewrite
large chunks of it. The draft is currently defined for TLS 1.2, but it
probably makes sense to order it after TLS 1.3.

TLS 1.3 also adds a many new extension points, and we can expect new TLS
1.3 implementations popping up in the near future, so having the ecosystem
primed against intolerance bugs would be great.

(As a happy anecdote, Chrome is currently GREASEing bits of its draft TLS
1.3 implementation. This worked beautifully. There was a draft TLS 1.3
server implementation that broke on unknown versions in supported_versions
and unknown groups in key_shares. Interop testing against a normal client
did not notice. When they tried interop testing against Chrome, the bugs
were caught and fixed.)

I was thinking of making the following changes:

- Cite TLS 1.3 instead of TLS 1.2.

- Add some text to use the same code point pattern for TLS 1.3
signature_algorithms.

- Add some text to suggest advertising GREASE values in key_shares if
advertised in supported_groups. [This already caught a bug.]

- Add some text to use the same code point pattern for
supported_versions. [This already caught a bug.]

- Generalize the extensions text to allow for CertificateRequest and
NewSessionTicket extensions sent by the server. [This might have caught a
bug had it not been caught by other means first.]

Do people agree with this plan?

I've left out psk_key_exchange_modes. It would be nice to GREASE that too,
but it uses u8 rather than u16 values. The natural generalization is to
reserve 0x?a instead of 0x?a?a. But then we lose 16 out of 256 code points,
rather than 16 out of 65536 code points. Do people feel this is an
acceptable tradeoff? Perhaps a smaller pattern? Or is this not worth
bothering with?

David

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 19 Jan 2017 10:04:52 +0900 (JST)

Hi David,

> Do people agree with this plan?

I agree.

Should we also add grease values for key_share?

--Kazu

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Jan 2017 14:15:32 +1300

> Should we also add grease values for key_share?

supported_groups code points should cover that, but if you are asking
if we should spend bytes on sending shares for bogus groups, that's a
question I don't have an opinion on.  I guess that you *could*, but
whether the document should recommend it ....

---

From: David Benjamin <[email-masked]>
Date: Thu, 19 Jan 2017 01:24:33 +0000

On Wed, Jan 18, 2017 at 8:15 PM Martin Thomson <[email-masked]>
wrote:

That's what we do in Chrome/BoringSSL. We send one fake NamedGroup at the
front of supported_groups and then put it in key_shares with a one-byte
fake KeyShareEntry.

It costs five bytes total and, having already caught a bug with it, seems
valuable. It ensures that servers are capable of skipping over an unknown
KeyShareEntry and don't just go for the first one. But, document-wise, I
was expecting to just use MAY for everything rather than expressing much
opinion.

(Front is because presumably if we add a new NamedGroup, it'd be because we
like it more than our current ones rather than less! So it's more important
that that edge continue working.)

David

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 19 Jan 2017 12:00:31 +0900 (JST)

> was expecting to just use MAY for everything rather than expressing much

OK.

--Kazu

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 19 Jan 2017 13:31:31 -0600

> Do people agree with this plan?

Yes :)

> I've left out psk_key_exchange_modes. It would be nice to GREASE that
> too, but it uses u8 rather than u16 values. The natural generalization
> is to reserve 0x?a instead of 0x?a?a. But then we lose 16 out of 256
> code points, rather than 16 out of 65536 code points. Do people feel
> this is an acceptable tradeoff? Perhaps a smaller pattern? Or is this
> not worth bothering with?
>

I feel like we're unlikely to come up with enough modes that we run out
of space, so it is probably okay to grease it.  But I would be okay if
people wanted to not do so, too.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Jan 2017 11:34:43 -0800

Grease away.

On Thu, Jan 19, 2017 at 11:31 AM, Benjamin Kaduk <[email-masked]> wrote:

> I feel like we're unlikely to come up with enough modes that we run out of
> space, so it is probably okay to grease it.  But I would be okay if people
> wanted to not do so, too.
>
> -Ben
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Hubert Kario <[email-masked]>
Date: Wed, 25 Jan 2017 13:49:25 +0100

> people wanted to not do so, too.

+1 to greasing psk_key_exchange_modes

-- 
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: Sean Turner <[email-masked]>
Date: Thu, 26 Jan 2017 15:15:09 -0500

> On Jan 18, 2017, at 17:49, David Benjamin <[email-masked]> wrote:
> 

Looks like we got general agreement this is a good approach to follow.

spt