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

From: John Mattsson <[email-masked]>
Date: Fri, 20 Jul 2018 19:52:00 +0000

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Jul 2018 13:02:19 -0700

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 <[email-masked]>
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).
>
> - One thing that could be discussed is integrity protection of the
> client’s ephemeral public key. The current construction
>
> 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:
>

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.
>

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 Jul 2018 18:00:53 +0300

> 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