Re: [dns-privacy] next steps for draft-opportunistic-adotq

[Stephen Farrell <[e-mail]>]

Hiya,

I think that makes sense with one caveat: I don't interpret
these changes as representing a consensus to not use TLSA - I
think such a decision is still down the road some, after we
have some better ideas as to the practicality or otherwise
of the various approaches one might adopt.

I know none of these are WG drafts yet but I'd be a bit
worried that your changing to use SVCB now might be
intrepreted in that way.

Cheers,
S.

On 22/03/2021 20:26, Peter van Dijk wrote:
> Hello DPRIVE,
> 
> First, a recap of my IETF110 presentation for those who missed it. I
> explained that the recent version of our opportunistic/unauthenticated
> draft (draft-ietf-dprive-opportunistic-adotq-01) included a rough
> skeleton of support for an authenticated use case, because no other
> proposal for that was alive at the time. Shortly after, another draft
> (draft-rescorla-dprive-adox-latest-00) describing an authenticated
> approach appeared. I suggested in my presentation that we take
> authentication out of our draft so that the two use cases (being
> 'unauthenticated' and 'authenticated') can progress side by side.
> 
> draft-rescorla-dprive-adox-latest-00 proposes SVCB as a discovery
> mechanism instead of our TLSA, and this sounds good to us. The
> unauthenticated use case only needs discovery, so SVCB appears to be an
> even better fit than TLSA. SVCB also provides more protocol
> flexibility.
> 
> Our proposal for a way forward:
> 
> * We take authentication out of draft-ietf-dprive-opportunistic-adotq
> again.
> * We give the draft a somewhat more accurate name, as the switch to
> SVCB stops us being limited to DoT and DoQ (although I really do wonder
> if there is any appetite for DoH on the recursive<>auth path).
> * We let the drafts develop side by side, making sure they use similar
> wording where appropriate, and don't get in each other's way.
> 
> Cheers, Paul&Peter
> 
> 
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>