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

[Brian Smith <[e-mail]>]

On Sat, Sep 12, 2015 at 1:49 PM, Eric Rescorla <[e-mail]> wrote:

> Issue: https://github.com/tlswg/tls13-spec/issues/242
>
> In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues:
>
> "Nobody must ever be *required* to send an alert. Any requirement for
> sending an alert should be SHOULD, at most."
>

Before I wade too deep into this thread, a question:

Assume the client and the server implement the mandatory-to-implement
parameters and that both the client and the server are otherwise
conformant. In this scenerio, when would an alert other than the non-fatal
close_notify be sent?

It could happen if the data is being tampered with (i.e. the connection is
under attack). But, is it really a good idea to send attacker-predictable
and attacker-controllable plaintext (the alert record) when you suspect you
are under attack? Wouldn't it be much safer to hole up in your turtle shell
when you detect signs of an attack?

It could happen that one peer does not trust the other peer's credentials
(certificate). That is common when browsers are involved, but in other
applications of TLS an untrusted certificate is a strong indicator of an
attack. And, in those scenerios, turtling seems like the best solution; at
the very least, it is a justifiable reason to not send an alert.

Because the alerting mechanism is under the influence of attacks, it is no
surprise that some attacks have already used the alerting mechanism. In
particular, CBC padding attacks abuse the alerting mechanism, as has
the Bleichenbacher attack. While it is nice that the specifics of those
particular attacks have been made irrelevant for TLS 1.3, the general
conclusion that the sending of alerts adds significant risk still holds.
Thus, it is reasonable for a careful implementation of TLS to avoid sending
alerts for this reason alone.

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.

If one peer is nonconformant, then it seems unfair, at best, to require the
other peer to put itself at additional risk to inform the nonconformant
peer of its non-conformance. It is each implementation's job to ensure its
own conformance.

Further, attempting to send fatal alerts adds non-trivial complexity to
implementations which emperical evidence has shown to cause significant
problems. I encourage the representatives of Mozilla and other projects to
look through their bug databases for bugs--both publicly-accessible and
hidden from the public--related to the sending of alerts. Also note that
Mozilla's implementation, NSS, has *never* conformed with the
specification's "MUST" requirements to send alerts, and it has bugs in this
area reported half a decade ago that remain unfixed. Thus, the empirical
evidence from Mozilla's widely-deployed implementation shows that (a) the
requirement to send alerts is difficult to conform to, and (b) it is
unimportant in practice to send alerts.

Finally, in an implementation for constrained devices, where every byte of
code size matters, even the small amounts of code necessary to conform with
these requirements are simply not justified. This alone should be
justification for avoiding requiring sending alerts.

Cheers,
Brian