Great, thanks both
S On 01/09/2021 19:04, Christopher Patton wrote:
Yup, that was my interpretation as well. On Wed, Sep 1, 2021 at 10:14 AM David Benjamin <david...@chromium.org> wrote:That's right. The AAD and actual CH should be exactly the same, apart from the payload being zeroed in place. You don't need to reserialize the structure as a server, or serialize ClientHelloOuter twice as a client. On Wed, Sep 1, 2021 at 1:01 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:(Apologies for the acronym laden subject:-) I'm more or less at the "code complete" stage of implementing draft-13 incl. HRR. (If anyone wants to try interop, for now please contact me, but I should have a server up in a few days.) I'm sure as usual I'll have gotten some details wrong, but I wasn't clear about one thing: - When sending the 2nd CH following HRR, the spec calls for omitting the "enc" field of the ECH extension ("enc" holds the sender's public HPKE value that's re-used from the 1st CH). - The AAD for that ECH encryption is the outer CH with zeros replacing where the ciphertext will go. - I concluded that the sender's ECH public value (the "enc" field) ought not be present in the AAD in that case, as well as being omitted in the ECH value, but it wasn't entirely clear to me from the spec (and it'd work either way). So my question is: did I get that right or not? Thanks in advance, S. _______________________________________________ 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
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
