Re: [TLS] Finished stuffing

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 18 September 2016 09:54 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 103A612B15E for <tls@ietfa.amsl.com>; Sun, 18 Sep 2016 02:54:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Level:
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.316] 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 dcV1PqmyjCnP for <tls@ietfa.amsl.com>; Sun, 18 Sep 2016 02:54:27 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACF012B15B for <tls@ietf.org>; Sun, 18 Sep 2016 02:54:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 020AE11DD2; Sun, 18 Sep 2016 12:54:25 +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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id cxOEcJNgSFUK; Sun, 18 Sep 2016 12:54:24 +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 BAFBB2310; Sun, 18 Sep 2016 12:54:24 +0300 (EEST)
Date: Sun, 18 Sep 2016 12:54:22 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20160918095421.GB23896@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBNqs+6SYsA9SnED8nWkUXifSPuF4gBdRG-gJamtWmxWNw@mail.gmail.com> <CABcZeBP890QrcbpGR9Ht2RkfHShavkkDmvvKPP+81x8Bz+SeDA@mail.gmail.com> <CAF8qwaCVyRrSm-XtL6Jd_VKD9qGmCJNFJW1GZVjmidsr3DnW_Q@mail.gmail.com> <CAOgPGoD8YEr=+c8eG+YZ=6nSvFB2uk7MiKNgN7Z=wg7ihAUhzg@mail.gmail.com> <e1048616-22f9-4f37-ee1c-712f97213e31@akamai.com> <20160909201903.t726g3tywns2pfuq@LK-Perkele-V2.elisa-laajakaista.fi> <599816da-8c60-938d-d6c0-3ec1510e2b96@akamai.com> <20160913191510.hfumchrmzvfplnlm@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBM7J8r2P2MoqLJ0UTKg7M1JDJ-_YN_KA-Tk=rz=KbgMaw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABcZeBM7J8r2P2MoqLJ0UTKg7M1JDJ-_YN_KA-Tk=rz=KbgMaw@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/s38kLwjpvtH1xjuG2ptSKhI-my4>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Finished stuffing
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, 18 Sep 2016 09:54:29 -0000

On Sat, Sep 17, 2016 at 02:43:49PM -0700, Eric Rescorla wrote:
> 
> In this case, I believe that the finished is computed over
> "ClientHello(groups=23,24,29;PSK=foo;shares=23:bar,29:baz,24:quux,..."
> 
> But that the handshake transcript is computed over all of:
> "Client: ClientHello(groups=23,24,29;PSK=foo;shares=23:bar,29:baz,.
> ..,finished=zot)
> Server: HelloRetryRequest(group=24)
> Client: ClientHello(groups=23,24,29;PSK=foo;shares=23:bar,29:baz,
> 24:quux,...,finished=???)"

Well, either way, I think there should be a note about how those
hashes behave with retries.

Also, has that extension been added as an exception to the rule that
extensions must remain the same across retry (since it can change)?
I don't see that being added to such list of exceptions.


-Ilari