Martin Thomson <martin.thom...@gmail.com> writes: > On 12 September 2015 at 13:49, Eric Rescorla <e...@rtfm.com> wrote: > > "Nobody must ever be required to send an alert. Any requirement for sending > > an alert should be SHOULD, at most." > > This was a point of debate for HTTP/2 as well. The conclusion there > was that you had to be prepared to have the connection disappear > without warning for various reasons, so requiring that an error be > sent was silly. > > After all, what are you going to do when the connection drops without > a GOAWAY? Drop the connection?
Try again, assuming the problem is a one-time glitch? > That only applies to fatal alerts of course, but I don't see a lot of > use of the warning level, in fact, they might be a bad thing to > support (but that's a separate subject). My suggestion is that we > require that endpoints treat certain errors as fatal and maybe suggest > a particular alert. However, also note that they MAY drop the > connection without sending the alert OR that even if they do send the > alert, it might get lost. For a lot of the alerts, two correct implementations speaking to each other should never use them, so it's hard to standardise what to do about them. However I would suggest that the unsupported_certificate, unknown_ca, protocol_version or insufficient_security alerts, benefit interoperability because the server (or client in some cases) might be able to do something different in the negotation if it is retried (for example present a different certificate chain), but only if it knows what the problem was. So I'd suggest these should be MUST. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
