Perhaps a reference to https://tools.ietf.org/html/rfc3756 as well as the security considerations sections of 2131, 4861, 4862, and 8415.
I'm capturing notes in https://github.com/capport-wg/7710bis/issues/30 . On Sun, 3 May 2020 at 17:09, Martin Thomson <m...@lowentropy.net> wrote: > I think that the standard assumption is that we can equate the ability to > send a DHCP response or a RA with control of the network (or at least those > aspects of the network upon which clients rely on DHCP/RA for). I don't > know if that assumption is written down in a place we could cite it, but if > it were, I would suggest a citation. > > On Mon, May 4, 2020, at 07:58, Erik Kline wrote: > > Rifaat, > > > > Thanks for your reading of the document. > > > > The security section has a paragraph that begins: > > > > """ > > An attacker with the ability to inject DHCP messages or RAs could > > include an option from this document to force users to contact an > > address of his choosing. As an attacker with this capability could > > simply list himself as the default gateway (and so intercept all the > > victim's traffic); this does not provide them with significantly more > > capabilities, but because this document removes the need for > > interception, the attacker may have an easier time performing the > > attack.... > > """ > > > > Do you have any specific ideas for what text might be added to clarify > > vis. your concern? Would a sentence that captures your "the use of TLS > > and presenting the identity in the certificate might not be of much > > help" observation suffice? > > > > Thanks, > > -Erik > > > > On Fri, 1 May 2020 at 05:10, Rifaat Shekh-Yusef via Datatracker > > <nore...@ietf.org> wrote: > > > Reviewer: Rifaat Shekh-Yusef > > > Review result: Has Issues > > > > > > Since the use of IP address literal is not forbidden by this > document, what if > > > an attacker with the ability to inject DHCP messages or RAs uses this > option > > > to force the user to contact an IP address of his choosing? In this > case, the use > > > of TLS and presenting the identity in the certificate might not be of > much help. > > > > > > I think this case should be discussed in the security consideration > section.. > > > > > > > > _______________________________________________ > > Captive-portals mailing list > > Captive-portals@ietf.org > > https://www.ietf.org/mailman/listinfo/captive-portals > > > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals >
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
