Re: [TLS] inappropriate_fallback

[Short, Todd]

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

> On Aug 9, 2018, at 12:11 PM, Hubert Kario  wrote:
> 
> On Thursday, 9 August 2018 16:09:02 CEST Short, Todd wrote:
>>> On Aug 9, 2018, at 9:02 AM, Matt Caswell  wrote:
>>> 
>>> 
>>> 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
>>> 
>> 
>> 
>> 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.
> 
> 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)

^

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

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



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] inappropriate_fallback

[Hubert Kario]

On Thursday, 9 August 2018 16:09:02 CEST Short, Todd wrote:
> > On Aug 9, 2018, at 9:02 AM, Matt Caswell  wrote:
> > 
> > 
> > 
> > On 09/08/18 13:56, Peter Gutmann wrote:
> > 
> >> ​Eric Rescorla  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:
> >> 
> >> 
> >>   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 ...
> >> 
> >> 
> >> 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.
> > 
> > 
> > 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
> > 
> 
> 
> 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.

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_

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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] inappropriate_fallback

[Short, Todd]

> On Aug 9, 2018, at 9:02 AM, Matt Caswell  wrote:
> 
> 
> 
> On 09/08/18 13:56, Peter Gutmann wrote:
>> ​Eric Rescorla  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:
>> 
>>   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 ...
>> 
>> 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.
> 
> 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
> 

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
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."


> 
>> The client is now
>> required to abort the handshake even though everything is running as it
>> should.
>> 
>> Peter.
>> ___
>> 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] inappropriate_fallback

[Matt Caswell]

On 09/08/18 13:56, Peter Gutmann wrote:
> ​Eric Rescorla  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:
> 
>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 ...
> 
> 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.

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
> required to abort the handshake even though everything is running as it
> should.
> 
> Peter.
> ___
> 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

Re: [TLS] inappropriate_fallback

[Peter Gutmann]

​Eric Rescorla  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:

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

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

Re: [TLS] inappropriate_fallback

[Eric Rescorla]

On Thu, Aug 9, 2018 at 1:07 AM, Peter Gutmann 
wrote:

> Eric Rescorla  writes:
>
> >The spec is actually extremely clear on this point
> >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.
>

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


> Peter.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] inappropriate_fallback

[Matt Caswell]

On 08/08/18 15:21, Eric Rescorla wrote:
> 
> 
> On Wed, Aug 8, 2018 at 7:11 AM, Matt Caswell  > wrote:
> 
> 
> 
> On 08/08/18 15:06, Eric Rescorla wrote:
> > 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.
> 
> In this case the client is acting as a TLS 1.2 client so I don't think
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] inappropriate_fallback

[Eric Rescorla]

On Wed, Aug 8, 2018 at 7:11 AM, Matt Caswell  wrote:

>
>
> On 08/08/18 15:06, Eric Rescorla wrote:
> > 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.
>
> In this case the client is acting as a TLS 1.2 client so I don't think
> 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


> Matt
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] inappropriate_fallback

[Matt Caswell]

On 08/08/18 15:06, Eric Rescorla wrote:
> 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.

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

Matt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] inappropriate_fallback

[Eric Rescorla]

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





On Wed, Aug 8, 2018 at 7:01 AM, Benjamin Kaduk  wrote:

> On Wed, Aug 08, 2018 at 02:52:27PM +0100, Matt Caswell wrote:
> >
> >
> > On 08/08/18 14:45, Eric Rescorla wrote:
> > >
> > >
> > > On Wed, Aug 8, 2018 at 6:26 AM, Matt Caswell  > > > wrote:
> > >
> > >
> > >
> > > On 08/08/18 14:21, Benjamin Kaduk wrote:
> > > > On Wed, Aug 08, 2018 at 02:05:00PM +0100, Matt Caswell wrote:
> > > >> 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?
> > > >
> > > > 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).
> > >
> > > 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.
> > >
> > >
> > > I don't think that is the alert I would choose in this circumstance.
> > > Probably "illegal_parameter"
> >
> > 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.
>
> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] inappropriate_fallback

[Matt Caswell]

On 08/08/18 15:01, Benjamin Kaduk wrote:
> On Wed, Aug 08, 2018 at 02:52:27PM +0100, Matt Caswell wrote:
>>
>>
>> On 08/08/18 14:45, Eric Rescorla wrote:
>>>
>>>
>>> On Wed, Aug 8, 2018 at 6:26 AM, Matt Caswell >> > wrote:
>>>
>>>
>>>
>>> On 08/08/18 14:21, Benjamin Kaduk wrote:
>>> > On Wed, Aug 08, 2018 at 02:05:00PM +0100, Matt Caswell wrote:
>>> >> 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?
>>> > 
>>> > 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).
>>>
>>> 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.
>>>
>>>
>>> I don't think that is the alert I would choose in this circumstance.
>>> Probably "illegal_parameter"
>>
>> 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.
> 
> 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...

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] inappropriate_fallback

[Benjamin Kaduk]

On Wed, Aug 08, 2018 at 02:52:27PM +0100, Matt Caswell wrote:
> 
> 
> On 08/08/18 14:45, Eric Rescorla wrote:
> > 
> > 
> > On Wed, Aug 8, 2018 at 6:26 AM, Matt Caswell  > > wrote:
> > 
> > 
> > 
> > On 08/08/18 14:21, Benjamin Kaduk wrote:
> > > On Wed, Aug 08, 2018 at 02:05:00PM +0100, Matt Caswell wrote:
> > >> 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?
> > > 
> > > 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).
> > 
> > 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.
> > 
> > 
> > I don't think that is the alert I would choose in this circumstance.
> > Probably "illegal_parameter"
> 
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] inappropriate_fallback

[Matt Caswell]

On 08/08/18 14:45, Eric Rescorla wrote:
> 
> 
> On Wed, Aug 8, 2018 at 6:26 AM, Matt Caswell  > wrote:
> 
> 
> 
> On 08/08/18 14:21, Benjamin Kaduk wrote:
> > On Wed, Aug 08, 2018 at 02:05:00PM +0100, Matt Caswell wrote:
> >> 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?
> > 
> > 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).
> 
> 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.
> 
> 
> I don't think that is the alert I would choose in this circumstance.
> Probably "illegal_parameter"

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


> 
> -Ekr
> 
> 
> Matt
> 
> ___
> 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

Re: [TLS] inappropriate_fallback

[Eric Rescorla]

On Wed, Aug 8, 2018 at 6:26 AM, Matt Caswell  wrote:

>
>
> On 08/08/18 14:21, Benjamin Kaduk wrote:
> > On Wed, Aug 08, 2018 at 02:05:00PM +0100, Matt Caswell wrote:
> >> 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?
> >
> > 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).
>
> 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.
>

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

-Ekr


> Matt
>
> ___
> 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

Re: [TLS] inappropriate_fallback

[Matt Caswell]

On 08/08/18 14:21, Benjamin Kaduk wrote:
> On Wed, Aug 08, 2018 at 02:05:00PM +0100, Matt Caswell wrote:
>> 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?
> 
> 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).

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] inappropriate_fallback

[Benjamin Kaduk]

On Wed, Aug 08, 2018 at 02:05:00PM +0100, Matt Caswell wrote:
> 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?

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] inappropriate_fallback

[Matt Caswell]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls