On Oct 24, 2017, at 3:24 PM, Ralph Droms <rdroms.i...@gmail.com> wrote: > ...with the assumption that a client would automatically revert to trying the > connection with the visibility extension if it can't make a connection > without the extension. Why would that assumption be useful? How is this > situation different than the current practice of using HTTP if HTTPS fails?
More likely the client would be failed with one that just automatically negotiates the visibility extension, because that's easier and quicker. > Can you demonstrate how such an attack would work without the assumption that > a client (e.g., browser) would, as policy, downgrade to using the extension > if it can't connect without the extension. I understand the general concern. I don't think it's necessary to demonstrate that, because the browser that implements this extension will just automatically negotiate it. > I still don't see how step 2 is different than forcing a connection without > using TLS at all? Why is the visibility extension more dangerous than only > allowing connections with no TLS? There's no fig leaf of security if you allow connections with no TLS. The problem with these proposals generally is that they push us in the direction of picking and choosing who we will allow to eavesdrop on us, and make it non-negotiable in order to access services we want. You and I are smart enough to say "no" when presented with this choice; unfortunately, at least at present, many people are not, and see things like browser security warnings as annoyances. This is why UAC failed in Windows Vista, and why Vista was widely reviled for its poor usability. It is demonstrably the case that users will say yes to things that are not in their self interest to get to the resources they want. Every time I visit my mom, she has new malware installed on her Chromebook that I removed on my previous visit. So if we do not say no to this, it's likely that ultimately not enough people will, and a lot of end users will suffer as a result, some of them operating things we'd like to remain secure. That is the discussion we should be having right now.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
