On Sat, Mar 3, 2018 at 9:52 AM, Warren Kumari <war...@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. 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 :) _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
