Re: [TLS] TLS ExtensionType Registry

Martin Thomson <> Fri, 12 August 2016 06:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD67F12D779 for <>; Thu, 11 Aug 2016 23:39:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tHWkyh6hBPz0 for <>; Thu, 11 Aug 2016 23:39:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 42BF612D54D for <>; Thu, 11 Aug 2016 23:39:52 -0700 (PDT)
Received: by with SMTP id t7so17490790qkh.0 for <>; Thu, 11 Aug 2016 23:39:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NfMDToJc9G9OWe+p3JBH5kqSZG9sZewhd152HAx3YVY=; b=V55Al8mgjwe3+/SoIXEJ1iNdHLFowy0K6c8TrjpgdBlCsjwnPUoYz1DvAHJMOcrvpm K0VULDqMswc6CmuxvI+L62oTtJMNbJbkDIdtcxcSr/eWwl65cjXT8DxrcKixCujlZKj9 NNzDRVUmOPDgpwH1lrxajtYiX6DVTrx5ljs9/dqltqdWOEiFsI8zv1DIGsMkWoQk6Qf+ I1tpj03P/bCmLr54yEX9ry/3zQ75c6nCruPN8JiM78YFfsXU4xMznEXWv60ioIQ7TlSp g/45D3npZUnXxFOtBXvf9NQYaDcPnxh+ub900Ap6JBTH800GZk1zv+FJfZjubDlPpKrJ 7aeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NfMDToJc9G9OWe+p3JBH5kqSZG9sZewhd152HAx3YVY=; b=lzNKm66P8rhf5/zgAN4wqKWipAAEykNWC4CG8HLQ1R6KViCc2jlFi8HG/FGmBGFnel +obVl+Hd3sAnwiV1WyO+9TrtBg+2l6BhcrsrCrDpXa8O456FAaAO0hD4pz1N/UWFNh2u 91AB/3FQrjUzxAiIi19oY7T4/U//0eYmmi5H/1fVOqWZL93nA3uM4DfNyJsn+Ufww7dg /DdPZQZv+QPzejjpRLMilMbIaG7bSgbeMD+FoOTbOBFA0JPnCbgktLiIJJQ2wmCfZsvG kKEcC13MP/f8Xz4S5HAnn3dgJVgUz3WZiZecncz59TdRRfhkI3iarQCPZCyETkf/MWsf /j5w==
X-Gm-Message-State: AEkoouunz0+b8827+ipj+K04QFOqxUSgiTuGhHCmnEgRA0HDuJkMk2/u6FsUTvirjZoDUDzsP6EOZqthIxmoXA==
X-Received: by with SMTP id o62mr16599829qke.282.1470983991416; Thu, 11 Aug 2016 23:39:51 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 11 Aug 2016 23:39:51 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Martin Thomson <>
Date: Fri, 12 Aug 2016 16:39:51 +1000
Message-ID: <>
To: Ilari Liusvaara <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] TLS ExtensionType Registry
X-Mailman-Version: 2.1.17
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, 12 Aug 2016 06:39:54 -0000

On 12 August 2016 at 05:09, Ilari Liusvaara <> wrote:
> Actually, the server_name could be made into 'client', since the only
> thing server sends about server_name is an ACK, meaning it has taken it
> into "consideration" (in some vague way).

I disagree.  If it can be encrypted, then it should be.  (I don't
believe that we ack this in NSS, so it's moot there.)

>> The max_fragment_length extension is sent in the initial ClientHello but
>> is not as essential as the server_name extension. Still, in most cases
>> there is no security context established at the time of sending the
>> ClientHello (at least not in the full handshake when ECDHE is used).
> I think max_fragement_length should be made into 'clear', given what
> it is used for.

I disagree.  The client doesn't need to use this value until it has
read all of the server's first flight, so it can be encrypted.  The
server can still act on the client's value until that time.  (I know
that you might make an argument that it could appear in
HelloRetryRequest to force the client to cut its second ClientHello
smaller, but that's really tricky to get right, and I think that
servers should just be prepared to swallow an entire ClientHello.)

>> The cookie is not sent encrypted in the HelloRetryRequest since the
>> HelloRetryRequest is sent when the client has not provided a suitable
>> "key_share" value. The DoS protection feature used in the
>> HelloRetryRequest is most likely useful only in context of an unreliable
>> transport protocol. If you want DoS protection then the server should
>> not store per-session state, which establishing security context would
>> require.
> The "encrypted" seems to be leftover from time when there were inter-
> connection cookies (which were removed).

Yep, this needs to be Client* with a note that it appears in the
HelloRetryRequest (a category in which this is currently the only