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 <[email protected]> on behalf of Christopher Wood <[email protected]> Sent: Wednesday, August 10, 2022 7:37:44 PM To: Ravi sankar MANTHA <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [dns-privacy] ODoH RFC SetupBaseS clarification EXTERNAL MAIL: [email protected] 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 > <[email protected]> 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&data=05%7C01%7Cr.mantha%40f5.com%7Ce46a7d20f78b46d3903108da7ad9d08b%7Cdd3dfd2f6a3b40d19be0bf8327d81c50%7C0%7C0%7C637957373465832299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=HlytaAnSlUzFAFxseZF5dxZlax1VZ1gQCgdY4shqu3w%3D&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 > [email protected] > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdns-privacy&data=05%7C01%7Cr.mantha%40f5.com%7Ce46a7d20f78b46d3903108da7ad9d08b%7Cdd3dfd2f6a3b40d19be0bf8327d81c50%7C0%7C0%7C637957373465832299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=lb%2Fh7id%2BLLZ5O18lD2nAyp8XpiytzbC1ak9WEupgEN0%3D&reserved=0 _______________________________________________ dns-privacy mailing list [email protected] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdns-privacy&data=05%7C01%7Cr.mantha%40f5.com%7Ce46a7d20f78b46d3903108da7ad9d08b%7Cdd3dfd2f6a3b40d19be0bf8327d81c50%7C0%7C0%7C637957373465832299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=lb%2Fh7id%2BLLZ5O18lD2nAyp8XpiytzbC1ak9WEupgEN0%3D&reserved=0
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
