Re: [TLS] inappropriate_fallback

[Eric Rescorla <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]
> > > <mailto:[e-mail]>> 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
>