[DNSOP] Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

[Jessica Krynitsky <[e-mail]>]

Hi Tiru,

I agree, and the need to be able to enforce an organizational hierarchy was one of our early requirements as well. Our thinking was that with mTLS, the organization could naturally use PKI to represent this structure (although I will not pretend that OAuth cannot do this too). With client certificates authenticating over TLS, these certs can represent a client device rather than a user identity, and this is largely up to the implementer/organization/network owner to decide the details. We viewed token-based auth as more strongly tied to user identities, and potentially a higher barrier to entry for small organizations which may already have PKI and associated policies.

Thanks!
Jess
________________________________
From: tirumal reddy <[e-mail]>
Sent: Tuesday, July 23, 2024 2:22:59 AM
To: Tommy Jensen <Jensen.Thomas=[e-mail]>
Cc: dnsop <[e-mail]>; Damick, Jeffrey <[e-mail]>; Jessica Krynitsky <[e-mail]>; Engskow, Matt <[e-mail]>
Subject: Re: [DNSOP] Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

You don't often get email from [e-mail]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
In enterprise networks, DNS services typically enforce policies at the organization and user-group levels, rather than at the individual user level. DNS filtering is generally not imposed based on individual user identities. It would be interesting to evaluate other possible solutions that could enforce security policies at the organization and user-group levels without revealing the end-user identities to the DNS service.

-Tiru

On Fri, 28 Jun 2024 at 00:12, Tommy Jensen <Jensen.Thomas=[e-mail]<mailto:[e-mail]>> wrote:
Hello dnsop,

Not to distract from the "should we deprecate DNS64" discussion I started after proposing updates to 7050, but this is the second draft (last one, I promise) I'll be proposing to this group as interesting work ahead of IETF 120. Joining me are co-authors Jessica from Microsoft and Jeff and Matt from Amazon.

In light of enterprises increasingly using encrypted DNS for their own "Protective DNS" resolvers, we are proposing best practices for when and how to use client authentication with encrypted DNS. Since this is a Good Thing for enterprises who control both peers (stronger security for client policy application and security auditing post-attack) and a Bad Thing otherwise (privacy violations for the non-enterprises cases common to consumers), we feel there is a need to specify when implementors should or should not use it.

Spoiler alert: we prefer mTLS as the ideal authentication mechanism. I'll let the draft speak for itself as to why. Feedback and discussion is welcome.

Thanks,
Tommy

________________________________
From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, June 27, 2024 11:32 AM
To: Jeffrey Damick <[e-mail]<mailto:[e-mail]>>; Jessica Krynitsky <[e-mail]<mailto:[e-mail]>>; Matt Engskow <[e-mail]<mailto:[e-mail]>>; Tommy Jensen <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

A new version of Internet-Draft draft-tjjk-cared-00.txt has been successfully
submitted by Tommy Jensen and posted to the
IETF repository.

Name:     draft-tjjk-cared
Revision: 00
Title:    Client Authentication Recommendations for Encrypted DNS
Date:     2024-06-27
Group:    Individual Submission
Pages:    11
URL:      https://www.ietf.org/archive/id/draft-tjjk-cared-00.txt
Status:   https://datatracker.ietf.org/doc/draft-tjjk-cared/
HTML:     https://www.ietf.org/archive/id/draft-tjjk-cared-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-tjjk-cared


Abstract:

   For privacy reasons, encrypted DNS clients need to be anonymous to
   their encrypted DNS servers to prevent third parties from correlating
   client DNS queries with other data for surveillance or data mining
   purposes.  However, there are cases where the client and server have
   a pre-existing relationship and each peer wants to prove its identity
   to the other.  For example, an encrypted DNS server may only wish to
   accept resolutions from encrypted DNS clients that are managed by the
   same enterprise.  This requires mutual authentication.

   This document defines when using client authentication with encrypted
   DNS is appropriate, the benefits and limitations of doing so, and the
   recommended authentication mechanism(s) when communicating with TLS-
   based encrypted DNS protocols.



The IETF Secretariat


_______________________________________________
DNSOP mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>