Re: [Gen-art] review of draft-ietf-tls-grease-03.txt
Benjamin Kaduk <kaduk@mit.edu> Fri, 23 August 2019 17:15 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3807120044; Fri, 23 Aug 2019 10:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 pGOFCTj6Y6H2; Fri, 23 Aug 2019 10:15:49 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDDB12000F; Fri, 23 Aug 2019 10:15:48 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7NHFYLj020523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Aug 2019 13:15:36 -0400
Date: Fri, 23 Aug 2019 12:15:34 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: David Benjamin <davidben@google.com>
Cc: Francis Dupont <Francis.Dupont@fdupont.fr>, General Area Review Team <gen-art@ietf.org>, draft-ietf-tls-grease.all@ietf.org
Message-ID: <20190823171533.GC60855@kduck.mit.edu>
References: <201908140721.x7E7LnLS028016@givry.fdupont.fr> <CAF8qwaD5gYyQ5rJSzy-0CKqJnjcnGuuM8E7WY8EU84MXPUt7jQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAF8qwaD5gYyQ5rJSzy-0CKqJnjcnGuuM8E7WY8EU84MXPUt7jQ@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/-n-31F9PT363k_fOewZ447msgZs>
Subject: Re: [Gen-art] review of draft-ietf-tls-grease-03.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Aug 2019 17:15:51 -0000
On Wed, Aug 21, 2019 at 05:55:44PM -0400, David Benjamin wrote: > On Wed, Aug 14, 2019 at 4:09 AM Francis Dupont <Francis.Dupont@fdupont.fr> > wrote: > > > - 5 page 7: I have a concern about your use of the term random. In fact > > even it is a security document here random is just plain English > > (vs any crypto meaning). Constraints seems to be: > > * coverage: the set of used values should not be small > > * privacy: fingerprinting should not be easy > > I do not propose any solution: just follow recommendations of > > the security directorate in the case this point is a problem. > > > > Ack. +Benjamin Kaduk <kaduk@mit.edu>, do you have preferences on this? I > don't think the requirements on "random" are particularly strong, so I > don't know if we should prescribe cryptographic randomness. At the same > time, it is perhaps odd to just say "random". I think it's okay to just say "random" here. There's no harm if someone chooses to use cryptographic randomness, but it's also okay to make a predictable choice (by using poor-quality randomness to guide what is, in essence, an arbitrary selection). -Ben > My implementation just draws from the PRNG because it's easy, but if the > values are predictable, it doesn't expose user-fingerprinting surface, > which is the more important one. (User-fingerprinting would come more from > doing something stateful or user-specific.) It does expose > implementation-fingerprinting surface, but even sending GREASE does so too. > TLS is full of implementation decision and policy points (e.g. the entire > ClientHello), nearly every one of which contributes to the implementation > fingerprint. :-/
- [Gen-art] review of draft-ietf-tls-grease-03.txt Francis Dupont
- Re: [Gen-art] review of draft-ietf-tls-grease-03.… David Benjamin
- Re: [Gen-art] review of draft-ietf-tls-grease-03.… Benjamin Kaduk