Re: [Captive-portals] Fixing RFC 7710

[Martin Thomson <[e-mail]>]

On Sat, Mar 3, 2018 at 9:52 AM, Warren Kumari <[e-mail]> wrote:
> Yeah, there was a significant amount of discussion on this at the time
> of the original document -- I can probably dredge it up if needed, but
> IIRC, it focused around the fact that 1: many clients behind a CP
> would not have enough working connectivity to be able to do the DNS
> stuff required to be able to validate the cert, and 2: a lack of
> clarity on what exactly would be authenticated.

We have good tools for that now.  In practice, the only relevant
network connectivity needed to validate the cert is the revocation
information.  The current idea is that mandating OCSP stapling is
enough.

Of the other things that are included, AIA is the only one that I know
is used in practice, but that can be forbidden here.  The only reason
to do AIA is to avoid including intermediate certificates in the
handshake, and this is a clear case where doing that is not helpful.
Practically speaking, not all clients do AIA, so it's not an
interoperable choice anyway.

> 2: How does the client know that your-preferred-internet-provider.com
> is the identity which *should* be providing Internets? Having the
> client accept that /might/ give the impression that there is some
> *reason* to believe this, and was viewed as a usability concern --
> training users / developers to make a leap of trust that "you should
> trust this identity is the right one" was viewed as a dangerous
> pattern.
>
> Somehow this turned into "Just ship http://192.168.1.1/foo and then
> that, um, someone else's problem"  -- before everyone jumps down my
> throat, I'm not arguing for or against the positions, rather trying to
> provide some background on how we ended up here. :-P

That's not substantially different to https://example.com/.  You end
up trusting that your DHCP/RA wasn't intercepted.  Look at it this
way: whatever you get from DHCP/RA is clearly from someone who
controls the network.  If the person who controls the network isn't
the one paying for it, then that's a problem for the person paying for
the network; it doesn't change what the device connecting to the
network thinks.  HTTPS is better in that the target of the URI might
not be on the local network, and so at least you have confidentiality
once packets leave the network.

> I don't have the time to be the only / primary author, but I'd be more
> than happy to help co-author (if that would be useful), contribute,
> review, fold, spindle or mutilate -- whatever would be helpful.

We might hold you to that :)