On Fri, Jul 20, 2018 at 01:02:19PM -0700, Eric Rescorla wrote: > On Fri, Jul 20, 2018 at 12:52 PM, John Mattsson <john.matts...@ericsson.com> > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
