Subject: Re: [TLS] WGLC for draft-ietf-tls-grease

From: Sean Turner <[email-masked]>
Date: Tue, 26 Feb 2019 20:57:59 -0500

This messages closes the WGLC for draft-ietf-tls-grease.  The draft will progress as is because we received no WGLC comments.

spt

> On Jan 24, 2019, at 10:50, Sean Turner <[email-masked]> wrote:
> 
> This is the working group last call for the "Applying GREASE to TLS Extensibility" draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-grease/. Please review the document and send your comments to the list by 2359 UTC on 8 February 2019.
> 
> NOTE: There is one outstanding issue raised by Hubert [0].  Please chime in there or here so that we can address his comment one way or the other.
> 
> Thanks,
> Chris, Joe, and Sean
> 
> [0] https://mailarchive.ietf.org/arch/msg/tls/nr4dA2JqcpqAjh-oY_1z2l6ZMFo

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Feb 2019 08:54:17 +0000

Hiya,

On 27/02/2019 01:57, Sean Turner wrote:
> This messages closes the WGLC for draft-ietf-tls-grease.  The draft
> will progress as is because we received no WGLC comments.

Apologies for missing the WGLC. I've just read this and fully
support it progressing. I have one question though:

The drafts says: 'A client MAY select one or more GREASE extension
values and advertise corresponding extensions with varying length
and contents' and 'For each of these, the "key_exchange" field MAY
be any value.' and 'Implementations advertising GREASE values
SHOULD select them at random.'

I was left wondering what ranges of lengths and what values are
recommended to be sent for greasy extension bytes and key_exchange
values.

Reason to ask is I happened to be looking at a few handshakes and
noticed those lengths being zero in all cases IIRC. (It was only
3 cases being one 1 h/s from each of 3 browsers so could be I was
just unlucky or missed a non-zero greasy length.)

I've no strong opinion as to what'd be best to say about those
lengths but I guess maybe we'd want to see some greasy lengths
that are shorter than all real values, some that are longer and
many in between, and value octets that that are random when
lengths are non-zero.

Does that match what people do? If so, would it be worth adding
something about that to the document?

Cheers,
S.

PS: Since I'm late to the game I'm fine if the above's treated as
a random last call comment.

>> This is the working group last call for the "Applying GREASE to TLS
>> Extensibility" draft available at
>> https://datatracker.ietf.org/doc/draft-ietf-tls-grease/. Please
>> review the document and send your comments to the list by 2359 UTC
>> on 8 February 2019.
>> 
>> NOTE: There is one outstanding issue raised by Hubert [0].  Please
>> chime in there or here so that we can address his comment one way
>> or the other.
>> 
>> Thanks, Chris, Joe, and Sean
>> 
>> [0]
>> https://mailarchive.ietf.org/arch/msg/tls/nr4dA2JqcpqAjh-oY_1z2l6ZMFo
>
>> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hubert Kario <[email-masked]>
Date: Wed, 27 Feb 2019 13:30:16 +0100

> just unlucky or missed a non-zero greasy length.)

I'm not sure which part for the key_share extension you mean as being empty, 
but the key_exchange in the KeyShareEntry can't be empty, per RFC 8446, 
Section 4.2.8:

      struct {
          NamedGroup group;
          opaque key_exchange<1..2^16-1>;
      } KeyShareEntry;

Only the client_shares inside the KeyShareClientHello may be empty:

      struct {
          KeyShareEntry client_shares<0..2^16-1>;
      } KeyShareClientHello;

-- 
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: Stephen Farrell <[email-masked]>
Date: Wed, 27 Feb 2019 12:52:57 +0000

>           opaque key_exchange<1..2^16-1>;

Ah sorry, you're right - there is one byte in the
key_exchange with a value 0x00 in a greasy KeyShareEntry
I just looked at.

And a different browser doing tls1.2 sent 2 greasy
extensions, one with no data and another with a single
byte (0x00 again).

I guess my question remains though, as to whether more
bytes ought be sent in these fields sometimes and whether
or not they also ought be random values.

FWIW, I guess it'd make sense to send a range of random
length random values some of the time, but mostly I'm
wondering what other folks are doing/expecting.

Cheers,
S.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 27 Feb 2019 14:04:35 +0100

On Wednesday, 27 February 2019 13:52:57 CET Stephen Farrell wrote:
> > I'm not sure which part for the key_share extension you mean as being
> > empty, but the key_exchange in the KeyShareEntry can't be empty, per RFC
> > 8446,> 
> > Section 4.2.8:
> >       struct {
> >       
> >           NamedGroup group;

that's ok, the extensions in general can have empty payloads
 
> wondering what other folks are doing/expecting.

for extensions doing an empty one and one with just few bytes should be 
sufficient

For key_share, to simulate actual use I'd say the values should be at least 
few dozen bytes long. That does inflate unnecessarily the ClientHello, so it's 
a balancing act...