Re: [TLS] A la carte handshake negotiation

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Mon, 15 June 2015 13:50 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 0E4631ACD6A for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 06:50:29 -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 qnRp-y6tDVvM for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 06:50:27 -0700 (PDT)
Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B75E41ACE3B for <tls@ietf.org>; Mon, 15 Jun 2015 06:50:25 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id B5E1CA7589; Mon, 15 Jun 2015 16:50:23 +0300 (EEST)
Date: Mon, 15 Jun 2015 16:50:23 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Hubert Kario <hkario@redhat.com>
Message-ID: <20150615135023.GA28680@LK-Perkele-VII>
References: <201506122145.13790.davemgarrett@gmail.com> <3129639.pNdByueU9m@pintsize.usersys.redhat.com> <20150615132353.GA27040@LK-Perkele-VII> <8295853.kIc6eIqDrM@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <8295853.kIc6eIqDrM@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/7cGRZmUnRhHwOOm-zwBlSgyHaRc>
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:50:29 -0000

On Mon, Jun 15, 2015 at 03:36:44PM +0200, Hubert Kario wrote:
> On Monday 15 June 2015 16:23:53 Ilari Liusvaara wrote:
> > On Mon, Jun 15, 2015 at 12:10:39PM +0200, Hubert Kario wrote:
> > > 
> > > 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

The signature or not comes much later than key exchange message (TLS 1.2 had
those in the same message, TLS 1.3 does not).

> > (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

Well, none of the key exchanges planned for TLS 1.3 have signature in server
key share (signature is its own message if it appears).
 
> > 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

Well, the former are what I called "context-sensitive". And presence or
absence of those can be inferred from the past handshake.


-Ilari