On Thu, Sep 17, 2015 at 03:00:05PM -0700, Brian Smith wrote: > On Thu, Sep 17, 2015 at 2:55 PM, Nico Williams <n...@cryptonector.com> > wrote: > > On Thu, Sep 17, 2015 at 05:47:50PM -0400, Dave Garrett wrote: > > > > Yes, exactly. Thanks. > > > > There's no evidence that the presence or absence of an alert when a > connection is closed makes any positive difference in the security of any > non-secure fallback mechanism. Keep in mind that the alerts during the > handshake are NOT authenticated, and the TLS threat models thus assumes > that the attacker can remove or alter them.
I thought your argument was that their presence led to version fallbacks. My response is that silent connection closes will too. My apologies if I misunderstood your argument. > > User certificates will be useless without alerts for validation or > > authorization failures. > > First, this is due to flaws in the design of applications and TLS in how > client certificates are handled. Yes: they shouldn't be relying on TLS to authenticate users. Got it. :^) Nonetheless, there is the feature, and if we have it then we might as well build it right, which includes meaningful error messages. > Secondly, if a server doesn't deal with client certificates, why > should it be forced to send alerts? That was just one case. > > > We could probably build a whole list here, but that's enough for me to > > > say that alerts matter in conformant implementations and that we need > > > to always expect they're used correctly. > > Again, the alerts are generally unauthenticated so there is really no > correct use of them. Diagnostics. And not all alerts need be unauthenticated. And heck, we could have the server send signed alerts in handshake failure cases. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
