Re: [dns-privacy] ODoH RFC SetupBaseS clarification

[Ravi sankar MANTHA <[e-mail]>]

Hi chris,
Thanks. I see that HPKE RFC defines Encap to be a randomised algorithm to generate a ephemeral. Thats sufficient and rest as you said is upto implementation.

Thanks,
Ravi Mantha
________________________________
From: dns-privacy <[e-mail]> on behalf of Christopher Wood <[e-mail]>
Sent: Wednesday, August 10, 2022 7:37:44 PM
To: Ravi sankar MANTHA <r.mantha=[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [dns-privacy] ODoH RFC SetupBaseS clarification

EXTERNAL MAIL: [e-mail]

Hi Ravi,

Most implementations allow applications to provide a source of randomness (via, e.g., a rand.Reader-like interface) for the purposes of deriving the client’s ephemeral key share. As this is an implementation detail, neither the HPKE nor ODoH RFCs explicitly specify how randomness is provided, so I don’t any change is needed here. If an HPKE implementation is _not_ using randomness for generating an ephemeral key share, then it’s horribly broken.

Best,
Chris

> On Aug 10, 2022, at 5:09 AM, Ravi sankar MANTHA <r.mantha=[e-mail]> wrote:
>
>
> Hi,
>
> In Section 6.2 of RFC 9230, its mentioned that SetupBaseS takes only 2 parameters  (pkR, "odoh query")
>
> However, reference implementations are indeed using a randomiser from client side.
>
> enc, ctxI, err := hpke.SetupBaseS(suite, rand.Reader, pkR, []byte(ODOH_LABEL_QUERY))
> (https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcloudflare%2Fodoh-go%2Fblob%2F7c6d9ff448c53e0e546f2afe915ad9608e11f7bd%2Fodoh.go%23L471&amp;data=05%7C01%7Cr.mantha%40f5.com%7Ce46a7d20f78b46d3903108da7ad9d08b%7Cdd3dfd2f6a3b40d19be0bf8327d81c50%7C0%7C0%7C637957373465832299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=HlytaAnSlUzFAFxseZF5dxZlax1VZ1gQCgdY4shqu3w%3D&amp;reserved=0)
>
> This has an implication on target implementations,
>
> If Targets assume the randomizer is not present in shared secret derivation, then Context is unique for Target Public Key and they may choose not to store/derive it per message per Public Key.
>
> If random seed is present, then contexts are unique only per message (DSN Query).
>
> So, this has an interoperability impact as Encrypt/Decrypt fails for Query Responses if wrong shared key/Context is used on Target side.
>
>  IMHO, we might need to clarify this in RFC either by updating pseudocode for SetupBaseS or add a note that Target should derive shared secret/Context with every oblivious DNS query. Or its implicit somewhere in the RFC ?
>
> Regards,
>
> Ravi Mantha
>
>
>
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdns-privacy&amp;data=05%7C01%7Cr.mantha%40f5.com%7Ce46a7d20f78b46d3903108da7ad9d08b%7Cdd3dfd2f6a3b40d19be0bf8327d81c50%7C0%7C0%7C637957373465832299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=lb%2Fh7id%2BLLZ5O18lD2nAyp8XpiytzbC1ak9WEupgEN0%3D&amp;reserved=0

_______________________________________________
dns-privacy mailing list
[e-mail]
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdns-privacy&amp;data=05%7C01%7Cr.mantha%40f5.com%7Ce46a7d20f78b46d3903108da7ad9d08b%7Cdd3dfd2f6a3b40d19be0bf8327d81c50%7C0%7C0%7C637957373465832299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=lb%2Fh7id%2BLLZ5O18lD2nAyp8XpiytzbC1ak9WEupgEN0%3D&amp;reserved=0