Re: [TLS] I-D Action: draft-ietf-tls-grease-02.txt

David Benjamin <> Fri, 25 January 2019 16:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22E77130E7F for <>; Fri, 25 Jan 2019 08:23:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.052
X-Spam-Status: No, score=-14.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sCkqmAxHFFCP for <>; Fri, 25 Jan 2019 08:23:35 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::842]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E81F5130EE7 for <>; Fri, 25 Jan 2019 08:23:34 -0800 (PST)
Received: by with SMTP id r14so11341008qtp.1 for <>; Fri, 25 Jan 2019 08:23:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ywlhNXUjXBUFoHmfENrqtINrK1w3YxJzS9sllbAhH0w=; b=SOQ16kKj1b4TJlnjuNN6K2l/h5xHN+Y8rVjfBPPi06aMdLFHhhbfcjjcUCFbfdgq1D EFEFS8AvjkCgLe5UcEeKt3agyJRtFwHYqQT2pPnNLJmtRrZpns1qQTaT4Ara/1RJfH/i GWMmvz5PG57nA63bVf7RdIHNOFKCPRp9oxC7M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ywlhNXUjXBUFoHmfENrqtINrK1w3YxJzS9sllbAhH0w=; b=IrCUJrjnuY4dCYEGl0hQy7wirlcKit/NIETL0pCghIUwO9yJsUm8ml+7odD2e3+7bv RzICyLE+k+XDCIiDq+krYID2XOqmXY/HDfSc9NgvtXBZwPaRe+UDxy8HSy3ojA4QG4no BP2NTS17VIii825HbhABobaf1BWHhoQz5lQnOYQU9kyy1zdvPTfWCPq8AjkMAQIIX1Lx cjJb4zGAeuAHPbLNxZ6xPmcZVU1SYQaNIZdrl+QI1jMkm4GKPhHDMPAyrQ/v63Rgz4qY mO+g1oX5Zql3kSXMXpflcm1sOnpShynXS/3oTAcoldl245f2hYK4S/L/IHPzqArjndAx zbwg==
X-Gm-Message-State: AJcUukfd9Z/4i3IyGYa/PadwhzUDjIW8LDCA2BQsMn9/pEK/TUYfCO8U stU3MBhcdUG//OSfTqBtW0VGToccmN5wVQT2mBuuG24=
X-Google-Smtp-Source: ALg8bN5xk2IV+cTym+8QJGqM3wLz9bHOxXNuTdkk4M73UiMN6SnjMBgptKeUxNxZhK62yOKzhoqengfYL3oE+6FoAjE=
X-Received: by 2002:aed:3482:: with SMTP id x2mr11269922qtd.72.1548433413975; Fri, 25 Jan 2019 08:23:33 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Fri, 25 Jan 2019 10:23:22 -0600
Message-ID: <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="00000000000099b16105804abf2f"
Archived-At: <>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-02.txt
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Jan 2019 16:23:37 -0000

On Thu, Jan 24, 2019 at 5:03 PM Martin Thomson <> wrote:

> On Fri, Jan 18, 2019, at 07:23, David Benjamin wrote:
> > > while record_size_limit extension sends just one value, it does
> > > specifically
> > > allow the client to advertise higher values than the protocol versions
> or
> > > extensions would indicate
> > >
> > > I wonder if sending such values shouldn't be part of GREASE behaviour,
> > > even if
> > > it wouldn't use GREASE values...
> > >
> >
> > I think that should be sorted out in a separate document. This one's been
> > sitting around for a while as it is, and record_size_limit doesn't have
> an
> > RFC to cite yet. :-)
> I'm in two minds about this.  On the one hand, we don't need any actual
> machinery here, so why do anything?  On the other hand, it's just a note
> that this is possible, and adding that sort of note is easy.
> > The record_size_limit extension {{!RFC8449}} includes a value that can
> be greased by endpoints that don't place constraints on their record size.
> Advertising values larger than the protocol supports is permitted and has
> no effect on the behavior of a compliant peer.

I don't feel very strongly either way, though it is odd that it basically
contradicts the sender's rules in RFC 8449.

   Higher values are currently reserved for future
   versions of the protocol that may allow larger records; an endpoint
   MUST NOT send a value higher than the protocol-defined maximum record
   size unless explicitly allowed by such a future version or extension.
   A server MUST NOT enforce this restriction; a client might advertise
   a higher limit that is enabled by an extension or version the server

It does say "unless explicitly allowed by such a future version or
extension", so this is basically blanket overruling that sentence a few
months after publication. (But overruling it isn't entirely wrong, given
the current text imposes a future-proofing receiver rule that the sender is
forbidden from checking.)