Re: [TLS] A la carte handshake negotiation

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Sun, 14 June 2015 06:33 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 2D4851B2AB3 for <tls@ietfa.amsl.com>; Sat, 13 Jun 2015 23:33:49 -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 j6chzpGokoZL for <tls@ietfa.amsl.com>; Sat, 13 Jun 2015 23:33:47 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1631B2AB0 for <tls@ietf.org>; Sat, 13 Jun 2015 23:33:45 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id E26B58181C; Sun, 14 Jun 2015 09:33:42 +0300 (EEST)
Date: Sun, 14 Jun 2015 09:33:42 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Dave Garrett <davemgarrett@gmail.com>
Message-ID: <20150614063342.GA24954@LK-Perkele-VII>
References: <201506111558.21577.davemgarrett@gmail.com> <201506132044.48381.davemgarrett@gmail.com> <CABcZeBO2h20DyrnmSOVFyO=sHRD2UEczziCdjRJxXx_yZmTG+w@mail.gmail.com> <201506132115.36615.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <201506132115.36615.davemgarrett@gmail.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/uQvvCjVR3EOIwZWUq3EM0l_haIo>
Cc: "<tls@ietf.org>" <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: Sun, 14 Jun 2015 06:33:49 -0000

On Sat, Jun 13, 2015 at 09:15:35PM -0400, Dave Garrett wrote:
> On Saturday, June 13, 2015 08:54:10 pm Eric Rescorla wrote:
> > On Sat, Jun 13, 2015 at 8:44 PM, Dave Garrett <davemgarrett@gmail.com>;
> > wrote:
> > > PSK suites could be replaced with a PSK SignatureAlgorithm codepoint in
> > > “signature_algorithms” extension. (this was suggested by someone at some
> > > point on this list, but I don't remember where that discussion was, offhand
> > 
> > I don't see how this is going to work. All of the PSK cipher suites use the
> > PSK as a source of keying material
> 
> A client proposing the PSK SignatureAlgorithm codepoint and a PSK identity
> would be offering to negotiate PSK using that key.
> 
> Anon would be proposed the same way, just with a null PSK identity. All
> security comes from the FS from (EC)DHE. (just like (EC)DH_anon)
> 
> The server could simply state acceptance of negotiation by echoing back
> the same PSK extension.

IMO, the problem here is that all the following have quite different
key exchange:
- GDHE_CERT
- GDHE_PSK
- GDHE_anon
- PSK

(PRF and symmetric cipher don't affect key exchange).

PSK is not signature algorithm. It works by mixing its key material into
secrets.

Trick of using empty cert and HMAC(PSK, ...) as authentication to unify
GDHE_CERT and GDHE_PSK won't work if one is to remain compatible with
TLS 1.2 DHE_PSK (or at least, requires further tricks).

The problem is that in TLS 1.2, there is thing called PSK hint, which
is optionally sent from server to client. Then client will chose its
final PSK identity. In TLS 1.3, that sort of thing would need 1RTT
miss, followed by extra message from the client to select the final
PSK identity (and possibly also sending a missing group key if in
GDHE_PSK).

And I think optional handshake messages are a bad idea, being souce
of nasty bugs (situation-dependent is different thing).


Trying to map GDHE_anon to GDHE_PSK doesn't at least run into
bad problems with messages, but I wouldn't use null identity, as
that can be very much used in real world.


Then the pure-PSK is totally different from anything else. There
the only source of keying is the psk, which has to act as direct
input to hMS.


-Ilari