[TLS] A readthrough of draft-ietf-tls-esni

[Watson Ladd <[e-mail]>]

Based on the github version.

Comments are in order of spotting, not seriousness. I understand
Martin Thompson has a clever way to format these emails I have tried
to follow but with little success. This is almost all editorial nits.

# Introduction

I would reorder the 3 and 4th paragraphs, with appropriate
modifications. Currently what the draft does is buried pretty far
down, and I think pulling it up is better. YMMV.

# Overview

I think we can say a little bit more to prepare the reader for the
Topology section, happy to suggest text.

## Topologies

"These are the same entity in Shared Mode, but in Split Mode, the
client-facing and backend servers are physically separated." - I think
we want to say in Split Mode the client-facing and backend servers are
logically separated and may be physically separated. The concept of
server and physical is a very messy one.

## encrypted-client-hello

It might be worth saying the rational for including the empty
extension in ClientHelloInner. I think the payload field description
might need tweaking: Should it say "EncodedClientHelloInner " instead
of "ClientHelloInner"?

## encoding-inner

I find the last paragraph a bit confusing. Instead of "Implementations
SHOULD bound the time to compute a ClientHelloInner proportionally to
the ClientHelloOuter size.", can we be more explicit alnogn the lines
of "Implementations SHOULD construct the ClientHelloInner in linear
time. Quadratic time implementations (such as may happen via naive
copying) create a denial of service risk"

## authenticating-outer

Reader isn't prepared for this bit IMHO. More to follow.

## real-ech

Here I have my first more crosscutting issue. After
#authenticating-outer the reader might have an idea that AAD is going
to be used here with HPKE. There's a bunch of material here that could
be moved back to {{authenticating-outer}} to make this one flow better
and keep the flow of topics, and we might also want to say that the
ClientHelloOuter is going to be authenticated back in
{{encrypted-client hello}}.

## grease-psk

Should we use RFC 2119 language for the server as well? Right now we
only say what the client must do when the server violates the rules.

## padding

I found this section very confusing. On a casual read it's not clear
if the ClientHelloInner is having its extensions padded, or, as is
actually intended, we're adding to the size of EncodedClientHello
inner based on estimating the size of each extension. I think part of
this is due to my confusion about what we're trying to hide from whom.
A little more text can solve this

# server behavior.

I'm confused by this section, which seems to imply the client picks
what role the server plays, not the configuration of the server. This
text also plays badly with the shared-mode topology, where the same
server plays both roles. Yeah, I knew what was probably meant, but a
little bit of TLC can clear this up.

## client-facing server

Some uncapitalized RFC 2119 language

## misconfiguration

I think either here or in {{rejected-configs}} we need to say a little
bit more about the way servers are supposed to do rollouts. In
particular the retry configuration needs to be supported on all
servers where the connection might hit, so it's not the most recent
that the server has.

# Security considerations
## goals

I think we should have a doc about split mode security or some
indication about how to set this up. Otherwise it won't work. Not
saying this RFC should be it, but without something no one will be
able to get interoperability.

For a very complex protocol that's taken quite some years to develop
this document is in pretty good shape.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim