Re: [dns-privacy] Authentication in draft-ietf-dprive-opportunistic-adotq

[Paul Wouters <[e-mail]>]

On Feb 16, 2021, at 10:23, Ben Schwartz <bemasc=[e-mail]> wrote:
> 
> 
> I don't see why there would be a conflict between draft-ietf-dprive-opportunistic-adotq and any future authenticated encryption RFC that we produce, so I don't see the need to impose a drastic dividing line (e.g. different port numbers).

I explained that in my previous message. Opportunistic normally is “do encryption, then you may omit authentication if that is too hard”. Opportunistic is not “try this technology and maybe in the future try this completely other technology”.  

> Here's a counter-proposal:
> 1. Mark draft-ietf-dprive-opportunistic-adotq "experimental".  This is in line with previous work on opportunistic encryption, e.g. RFC 8164, and accurately reflects the draft's status as both speculative and (hopefully) transitional.
> 2. Replace Section 5 with the following language:
> 
> There is currently no defined mechanism for authenticated ADoT, so resolvers MUST NOT authenticate the server except by private agreement with the server operator.

That makes using a LetsEncrypt certificate violate the RFC’s MUST NOT. I strongly object to this as now you are actively weakening security.


>   Server operators SHOULD use self-signed certificates to avoid implying an authentication mechanism that might conflict with a future ADoT authentication standard.

Same here.

> As I've said before, I _do_ think this draft is valuable and presents a worthwhile public experiment that will pave the way for authenticated ADoT.  For DNS services that are used to DNS over UDP, running DNS over TLS is a big, scary project.  This draft can provide a way to get some practice with that in a low-risk setting, where TLS-related failures are not significantly user-visible.

The “big scary” part of using TLS is in the transport that is common for authenticated and unauthenticated TLS. And as I’ve said before, at this point in time generating a selfsigned cert is harder than getting a validated ACME certificate.


>   Once operators are comfortable with DNS over TLS, I think it will be a lot easier to start rolling out some real authentication.

I strongly disagree, please reread my previous message that describes how these solutions are identical except for how or if the authenticate the incoming certificate payload.

Paul


> 
> On Mon, Feb 15, 2021 at 5:25 PM Paul Hoffman <[e-mail]> wrote:
>> Greetings again. One of the issues that seems to most bother people who don't like the idea of opportunistic ADoT(Q) is the handwaviness of "but authenticate if you can". That comes from RFC 7435, which is the informational RFC that defines opportunistic security (OS). To quote from section 1.2 of that document:
>>    To achieve widespread adoption, OS must support incremental
>>    deployment.  Incremental deployment implies that security
>>    capabilities will vary from peer to peer, perhaps for a very long
>>    time.  OS protocols will attempt to establish encrypted communication
>>    whenever both parties are capable of such, and authenticated
>>    communication if that is also possible.  Thus, use of an OS protocol
>>    may yield communication that is authenticated and encrypted,
>>    unauthenticated but encrypted, or cleartext.  This last outcome will
>>    occur if not all parties to a communication support encryption (or if
>>    an active attack makes it appear that this is the case).
>> 
>> So far, the proposals for opportunistic ADoT(Q) in this WG have followed that by talking about authentication, but so far no one has given a reason to require authenticated transport given the presence of DNSSEC in the DNS protocol. There have been comments on the list (but without any supporting Internet Drafts) that some resolvers might want to only serve answers that they got in a fully authenticated fashion, and those same people objected to the consideration of opportunistic ADoT(Q) because it would make the possible later definition of a fully-authenticated protocol more difficult.
>> 
>> I propose a way forward: make the two protocols obviously different so that they don't affect each other. For those who want opportunistic ADoT(Q), change the current design so that deploying it would not make creating and deploying a fully-authenticated protocol more difficult; for those who want a fully-authenticated protocol, design it so that it does not make designing and deploying opportunistic ADoT(Q) more difficult.
>> 
>> Does this sound like a good approach going forward. It gives those supporting fully-authenticated protocol as much time as they need to come up with a working protocol design, without stopping progress on the proposal that has already gotten a fair amount of support in the WG.
>> 
>> --Paul Hoffman_______________________________________________
>> dns-privacy mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dns-privacy
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy