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
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
