Re: [Captive-portals] Fixing RFC 7710

[Warren Kumari <warren@kumari.net>]

On Sun, Mar 4, 2018 at 5:55 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On Sat, Mar 3, 2018 at 9:52 AM, Warren Kumari <warren@kumari.net> 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.
>

Okey dokey!


> 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.

Yup, 100% agree -- I believe that hte argument wasn't a technical
objection, but rather a human factors / "If we let people think that
it is OK to trust a TLS cert (note the above was HTTP) without having
in mind some identity to tie it to, they will start believing that
this is OK for their bank and similar - cats and dogs will lie down
together, rains of blood, etc."


>  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.

Yup. And even if it *is* on the local network, there is a good chance
that this is an unencrypted WiFi network, and so you and all your
fellow coffee drinkers can happy watch the packets go by.

>
>> 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 :)

Doh! Sure..

W




-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf