Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04

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 
> <noreply@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
>