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

[[e-mail] (Martin Rex)]

Brian Smith wrote:
> 
> 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.

Alerts can help troubleshooting/debugging, in particular when one only has
access to logs/traces of one of the communication peers.

Alerts are not authenticated, and whenever they're the last message
on a connection, could get lost on socket closure (killed in a tcp
socket when pipe is full and lingering not enabled), or could get
stripped by an attacker.

How many TLS implementation remove a session from the session cache
if the session ends without close-notify?  The original idea wasn't
really well thought-out, because implementations may start TLS session
"forking" (storing sessions in cache and proposing their resumption
on parallel network connections) immedately when the TLS handshake
has completed (and before any app-level request & response has completed,
i.e. long before a close-notify alert will be exchanged.

There are TLS implementations that use a transport-free programming API,
which means that the decision to send a fatal alert over the transport
is not a decision of the TLS implementation, but of the application caller
on top.  And that application caller may not bother with processing any
"transport requests" that accompany a fatal API error code at all.

Microsoft' TLS implementation (SChannel) is an example of a transport-less
implementation, and neither MSIE nor IIS send fatal TLS alerts over the
wire before they close the network connection after a TLS handshake failure.
(I don't have any Windows 8.x or 10 machines, so I don't know whether
 this was ever changed).  You'll have to dig out the TLS alert number
from the windows system event log on the machine where it happened,
which is often not an option when the remote peer from a different
service provider hangs up half way through the TLS handshake.


Easier troubleshooting is IMO a sufficient rationale to justify existence
of the alert mechanism and a "SHOULD send the alert before closing the
network connection".

A "MUST send fatal alert" requirement, however, would be silly (and
will be void in face of rfc2119 section 6 anyway).  What would be
the semantics of such a requirement anyway?

If one of the communication peers closes the network connection
prior to completion of the TLS handshake, then the result is a 100%
interoperability failure.  How is a "MUST send alert" supposed to
affect that outcome when the server does not send one?
Is it a 120% interop failure then?

-Martin