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: > > On Thursday, September 17, 2015 03:27:10 pm Brian Smith wrote: > > > (We should focus on conformant implementations because non-conformant > > > implementations can do whatever they want, by definition). > > > > The flaw in your logic here is the fact that specifications change. > > Firefox will receive a protocol_version alert from a > > version-incompatible server. Both implementations could be fully > > conformant to their target specifications, just different versions. > > Without this alert being consistently sent, everyone gave up and > > implemented a sloppy fallback mechanism which made downgrade attacks > > rather simple. > > 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. > > Certificate alerts can happen pretty much anywhere and this is a > > user-configurable area so it's not the implementations fault, but it > > needs to know what happened for anyone to be able to handle it. > > 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. Secondly, if a server doesn't deal with client certificates, why should it be forced to send alerts? > > 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. Cheers, Brian -- https://briansmith.org/
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
