Subject: [TLS] inappropriate_fallback

From: Matt Caswell <[email-masked]>
Date: Wed, 8 Aug 2018 14:05:00 +0100

Draft 28 defines the inappropriate_fallback alert as follows:

inappropriate_fallback  Sent by a server in response to an invalid
      connection retry attempt from a client

With the introduction of the downgrade protection sentinels it now seems
that an inappropriate fallback could also be detected by the client.
Should this wording be changed?

Matt

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 8 Aug 2018 08:21:51 -0500

> Should this wording be changed?

Well, *fallback* specifically is inherently client-driven; the things the
client could detect would be more of an incorrectly negotiated version
(presumably due to an active attack).

-Ben

---

From: Matt Caswell <[email-masked]>
Date: Wed, 8 Aug 2018 14:26:28 +0100

> (presumably due to an active attack).

Consider the scenario where a server supports TLSv1.3/TLSv1.2 but does
not support RFC7507 (TLS Fallback Signalling Cipher Suite Value).

If the client attempts a TLSv1.3 connection first and fails (e.g. an
active attacker prevented it) and then falls back to TLSv1.2 it would be
able to detect that its fallback attempt was inappropriate when it sees
the downgrade protection sentinels. In that case inappropriate_fallback
seems reasonable.

Matt

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Aug 2018 06:45:36 -0700

> the downgrade protection sentinels. In that case inappropriate_fallback

I don't think that is the alert I would choose in this circumstance.
Probably "illegal_parameter"

-Ekr

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

---

From: Matt Caswell <[email-masked]>
Date: Wed, 8 Aug 2018 14:52:27 +0100

On 08/08/18 14:45, Eric Rescorla wrote:
> 
> 
> On Wed, Aug 8, 2018 at 6:26 AM, Matt Caswell <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> 

illegal_parameter suggests to me that the peer is misbehaving in some
way - which isn't the case here? Also it seems strange that we would
have a more explicit alert than the generic illegal_parameter, that
seems to precisely describe the scenario (a fallback occurred, and it
turns out it was inappropriate) but not be able to use it.

Matt

>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tls>
> 
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 8 Aug 2018 09:01:59 -0500

> turns out it was inappropriate) but not be able to use it.

Aren't the semantics here "whoops, I made a new connection attempt that
I shouldn't have; let me go back out of that"?  In which case one could
argue even for close_notify...

-Ben

---

From: Matt Caswell <[email-masked]>
Date: Wed, 8 Aug 2018 15:05:34 +0100

> argue even for close_notify...

Well, it is an error condition. The client is expecting this to be ok
and it isn't and has to abruptly close. close_notify doesn't seem like a
good match to me.

Matt

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Aug 2018 07:06:00 -0700

The spec is actually extremely clear on this point
https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.3

   TLS 1.3 clients receiving a ServerHello indicating TLS 1.2 or below
   MUST check that the last 8 bytes are not equal to either of these
   values.  TLS 1.2 clients SHOULD also check that the last 8 bytes are
   not equal to the second value if the ServerHello indicates TLS 1.1 or
   below.  If a match is found, the client MUST abort the handshake with
   an "illegal_parameter" alert.

I think it's way late to change it.

-Ekr

---

From: Matt Caswell <[email-masked]>
Date: Wed, 8 Aug 2018 15:11:15 +0100

On 08/08/18 15:06, Eric Rescorla wrote:
> <https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.3>
> 

In this case the client is acting as a TLS 1.2 client so I don't think
that this paragraph applies.

Matt

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Aug 2018 07:21:30 -0700

> that this paragraph applies.

Well, not quite. It's a TLS 1.3 implementation that has sent a TLS 1.2 CH,
but that looks the same to the server as an active downgrade. This text was
is in fact intended to cover this case -- and that's how NSS interprets it
--  though perhaps it's not as explicit as one would like.

Regardless, I think illegal_parameter is a reasonable alert to send,
especially as sending a separate alert in the case of fallback and of
active downgrade is a pain.

-Ekr

---

From: Matt Caswell <[email-masked]>
Date: Wed, 8 Aug 2018 15:25:37 +0100

On 08/08/18 15:21, Eric Rescorla wrote:
> 
> 
> On Wed, Aug 8, 2018 at 7:11 AM, Matt Caswell <[email-masked]
>     > <https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.3
>     <https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.3>>
>     > 
> Well, not quite. It's a TLS 1.3 implementation that has sent a TLS 1.2
> CH, but that looks the same to the server as an active downgrade. This
> text was is in fact intended to cover this case -- and that's how NSS
> interprets it --  though perhaps it's not as explicit as one would like.

Fair enough if that was the intention at the time. It's not clear to me
from the text - but ok. I do think inappropriate_fallback would have
been a better choice for this scenario - but I realise I'm raising this
at the last possible moment!

Matt

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 9 Aug 2018 08:07:26 +0000

>https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.3

I hadn't looked at this bit too closely before, but since it says:

   If negotiating TLS 1.1 or below, TLS 1.3 servers MUST and TLS 1.2
   servers SHOULD set the last eight bytes of their Random value ...
   
   [second value]

[...]

   TLS 1.2 clients SHOULD also check that the last eight bytes
   are not equal to the second value if the ServerHello indicates TLS
   1.1 or below.  If a match is found, the client MUST abort the
   handshake

Doesn't this mean that no-one can ever use TLS 1.1 or below any more? The
server has to set its Random signalling bytes to X if it wants TLS 1.1 or
below, and then the client has to abort the handshake if it finds those bytes.

Peter.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 9 Aug 2018 06:53:39 -0500

[changed subject to reflect forking of thread]

> below, and then the client has to abort the handshake if it finds those bytes.

Well, what do you mean by "no one"?  A TLS 1.1-only implementation will happily
negotiate 1.1 and take no special action on the signalling random value.
A 1.2-capable implementation that is configured to only offer 1.1 should be
able to behave similarly.

-Ben

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 9 Aug 2018 11:57:20 +0000

>able to behave similarly.

Except that it can't, because as soon as the server indicates use of TLS 1.1,
the client is required to abort the handshake.  Thus no one can use TLS 1.1 or
below, because the client is required to abort the handshake if the server
indicates it's using this.

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Aug 2018 05:25:51 -0700

On Thu, Aug 9, 2018 at 1:07 AM, Peter Gutmann <[email-masked]>
wrote:

> Eric Rescorla <[email-masked]> writes:
>

I don't believe so, no.

The server MUST set these bytes if it supports > TLS 1.1 and the client
MUST check them if it gets TLS 1.1 and it wants > TLS 1.1.

So if the server wants TLS 1.1, then it doesn't set the bytes. If the
client wants TLS 1.1, it doesn't check them. In either case, the handshake
succeeds.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Aug 2018 05:26:58 -0700

> indicates it's using this.

I believe you are misreading this text. The client is required to abort
only if the server
supplies the signalling bytes in ServerRandom, which a 1.1 server will not.

-Ekr

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Thu, 09 Aug 2018 14:34:39 +0200

On Thursday, 9 August 2018 13:57:20 CEST Peter Gutmann wrote:
> Except that it can't, because as soon as the server indicates use of TLS
> 1.1, the client is required to abort the handshake.  Thus no one can use
> TLS 1.1 or below, because the client is required to abort the handshake if
> the server indicates it's using this.

the signalling bytes must be included only if server has support for higher 
protocol versions enabled; if TLS 1.2 and TLS 1.3 is explicitly disabled on 
the server, it must not include those signalling bytes

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 9 Aug 2018 12:56:43 +0000

​Eric Rescorla <[email-masked]> writes:

>So if the server wants TLS 1.1, then it doesn't set the bytes.

If that's the case then the text that says:

needs to be fixed, beause as far as I can tell that's saying that if the
server wants TLS 1.1 then it has to set the bytes, not that it doesn't set the
bytes.

Here's an example of where this causes problems.  A TLS 1.2 client connects to
the server.  The server, a TLS 1.2 server, is configured to use TLS 1.1, so it
responds with the signalling bytes in its random value.  The client is now
required to abort the handshake even though everything is running as it
should.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 9 Aug 2018 13:00:04 +0000

>the server, it must not include those signalling bytes

Ah, OK.  In that case the text should probably make clear that "TLS 1.2
server" isn't "a server that implements RFC 5246" but "a server that's
currently configured to run TLS 1.2".

Peter.

---

From: Matt Caswell <[email-masked]>
Date: Thu, 9 Aug 2018 14:02:24 +0100

On 09/08/18 13:56, Peter Gutmann wrote:
> responds with the signalling bytes in its random value.

That's not the way I read it. If a server is configured to use TLSv1.1
then its not a TLSv1.3 server and this text doesn't apply (regardless of
whether the binary could do TLSv1.3 if it was configured differently).

Matt

>  The client is now

---

From: "Short, Todd" <[email-masked]>
Date: Thu, 9 Aug 2018 14:09:02 +0000

> On Aug 9, 2018, at 9:02 AM, Matt Caswell <[email-masked]> wrote:
> 
> 
> 

Agreed.

If a TLS 1.2 (capable) server is negotiating TLS 1.1 with a TLS 1.2 client, then it can’t be considered a TLS 1.2 server, otherwise, it would negotiate TLS 1.2.

It must be considered a TLS 1.1 server, since that is the maximum version it is configured to support.

--
-Todd Short
// [email-masked]
// "One if by land, two if by sea, three if by the Internet."

---

From: Hubert Kario <[email-masked]>
Date: Thu, 09 Aug 2018 18:11:43 +0200

On Thursday, 9 August 2018 16:09:02 CEST Short, Todd wrote:
> >> the server.  The server, a TLS 1.2 server, is configured to
> >> use TLS 1.1, so it responds with the signalling bytes in its random
> >> value.
> > 
> > 
> If a TLS 1.2 (capable) server is negotiating TLS 1.1 with a TLS 1.2 client,
> then it can’t be considered a TLS 1.2 server, otherwise, it would negotiate
> TLS 1.2.
 
> is configured to support.

actually, no, if it has both TLS 1.2 and TLS 1.1 enabled, then it is a TLS 1.2 
server, so receiving a TLS 1.1 ClientHello with FALLBACK_SCSV MUST fail with 
inappropriate_fallback

if it is has TLS 1.1 enabled, and nothing else, *then* it is TLS 1.1 server, 
and receiving a TLS 1.1 ClientHello with FALLBACK_SCSV SHOULD NOT fail (it may 
fail because of ciphersuite mismatch, but it MUST NOT fail because of the the 
FALLBACK_SCSV being present)

situation with TLS 1.3, TLS 1.2 and downgrade protection from Section 4.1.3 
(bottom of page 37 onwards:
https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-37) is exactly the 
same – it does not matter what is _implemented_ it matters what is _enabled_

---

From: "Short, Todd" <[email-masked]>
Date: Thu, 9 Aug 2018 18:00:27 +0000

> On Aug 9, 2018, at 12:11 PM, Hubert Kario <[email-masked]> wrote:
> 

^^^^^^^^^^^^^^^^^^^^^

This is the situation I am referring to TLS 1.1 only (even if it has disabled TLS 1.2 code). If TLS 1.2 were enabled in the above scenario, then TLS 1.2 would be negotiated with the TLS 1.2 client.
I explicitly stated "since that [TLS 1.1] is the maximum version it is configured to support".