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, [email protected] 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
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg


Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to