Re: [TLS] Finished stuffing/PSK Binders

Benjamin Kaduk <bkaduk@akamai.com> Fri, 07 October 2016 20:40 UTC

Return-Path: <bkaduk@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC5F12940F for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 13:40:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.696
X-Spam-Level:
X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
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 6HV_sHf3TzmI for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 13:39:58 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 79077129547 for <tls@ietf.org>; Fri, 7 Oct 2016 13:39:58 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A64C64E1335; Fri, 7 Oct 2016 20:39:57 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 8FAE74E1313; Fri, 7 Oct 2016 20:39:57 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1475872797; bh=MJXUelNkFa+RidSN0ogkwPn8V6ZXQrWgNsjvN2IzTYY=; l=8031; h=To:References:Cc:From:Date:In-Reply-To:From; b=i8u3CZR2cTApgEOnHDhjuRk1tMz7XUESpDXN5Oystru0MDIQtQQLFBbQSbzO6QJd8 kNDwhF3CSx/z1yTeO6Z5EkGzkLWoRfvDqnYyyrXlhHWpXih8Aa28aDbZ2i3C13UGI/ Q5YlPu96LXOjabxHgo4BjBy10eJznyhRtyZ47tes=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 51FFE1FC88; Fri, 7 Oct 2016 20:39:57 +0000 (GMT)
To: Eric Rescorla <ekr@rtfm.com>, Ilari Liusvaara <ilariliusvaara@welho.com>
References: <CABcZeBOJPz8DY92LE6531xbRYLU-Wvkqeb-vTX59gU5rYcp+Ww@mail.gmail.com> <20161007152628.GA9408@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBO5HEJAm=QO2NjEWHAH_mKBUBoPn0=Zw5mtKmVz9SP=wQ@mail.gmail.com> <20161007170323.GA9856@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBNp6wjxHBQ+io2Pcwd364=iiobKp-UHZZxOYZbmR7X7AQ@mail.gmail.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <c405a571-3a49-e0bc-bd21-bae469334f9a@akamai.com>
Date: Fri, 7 Oct 2016 15:39:57 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBNp6wjxHBQ+io2Pcwd364=iiobKp-UHZZxOYZbmR7X7AQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------ED62A6EB235372656596D553"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KDF8h8o2dNDF8d3sApenLPV5TLw>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Finished stuffing/PSK Binders
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 07 Oct 2016 20:40:01 -0000

On 10/07/2016 12:08 PM, Eric Rescorla wrote:
>
>
> On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara
> <ilariliusvaara@welho.com <mailto:ilariliusvaara@welho.com>> wrote:
>
>     On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote:
>     > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara
>     <ilariliusvaara@welho.com <mailto:ilariliusvaara@welho.com>>
>     > wrote:
>     >
>     > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
>     > > > 4. I've taken a suggestion from David Benjamin to move the negotiation
>     > > > of the PSK key exchange parameters out of the PSK itself and
>     into a
>     > > > separate message. This cleans things up and also lets us
>     drop the
>     > > > currently non-useful auth_mode parameter.
>     > >
>     > > Eeh... From the text, it seems to currently require the kex modes
>     > > extension if PSK extension is present. Which seems worse than
>     useless
>     > > if the meaning is to get rid of the kex mode parameter from PSK
>     > > extension (since you will have the value anyway, but need to
>     dig it
>     > > from another extension... Blech).
>     >
>     > I guess this is a matter of taste, but what convinced me was that:
>     >
>     > 1. It put all the logic on the server side.
>

I was going to ask whether this also includes the decision on whether to
send a Certificate to authenticate the server (even for PSK modes), but
it looks like this change is intentionally removing the ability to do
PSK keyex and auth with a certificate?

>     > 2. It removed the auth mod parameter.
>     >
>     > Maybe david can say more.
>
>     I mean if server is to accept PSK, it must now go fishing for another
>     extension, check that it is present and pay attention to values there.
>     As opposed to having the data in where it is needed.
>
>
> This is a reasonable argument (and the reason I stuffed the binder here).
> However, David's argument was that this applied to *all* PSKs even new
> ones.
>

Implementations already have to do some amount of "scan through all
extensions to detect certain things, do some initial processing, and
then finish process everything [else]", not least because SNI can change
what cert types you have, configuration knobs, etc..  So, yes it's bad,
but how bad is it in a relative sense?

I think there is some value in the client indicating to the server
whether it doesn't want to do psk_dhe (or doesn't want to do pure psk)
for future NSTs, though it's perhaps not of the utmost importance.  That
property does support a separate psk_key_exchange_modes extension in
preference  to rolling it into pre_shared_keys (as a separate list next
to identities and binders), but it seems to only be a weak argument for
separation.  I do think that keeping the psk kex mode orthogonal to the
individual keys is helpful, though.

Anyway, maybe it's time to bite the bullet and actually write up the
description of the proper procedure for ClientHello processing (scan
extensions for SNI, load up servername-specific config+cert/key, etc.). 
Which would make this stuff any prettier, but would at least help people
not get it wrong.

-Ben