On Oct 30, 2020, at 9:11 AM, Paul Wouters <[email protected]> wrote:
> I still believe the cost of authenticating a DNS(SEC) server is so low
> these days (with ACME available at no cost and with full automation)
> that this draft is better not done.

The cost in terms of CPU cycles is indeed low. That is not the cost that is 
being considered when choosing opportunistic encryption. There is a real cost 
to the system if entire zones get server failures due to authentication 
mistakes made by the authoritative servers (not renewing certificates, errors 
in TLSA records, upstream validation problems that cause TLSA records not to 
validate, ...) or resolvers (dropping trust anchors that are in use, bad 
validation logic for TLSA, ...).

> One thing that stands out:
> 
> 
>       The recursive resolver MAY note the
>       authentication failure and act on it (such as by logging it or noting
>       it in the cache), as long as the failure does not prevent the TLS
>       session from completing.
> 
> I believe what is meant here is certificate validation (identity
> authentication) and not (session) authentication.

Arrrgh, you are absolutely correct here. I've even made this mistake before.

> For example, an attack
> modifying the TLS handshake parameters would lead to an authentication
> failure and such a failure MUST NOT be ignored.

Yep, and others. Will fix.

> The Transport Cache section should probably mention negative cache
> too.  That ia,s clarify that the cache is used not only positive TLS
> authentication information but also the lack there of.

Good catch, yes.

> I'm not sure why the AUTHINFO section was removed?

Because you complained that the protocol was too complicated, and I agreed.

--Paul Hoffman

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to