On Sat, Sep 12, 2015 at 1:49 PM, Eric Rescorla <e...@rtfm.com> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
