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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
