Re: [TLS] Finished stuffing/PSK Binders

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 07 October 2016 17:03 UTC

Return-Path: <ilariliusvaara@welho.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 7A70F12965B for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 10:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.896
X-Spam-Level:
X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no
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 q5zwB-CSqGua for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 10:03:31 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id AC75A129663 for <tls@ietf.org>; Fri, 7 Oct 2016 10:03:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 4D401117EE; Fri, 7 Oct 2016 20:03:29 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id pLgEBEWUJFx5; Fri, 7 Oct 2016 20:03:28 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id D43C92313; Fri, 7 Oct 2016 20:03:28 +0300 (EEST)
Date: Fri, 07 Oct 2016 20:03:23 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20161007170323.GA9856@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBOJPz8DY92LE6531xbRYLU-Wvkqeb-vTX59gU5rYcp+Ww@mail.gmail.com> <20161007152628.GA9408@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBO5HEJAm=QO2NjEWHAH_mKBUBoPn0=Zw5mtKmVz9SP=wQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBO5HEJAm=QO2NjEWHAH_mKBUBoPn0=Zw5mtKmVz9SP=wQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Ux42EhAVgXf3cHYKKHOGQXLQcU4>
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 17:03:34 -0000

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>
> 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.
> 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.
 
> > Also, didn't notice what prevents pathology like this (I presume this
> > is not allowed):
> >
> > (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256)
> >
> > ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication] --->
> > [0-RTT data, encrypted using AES-128-GCM-SHA256]
> > <-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256]
> > <-- EncryptedExtensions[EarlyDataIndication]
> >
> > Note the record protection algorithm mismatch.
> >
> 
> Yes, this is forbidden by the combination of:
> 
> "The parameters for the 0-RTT data (symmetric cipher suite,
> ALPN, etc.) are the same as those which were negotiated in the connection
> which established the PSK.  The PSK used to encrypt the early data
> MUST be the first PSK listed in the client's "pre_shared_key" extension."
> (though I think I just recently added cipher suite).
> 
> and:
> "Any ticket MUST only be resumed with a cipher suite that is identical
> to that negotiated connection where the ticket was established."
 
If 0-RTT is used with manually provisioned PSKs (might not be allowed
currently, but might be allowed soon), does that still hold?

Also, I think it is problematic that externally provisioned PSKs can
be used with any protection with given prf-hash, while NST-provisioned
PSKs can only be used with one protection and prf-hash.

0-RTT requirements are separate matter, since those would apply to all.

The original purpose of resumption-as-PSK was AFAIK to unify the two
mechanisms to simplify things. Therefore those two should be as similar
as possible.
 
> 
> Also, to straightforwardly prove that collision resistance of HKDF and
> > HMAC (as used) follows from collision resistance of the underlying hash
> > function, yon need to take the output to be at least the hash output
> > size. As otherwise it is not guaranteed that any collision in HKDF or
> > HMAC can be reduced into collision of the underlying hash.
> >
> 
> Right. I have some text here but please feel free to suggest more.

Yes, but the text says 256 bit output is enough. One isn't guaranteed
to be able to reduce such collision to collision of >256 bit hash.

(In fact, if the hash is e.g. 384 bit, 256-bit collisions are extremely
unlikely to reduce).



-Ilari