[TLS] Should we require implementations to send alerts?
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." As Dave Garrett notes in the same thread, this is a common requirement throughout the specification and we recently have had requests to add more of these requirements. This is a global specification issue, so seems appropriate to discuss on-list. FWIW, I would note that the just approved session-hash draft contains such requirements as well: https://tools.ietf.org/html/draft-ietf-tls-session-hash-06#section-5.2 "In the following, we use the phrase "abort the handshake" as shorthand for terminating the handshake by sending a fatal "handshake_failure" alert." so it could be argued that this reflects recent WG consensus. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On 12 September 2015 at 13:49, Eric Rescorla 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Sat, Sep 12, 2015 at 2:13 PM, Martin Thomson wrote: > On 12 September 2015 at 13:49, Eric Rescorla 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
Re: [TLS] Should we require implementations to send alerts?
Martin Thomson writes: > On 12 September 2015 at 13:49, Eric Rescorla 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? Try again, assuming the problem is a one-time glitch? > 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. For a lot of the alerts, two correct implementations speaking to each other should never use them, so it's hard to standardise what to do about them. However I would suggest that the unsupported_certificate, unknown_ca, protocol_version or insufficient_security alerts, benefit interoperability because the server (or client in some cases) might be able to do something different in the negotation if it is retried (for example present a different certificate chain), but only if it knows what the problem was. So I'd suggest these should be MUST. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
This seems like the right set of options... On 12 September 2015 at 14:26, Eric Rescorla wrote: > 1. Require termination and say nothing else I think the mere existence of alerts suggests that this isn't really a good option. > 2. Require termination and suggest an alert. > 3. Require termination and say that if you send an alert it must be X. I think that the distinction between these relies on the suggestion that we think that lying about causes would be desirable in some cases. I think that the latter would be better. > 4. Require termination and say that you must send alert X. As Geoff indicates, maybe this makes sense in cases where the information the alert carries is especially valuable. I can accept that argument. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
> > After all, what are you going to do when the connection drops without > > a GOAWAY? Drop the connection? > > Try again, assuming the problem is a one-time glitch? That's important. Without the alert, you might just try again. And again. And again.. .. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Sat, Sep 12, 2015 at 01:49:49PM -0700, Eric Rescorla wrote: > "Nobody must ever be *required* to send an alert. Any requirement for > sending an alert should be SHOULD, at most." Interoperability problems are hard enough to debug even when alerts are sent, and they are *very* useful. If the peer just hangs up, we don't know whether it crashed, refused service, enforced some protocol or policy constraint, ... I help many users debug TLS connectivity issues, and would be considerably hampered in this without alert information. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Sat, Sep 12, 2015 at 3:18 PM, Viktor Dukhovni wrote: > On Sat, Sep 12, 2015 at 01:49:49PM -0700, Eric Rescorla wrote: > > > "Nobody must ever be *required* to send an alert. Any requirement for > > sending an alert should be SHOULD, at most." > To be clear, you're quoting me quoting Brian Smith. This isn't my position. > Interoperability problems are hard enough to debug even when alerts > are sent, and they are *very* useful. If the peer just hangs up, > we don't know whether it crashed, refused service, enforced some > protocol or policy constraint, ... > > I help many users debug TLS connectivity issues, and would be > considerably hampered in this without alert information. > > -- > Viktor. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
