[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Captive-portals] Fixing RFC 7710
On Sun, Mar 4, 2018 at 5:55 PM, Martin Thomson <[email protected]> wrote:
> On Sat, Mar 3, 2018 at 9:52 AM, Warren Kumari <[email protected]> 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
> 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
>> 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 :)
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