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

Hubert Kario <hkario@redhat.com> Wed, 27 February 2019 12:30 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E64130EC8 for <tls@ietfa.amsl.com>; Wed, 27 Feb 2019 04:30:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zokt8M-6g6S3 for <tls@ietfa.amsl.com>; Wed, 27 Feb 2019 04:30:20 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0078130EC5 for <tls@ietf.org>; Wed, 27 Feb 2019 04:30:19 -0800 (PST)
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7918FC0ABF51; Wed, 27 Feb 2019 12:30:19 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4331B5DE86; Wed, 27 Feb 2019 12:30:18 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 27 Feb 2019 13:30:16 +0100
Message-ID: <2350834.CDpgWZAquZ@pintsize.usersys.redhat.com>
In-Reply-To: <bb30427a-f9b1-16c1-648c-76d18cc0d4fb@cs.tcd.ie>
References: <ED498E62-2695-4760-9C47-BC8D54787E64@sn3rd.com> <04D78BE6-2048-4EC0-A191-68AFD8D71A68@sn3rd.com> <bb30427a-f9b1-16c1-648c-76d18cc0d4fb@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart70516280.FWkIIZ7GgO"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 27 Feb 2019 12:30:19 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jkoTBS5VzePIDqWeYy11T4sKgQA>
Subject: Re: [TLS] WGLC for draft-ietf-tls-grease
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2019 12:30:26 -0000

On Wednesday, 27 February 2019 09:54:17 CET Stephen Farrell wrote:
> 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'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;
 
> 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.
> 
> > spt
> > 
> >> On Jan 24, 2019, at 10:50, Sean Turner <sean@sn3rd.com> 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
> > 
> > _______________________________________________ TLS mailing list
> > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls


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