Re: [secdir] secdir review of draft-ietf-tls-grease

Sean Turner <> Tue, 13 August 2019 15:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F6341200FA for <>; Tue, 13 Aug 2019 08:52:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TzP4WjmESZnH for <>; Tue, 13 Aug 2019 08:52:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83E83120273 for <>; Tue, 13 Aug 2019 08:52:29 -0700 (PDT)
Received: by with SMTP id j15so13222111qtl.13 for <>; Tue, 13 Aug 2019 08:52:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jSFF+SmVZBRyN4TdQJT+4Hz9oKz5tg8Jkygdw6mZumo=; b=MwFcVS2hMxZUssfoBc0b3g8AfdxaTWsmmleh/uC5UAR+kw3JiLdJVDqRR6VRikkVuH jXeyIk4gfHazAT0jJHdhn+zXKRixATt5XhHvpqyuoQI9q1FI3UAeQv2X3u2E0rGmtcV3 pelFhz19jGPTUbBGEUnOpSG6agL7dKM5GDQXw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jSFF+SmVZBRyN4TdQJT+4Hz9oKz5tg8Jkygdw6mZumo=; b=h5m73vynPcQw16Nt4A/KDkQpTSoh7iiOXGhYOkmCuMt2T8Xg4paF6gVO7X7Qm9nCC1 M82DI3mvp3WDPOubSUYK7aU3sj5MCuE6vbodAKqPnmqULL0R0CL4q9YCMo708oIyt2a6 gvogG0DoRqYFLugpvF745Wx55HF6RQvHis645vXCEGbkAzoATazI+6GGWcgQKYF1OJyo /RkWyjoC3xKK2rJ7fm3RMP53aFY4o4vfGBT0O5LZdutJRUYasxUK9zYJX6uC1wZNQoks NpIF+4ZY3oDwyZw7OROFp+DZ1v0DC6UDGL7KNNLq7hk5/F9WkoZPc6BL1Dho0l9zF3IC gQUg==
X-Gm-Message-State: APjAAAXbcIbu4fUFatnjjtIm6dptFjKTVdygS2PqPWfEh+ehfJmFBghy XmUXPoyjZcpi8zMjiD+1qBcHWQ==
X-Google-Smtp-Source: APXvYqyndEdffyyY27HkJX/aC9G4tB33kddBT0LZCG6DZ/BOCL2tDAAXif24bUZ7UBJ4cj+tCzFKrg==
X-Received: by 2002:ac8:7402:: with SMTP id p2mr13785663qtq.182.1565711548708; Tue, 13 Aug 2019 08:52:28 -0700 (PDT)
Received: from sn3rd.lan ([]) by with ESMTPSA id k25sm60601035qta.78.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Aug 2019 08:52:28 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sean Turner <>
In-Reply-To: <>
Date: Tue, 13 Aug 2019 11:52:27 -0400
Cc: The IESG <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Carl Wallace <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-tls-grease
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Aug 2019 15:52:33 -0000

> On Aug 13, 2019, at 10:37, Carl Wallace <> wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments
> just like any other last call comments.
> This document describes a mechanism to prevent extensibility failures in
> the TLS ecosystem.  It reserves a set of TLS protocol values that may be
> advertised to ensure peers correctly handle unknown values. Aside from a
> nit/question, the document is ready.
> The question relates to language in section 2. which states: "The values
> allocated above are thus no longer available for use as TLS or DTLS
> [RFC6347] version numbers." Should this draft be marked as updating 6347
> and 8446 as a result? At present it is Informational and does not update
> any other specifications.

I tend to think that an updates header is not required.  RFCs that allocate and reserve code points do not need to update the RFC that originally created them.  For example, RFC5764/RFC7983 reserve a block of TLS ContentType space and neither of the those drafts updated the base TLS spec.