Re: [TLS] A la carte handshake negotiation

Hubert Kario <hkario@redhat.com> Mon, 15 June 2015 13:36 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F291A1E0F for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 06:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM8dydhgwgJC for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 06:36:55 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D68F1A1A12 for <tls@ietf.org>; Mon, 15 Jun 2015 06:36:55 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id E49A2345A8A; Mon, 15 Jun 2015 13:36:54 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-196.brq.redhat.com [10.34.0.196]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5FDaoHm023559 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 15 Jun 2015 09:36:52 -0400
From: Hubert Kario <hkario@redhat.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Mon, 15 Jun 2015 15:36:44 +0200
Message-ID: <8295853.kIc6eIqDrM@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; )
In-Reply-To: <20150615132353.GA27040@LK-Perkele-VII>
References: <201506122145.13790.davemgarrett@gmail.com> <3129639.pNdByueU9m@pintsize.usersys.redhat.com> <20150615132353.GA27040@LK-Perkele-VII>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1768965.Pnt4Yhm5g4"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/-TdnRzriVaT3L7h4y6lLxV1Y6J8>
Cc: tls@ietf.org
Subject: Re: [TLS] A la carte handshake negotiation
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2015 13:36:56 -0000

On Monday 15 June 2015 16:23:53 Ilari Liusvaara wrote:
> On Mon, Jun 15, 2015 at 12:10:39PM +0200, Hubert Kario wrote:
> > On Friday 12 June 2015 21:45:13 Dave Garrett wrote:
> > > New draft text:
> > > https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-t
> > > ls13 .md#cipher-suites Diff with master:
> > > https://github.com/tlswg/tls13-spec/compare/master...davegarrett:alacart
> > > e
> > 
> > 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?), ECDHE+PSK (and ECDHE+PSK+ECDSA, ECDHE+PSK+ECDSA?), ADH and
> > AECDH in a single ciphersuite...
> > 
> > Especially with the case of overloading the ECDHE to handle the ECDH_anon,
> > it makes it possible that many implementations will reintroduce state
> > machine bugs...
> 
> Well, the server key exchange message is presumably the same for all GDHE
> key exchanges, so one parser could parse those all

there's still the difference between signed vs not-signed

> (and pure-PSK would be
> separate, which doesn't even have server key exchange).

pure PSK is outside TLSv1.3 as it doesn't provide PFS, ECDHE-PSK and DHE-PSK 
though doesn't use signature on server key share

> However, if we were serious about eliminating state machine bugs (and TLS
> 1.3 state machine is totally different from TLS 1.2), we would eliminate
> all optional messages (different from context-sensitive messages, like
> Server key exchange message), and then eliminate handshake message types
> (except for those which have to have type numbers for backward
> compatiblity).

there's a difference between having messages which are optional from protocol 
standpoint but are mandatory for given ciphersuite and messages which are 
optional always

> Regarding the PSK integration work EKR has been doing in the WIP branch:
> 
> 1) Doesn't support identity hints. Now, these might be something nobody
> uses and can be deprecated.
> 
> 2) GDHE_PSK ciphers can't seemingly be safely resumed: Because resumption
> is PSK, it eats the PSK slot, not leaving space for the primary identity.



-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic