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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
