Re: [OPSAWG] RADIUS Extensions for Encrypted DNS
Hi Alan, Thank you the feedback. Much appreciated. Please see inline. Cheers, Med > -Message d'origine- > De : Alan DeKok [mailto:al...@deployingradius.com] > Envoyé : vendredi 4 juin 2021 15:00 > À : BOUCADAIR Mohamed INNOV/NET > Cc : Stefan Winter ; opsawg@ietf.org > Objet : Re: RADIUS Extensions for Encrypted DNS > > On Jun 4, 2021, at 8:13 AM, mohamed.boucad...@orange.com wrote: > > (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://datatracker.ietf.org/doc/draft-boucadair-opsawg-add- > encrypted-dns/ > > 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". [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. > > But overall, I think it's a good approach. [Med] Thank you. > > Alan DeKok. > _ 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] RADIUS Extensions for Encrypted DNS
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: On Jun 4, 2021, at 8:13 AM, mohamed.boucad...@orange.com wrote: (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://datatracker.ietf.org/doc/draft-boucadair-opsawg-add-encrypted-dns/ 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg OpenPGP_signature Description: OpenPGP digital signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] RADIUS Extensions for Encrypted DNS
On Jun 4, 2021, at 8:13 AM, mohamed.boucad...@orange.com wrote: > (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://datatracker.ietf.org/doc/draft-boucadair-opsawg-add-encrypted-dns/ 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] RADIUS Extensions for Encrypted DNS
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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
