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

Martin Thomson <> Sat, 26 January 2019 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 559D11311E1 for <>; Sat, 26 Jan 2019 13:46:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=E8tXNEZ7; dkim=pass (2048-bit key) header.b=I5mWeFi5
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K4GFcuj4Of68 for <>; Sat, 26 Jan 2019 13:46:34 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55EC91311DA for <>; Sat, 26 Jan 2019 13:46:34 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 6B91B21D19; Sat, 26 Jan 2019 16:46:33 -0500 (EST)
Received: from web2 ([]) by compute1.internal (MEProxy); Sat, 26 Jan 2019 16:46:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:subject:references:in-reply-to:date; s=fm1; bh=Bg0 Aj3HAKBa96iav7o9IPf6ZQl+6QLAa4BxOA1CKKRU=; b=E8tXNEZ7sSM8954VWK2 teqBsTAIuFmcQPTX5bH9ioGVlTVtROmcXkpEZYYGGHfNqNsayZaIWqWHsO77BGiS rhgLrKQpySi4WwLdEGcZOvfS1Tf7ocaYcPwhBLoKsKCV1fGIGTsBQgrz5Qfu8/mq bRKUQJPCwu7SCaK7JqqiW4L7oa4bFgvUdIt7etgEBHNYDOis7fmzQ1znZJKgVJmY nSLAIbQB4dx/clBWlOeqx4zG0cUu6ZbSuxIQOQmWPZ/BWThaER7Z+JM8AMXlaVcF dOh1uR+DCcyrxGS8/li4JRTkvJNH7amMLKr/RrEXEWbZP2tyuxb/J0S+yVmoVp1Q C9g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Bg0Aj3HAKBa96iav7o9IPf6ZQl+6QLAa4BxOA1CKK RU=; b=I5mWeFi5ky31Zx8+ep+ajCrMaixE4TwhVIT5rZZdMh0sPkTC7BidI60sl tgP9u1H40QyAsoQqjG44nCGnxFSkzS+b5IHhILbdqNGxhqA2mD28ddj65SiDwJwd SDjCS37stSE8VK0O4UiEo8dCo4efmldxfg/zlZG5Vp6CKjBs5L/KoI9BEWEKB4Yu TaibKjOpTKLSk0rpi5gIr6GJBLb6Bb1ABD6YqRTF9sgXOtiqNe3sUrIhsDb14j9W ItyiCQeHv5AFF1Zsj5JnM6fU/UH/G6+t4lXGpGRjzg/RtvzLkc1okJnpL91JDpkq gWrtoNje4SwGRVWVVCsUL0TdsyuNw==
X-ME-Sender: <xms:ONVMXC96hSo7P9eLC9O5CNI6zhruu81MaN5Fk1sleCmheSYP0BeDtg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrieeigdduheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkhffvggfgtg foufhfjgffsehtjeertdertdejnecuhfhrohhmpeforghrthhinhcuvfhhohhmshhonhcu oehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:ONVMXNrW7pu82yhM3u9NNZ1uclUEaerc3XnrrujKukUqkH7ki8tntg> <xmx:ONVMXKo8yG8nA2MYtng4nnog60wkNqomV2K9kJ9XT7Esn390tw7Piw> <xmx:ONVMXJNEK-obxvBRQG-Hg7obd97Pv0HnNb1IkRnXRZAX6bKm5t-e-A> <xmx:OdVMXD9cWpslOyG32fqmQgB19HnQUxdsHhQ9B4O62qODigbEfFaztQ>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6947762304; Sat, 26 Jan 2019 16:46:32 -0500 (EST)
Message-Id: <>
From: Martin Thomson <>
To: David Benjamin <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: Webmail Interface - ajax-36e4bfd3
References: <> <> <> <> <>
In-Reply-To: <>
Date: Sun, 27 Jan 2019 08:46:32 +1100
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: Sat, 26 Jan 2019 21:46:43 -0000

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

Yeah, it's not ideal.  Given that, I'd say that we don't need to say anything.  It's still safe to grease by setting smaller values, but the value in doing so is hopefully marginal.