Re: [TLS] PR#625: Change alert requirements

[[e-mail] (Martin Rex)]

Salz, Rich wrote:
>
> I've been reading this.
> 
> I think we should get rid of the "abort" concept.  There's a clean
> shutdown and there's everything else which is an abrupt or unclean
> closing of the connection.  The "send alert" and "close connection"
> concepts are separable and I think we should do that.
> 
> I think writing things this way will make it more clear.
> And then we can bikeshed over which alerts are MAY MUST SHOULD,
> knowing all along that ECONNRESET means the other side gave up.

For TLS handshake failures, the presence of Alerts on-the-wire can
significantly facilitate troubleshooting.

For terminating application data flows after successful TLS handshakes
an ECONNRESET may actually be preferable to graceful TLS closure alerts
in certain scenarios (but this means that applications will have to
perform proper application-level end-of-data signaling).

If the backend uses a multi-tier architecture (such as a reverse proxy
in a DMZ), then its easier to notice (and process) ECONNRESET than
a TLS closure alert, and cancel processing of the active request
in the backend.

This becomes even more important when the stupid idea of hiding the
content type is not removed from TLSv1.3/TLSv2.0.  Recognizing
ECONNRESET is trivial.  Peeking and recognizing a pending TLS Alert
is doable in TLS up to v1.2, but this is going to be a royal PITA
in an Alert-ContentType-concealing TLSv1.3/TLSv2.0.


-Martin