Re: [TLS] A la carte handshake negotiation

Dave Garrett <> Fri, 12 June 2015 17:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4B1A41ACD10 for <>; Fri, 12 Jun 2015 10:00:04 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4apsq7QcnupC for <>; Fri, 12 Jun 2015 10:00:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 85D9D1ACCFE for <>; Fri, 12 Jun 2015 10:00:02 -0700 (PDT)
Received: by qcbfb9 with SMTP id fb9so3400142qcb.1 for <>; Fri, 12 Jun 2015 10:00: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-type:content-transfer-encoding:message-id; bh=GDZBNbmIEMNTXiOXfvzz8Av+UK/KpcG+UdD1e4FwXG0=; b=ce9oJKM2aLWrRtB7h5xLDURSgG50kLQQoy0VW73oifOzgnlwutpKA6Xp8iGomXPMJY gI19Exua96ksjZCLRTFaulMHtgMibqPyJdsz/Jjq/4AkGNUBkzkroyB+p1GWNcYslG8U 840OFF2eoKz8YAU2mRQnBORzCx2bOyewAExhFf3b+yRB5aHoxwbTv3MWEIviAru8a8XG zYWcy8kt5BSocEFN2Pv6SMqq+naJg9g0E/7GYQFIJZEQricXt2IBs3CZzqd9Izmug2Tn WcN5HGZ7kjSGf+UWxPeZ9botiZ9aTvH9s2ayNVAYge6r0RPX0EH1jlSPsa9BwWtkwTxk o3kA==
X-Received: by with SMTP id a71mr32648528qkh.15.1434128401907; Fri, 12 Jun 2015 10:00:01 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id u95sm1915839qge.16.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 10:00:01 -0700 (PDT)
From: Dave Garrett <>
To: Aaron Zauner <>
Date: Fri, 12 Jun 2015 13:00:00 -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="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] A la carte handshake negotiation
X-Mailman-Version: 2.1.15
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 Jun 2015 17:00:04 -0000

On Friday, June 12, 2015 12:43:21 pm Aaron Zauner wrote:
> I'm supportive in general, let's see how this turns out. Not surprising
> though will be that I noticed additional CCM cipher-suites, as I
> currently have a draft on OCB mode I'm not really supportive of that.
> There should be a block-cipher mode that also offers considerable
> performance for non-AESNI architectures - CCM was introduced because of
> patents on OCB, we seem to have resolved this issue by now. At least for
> TLS.

The only reason OCB isn't in this draft is because I left it out of PR #180 because it doesn't have any codepoints yet. (again, this draft proposal uses that as a base)

As soon as it progresses to WG adoption and codepoint assignment, then it certainly belongs in the TLS 1.3 draft.

As far as I'm aware, even non-MTI suites listed in the spec need to be normative references and thus must be finalized before the full TLS 1.3 spec can be published. Just referencing the existence of others, which might be desired for the non-standards-track ones might be ok as informative, but I'm not sure on the specifics of the requirements there. Eric had said that we may want only ST listed at all, but that means that ECDHE CCM would be out but DHE CCM would be in, which is a problem. (it should probably just be promoted to ST) PR #180 just lists everything, at the moment.

On Friday, June 12, 2015 12:50:20 pm Aaron Zauner wrote:
> ..also why include both the cipher-suite with the 8-bit auth. tag and
> the 16-bit tag? I found this particularly confusing with the CCM draft,
> which is why I decided not to go for two different tag sizes.

They exist, so they're included. If the WG can get consensus to mandate a one-true-tag-size, then we can prohibit the other for TLS 1.3+, but I have no opinion on the topic.