Re: [TLS] A la carte handshake negotiation

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Mon, 15 June 2015 13:28 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
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 E35B61B3616 for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 06:28:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 qv0XAy4TXkMX for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 06:28:00 -0700 (PDT)
Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5961B2D38 for <tls@ietf.org>; Mon, 15 Jun 2015 06:23:56 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 453D81A26B7; Mon, 15 Jun 2015 16:23:53 +0300 (EEST)
Date: Mon, 15 Jun 2015 16:23:53 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Hubert Kario <hkario@redhat.com>
Message-ID: <20150615132353.GA27040@LK-Perkele-VII>
References: <201506122145.13790.davemgarrett@gmail.com> <3129639.pNdByueU9m@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <3129639.pNdByueU9m@pintsize.usersys.redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/cZaeAMiEt23JAayGDyAq_zmsh0k>
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:28:07 -0000

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-tls13
> > .md#cipher-suites Diff with master:
> > https://github.com/tlswg/tls13-spec/compare/master...davegarrett:alacarte
> 
> 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 (and pure-PSK would be
separate, which doesn't even have server key exchange).


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).

That way, any state machine bugs just cause handshake failures, not
security failures.


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.



-Ilari