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

From: Eric Rescorla <[email-masked]>
Date: Sat, 12 Sep 2015 13:49:49 -0700

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

---

From: Martin Thomson <[email-masked]>
Date: Sat, 12 Sep 2015 14:13:53 -0700

On 12 September 2015 at 13:49, Eric Rescorla <[email-masked]> 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.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 12 Sep 2015 14:26:27 -0700

> 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

---

From: Geoffrey Keating <[email-masked]>
Date: 12 Sep 2015 14:33:29 -0700

> a GOAWAY?  Drop the connection?

Try again, assuming the problem is a one-time glitch?

> 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.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 12 Sep 2015 14:42:02 -0700

This seems like the right set of options...

> 1. Require termination and say nothing else

I think the mere existence of alerts suggests that this isn't really a
good option.

> 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.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 12 Sep 2015 21:55:41 +0000

> 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.. ..

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 12 Sep 2015 22:18:46 +0000

> 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.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 12 Sep 2015 15:19:32 -0700

> > sending an alert should be SHOULD, at most."

To be clear, you're quoting me quoting Brian Smith. This isn't my position.

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Dave Garrett <[email-masked]>
Date: Sat, 12 Sep 2015 22:21:33 -0400

> protocol or policy constraint, ...

To reiterate in this thread, not being strict with error alert requirements is how we got TLS version intolerance, which is how we got insecure fallback. This one instance is sufficient for me to say that almost all alerts specified for during the handshake should be mandatory. Allowing fuzzy reactions to errors on one end leads to fuzzy kludges to deal with them on the other. We should attempt to map out every possible logic path and at least have an expectation given, if not mandated. People are less likely to do stupid things in their implementations if they're actually told what they're dealing with properly.

Dave

---

From: Andrei Popov <[email-masked]>
Date: Mon, 14 Sep 2015 00:29:16 +0000

I generally agree that sending alerts is the right thing for an implementation to do, for all the reasons discussed on this thread. It is also helpful when RFCs specify the appropriate alerts for various conditions.

On the other hand, it seems unimportant whether an alert is defined as a SHOULD or a MUST: either way the peer can't enforce the use of alerts.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Dave Garrett
Sent: Saturday, September 12, 2015 7:22 PM
To: [email-masked]
Cc: Geoffrey Keating <[email-masked]>
Subject: Re: [TLS] Should we require implementations to send alerts?

On Saturday, September 12, 2015 05:55:41 pm Salz, Rich wrote:
> > > After all, what are you going to do when the connection drops 
> > > without a GOAWAY?  Drop the connection?
> > 

On Saturday, September 12, 2015 06:18:46 pm Viktor Dukhovni wrote:
> 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, ...

Dave

---

From: Hanno Böck <[email-masked]>
Date: Mon, 14 Sep 2015 10:41:04 +0200

On Sat, 12 Sep 2015 13:49:49 -0700

> sending an alert should be SHOULD, at most."

Just a quick thought on this: We had vulns in the distant past that
relied on different reactions to different errors (Vaudenay / Padding
Oracle attack).

The Vaudenay attack is history because we agreed long that CBC/HMAC
with MAC-then-Encrypt will be gone. But I think making the error alert
optional may lead to similar attacks. An implementation may decide to
send an error alert in one situation and no error in another. This
may leak information valuable to an attacker.

I generally think having a more strict spec with less wiggle room is
better. Therefore: I think a MUST is better.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Florian Weimer <[email-masked]>
Date: Tue, 15 Sep 2015 15:18:30 +0200

> sending an alert should be SHOULD, at most."

Using full-duplex TCP, it's difficult to get a fatal alert over the wire
if you want to close the connection immediately:

<http://www.ietf.org/mail-archive/web/tls/current/msg08342.html>

The workarounds proposed in that thread may not be always practical.

-- 
Florian Weimer / Red Hat Product Security

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 15 Sep 2015 14:41:02 +0000

> Using full-duplex TCP, it's difficult to get a fatal alert over the wire if you want
> to close the connection immediately:

Yes.

But so what. )

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Sep 2015 11:29:22 -0500

> if you want to close the connection immediately:

But if you have a fatal error you'll be closing immediately anyways.
Does sending the fatal alert cause a problem other than increase the
likelihood of RSTs?  What is the alternative considering that the next
step is to close the connection anyways?

Nico
--

---

From: Florian Weimer <[email-masked]>
Date: Wed, 16 Sep 2015 12:02:57 +0200

> step is to close the connection anyways?

I'm trying to explain that any requirement to send fatal alerts will be
difficult to implement.  With the BSD sockets API, the only way to do
that reliable is *not* to close the socket immediately, which is
apparently not what you (or existing APIs) expect, and which is where
the difficulty lies.

---

From: Henrik Grubbström <[email-masked]>
Date: Wed, 16 Sep 2015 13:51:40 +0200

> On 09/15/2015 06:29 PM, Nico Williams wrote:
[...]
> apparently not what you (or existing APIs) expect, and which is where

What about SO_LINGER?

-- 
Henrik Grubbström                                       [email-masked]
Roxen Internet Software AB                              [email-masked]

---

From: Florian Weimer <[email-masked]>
Date: Wed, 16 Sep 2015 13:54:20 +0200

>> apparently not what you (or existing APIs) expect, and which is where

With full-duplex connections, it does not make a difference.  TCP will
still detect a data loss event, send the RST segment, and discard the
queued fatal alert.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 16 Sep 2015 14:23:50 +0000

> With full-duplex connections, it does not make a difference.  TCP will still
> detect a data loss event, send the RST segment, and discard the queued fatal
> alert.

Yes, it might be hard(er) to do the right thing.  We should not penalize everyone because of that.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 Sep 2015 16:57:06 +0000

> apparently not what you (or existing APIs) expect, and which is where

This is silly.  The server sends the alert on a best-effort basis.
We cannot impose a magical requirement that the alert gets there.
The requirement is to send, not to guarantee successful transmission.

Sending is easy, just write the alert down the socket (even that
might fail and that's fine).

In practice, if the the server is the first to detect an error,
its alert gets to the client.  There's no need to read too much
into this.

-- 
	Viktor.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 16 Sep 2015 12:06:26 -0700

> From: TLS [mailto:[email-masked]] On Behalf Of Salz, Rich
> Sent: Wednesday, September 16, 2015 7:24 AM
> To: Florian Weimer <[email-masked]>; Henrik Grubbström
> <[email-masked]>
> Cc: [email-masked]
> Yes, it might be hard(er) to do the right thing.  We should not penalize
everyone
> because of that.

There are cases where TLS is not traveling over TCP connections.  In this
case having the alert be transmitted is a better way of signaling either
that a session has ended or the other channel needs to be closed.

Jim

---

From: Nico Williams <[email-masked]>
Date: Wed, 16 Sep 2015 14:23:40 -0500

> apparently not what you (or existing APIs) expect, and which is where

*Sending* the fatal alert is not hard at all.  Giving the peer a fair
chance to get them is the difficult thing.  Strictly speaking then,
requiring that fata alerts be sent is not difficult to implement.  :^)

Tongue-in-cheek aside, I think it's fair to say that fata alerts SHOULD
be sent rather than MUST be sent.  And it's a good idea to explain that
sending a fatal alert, by itself, does not really mean that the peer is
even more likely than not to see it, that more effort is required by the
sender to give the peer a fair chance of seeing it.

Fatal alerts are useful for diagnostics purposes at least, but there's
no real need to tell a peer why you're slamming the door on them, is
there.

Nico
--

---

From: Dave Garrett <[email-masked]>
Date: Wed, 16 Sep 2015 15:29:40 -0400

> sender to give the peer a fair chance of seeing it.

I'd be fine with phrasing it as: implementations MUST send all alerts when indicated, and SHOULD make a best-effort to ensure they get delivered to the peer.

If we're hung up on how to define "send"; e.g. as implementation tried or as actually got on the wire and to the peer, then I would formally define it as the former.

Dave

---

From: Nico Williams <[email-masked]>
Date: Wed, 16 Sep 2015 14:52:39 -0500

On Wed, Sep 16, 2015 at 03:29:40PM -0400, Dave Garrett wrote:
> I'd be fine with phrasing it as: implementations MUST send all alerts
> when indicated, and SHOULD make a best-effort to ensure they get
> delivered to the peer.

+1.

Perhaps some text explaining the difficulty in the latter and offering
some implementation advice.  Something like:

   Sending a fatal alert is easy, but ensuring that the peer gets it
   when running over TCP or similar can be difficult because a shutdown
   or close will result in the peer getting an RST if data is received
   from it before the alert is sent.

   Depending on the TCP stack, giving the alert a chance of being
   received may require delaying the closing of the connection by some
   amount of time.  A "simple" way to do this is to "service" a pool of
   pending-close connections on a timer, or at the next new connection
   or insertion of a new delayed-close connection into the pool.  A
   reasonably low implementation cost method is to have a fixed-sized
   pool of pending-close connections, closing the oldest connection
   whenever adding a new pending-close connection to a full pool.  Note
   that any scheme that can leave pending-close connections alive
   possibly indefinitely will also consume the associated TCP PCB
   resources indefinitely.

The second paragraph might be giving too much implementation advice.

Nico
--

---

From: Brian Smith <[email-masked]>
Date: Wed, 16 Sep 2015 12:53:53 -0700

> sending an alert should be SHOULD, at most."

Before I wade too deep into this thread, a question:

Assume the client and the server implement the mandatory-to-implement
parameters and that both the client and the server are otherwise
conformant. In this scenerio, when would an alert other than the non-fatal
close_notify be sent?

It could happen if the data is being tampered with (i.e. the connection is
under attack). But, is it really a good idea to send attacker-predictable
and attacker-controllable plaintext (the alert record) when you suspect you
are under attack? Wouldn't it be much safer to hole up in your turtle shell
when you detect signs of an attack?

It could happen that one peer does not trust the other peer's credentials
(certificate). That is common when browsers are involved, but in other
applications of TLS an untrusted certificate is a strong indicator of an
attack. And, in those scenerios, turtling seems like the best solution; at
the very least, it is a justifiable reason to not send an alert.

Because the alerting mechanism is under the influence of attacks, it is no
surprise that some attacks have already used the alerting mechanism. In
particular, CBC padding attacks abuse the alerting mechanism, as has
the Bleichenbacher attack. While it is nice that the specifics of those
particular attacks have been made irrelevant for TLS 1.3, the general
conclusion that the sending of alerts adds significant risk still holds.
Thus, it is reasonable for a careful implementation of TLS to avoid sending
alerts for this reason alone.

Further, the alerting mechanism has encouraged the unsafe practice of
"version fallback." It is clear from looking at the bug databases of
Firefox and Chrome that their attempts to make security decisions based on
what alerts they received was bad for security.

If one peer is nonconformant, then it seems unfair, at best, to require the
other peer to put itself at additional risk to inform the nonconformant
peer of its non-conformance. It is each implementation's job to ensure its
own conformance.

Further, attempting to send fatal alerts adds non-trivial complexity to
implementations which emperical evidence has shown to cause significant
problems. I encourage the representatives of Mozilla and other projects to
look through their bug databases for bugs--both publicly-accessible and
hidden from the public--related to the sending of alerts. Also note that
Mozilla's implementation, NSS, has *never* conformed with the
specification's "MUST" requirements to send alerts, and it has bugs in this
area reported half a decade ago that remain unfixed. Thus, the empirical
evidence from Mozilla's widely-deployed implementation shows that (a) the
requirement to send alerts is difficult to conform to, and (b) it is
unimportant in practice to send alerts.

Finally, in an implementation for constrained devices, where every byte of
code size matters, even the small amounts of code necessary to conform with
these requirements are simply not justified. This alone should be
justification for avoiding requiring sending alerts.

Cheers,
Brian

---

From: Florian Weimer <[email-masked]>
Date: Thu, 17 Sep 2015 09:57:47 +0200

> conformant. In this scenerio, when would an alert other than the non-fatal

I have been told that mandatory-to-implement does not mean
mandatory-to-enable, and that it is possible to run a nominally
RFC-conforming client or server in a mode which is not interoperable
with anything else.  Under such a scenario, fatal alerts happen without
an attack.

Most fatal alerts in the wild appear to be harmless in the sense that
they are not due to attacks, but due to interoperability failures (due
to not enabling mandatory-to-implement cipher suites, self-signed
certificates, incomplete certificate chains, or just bugs).

---

From: Hubert Kario <[email-masked]>
Date: Thu, 17 Sep 2015 12:27:42 +0200

On Wednesday 16 September 2015 12:53:53 Brian Smith wrote:
> Thus, the empirical evidence from Mozilla's
> widely-deployed implementation shows that (a) the requirement to send
> alerts is difficult to conform to, and (b) it is unimportant in
> practice to send alerts.

and yet Firefox depends on them to report human-readable errors to users 
when it can't connect to a server...

Making the alerts more predictable and with more pinned down meanings 
will only _help_ the opportunistic HTTPS and HTTPS-by-default campaigns.

yes, we need to be careful about alerts that provide information about 
secret data, but there's very little of such data during handshaking, 
where the vast majority of alerts apply and where they are most useful
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Brian Smith <[email-masked]>
Date: Thu, 17 Sep 2015 12:27:10 -0700

> when it can't connect to a server...

In what situation will a conformant implementation send Firefox an alert?
Firefox is conformant (AFAICT) and in particular Firefox implements the
mandatory-to-implement cipher suite. Therefore no conformant implementation
should be sending Firefox an alert other than close_notify.

(We should focus on conformant implementations because non-conformant
implementations can do whatever they want, by definition).

> will only _help_ the opportunistic HTTPS and HTTPS-by-default campaigns.

I've not seen any evidence that that is true. I have seen evidence in
Firefox and other implementations that detailed alert information was
harmful for security, and I shared a summary of that evidence in my early
message. Also, instances of such harm are documented within the TLS RFCs
themselves.

> where the vast majority of alerts apply and where they are most useful

It's not clear that there is "little of such data" especially when you
consider that more of the handshake is encrypted in TLS 1.3 and when you
consider that an application may not process unencrypted data as soon as it
has been received.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Sep 2015 15:50:06 -0500

> what alerts they received was bad for security.

Do we think that silent connection closings wouldn't also lead to
version fallback?

"Let's try this.  Nope, didn't work.  Let's try this other thing...
Nope, didn't work.  ..."

Fatal alerts are quite handy for diagnostics on the client side, really.
I'd rather keep them than remove them, but I'd be OK with clients never
sending them.  I'm OK with fata alerts being SHOULD send.  I'm OK with
having text explaining how to send them such that peers (clients) will
get a fair chance of receiving them.

We shouldn't always fight the last war.

I hope the browsers won't implement reconnect version fallbacks again,
ever.

Nico
--

---

From: Brian Smith <[email-masked]>
Date: Thu, 17 Sep 2015 14:46:39 -0700

> Do we think that silent connection closings wouldn't also lead to

Let's ask the browser vendors:

Browser vendors, if web servers were to stop sending alerts during
handshake failures, would you start doing version fallback when a
connection is closed?

I agree that they are often marginally useful. However, the risks
associated with the alert mechanism outweigh those benefits.

> sending them.  I'm OK with fata alerts being SHOULD send.

I suggest that, at most, implementations SHOULD NOT send them. IMO it would
be better to remove the alert mechanism altogether in TLS 1.3.

Most people that are arguing for retaining the alert requirements seem to
be concerned about alerts sent from the server to the client. Does anybody
think it is important to require clients to ever send alerts other than
close_notify?

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Dave Garrett <[email-masked]>
Date: Thu, 17 Sep 2015 17:47:50 -0400

> implementations can do whatever they want, by definition).

The flaw in your logic here is the fact that specifications change. Firefox will receive a protocol_version alert from a version-incompatible server. Both implementations could be fully conformant to their target specifications, just different versions. Without this alert being consistently sent, everyone gave up and implemented a sloppy fallback mechanism which made downgrade attacks rather simple.

Likewise, you'll get an alert if different ciphers are supported on each endpoint. Mandatory to implement does not mean mandatory to use.

Certificate alerts can happen pretty much anywhere and this is a user-configurable area so it's not the implementations fault, but it needs to know what happened for anyone to be able to handle it.

We could probably build a whole list here, but that's enough for me to say that alerts matter in conformant implementations and that we need to always expect they're used correctly.

Dave

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Sep 2015 16:52:32 -0500

> handshake failures, would you start doing version fallback when a

That's not how we answers to questions like that.  These behaviors (on
the part of developers) arise long after we think ask the question.

The point is: if they did it then, why would we think they wouldn't do
it now without fatal alerts?

Spoiler alert!1!!: developers want the user experience to be smooth,
security be damned, so yes, they will in fact implement version
fallbacks on connection close.

But now consider a fatal alert that conveys a "it's not gonna work with
earlier versions either, you dummy" message.  That's got a slightly
better chance of working.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Sep 2015 16:55:16 -0500

On Thu, Sep 17, 2015 at 05:47:50PM -0400, Dave Garrett wrote:
> The flaw in your logic here is the fact that specifications change.
> Firefox will receive a protocol_version alert from a
> version-incompatible server. Both implementations could be fully
> conformant to their target specifications, just different versions.
> Without this alert being consistently sent, everyone gave up and
> implemented a sloppy fallback mechanism which made downgrade attacks
> rather simple.

Yes, exactly.  Thanks.

> Certificate alerts can happen pretty much anywhere and this is a
> user-configurable area so it's not the implementations fault, but it
> needs to know what happened for anyone to be able to handle it.

User certificates will be useless without alerts for validation or
authorization failures.

> We could probably build a whole list here, but that's enough for me to
> say that alerts matter in conformant implementations and that we need
> to always expect they're used correctly.

+1

Nico
--

---

From: Dave Garrett <[email-masked]>
Date: Thu, 17 Sep 2015 17:57:25 -0400

> handshake failures, would you start doing version fallback when a

Well, what else would clients do instead? The answer is an unambiguous yes. There's no way to tell a microwave oven killing the WiFi and a legitimate handshake failure apart if no information is sent back. Implementors will always assume it's possible to retry, and we know from history that this will involve an unsafe fallback dance.

> think it is important to require clients to ever send alerts other than

There's also user_canceled and cert errors when doing client authentication.

The idea of restricting what alerts clients, specifically, should send is not necessarily something I'd object to, though I don't think it's useful.

Dave

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Sep 2015 14:58:43 -0700

On 17 September 2015 at 14:46, Brian Smith <[email-masked]> wrote:
> Browser vendors, if web servers were to stop sending alerts during handshake
> failures, would you start doing version fallback when a connection is
> closed?

I'm not sure.  We still have a small amount of vestigal fallback code
in our code.  We are gradually killing version fallback off and
removing alerts would likely set that effort back.

We're not sure where we stand with version fallback and 1.3.  We don't
know how much version intolerance 1.3 will generate.  That at least
might not depend on alerts, though we don't know just yet.

I don't see much support for the notion that forbidding alerts is a
good idea.  We use alerts quite a bit for basic diagnosis.  Bad
configurations are pretty commonplace, the most common being one where
there is no common cipher suite.  Being able to isolate the error that
is pretty useful.

---

From: Brian Smith <[email-masked]>
Date: Thu, 17 Sep 2015 15:00:05 -0700

> > implemented a sloppy fallback mechanism which made downgrade attacks

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.

> User certificates will be useless without alerts for validation or

First, this is due to flaws in the design of applications and TLS in how
client certificates are handled.

Secondly, if a server doesn't deal with client certificates, why should it
be forced to send alerts?

> > to always expect they're used correctly.

Again, the alerts are generally unauthenticated so there is really no
correct use of them.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Sep 2015 17:00:55 -0500

> sending an alert should be SHOULD, at most."

There have been two main lines of argument in this thread, paraphrased:
a) don't send them, they are dangerous, and b) making it even just
likely that fatal alerts reach the peer is hard, therefore why bother.

I believe (a) is flawed and wrong.  Fatal alerts are not the cause of
version fallback reconnects, and they should not be a problem with any
of the ciphersuites in 1.3.

I believe (b) is no reason not to send the fatal alerts.  It is reason
to have text about how an implementation that cares can improve the
likelihood of the peer receiving them.

Yes, fatal alerts should be required to be sent.  Servers should be
encouraged to improve the chances of the alerts being received by
clients by attempting to delay close the connection.  (A simple timer is
not enough; a hard limit on the number of pending-close connections is
desirable.  IMO.)

Nico
--

---

From: Brian Smith <[email-masked]>
Date: Thu, 17 Sep 2015 15:08:41 -0700

> There have been two main lines of argument in this thread, paraphrased:

It is amusing when people pull this trick, but it gets old. There are more
than two lines of argument against sending alerts, and your paragraphing
mischaracterizes them.

Cheers,
Brian

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Sep 2015 17:10:23 -0500

> that the attacker can remove or alter them.

I thought your argument was that their presence led to version
fallbacks.  My response is that silent connection closes will too.

My apologies if I misunderstood your argument.

> client certificates are handled.

Yes: they shouldn't be relying on TLS to authenticate users.  Got it.

:^)

Nonetheless, there is the feature, and if we have it then we might as
well build it right, which includes meaningful error messages.

> Secondly, if a server doesn't deal with client certificates, why
> should it be forced to send alerts?

That was just one case.

> Again, the alerts are generally unauthenticated so there is really no

Diagnostics.  And not all alerts need be unauthenticated.  And heck, we
could have the server send signed alerts in handshake failure cases.

Nico
--

---

From: Dave Garrett <[email-masked]>
Date: Thu, 17 Sep 2015 18:15:27 -0400

> that the attacker can remove or alter them.

The whole handshake is retroactively authenticated upon completion. Just because an attacker can muck up the attempt to connect, doesn't mean all hope is lost.

The primary benefit with the version alert, specifically, is that it allows a client to at least have a clue as to what to attempt.

Without alert:
client tries
server stares blankly into the void and/or drops abruptly
now, what does the client do? try again as-is, or try again with old stuff?

With alert:
client tries
if server responds with an alert, react to it
if not, try again until there's a response; give up eventually

Sure, a MitM could try to downgrade by injecting an unauthenticated alert into the mix, but the handshake will fail once that is authenticated at the end.

Just as the obvious footnote: it's impossible to make any of this resistant to an attacker killing the connection. Just assume that's always possible, at minimum with wirecutters. The goal is security or bust. Alerts give clients the confidence to actually bust when they have to.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Thu, 17 Sep 2015 18:22:54 -0400

> Sure, a MitM could try to downgrade by injecting an unauthenticated alert into the mix, but the handshake will fail once that is authenticated at the end.

To correct myself, SCSV is needed to protect here.
https://tools.ietf.org/html/rfc7507

Dave

---

From: David Benjamin <[email-masked]>
Date: Thu, 17 Sep 2015 22:24:28 +0000

(Resending from the right address, again. Possibly I should have subscribed
with the other one...)

On Thu, Sep 17, 2015 at 6:23 PM David Benjamin <[email-masked]> wrote:

> On Thu, Sep 17, 2015 at 5:46 PM Brian Smith <[email-masked]> wrote:
>
> Connection close is already a fallback trigger.
>
>
> I don't think the existence of alerts at all increases the "risk" that
> people will do fallbacks. I think you've got causality flipped. It wasn't
> "we get alerts, ergo we can get away with a fallback" but "Servers are
> dumb, we want to fallback. If there's something easy we can do to constrain
> when fallbacks happen, we should. Being more lenient means even more
> unexpected dependencies on the fallback may crop up. (Not that this hasn't
> happened anyway.)".
>
> Besides, fallback conditions tend to be extremely liberal in my
> experience. Which makes sense since it's used against buggy servers. If a
> buggy server blew up because it's version-intolerant, it's not likely to be
> kind enough to tell you that.
>
> While I don't see much use in "your records don't authenticate" and
> "that's not even a syntactically valid ServerKeyExchange!", not all
> failures are protocol failures. There's also negotiation failures when
> parameters aren't okay. When removing cipher suites or bumping minimum
> versions, it's nice to show a dedicated error message when it goes wrong.
>
> And client certs break (even more) if you can't distinguish network errors
> from the peer complaining at you. I wish they would go away, but I'm stuck
> with supporting it right now and I doubt the world will rally behind
> "client certs on the web are deprecated; you do not get TLS 1.3 if you use
> client certs".
>
> David
>
>
>>
>>
>> I suggest that, at most, implementations SHOULD NOT send them. IMO it
>> would be better to remove the alert mechanism altogether in TLS 1.3.
>>

---

From: Brian Smith <[email-masked]>
Date: Thu, 17 Sep 2015 15:30:12 -0700

Martin Thomson <[email-masked]> wrote:

> handshake

Actually, Firefox has already stopped doing version fallback completely for
all versions of TLS it supports, unless the website is on a whitelist.
That's not really "gradually."

> might not depend on alerts, though we don't know just yet.

A conformant TLS 1.3 implementation cannot be version intolerant. If it
were version intolerant then it would not be a conformant TLS 1.3
implementation. So, conformance requirements for TLS .1.3 servers don't
matter as far as version intolerance is concerned.

> there is no common cipher suite.  Being able to isolate the error that

I still think it is better to recommend to never send alerts. But, at least
there are good reasons (which I gave much earlier in the thread) for why a
server would choose not to send alerts, e.g. out of an abundance of
caution. So, "MUST send" is clearly too far.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Brian Smith <[email-masked]>
Date: Thu, 17 Sep 2015 15:37:29 -0700

On Thu, Sep 17, 2015 at 3:15 PM, Dave Garrett <[email-masked]>
wrote:

> The whole handshake is retroactively authenticated upon completion. Just
> because an attacker can muck up the attempt to connect, doesn't mean all
> hope is lost.
>

A fatal alert during the handshake is never authenticated, because (a) the
alert record is the last record sent (i.e. there is no Finished message
sent afterward to authenticate it), and (b) The handshake hashes only cover
Handshake records, not Alert records.

> The primary benefit with the version alert, specifically, is that it
> allows a client to at least have a clue as to what to attempt.
>
> Without alert:
> client tries

A conformant TLS 1.3 implementation will not be version intolerant. If the
client does insecure version fallback in response to an alert or connection
close by a conformant TLS 1.3 implementation then it is guaranteed to be
doing the wrong thing.

> Sure, a MitM could try to downgrade by injecting an unauthenticated alert
> into the mix, but the handshake will fail once that is authenticated at the
> end.
>

This is not how the protocol works at all. The alert is unauthenticated,
full stop.

The only time an alert is authenticated is when it is sent after the
Finished message. But then, since such alerts can be triggered by a MitM
who does not have knowledge of the keys, such sending of alerts allows the
MitM to effectively inject known plaintext (the alert record) into the
connection, which runs the risk of facilitating attacks.

> Just as the obvious footnote: it's impossible to make any of this
> resistant to an attacker killing the connection. Just assume that's always
> possible, at minimum with wirecutters. The goal is security or bust. Alerts
> give clients the confidence to actually bust when they have to.
>

In general, the "when to bust" is "always."

Again, there is no such thing as a secure non-secure fallback.

Cheers,
Brian
--
https://briansmith.org/

---

From: Dave Garrett <[email-masked]>
Date: Thu, 17 Sep 2015 18:39:04 -0400

> That's not really "gradually."

It wasn't switched from fully on to fully off, therefore, this is gradual. The whitelist is not small.

> matter as far as version intolerance is concerned.

TLS 1.3 implementations will have to deal with TLS 1.0 servers until the end of time, or TLS, whichever comes first. Lots of these are buggy as hell.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Thu, 17 Sep 2015 18:44:54 -0400

[...]
> The alert is unauthenticated, full stop.

Yes, this is correct. I replied to quickly. I sent a followup message to correct myself and note that SCSV is needed here.

It might be nice if this got included in the session hash.

> close by a conformant TLS 1.3 implementation then it is guaranteed to be

The client initially has no way of telling apart a conformant TLS 1.3 server, a TLS 1.2 server, a TLS 1.0 server full of bugs, or a potato.

Dave

---

From: [email-masked] (Martin Rex)
Date: Fri, 18 Sep 2015 00:58:19 +0200 (CEST)

> 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

---

From: Brian Smith <[email-masked]>
Date: Thu, 17 Sep 2015 16:00:26 -0700

On Thu, Sep 17, 2015 at 3:44 PM, Dave Garrett <[email-masked]>
wrote:

> The client initially has no way of telling apart a conformant TLS 1.3
> server, a TLS 1.2 server, a TLS 1.0 server full of bugs, or a potato.
>

Right. I am not saying anything about how to *receive* alerts. That's a
separate topic.

What I'm saying is that a conformant TLS 1.3 implementation shouldn't be
required to send fatal alerts in any circumstance; i.e. there should be no
"MUST send" requirements for (fatal) alerts.

Also, I agree with Martin Rex's recent reply to this thread.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Dave Garrett <[email-masked]>
Date: Thu, 17 Sep 2015 19:09:53 -0400

[...]
> I hope the browsers won't implement reconnect version fallbacks again,

The unfortunate truth, is that once any fuzziness is allowed, everyone has to become fuzzy to adapt. The one browser that uses an insecure fallback is the one people says "works", and everyone else is "broken". Vendors do not have the strength to resist this.

Also, this is all a confusing mess. Nobody can say with a straight face that this is clean and straightforward. We'd need to make a new protocol to try that. Version fallback needs SCSV to be safe (which I forgot to mention in a previous email), the session hash extension is needed to avoid certain MitM, there's a renegotiation fix extension... if we want to get this working at all, we need the information feedback to react to. This cannot be improved to an ideal state. TLS MUST be replaced at some point if we want to make things better here.

To note again, because this thread is also now a bit of a mess, I'm not entirely against the notion of restricting what alerts _clients_ send. That's a related but different matter, as far as I'm concerned. To work in this current environment, though, servers need to report proper errors for anyone to attempt to work without expecting developers to resort to unsafe kludges really quickly. They shouldn't, but we know they do.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Thu, 17 Sep 2015 19:15:36 -0400

> Is it a 120% interop failure then?

Well, yeah, sort of. :p

If it's going to fail, I want it to fail in a way we can get it fixed. If I get a server in one of the giant tracking meta-bugs for servers that have TLS failures and I can see what is wrong, we can point to something to get fixed. If not, then we have nothing to go on and it probably won't be fixed ever.

Dave

---

From: Brian Smith <[email-masked]>
Date: Thu, 17 Sep 2015 17:20:22 -0700

On Thu, Sep 17, 2015 at 4:15 PM, Dave Garrett <[email-masked]>
wrote:

> If it's going to fail, I want it to fail in a way we can get it fixed. If
> I get a server in one of the giant tracking meta-bugs for servers that have
> TLS failures and I can see what is wrong, we can point to something to get
> fixed. If not, then we have nothing to go on and it probably won't be fixed
> ever.
>

Whether or not the server sends an alert doesn't matter for that. The user
gets a cryptic error message either way, and bugs get filed and tracked.
Here are two of many examples:

https://bugzilla.mozilla.org/show_bug.cgi?id=704990
https://bugzilla.mozilla.org/show_bug.cgi?id=698203

Cheers,
Brian
-- 
https://briansmith.org/

---

From: David Benjamin <[email-masked]>
Date: Thu, 17 Sep 2015 22:23:27 +0000

Besides, fallback conditions tend to be extremely liberal in my experience.
Which makes sense since it's used against buggy servers. If a buggy server
blew up because it's version-intolerant, it's not likely to be kind enough
to tell you that.

While I don't see much use in "your records don't authenticate" and "that's
not even a syntactically valid ServerKeyExchange!", not all failures are
protocol failures. There's also negotiation failures when parameters aren't
okay. When removing cipher suites or bumping minimum versions, it's nice to
show a dedicated error message when it goes wrong.

David

---

From: Hubert Kario <[email-masked]>
Date: Fri, 18 Sep 2015 13:27:41 +0200

On Thursday 17 September 2015 15:30:12 Brian Smith wrote:
> A conformant TLS 1.3 implementation cannot be version intolerant. If
> it were version intolerant then it would not be a conformant TLS 1.3
> implementation. So, conformance requirements for TLS .1.3 servers
> don't matter as far as version intolerance is concerned.

except that a TLS1.3 version intolerant implementation won't show its 
ugly head until TLS1.4 gets deployed

"non conformant" TLS1.2 is in same boat. Just because it can 
interoperate (the *only* thing PHBs care about) doesn't mean it is 
conformant (that's the stuff we care about because that means backwards 
and *forwards* compatibility)

> > configurations are pretty commonplace, the most common being one
> > where there is no common cipher suite.  Being able to isolate the
> > error that is pretty useful.
> 
> I still think it is better to recommend to never send alerts. But, at
> least there are good reasons (which I gave much earlier in the
> thread) for why a server would choose not to send alerts, e.g. out of
> an abundance of caution. So, "MUST send" is clearly too far.

Sorry, but there are no good reasons why not to send them. Not sending 
them may cause interoperability issues in the future, so an 
implementation, if at all possible, should send them. That makes them a 
MUST.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Hubert Kario <[email-masked]>
Date: Fri, 18 Sep 2015 13:36:29 +0200

On Friday 18 September 2015 00:58:19 Martin Rex wrote:
> 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".
> 

That's true only if you ignore the situation when TLS 1.4 or TLS 2.0 is 
deployed.

So yes, it's no a direct interoperability issue, but it will become one 
in the future.

The same way as TLS protocol version in Client Hello

---

From: Brian Smith <[email-masked]>
Date: Fri, 18 Sep 2015 13:24:33 -0700

> in the future.

Given a *conformant* TLS 1.3 implementation, that kind of interoperability
problem could only happen if the TLS working group specifically designed it
to happen. In particular, a conformant TLS 1.3 implementation must accept
larger values of ClientHello.client_version.

Right. We already have ample evidence that shows it is not reasonable for
TLS 1.3 nor future versions can use ClientHello.client_version to signal
the TLS version, due to broken non-TLS-1.3 implementations. But, unless a
terrible mistake is made, whether or not a conformant TLS 1.3
implementation sends alert will not matter in those interactions.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Sep 2015 15:34:14 -0500

On 09/18/2015 03:24 PM, Brian Smith wrote:
> On Fri, Sep 18, 2015 at 4:36 AM, Hubert Kario <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Given a *conformant* TLS 1.3 implementation, that kind of
> interoperability problem could only happen if the TLS working group
> specifically designed it to happen. In particular, a conformant TLS
> 1.3 implementation must accept larger values of
> ClientHello.client_version.
>

It seems like the unstated point was that writing a conformant TLS 1.3
implementation from scratch is hard, and the only approximation to a
conformance test that we have is interoperability with different TLS 1.3
implementations.  We should be prepared to encounter things that are
almost conformant TLS 1.3 implementations and interoperate fully, but
have subtle bugs that could cause forward-incompatibilities due to
undetected non-conformities.  The paper shield of "but they're not
conformant" does not provide much cover for us to completely ignore this
possibility.

-Ben

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 18 Sep 2015 13:48:21 -0700

On Friday, September 18, 2015, Benjamin Kaduk <[email-masked]> wrote:
> implementations.

My 2c on this:

- I think alerts are of waning usefulness as we move to better
cryptographic primitives (which I've been fighting hard for on the CFRG
list)
- Alerts have the potential to be sidechannels which are useful to
attackers and would weaken overall security
- I understand the utility of alerts for debugging, but why not make them a
debugging-only feature?

For what it's worth, where I work we run thousands of services on thousands
of servers, almost all of which utilize mutual TLS authentication, and I
have literally never needed to use alerts to debug a problem. I probably
spend on average at least 5 hours a week helping people debug TLS interop
problems. But I *do* worry that if alerts were mandatory, they could be
used against us.

-- 
Tony Arcieri

---

From: Dave Garrett <[email-masked]>
Date: Fri, 18 Sep 2015 16:49:51 -0400

On Friday, September 18, 2015 04:24:33 pm Brian Smith wrote:
> [...] unless a terrible mistake is made [...]

We're designing a security protocol to be used globally. We should be assuming that not only will we have at least one terrible mistake, but also that there's at least a few more that have already been made that we haven't found yet, but will still need to handle. Again, this is a 20 year old mess of a protocol; no development can stem from any premise that expects no flaws.

Dave

---

From: Bill Frantz <[email-masked]>
Date: Fri, 18 Sep 2015 15:13:37 -0700

On 9/18/15 at 4:27 AM, [email-masked] (Hubert Kario) wrote:

>except that a TLS1.3 version intolerant implementation won't 
>show its ugly head until TLS1.4 gets deployed

Is there a reason a test suite can't offer TLS 1.4, even if we 
don't know what it is? The TLS implementation under test should 
gracefully step back to TLS 1.3.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"Web security is like medicine - trying to 
do good for
408-356-8506       |an evolved body of kludges" - Mark Miller
www.pwpconsult.com |

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 19 Sep 2015 13:28:24 +0200

> close by a conformant TLS 1.3 implementation then it is guaranteed to be

Let me correct that for you:

A conformant TLS 1.0 implementation will not be version intolerant. If the
client does version fallback then it is guaranteed to be doing the wrong
thing.

Kurt

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 19 Sep 2015 15:14:07 +0200

>From what I understand, the RST is send after calling close(),
shutdown(SHUT_RD) or shutdown(SHUT_RDWR) and not all data has
been read from the socket or more data is received.

So my understanding of making sure the other end receives it is
calling close() when read() returns 0 (or an error).  You might
want to do shutdown(SHUT_WR) before that to indicate you're not
going to send anything anymore, but that should have no effect
since the other end is supposed to close the connection after
receiving the alert anyway.  You might want to have a timeout and
close it anyway.  If read() returns any data, you should of course
throw it away.

It seems that when you using SO_LINGER you might end up turning
your non-blocking socket into a blocking one on close() (or
shutdown?), and can't even tell if it was received succesfully or
not.

But I wonder in which cases it's important to receive the fatal
alert.  I guess it's the cases where it can tell you that
connecting again might work, and so would only be during the
handshake.  The only case I can think of is something like "client
certificate required", and as far as I know we don't even
currently have something that says that explicitly.

Kurt

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 19 Sep 2015 18:32:26 +0000

> currently have something that says that explicitly.

Alerts are very important in resolving interoperability problems,
they probably should not generally lead to different peer behaviour
than had the connection been closed instead.  The handshake failed,
try another server if there are multiple A records, SRV records,
...  or else give up.

Alerts SHOULD be sent (on a best-effort basis) and are typically
not lost.  This discussion seems much too long/complicated.  Send
the requisite alert, and close, it might not arrive, but that's
not the sender's problem if the peer closes prematurely or the
network is layer is lossy.

-- 
	Viktor.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 21 Sep 2015 12:35:55 +0200

On Friday 18 September 2015 15:13:37 Bill Frantz wrote:
> don't know what it is?

There is no reason. In fact, any test suite should basically start with 
this (it being one of the very first fields the server needs to handle).

> The TLS implementation under test should

correct

---

From: Hubert Kario <[email-masked]>
Date: Mon, 21 Sep 2015 12:45:25 +0200

On Friday 18 September 2015 13:24:33 Brian Smith wrote:
> > That's true only if you ignore the situation when TLS 1.4 or TLS 2.0
> > is deployed.
> 

Given that there is no *conformant* TLS 1.2 implementation that is 
widely deployed[1], I won't hold my breath for there being many TLS1.3 
ones either.

We don't live in ideal world, lets build protocols that can handle 
breakage. Lets make specifications that have the sticks that we can hit 
developers with when they do wrong.

 1 - NSS, SChannel and OpenSSL, all ignore some MUSTs in TLS1.2
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic