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
