Re: [TLS] Finished stuffing/PSK Binders

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 12 October 2016 08:50 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 4C65D129445 for <tls@ietfa.amsl.com>; Wed, 12 Oct 2016 01:50:57 -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 Pbw8OfEwjon6 for <tls@ietfa.amsl.com>; Wed, 12 Oct 2016 01:50:55 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id EF1EA127078 for <tls@ietf.org>; Wed, 12 Oct 2016 01:50:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id EA33313B8D; Wed, 12 Oct 2016 11:50:53 +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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id oGkyFaK7C5Q0; Wed, 12 Oct 2016 11:50:53 +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 824AA21C; Wed, 12 Oct 2016 11:50:53 +0300 (EEST)
Date: Wed, 12 Oct 2016 11:50:47 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20161012085047.GD16436@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> <CABcZeBNJokdTHJLkWWx22AtW+4qWRjZtzh5JuviVuJcwbcmnTA@mail.gmail.com> <CABkgnnWC18Q+wxERnEgKLF_tjjYAmJB__32ci-hbHPuGUq162A@mail.gmail.com> <CABcZeBMtYyL9+8=qD-rJo5tigx6qQZGorVS0fvGMmAttG5j=Zw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBMtYyL9+8=qD-rJo5tigx6qQZGorVS0fvGMmAttG5j=Zw@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/JUv6M9BsK0EkrezyjlDRroT_Auc>
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: Wed, 12 Oct 2016 08:50:57 -0000

On Tue, Oct 11, 2016 at 07:48:05PM -0700, Eric Rescorla wrote:
> On Tue, Oct 11, 2016 at 5:16 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> 
> > On 12 October 2016 at 00:51, Eric Rescorla <ekr@rtfm.com> wrote:
> > > See:
> > > https://github.com/tlswg/tls13-spec/pull/678
> >
> > I'm convinced that this is the right change.  Reconstruction was
> > always going to be brittle.  I will note that I don't think that the
> > change gets the error codes right though.  I explained why on the PR.
> >
> Thanks, I'll look at this. I'll be merging this change (modulo your
> comments) Friday unless there is significant objection.

Well, if reject with in-list group is spurious or not depends on if
there is some hello-altering extension other than key share group
(it isn't if any other extension alters CH).


I also noticed another edge case: What is to prevent server from
omitting key share group (emitting a cookie, so the restart is
not spurious), presumably causing the client to blank its key_share
and then proceed to accept DH versus client's previously sent share?

(That kind of thing really plays hell if client has explicit list
of keypairs it considers active for connection).


-Ilari