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
