Re: [TLS] Some comments on draft-rescorla-tls-esni-00
On Fri, Jul 20, 2018 at 01:02:19PM -0700, Eric Rescorla wrote: > On Fri, Jul 20, 2018 at 12:52 PM, John Mattsson > 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
Re: [TLS] Some comments on draft-rescorla-tls-esni-00
John, Thanks for your comments. It's good to know that someone has already done this! On Fri, Jul 20, 2018 at 12:52 PM, John Mattsson wrote: > Hi, > > I looked through the draft, mainly focusing on the crypto parts. This is > more or less ECIES, but with a more modern style of key derivation that > most existing standards. This solution is very similar to the standardized > 3GPP identity encryption (SUCI) with the difference that the static public > keys are distributed through DNS instead of UICCs (aka SIM cards). > > The current construction looks very good. > > - One thing that could be discussed is integrity protection of the > client’s ephemeral public key. The current construction > > encrypted_sni = AEAD-Encrypt(key, iv, "", PaddedServerNameList) > > does not achieve IND-CCA security (but only suffers from benign > malleability [1][2]). An addition of the client’s key share would make the > SNI encryption IND-CCA secure: > > 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? > - The hash algorithm used in “Hash(ClientHello.Random)” does not seem to > be stated. I assume that it is the hash function associated with "suite". Yes. > Also, is hashing the random value needed? > No, it's just a result of the slightly goofy HKDF-Expand-Label interface. -Ekr - A mistake ECIES implementations has done in the past is to let the > integrity key depend on the plaintext which breaks the security proof of > ECIES, but this is not the case here. > > Cheers, > John > > [1] http://www.secg.org/sec1-v2.pdf > [2] http://shoup.net/papers/iso-2_1.pdf > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Some comments on draft-rescorla-tls-esni-00
Hi, I looked through the draft, mainly focusing on the crypto parts. This is more or less ECIES, but with a more modern style of key derivation that most existing standards. This solution is very similar to the standardized 3GPP identity encryption (SUCI) with the difference that the static public keys are distributed through DNS instead of UICCs (aka SIM cards). The current construction looks very good. - One thing that could be discussed is integrity protection of the client’s ephemeral public key. The current construction encrypted_sni = AEAD-Encrypt(key, iv, "", PaddedServerNameList) does not achieve IND-CCA security (but only suffers from benign malleability [1][2]). An addition of the client’s key share would make the SNI encryption IND-CCA secure: encrypted_sni = AEAD-Encrypt(key, iv, KeyShareClientHello, PaddedServerNameList) Unless it causes problems of some kind, I would recommend doing that. - The hash algorithm used in “Hash(ClientHello.Random)” does not seem to be stated. I assume that it is the hash function associated with "suite". Also, is hashing the random value needed? - A mistake ECIES implementations has done in the past is to let the integrity key depend on the plaintext which breaks the security proof of ECIES, but this is not the case here. Cheers, John [1] http://www.secg.org/sec1-v2.pdf [2] http://shoup.net/papers/iso-2_1.pdf ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
