Subject: [TLS] ECHO padding review and some open issues

From: "Christopher Wood" <[email-masked]>
Date: Thu, 23 Apr 2020 16:30:25 -0700

In preparation for next week's virtual interim session on ECHO, I'd like to draw your attention to the following issues and PRs we'll be discussing. 

First, there's a PR up for padding [https://github.com/tlswg/draft-ietf-tls-esni/pull/209]. This PR describes a padding algorithm for clients that roughly works as follows. Clients compute the amount of ClientHelloInner padding based on padding for each inner CH extension. Some extensions might take server hints as input to this computation. In our case, we only have one such extension and hint: the SNI and ECHOConfig.max_name_len. Once done, round the total padding to the nearest 32B value. It also suggests that other handshake messages should be padded, yet elides details. (We previously didn't specify padding for anything beyond the CH message, so this isn't a change.)

Is this PR ready to go? If not, why not? What would you change, and why? (Concrete suggestions are highly encouraged!) Note also that this is currently only a recommended padding algorithm. Implementations are therefore free to do what they wish. Is this acceptable? Do we need to be more prescriptive? Food for thought!

After that PR, there's a pile of issues that need attention and discussion. Please have a look at the list below and comment on whether you think they're worth addressing. 

- ECHOConfigContents.extensions [https://github.com/tlswg/draft-ietf-tls-esni/issues/217]
- ECHOConfig vs HTTPSSVC [https://github.com/tlswg/draft-ietf-tls-esni/issues/219, https://github.com/tlswg/draft-ietf-tls-esni/issues/216]
- GREASE indistinguishability [https://github.com/tlswg/draft-ietf-tls-esni/issues/177]
- HPKE code points [https://github.com/tlswg/draft-ietf-tls-esni/issues/218]
- Tunnel TLS 1.2 and below [https://github.com/tlswg/draft-ietf-tls-esni/issues/214]

These are the last major outstanding issues against the document. I hope we can move forward after we resolve them, one way or another.

Thanks,
Chris (no hat)

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Apr 2020 00:37:57 +0100

Sorry - I have one more I wanted to raise as an issue. Will
do that tomorrow and send a mail,

Cheers,
S.

On 24/04/2020 00:30, Christopher Wood wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Apr 2020 16:35:10 +0100

Hiya,

> do that tomorrow and send a mail,

I've done that now. [1] We did have some list mails on this
earlier but it kinda tailed off rather than got resolved.

Cheers,
S.

[1] https://github.com/tlswg/draft-ietf-tls-esni/issues/223

---

From: Rob Sayre <[email-masked]>
Date: Fri, 24 Apr 2020 11:31:47 -0700

On Thu, Apr 23, 2020 at 4:31 PM Christopher Wood <[email-masked]>
wrote:

>
> Is this PR ready to go? If not, why not? What would you change, and why?
> (Concrete suggestions are highly encouraged!) Note also that this is
> currently only a recommended padding algorithm. Implementations are
> therefore free to do what they wish. Is this acceptable? Do we need to be
> more prescriptive? Food for thought!
>

It took me a while to notice that many of the padding debates aren't so
important if ECHO allows arbitrary structs/extensions in the encrypted
ClientHello. The recommendation is fine as a minimum, as long as servers
are tolerant of unknown extensions in the ciphertext.

thanks,
Rob