Re: [Gen-art] review of draft-ietf-tls-grease-03.txt

David Benjamin <davidben@google.com> Wed, 21 August 2019 21:56 UTC

Return-Path: <davidben@google.com>
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 BE74512010E for <gen-art@ietfa.amsl.com>; Wed, 21 Aug 2019 14:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 s29Fd0d0P_9t for <gen-art@ietfa.amsl.com>; Wed, 21 Aug 2019 14:56:01 -0700 (PDT)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2651200B6 for <gen-art@ietf.org>; Wed, 21 Aug 2019 14:56:01 -0700 (PDT)
Received: by mail-pl1-x62e.google.com with SMTP id c2so2070255plz.13 for <gen-art@ietf.org>; Wed, 21 Aug 2019 14:56:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6JNuaijf7CvmtCnMZS5yerSuHLWAFZio5eySoe6WbCE=; b=stQVjAmY8+yaZF+w6lFy3zrDkrlE0kf2+LJMAqJCmHuYpr6svCMeYfiDmxykRfCN1a yfawtSUgmwAbd4SazyESw4gWuSkv3uRDqOaL8Mz7V7p2L7iLM9zX3znE+XB2R90Fs2xj dYODFstF3aS/OptBYh1winnroPsUP3YbZOCu4tdNFHmLtSCwEMuiCjB1w507tbXjqiWT 49YSsIA6OmN7bR4fTKw3UZPzokPkctyQOQD9q1rPUkE4hzLIIhlZWvMTj0r8CxbdSUKb iP16c8OS1k46DbugR/U3ot8XIwnhZWSESBdjKiHtdVO9MxdO0YghO0tqsFv1rArDf7F6 J8qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6JNuaijf7CvmtCnMZS5yerSuHLWAFZio5eySoe6WbCE=; b=m8eO6v/jEIql+Qx59BEVJXWCB3fFe41LO1WqpHR2BP0YaqJqufLjFMLVL24Ta0QGcW dRHRImcAQeV2Jrsx6xvypFAIVQfrD7c8aLsQTgIIJSWn99gXJXtdQf0JyhBJ91CT8csN v3qNFo2tSf7JgbertuBIY6JCNmtGlkj9bLcAGubkETxxxgWv75PcwXdnQkNkhpTSPQJX Vopj1FKPRfEB9BQeTDPpwZLHwTVh3SDmaeeOReueBPhotI2AJrOG9VTniZzVCyKV2HZU M1e+v6ZHxMtnFRCOs/H47ueeWC3YH2/3ba2iQhUiCkAVk70aEYM96mqQG2MYkXyrFHhB 2JCQ==
X-Gm-Message-State: APjAAAUenYzb3rFXRoaIwwi/I3mB6iALpbRkMVCgY5ojxY0GZtOfm6KQ 8v9oV4RKtKqWI8zXfCdez6wZrYs83INtb0nCf+1/
X-Google-Smtp-Source: APXvYqx7bYNJOyla756P/RD1xsqHUuFc11N3Sdyqo0yyNL0NkNwNZd/qVZ/b+CyBto3UAApafQiYlIKP3g7eH2XuhqE=
X-Received: by 2002:a17:902:f64:: with SMTP id 91mr5221783ply.334.1566424560334; Wed, 21 Aug 2019 14:56:00 -0700 (PDT)
MIME-Version: 1.0
References: <201908140721.x7E7LnLS028016@givry.fdupont.fr>
In-Reply-To: <201908140721.x7E7LnLS028016@givry.fdupont.fr>
From: David Benjamin <davidben@google.com>
Date: Wed, 21 Aug 2019 17:55:44 -0400
Message-ID: <CAF8qwaD5gYyQ5rJSzy-0CKqJnjcnGuuM8E7WY8EU84MXPUt7jQ@mail.gmail.com>
To: Francis Dupont <Francis.Dupont@fdupont.fr>, Benjamin Kaduk <kaduk@mit.edu>
Cc: General Area Review Team <gen-art@ietf.org>, draft-ietf-tls-grease.all@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007cea690590a7a364"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/kOwLN91_ri8wWIaxSPwhdhF5qpk>
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: Wed, 21 Aug 2019 21:56:04 -0000

On Wed, Aug 14, 2019 at 4:09 AM Francis Dupont <Francis.Dupont@fdupont.fr>
wrote:

> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-tls-grease-03.txt
> Reviewer: Francis Dupont
> Review Date: 20190803
> IETF LC End Date: 20190812
> IESG Telechat date: 20190822
>
> Summary: Ready
>
> Major issues: None
>
> Minor issues: None
>
> Nits/editorial comments:
>  - ToC page 2 and 8 page 11: Acknowledgements -> Acknowledgments
>

Thanks! I've updated this in my local copy, which I'll publish as -04 later
this week.


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

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