Re: [TLS] Some comments on draft-rescorla-tls-esni-00

[Ilari Liusvaara <[e-mail]>]

On Fri, Jul 20, 2018 at 01:02:19PM -0700, Eric Rescorla wrote:

> On Fri, Jul 20, 2018 at 12:52 PM, John Mattsson <[e-mail]>
> wrote:
> 
> > encrypted_sni = AEAD-Encrypt(key, iv, KeyShareClientHello,
> > PaddedServerNameList)
> >
> > Unless it causes problems of some kind, I would recommend doing that.
> >
> 
> Thanks. This seems like a good plan. Would an acceptable alternative be to
> hash the KeyShare into the key?

Might also consider hashing in the server side public key and group
identification.

Also, one might consider post-quantum already. Even if the algorithms
are not known, the characteristics of the algorithms are: The client
key share is not useful to derive the shared secret (because client
key share is client's public key), and furthermore none of the algorithms
client key shares use might be useful, because they all might only
be secure for one use, where SNI encryption needs security with many
uses (whereas key exchange only needs to be secure for one use[2]).

That one can reuse the key shares for both purposes only works with
Diffie-Hellman type schemes. The ones similar enough that are known
for PQC are of quite uncertain security and very slow.


Also, the document says:

"Note that the length of this structure MUST NOT exceed 2^16 - 1, as
the RDLENGTH is only 16 bits [RFC1035]."

Actually, you get trouble before that point:

- 48,960 byte ESNI keys structure would blow the DNS RDLENGTH field
  due to BASE64 and TXT overheads (binary data in TXT record is a bad
  idea, even if in theory it would work).
- About 48750 byte or thereabouts total ESNI keyset could blow DNS
  maximum message size, which just breaks DNS, with no recovery
  possible[1]. No sharp limit can be given due to precise limit
  depending on the domain.


Also, searching if there is some pre-emptive answer in the document
as to why it uses TXT as opposed to new RRTYPE, I found the following:

"Clients SHOULD not fall back to cleartext SNI,"

I presume "SHOULD not" should be "SHOULD NOT".



[1] Many DNS implementations probably treat exceeding maximum DNS
message size as Undefined Behavior: They assume it never happens,
and if it happens, the consequences can be anything. And these
implementations can internally add stuff, and assume this added
stuff will fit.

[2] The one-use schemes tend to be much more efficient even with
key generation for each connection included. And one can not eliminate
that many key generations even for use-multiple algorithms, because
reusing a key across SNI values is insecure.


-Ilari