Re: [TLS] A la carte handshake negotiation

Hubert Kario <hkario@redhat.com> Mon, 15 June 2015 14:30 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 98EA01B2D9F for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 07:30:27 -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 e_o0MeipD9U2 for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 07:30:25 -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 65AB31B2D9A for <tls@ietf.org>; Mon, 15 Jun 2015 07:30:25 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 2F0BE350112; Mon, 15 Jun 2015 14:30:25 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-196.brq.redhat.com [10.34.0.196]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5FEUNn6003621 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 15 Jun 2015 10:30:24 -0400
From: Hubert Kario <hkario@redhat.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Mon, 15 Jun 2015 16:30:16 +0200
Message-ID: <4377771.p3nGbdM9qk@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: <20150615135023.GA28680@LK-Perkele-VII>
References: <201506122145.13790.davemgarrett@gmail.com> <8295853.kIc6eIqDrM@pintsize.usersys.redhat.com> <20150615135023.GA28680@LK-Perkele-VII>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart7398370.DcBUk5ymSD"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/S3KShoHG-9ae5xMisPlyeOw2e-U>
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 14:30:27 -0000

On Monday 15 June 2015 16:50:23 Ilari Liusvaara wrote:
> 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...
> > > 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.

yes, and I'm saying we should be careful not to introduce ones which can not 
be inferred from previous messages

putting ECDH_anon or ECDHE_PSK behind ECDHE_ECDSA_* ciphersuites makes this 
likely
-- 
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