Re: [TLS] Finished stuffing/PSK Binders

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 09 October 2016 15:45 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 695C4129573 for <tls@ietfa.amsl.com>; Sun, 9 Oct 2016 08:45:07 -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 xE14hdZOtr1l for <tls@ietfa.amsl.com>; Sun, 9 Oct 2016 08:45:04 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEBB129572 for <tls@ietf.org>; Sun, 9 Oct 2016 08:45:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 620D811495; Sun, 9 Oct 2016 18:45:02 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id KCaUZ2ZW3iJJ; Sun, 9 Oct 2016 18:45:01 +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-smtp2.welho.com (Postfix) with ESMTPSA id E40F121C; Sun, 9 Oct 2016 18:45:01 +0300 (EEST)
Date: Sun, 09 Oct 2016 18:44:55 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20161009154455.GA13453@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBOJPz8DY92LE6531xbRYLU-Wvkqeb-vTX59gU5rYcp+Ww@mail.gmail.com> <20161009135817.GA13000@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBNjVbFinq8oH5UrQRSa6FpGBiOXj8WB_X0PncZvz49zDA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBNjVbFinq8oH5UrQRSa6FpGBiOXj8WB_X0PncZvz49zDA@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/bXtGmIfrJGNSmtDbgr8KpXmcPH0>
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: Sun, 09 Oct 2016 15:45:07 -0000

On Sun, Oct 09, 2016 at 07:10:59AM -0700, Eric Rescorla wrote:
> On Sun, Oct 9, 2016 at 6:58 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
> 
> > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
> > > After the discussion on PR #615, I took another pass at this with some
> > > help from the research community. Please see:
> > >
> > >    https://github.com/tlswg/tls13-spec/pull/672
> > >
> >
> > Also, an observation: This seems to interact in somewhat annoying way
> > with stateless HRR.
> >
> > Basically, CH reconstruction no longer works properly, so one needs to
> > have a  freezeable PRF hash (and most implementations of hashes can not
> > be frozen).
> >
> 
> I've been coming to the conclusion that CH reconstruction is a bad idea.
> It's
> tricky to get right and in the common case involves a lot of bloat in the CH
> (because of duplicating the Key Shares). I think we would be better off just
> removing it and replacing (rather than appending to ) KeyShares in HRR.
> This was primarily intended as an attempt to avoid the need to continue
> the hash in any case.
> 

That creates a bit of a edge case, where the server might need to pull
client's share accross retry.

(Since if group is OK, the group is not included in HRR, which presumably
causes the client to blank its KeyShare).



Also, doing some size calculations:

ClientHello with "smallest group" rule is ~200 bytes with reasonable
parameters (I got a dump of one TLS 1.3 draft-16 CH from my TLS stack,
it is 265 bytes, but would be 196 with "smallest group" rule).

The amount of space needed to freeze (octet) SHA-256 is 32+63+8=103
octets. And the space needed to freeze (octet) SHA-384 is 64+127+16=207
bytes (for full SHA-256 and SHA-384, add one more byte).

So if selecting ciphersuite using SHA-384, the state size might be
comparable to ClientHello size.


-Ilari