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
