Re: [TLS] Should we require implementations to send alerts?

[Geoffrey Keating <[e-mail]>]

Martin Thomson <[e-mail]> writes:

> On 12 September 2015 at 13:49, Eric Rescorla <[e-mail]> 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.