Re: [TLS] draft-ietf-tls-esni feedback

[Ilari Liusvaara <[e-mail]>]

On Tue, Oct 22, 2019 at 10:39:24PM -0700, Watson Ladd wrote:
> 
> At the same time Client Hello sizes aren't constrained to be tiny, but
> the next problem of 1280 bytes is not that far off either. So we
> should be judicious in spending those bytes.

I do not think 1280 bytes is a big issue.

- If using QUIC, one expects fragmentation above 1200 bytes. I am not
  sure if fragmentation is presently allowed, but I am sure it is not
  pleasant to implement in robust way.
- For classical TLS over TCP, in practice one can push something like
  1400 octets or so in a single packet over virtually all paths.
- Present handshake sizes are AFAIK bit north of 256 bytes (still
  mostly padded to 512 to avoid old TLS server bugs). So sticking even
  350 bytes (256 for name plus 80 bytes crypto overhead plus few odd
  other bytes) extra would not blow any soft limits.
- With post-quantum, you are going to bust single packet limits no
  matter what, since:
  - SIKE is slow, so server operators probably prefer lattices as
    those are like two orders of magnitude faster than SIKE (or SIDH).
  - Lattices are roughly 800 bytes at minimum at reasonable security
    levels.
  - You are going to need two keys, because all the post-quantum
    ways of sharing one key are both even slower and more exciting
    (not in a good way) than anything in NISTPQC.


-Ilari