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

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 <mt@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
> > <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
> >
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>