Hi Tatuya, Thank you for the follow-up. We submitted a new version to address your review: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-add-encrypted-dns-11. Please see inline for more context, fwiw. Cheers, Med > -----Message d'origine----- > De : JINMEI Tatuya / 神明達哉 <jinmei@xxxxxxxxxx> > Envoyé : samedi 11 mars 2023 06:51 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx> > Cc : int-dir@xxxxxxxx; draft-ietf-opsawg-add-encrypted- > dns.all@xxxxxxxx; last-call@xxxxxxxx; opsawg@xxxxxxxx > Objet : Re: [dhcwg] Intdir telechat review of draft-ietf-opsawg- > add-encrypted-dns-10 > > On Thu, Mar 9, 2023 at 10:23 PM <mohamed.boucadair@xxxxxxxxxx> > wrote: > > > [Med] What is actually more important in this para is the part > in > > [...]. That text is there to provide an example of when the > attributes > > can be present in CoA-Request. > > I have no problem with that part, and I didn't mean it's less > important than the use of DHCPv6 Reconfigure by omitting that > part. > > > [Med] These considerations are specific to the dhcp options that > will > > be carried in the RADIUS attribute. The security considerations > > (including issues with the use of reconfigure) fall under this > part: > > >> Security considerations specific to the DHCP options that are > >> carried in RADIUS are discussed in relevant documents that > specify > >> these options. > > Do you specifically mean draft-ietf-add-dnr-13? I first expected > that while reviewing draft-ietf-opsawg-add-encrypted-dns and > checked it, but it didn't discuss anything about DHCPv6 > Reconfigure. That's one reason why I raised the point in my > review. > > From your response, I'd suggest: > - Describe the DHCP part of reconfigure operation in more detail > in > draft-ietf-add-dnr (including whether to use Reconfigure message > in > the first place), and/or > - Remove the reference to DHCPv6 reconfigure from > opsawg-add-encrypted-dns and just say something like "How the > DHCPv6 > server uses the new encrypted DNS resolver information is out of > scope of this document." > [Med] OK. Added a reminder of where to find dhcp-related security issues with a specific RFC for reconfigured-specific issues (RFC6977). > > [Med] I also hesitated, but MAY is not used here as this does > not > > impact interop. I had to reread Sections 5/6 of RFC2119 > regularly for > > may/MAY. > > I don't object here. > > > [Med] The use of normative language is justified here because we > don't > > want the RADIUS servers to blindly pass data. What this text > says is > > that the attributes should not be seen as opaque data by the > RADIUS > > server but it should understand the encoding of the enclosed > options. > > Hmm, I didn't read it that way. If that's the intent (and if I > understand it correctly), "For ease of administrator > configuration" > especially sounds awkward, since it seems to say the purpose of > this requirement is better UX. Again, assuming I understand the > intent correctly, I'd suggest something like this: > > The RADIUS server SHOULD reject a configuration attempt of > including > a DHCP option in a DHCP*-Options RADIUS attribute if the server > does > not understand that DHCP option and its format. > [Med] Thanks. We went with a more elaborated version to better explain the intent and call out the constraints: NEW: RADIUS servers have conventionally tolerated the input of arbitrary data via the "string" data type (Section 3.5 of [RFC8044]). This practice allows RADIUS servers to support newer standards without software upgrades, by allowing administrators to manually create complex attribute content and, then, to pass that content to a RADIUS server as opaque strings. While this practice is useful, it is RECOMMENDED that RADIUS servers that implement the present specification are updated to understand the format and encoding of DHCP options. Administrators can, thus, enter the DHCP options as options instead of manually-encoded opaque strings. This recommendation increases security and interoperability by ensuring that the options are encoded correctly. It also increases usability for administrators. > -- > jinmei _________________________________________________________________________________________________________________________ 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
