On Sat, Sep 12, 2015 at 2:13 PM, Martin Thomson <martin.thom...@gmail.com> wrote:
> On 12 September 2015 at 13:49, Eric Rescorla <e...@rtfm.com> wrote: > > "Nobody must ever be required to send an alert. Any requirement for > sending > > an alert should be SHOULD, at most." > > This was a point of debate for HTTP/2 as well. The conclusion there > was that you had to be prepared to have the connection disappear > without warning for various reasons, so requiring that an error be > sent was silly. > > After all, what are you going to do when the connection drops without > a GOAWAY? Drop the connection? > > That only applies to fatal alerts of course, but I don't see a lot of > use of the warning level, in fact, they might be a bad thing to > support (but that's a separate subject). My suggestion is that we > require that endpoints treat certain errors as fatal and maybe suggest > a particular alert. However, also note that they MAY drop the > connection without sending the alert OR that even if they do send the > alert, it might get lost. > It seems like there are the following options: 1. Require termination and say nothing else 2. Require termination and suggest an alert. 3. Require termination and say that if you send an alert it must be X. 4. Require termination and say that you must send alert X. As you say, implementations can always terminate without sending alerts, however (at least in TLS 1.2) alerts served three purposes: 1. A secure indication of close (and for orderly close in the case of close_notify). 2. Session cache invalidation. 3. An indication to the other side of what went wrong. At least in the third cases, even if implementations can in principle close without sending alerts, they still serve a function and one might argue that that's a reason to encourage/require them. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
