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

From: Rifaat Shekh-Yusef via Datatracker <[email-masked]>
Date: Fri, 01 May 2020 05:10:19 -0700

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.

---

From: Erik Kline <[email-masked]>
Date: Sun, 3 May 2020 14:58:29 -0700

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

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 04 May 2020 10:08:31 +1000

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:
>  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 
> <[email-masked]> wrote:
> >  I think this case should be discussed in the security consideration section..
> > 
> > 
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Erik Kline <[email-masked]>
Date: Sun, 3 May 2020 21:09:29 -0700

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 <[email-masked]> 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.
>