Re: [TLS] Finished stuffing

Ilari Liusvaara <> Fri, 09 September 2016 20:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C943F12B390 for <>; Fri, 9 Sep 2016 13:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.408
X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wO4EUGwlKWhI for <>; Fri, 9 Sep 2016 13:19:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C405512B367 for <>; Fri, 9 Sep 2016 13:19:06 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 518F011752; Fri, 9 Sep 2016 23:19:05 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id MDW529MwwEOE; Fri, 9 Sep 2016 23:19:05 +0300 (EEST)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id F12C52310; Fri, 9 Sep 2016 23:19:04 +0300 (EEST)
Date: Fri, 09 Sep 2016 23:19:03 +0300
From: Ilari Liusvaara <>
To: Benjamin Kaduk <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: NeoMutt/ (1.7.0)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Finished stuffing
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Sep 2016 20:19:09 -0000

On Fri, Sep 09, 2016 at 02:50:59PM -0500, Benjamin Kaduk wrote:
> I made a few notes on the pull request.  Generally, I support the
> change, but I get the sense that it may aid the cryptographic properties
> if we keep the resumption_context and do not overload the resumption_psk
> as much.

One problem with this is that authentication_methods can include
nontrivial methods even for "static" PSKs, and if server takes such
method, you have an attack unless you bind the PSK secret used. And
"static" PSKs don't have resumption_context.
And I would expect that someone will be crazy enough to try to
provision "static" PSK with the information required to perform
0-RTT (ALPN (or indication there is none) and associated cipher)...

> I have a slight (i.e., unjustified) preference for doing
> ClientHello-with-block-of-zeros rather than prefix-of-ClientHello.  (Is
> there a reason to require this extension to be the last one with
> block-of-zeros?  Clearly there is for prefix-of-ClientHello.)

What about the case where client tries DHE-PSK and gets attempt
rejected because of missing group (or because address verification)?
0-RTT is gone yes, but the PSK attempt isn't.

What happens to the hash in this case?