Re: [TLS] inappropriate_fallback

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

Re: [TLS] inappropriate_fallback

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

Re: [TLS] inappropriate_fallback

> 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

Re: [TLS] inappropriate_fallback

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

Re: [TLS] inappropriate_fallback

​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

Re: [TLS] inappropriate_fallback

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 T

Re: [TLS] inappropriate_fallback

​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

Re: [TLS] inappropriate_fallback

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

Re: [TLS] inappropriate_fallback

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

Re: [TLS] inappropriate_fallback

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

Re: [TLS] inappropriate_fallback

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 c

Re: [TLS] inappropriate_fallback

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 K

Re: [TLS] inappropriate_fallback

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

Re: [TLS] inappropriate_fallback

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

Re: [TLS] inappropriate_fallback

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

Re: [TLS] inappropriate_fallback

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

Re: [TLS] inappropriate_fallback

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

[TLS] inappropriate_fallback

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 detec