Re: [TLS] A la carte handshake negotiation

Hubert Kario <> Mon, 15 June 2015 10:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 003981B3548 for <>; Mon, 15 Jun 2015 03:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WMysV9FHe1jM for <>; Mon, 15 Jun 2015 03:10:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 85D3A1B3539 for <>; Mon, 15 Jun 2015 03:10:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 18A903582A0; Mon, 15 Jun 2015 10:10:47 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id t5FAAjnA013655 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 15 Jun 2015 06:10:46 -0400
From: Hubert Kario <>
Date: Mon, 15 Jun 2015 12:10:39 +0200
Message-ID: <>
User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; )
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1889505.7lrVgTz8D7"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on
Archived-At: <>
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: Mon, 15 Jun 2015 10:10:49 -0000

On Friday 12 June 2015 21:45:13 Dave Garrett wrote:
> Based on the discussions today, I've significantly revised the text of this
> proposal. This new draft goes into more detail for the PSK & anon cipher
> suites.
> Of note, I've added a table to state what's available to negotiate with
> what. It's longer than it should be because both DHE_PSK and DH_anon should
> be dropped from there, but for now I've included them because ECDHE_PSK and
> ECDH_anon AEAD cipher suites have yet to be standardized. There's expired
> drafts for these and if PSK and anon are to be considered fully compatible
> with TLS 1.3, then these really should be defined. Merging them together
> into one I-D for AEAD ECDHE cipher suite assignments seems like the
> simplest route.
> I'd also rather plain (symmetric-only) PSK be relegated to its own
> specifications and not included here, but I've included it in the table for
> now. ECDHE_PSK should ideally be the only supported PSK handshake. Plain
> PSK has no FS and it was generally agreed that TLS 1.3+ should be FS only.
> New draft text:
> .md#cipher-suites Diff with master:

How will the client know which parser it should use to deserialize the Server 
Key Exchange?

Especially when we're close to having DHE, ECDHE, DHE+PSK (and DHE+PSK+RSA?), 

Especially with the case of overloading the ECDHE to handle the ECDH_anon, it 
makes it possible that many implementations will reintroduce state machine 
Hubert Kario
Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic