Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Dave Garrett <> Tue, 12 July 2016 05:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E4B912B032 for <>; Mon, 11 Jul 2016 22:53:03 -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 5VCLheMdZY1t for <>; Mon, 11 Jul 2016 22:53:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5137612B031 for <>; Mon, 11 Jul 2016 22:53:01 -0700 (PDT)
Received: by with SMTP id i12so4922355ywa.1 for <>; Mon, 11 Jul 2016 22:53:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=0T89Pqder249KJ5v44NfsDuxxjO2BbCdVNxOzRAMIIc=; b=IUDpSSLhZLztC4oJO4hzuR7JfT2DSEYVZk3K9N2XEmvMjkhuNwqI6dGHbRYDwBkY3k kuZWjCDIve6IcFw+ckmyjy2WKyLInkmkA0QRJj1QWzL9EbJa/DsYBXD3IE+uwFu1tKFO f035NympyBQk3uJsyy23suhXLQbI9FqIpAgNNO1m1IyPRtHMjXY27ZBZWGFpBf2BCybW /JGPsZ23KJm5Qo9iJzugN6wFWk6+5rvIGMUMOw+lCBu5znkDwV6DS4QAHvQgJ5s5imtA 0LzCTrw+DyZh8FtpEIIuag+VR/BHfiR3pPO581aQe91fup3qIYa3e4Slq7l8ON3ubhhK R+cw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=0T89Pqder249KJ5v44NfsDuxxjO2BbCdVNxOzRAMIIc=; b=m6ccAu/dDcJ18xoPlsaSto94FEwlxCVU+QvAsZ8tHS4ARQSX6EArVPFCY8oWKvZDQh N1zD99Mdsy12b67QlxVxgA0HjkK3mG1oA8b00wFec/RO81NbxmsP5NS990X1QP2E0Him m5gvCD1YhmJ+XR0tazX7RsvPgv4biEiEBXIfA/FoAq6yMgMsLloDvsg3GlBpYLKxsjw5 d/UClqIY5+0PrHaT5pWwHRnXO/v5DH7dWkJ+NPN8+tgbKQd6ypzBypRHdmV+xX1eVvDQ 5uxH/iiX/iV4fb9E46vKZlEjD1ONsh/tUTxtomkwXq8KbRZhtD+21872MYRuHtM6lrlQ uJjQ==
X-Gm-Message-State: ALyK8tK+n1ctXZiiNV1/IRXzA0pWj5zXNVwdOB0WqZ5whOuESkOFErzHnKMKSgP2LoX02A==
X-Received: by with SMTP id x84mr53056ywc.254.1468302780465; Mon, 11 Jul 2016 22:53:00 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id b5sm7410366ywd.8.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 11 Jul 2016 22:52:59 -0700 (PDT)
From: Dave Garrett <>
Date: Tue, 12 Jul 2016 01:52:57 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
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: Tue, 12 Jul 2016 05:53:03 -0000

Just replying to a few points.

On Tuesday, July 12, 2016 12:16:24 am Ilari Liusvaara wrote:
> ###  Hello Retry Request
> > selected_group
> > : The mutually supported group the server intends to negotiate and
> >   is requesting a retried ClientHello/KeyShare for.
> > {:br }
> What is written into this field if server selects pure-PSK ciphersuite
> and then decides to reject the ClientHello? Or connections that use
> pure-PSK just plain can't be rejected for any reason (including IP
> address verification in DTLS?)

The HelloRetryRequest message is not applicable to pure-PSK, which does not use the KeyShare extension at all. PSK has its own separate extension. ((EC)DHE-PSK uses both together)

The purpose of HelloRetryRequest is to allow for clients to not send full keys for every single algorithm they support, yet allow the server to still pick from that entire list if it needs to. PSK has no equivalent system; pre-shared keys are first-flight or bust. If an (EC)DHE-PSK suite is selected, and a valid PSK identity is selected, the server can use HelloRetryRequest to reject a group in favor of another supported by the client, but it can't reject the suite or identity in this manner. The response to no acceptable PSK identity is either to negotiate another suite or to abort with a fatal alert.

See draft 14 section 4.2.5:

> > ## Cipher Suites
> > 
> > Note: The values listed for ECDHE and ChaCha/Poly are preliminary but
> > are being or will be used for interop testing and therefore are likely to be
> > assigned.
> Isn't the RFC already published, so the codepoints are stable?

xiaoyinl fixed the second one of those notes, but that was merged after the checkpoint for draft 14. I'll fix this one to just note for ECDHE PSK AES.

> > ## Implementation Pitfalls
> > 
> > -  Have you ensured that all support for SSL, RC4, EXPORT ciphers, and
> >   MD5 (via the "signature_algorithm" extension) is completely removed from
> >   all possible configurations that support TLS 1.3 or later, and that
> >   attempts to use these obsolete capabilities fail correctly?
> >   (see {{backward-compatibility}})
> Better to just nuke the code entierely for all versions.
> "Disabled" code has nasty tendency of coming back to life.

Emphatically agreed, however I worded it this way to be slightly more general. If I said that all that code should be universally gutted, I'd risk more people ignoring it due to the severe status quo bias that is very common. In lieu of modernizing fully and dropping it completely, having these old features disabled via the same compile-time option that enables building of TLS 1.3 would be acceptable, IMO (though, more trouble than it should be worth, and still not ideal at all). Bikeshedding better wordings in this section would not be unwelcome, if you think anything here can be made better.

> > -  Do you handle TLS extensions in ClientHello correctly, including
> >   unknown extensions or omitting the extensions field completely?
> The extensions field can't be omitted in TLS 1.3. And I would
> consider TLS 1.2 client implementations that send such messages
> as quite pathological.

Implementations should be expected to handle pathological cases gracefully, even if only to recognize and reject. ;)