(Resending from the right address, again. Possibly I should have subscribed with the other one...)
On Thu, Sep 17, 2015 at 6:23 PM David Benjamin <david...@google.com> wrote: > On Thu, Sep 17, 2015 at 5:46 PM Brian Smith <br...@briansmith.org> wrote: > >> On Thu, Sep 17, 2015 at 1:50 PM, Nico Williams <n...@cryptonector.com> >> wrote: >> >>> On Wed, Sep 16, 2015 at 12:53:53PM -0700, Brian Smith wrote: >>> > Further, the alerting mechanism has encouraged the unsafe practice of >>> > "version fallback." It is clear from looking at the bug databases of >>> > Firefox and Chrome that their attempts to make security decisions >>> based on >>> > what alerts they received was bad for security. >>> >>> Do we think that silent connection closings wouldn't also lead to >>> version fallback? >>> >> >> Let's ask the browser vendors: >> >> Browser vendors, if web servers were to stop sending alerts during >> handshake failures, would you start doing version fallback when a >> connection is closed? >> > > Connection close is already a fallback trigger. > > >> Fatal alerts are quite handy for diagnostics on the client side, really. >>> >> >> I agree that they are often marginally useful. However, the risks >> associated with the alert mechanism outweigh those benefits. >> > > I don't think the existence of alerts at all increases the "risk" that > people will do fallbacks. I think you've got causality flipped. It wasn't > "we get alerts, ergo we can get away with a fallback" but "Servers are > dumb, we want to fallback. If there's something easy we can do to constrain > when fallbacks happen, we should. Being more lenient means even more > unexpected dependencies on the fallback may crop up. (Not that this hasn't > happened anyway.)". > > Besides, fallback conditions tend to be extremely liberal in my > experience. Which makes sense since it's used against buggy servers. If a > buggy server blew up because it's version-intolerant, it's not likely to be > kind enough to tell you that. > > While I don't see much use in "your records don't authenticate" and > "that's not even a syntactically valid ServerKeyExchange!", not all > failures are protocol failures. There's also negotiation failures when > parameters aren't okay. When removing cipher suites or bumping minimum > versions, it's nice to show a dedicated error message when it goes wrong. > > And client certs break (even more) if you can't distinguish network errors > from the peer complaining at you. I wish they would go away, but I'm stuck > with supporting it right now and I doubt the world will rally behind > "client certs on the web are deprecated; you do not get TLS 1.3 if you use > client certs". > > David > > >> >> > I'd rather keep them than remove them, but I'd be OK with clients never >>> sending them. I'm OK with fata alerts being SHOULD send. >> >> >> I suggest that, at most, implementations SHOULD NOT send them. IMO it >> would be better to remove the alert mechanism altogether in TLS 1.3. >> >> Most people that are arguing for retaining the alert requirements seem to >> be concerned about alerts sent from the server to the client. Does anybody >> think it is important to require clients to ever send alerts other than >> close_notify? >> >>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
