Subject: [OPSAWG] RADIUS Extensions for Encrypted DNS

From: <[email-masked]>
Date: Fri, 4 Jun 2021 12:13:49 +0000

Hi Alan, Stefan, all,

(sending the message to opsawg as I understood that radext is dormant and related matters should be here)

We published this new draft as a companion document to some of the work we are doing in ADD WG about discovery/provisioning of encrypted DNS servers (DNS over TLS, DNS over HTTP, etc.): https://datatracker.ietf.org/doc/draft-boucadair-opsawg-add-encrypted-dns/

Your comments and suggestions are more than welcome.

Thank you.

Cheers,
Med

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 4 Jun 2021 09:00:20 -0400

> (sending the message to opsawg as I understood that radext is dormant and related matters should be here)

  Officially alive, but in limbo.

> We published this new draft as a companion document to some of the work we are doing in ADD WG about discovery/provisioning of encrypted DNS servers (DNS over TLS, DNS over HTTP, etc.): https://dat…

  On quick inspection it looks reasonable.

  The one thing I noted was Encrypted-DNS-ADN TLV, which is in the DNS "compressed label" format.  Pretty much every other DNS name in RADIUS is in string format, not the compressed label.  I understand why it's done that way, but it should be called out a little more clearly, I think.  "note, this is not a humanly readable DNS name".

  The Encrypted-DNS names can be a little misleading.  It might be worth reiterating that these attributes are not encrypted as with User-Password or Tunnel-Password.

  It's not that the text is wrong, it's that I've seen too many implementors do the "obvious" thing, and not what the draft says.  So it's worth talking about the "obvious" thing, and explaining why it's wrong.

  But overall, I think it's a good approach.

  Alan DeKok.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 4 Jun 2021 15:16:53 +0200

I don't think this is the right approach.  I would rather see the 
information provided in an EAP method, so that DHCP can be removed 
entirely from the equation.  Otherwise we have multiple, disparate, 
security models in play to trust the information.

Eliot

On 04.06.21 15:00, Alan DeKok wrote:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 4 Jun 2021 10:04:37 -0400

On Jun 4, 2021, at 9:16 AM, Eliot Lear <[email-masked]> wrote:
> 
> I don't think this is the right approach.  I would rather see the information provided in an EAP method, so that DHCP can be removed entirely from the equation.  Otherwise we have multiple, disparate, security models in play to trust the information.

  I agree.  But...

*  We already have DHCP options encoded in RADIUS.  Adding one more isn't terrible

* reving EAP is likely hard, as compared to adding a few more RADIUS attributes

* Then there's RFC 5505, and lower-layer independence https://datatracker.ietf.org/doc/html/rfc5505#section-2.4

  i.e. tying multiple layers together is officially frowned upon by the IAB.

  Alan DeKok.

---

From: <[email-masked]>
Date: Tue, 8 Jun 2021 12:36:19 +0000

Hi Alan, 

Thank you the feedback. Much appreciated. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Alan DeKok [mailto:[email-masked]]
> Envoyé : vendredi 4 juin 2021 15:00
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> Cc : Stefan Winter <[email-masked]>; [email-masked]
> Objet : Re: RADIUS Extensions for Encrypted DNS
> 
> > (sending the message to opsawg as I understood that radext is
> dormant and related matters should be here)
> 
> > We published this new draft as a companion document to some of the
> work we are doing in ADD WG about discovery/provisioning of
> encrypted DNS servers (DNS over TLS, DNS over HTTP, etc.):
> https://datatracker.ietf.org/doc/draft-boucadair-opsawg-add-
> encrypted-dns/
> 
>   The one thing I noted was Encrypted-DNS-ADN TLV, which is in the
> DNS "compressed label" format.  Pretty much every other DNS name in
> RADIUS is in string format, not the compressed label.  I understand
> why it's done that way, but it should be called out a little more
> clearly, I think.  "note, this is not a humanly readable DNS name".

[Med] Actually, the compressed form must not be used. This is to align with how things are done for the corresponding DHCP options in particular. 

> 
>   The Encrypted-DNS names can be a little misleading.  It might be
> worth reiterating that these attributes are not encrypted as with
> User-Password or Tunnel-Password.

[Med] Good point. Fixed now in https://datatracker.ietf.org/doc/html/draft-boucadair-opsawg-add-encrypted-dns-01 

NEW:

   The value field of *-Encrypted-DNS and Encrypted-DNS-* Attributes is
   encoded in clear and not encrypted as, for example, Tunnel-Password
   Attribute [RFC2868].

> 
>   It's not that the text is wrong, it's that I've seen too many
> implementors do the "obvious" thing, and not what the draft says.
> So it's worth talking about the "obvious" thing, and explaining why
> it's wrong.
> 

[Med] Thank you.