Draft: draft-ietf-tls-esni

Commentary: Addresses . A given ECHOConfig now lists a single HPKE public key , with the corresponding KEM identifier , and a list of acceptable AEAD and KDF algorithm identifiers . Clients may then choose their preferred AEAD and KDF algorithms for ClientHello encryption . We may need to provide some guidance , either here or in the HPKE document , about acceptable ( KEM , KDF , AEAD ) tuples . cc 
 I had n't realized these were separate IDs . Oh well . 
 HpkeCipherSuite should also be used in ClientEncryptedCH . 
 Oops -- thanks , Fixed here : 
 HPKE has it 's own cipher suite code points , as well as the KEM i d. I do n't see why we 're using TLS codepoints ( and ) and yet also use one HPKE code point ( ) . But maybe I 'm missing something ? If not , I think one of two things would make sense : HPKE to use TLS code points . ( That could be done but'd involve a bit of nose - holding , however it might be better in the longer term . ) use HPKE code points in ECHO - I do n't see that TLS ciphersuites are actually needed for ECHO , so this seems easiest . ( That 'd mean s / suite / aeadid / g I guess . ) 
 I tend to agree with Stephen here . ISTM that probably ( 1 ) is better , actually . 
 I do n't think we want HPKE to depend on TLS code points . Algorithms that come down the pipe may not be suitable for TLS . I 'd prefer option ( 2 ) . 
 There 's also a third option here : TLS code points ( or something else ) and define a mapping to HPKE code points Like I am disinclined to tie HPKE to TLS , since it is a more general tool . It seems like the answer here depends on what the negotiation in ECHO is being used for . If it 's just for the HPKE , use HPKE code points . If it 's used in TLS further down the line , use TLS code points and map to HPKE for the HPKE bits . 
 How is ( 3 ) different than the current design ? 
 Per the call today , we 'll use this issue to track moving everything to HPKE codepoints . ( We can remove the mapping table at the same time ) .
Paragraph (version A):
The list of TLS cipher suites which can be used by the client to
encrypt the ClientHello.  See hpke-map for information on how a
cipher suite maps to corresponding HPKE algorithm identifiers.
Paragraph (version B):
The list of HPKE I-D.irtf-cfrg-hpke AEAD and KDF identifier pairs
clients can use for encrypting the ClientHello.
Paragraph (version A):
Note that the HPKE algorithm identifiers are those which match the
client's chosen CipherSuite, according to hpke-map.  The client MAY
replace any large, duplicated extensions in ClientHelloInner with the
corresponding "outer_extensions" extension, as described in outer-
extensions.
Paragraph (version B):
Note that the HPKE algorithm identifiers are those which match the
client's chosen preference from ECHOConfig.cipher_suites.  The client
MAY replace any large, duplicated extensions in ClientHelloInner with
the corresponding "outer_extensions" extension, as described in
outer-extensions.
Paragraph (version A):
Per RFC8446, TLS ciphersuites define an AEAD and hash algorithm.  In
contrast, HPKE defines separate AEAD algorithms and key derivation
functions.  The table below lists the mapping between ciphersuites
and HPKE identifiers.  TLS_AES_128_CCM_SHA256 and
TLS_AES_128_CCM_8_SHA256 are not supported ECHO ciphersuites as they
have no HPKE equivalent.