Re: [TLS] A la carte handshake negotiation

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Mon, 15 June 2015 15:21 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 433EA1A883D for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 08:21:57 -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 PBWXQUiZ114n for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 08:21:52 -0700 (PDT)
Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A171B2E75 for <tls@ietf.org>; Mon, 15 Jun 2015 08:21:48 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id B7D41188868; Mon, 15 Jun 2015 18:21:45 +0300 (EEST)
Date: Mon, 15 Jun 2015 18:21:45 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Hubert Kario <hkario@redhat.com>
Message-ID: <20150615152145.GA30212@LK-Perkele-VII>
References: <201506122145.13790.davemgarrett@gmail.com> <8295853.kIc6eIqDrM@pintsize.usersys.redhat.com> <20150615135023.GA28680@LK-Perkele-VII> <4377771.p3nGbdM9qk@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <4377771.p3nGbdM9qk@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/XJSr4u8cuD9r1cRj9r7Tl1GZ2II>
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 15:21:57 -0000

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

Unfortunately, things get nasty when considering extensions that introduce
new handshake messages. Especially if you have multiple such things trying
to put messages in the same "slot":

Scanning TLS registeries and relevant RFCs, I found 7:

client_certificate_url(2) uses certificate_url(21)

This extension is somewhat dangerous.

status_request(5) uses certificate_status(22)

Obsoleted by status_request_v2

user_mapping(6) uses supplemental_data(23)

Dunno about this.

client_authz(7) uses supplemental_data(23)

Infamous.

server_authz(8) -> supplemental_data(23)

Infamous.

status_request_v2(17) -> certificate_status(22)

This one looks to be in actual use.

SessionTicket TLS(35) -> NewSessionTicket(4)

Related to resumption in TLS 1.0-1.2


The slots these messages go is (apparently):

certificate_url: Replaces certificate
certificate_status: Immediately after certificate
supplemental_data: Immediately before certificate
NewSessionTicket: Immediately before server CCS.


-Ilari