Re: [TLS] Finished stuffing

Benjamin Kaduk <> Tue, 13 September 2016 17:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B923412B400 for <>; Tue, 13 Sep 2016 10:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4tYZl51Eci6i for <>; Tue, 13 Sep 2016 10:10:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7FDF412B3EE for <>; Tue, 13 Sep 2016 10:04:41 -0700 (PDT)
Received: from (localhost.localdomain []) by postfix.imss70 (Postfix) with ESMTP id CB2B8433406; Tue, 13 Sep 2016 17:04:40 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id B45C0433401; Tue, 13 Sep 2016 17:04:40 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a1; t=1473786280; bh=q+0VDyoff3hjRsRz7qw+orUWb9r/NY2GARVq43btnF8=; l=5210; h=To:References:Cc:From:Date:In-Reply-To:From; b=Hnxb4X+CjnuWHh36+5Abmt34O+gDimY9J8Chp8lrQD/8HHGsGpcEJ+h9mP6pgjUe4 SEU5F+tY6t+dIMHT91fRLNZdgOiN+O1QyqO+Zn7nmF2JDd4ZoWyQIaw7IlLESXTjlP DjT8e816EFATjGZrCoPgYX57a/eQB+LuXl7ueJ5Y=
Received: from [] ( []) by (Postfix) with ESMTP id 7FE381FC88; Tue, 13 Sep 2016 17:04:40 +0000 (GMT)
To: Ilari Liusvaara <>
References: <> <> <> <> <> <>
From: Benjamin Kaduk <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Tue, 13 Sep 2016 12:04:40 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------03FF98F60F1433AFAA3C79C5"
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: Tue, 13 Sep 2016 17:10:40 -0000

On 09/09/2016 03:19 PM, Ilari Liusvaara wrote:
> 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)...

Wasn't Hannes just asking about that? ;)

>> 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?

I feel like I must be missing something, but I don't really understand
the question.  (Sadly, waiting in the hope that someone else did
understand and would respond didn't work.)  The 0-RTT failed, so the
full handshake will have an actual Finished message, with a different
hash calculated (including over the "hello_finished" extension).  The
most plausible way I could interpret the question seems to be asking
about the lack of Hash(resumption_context) in the 1-RTT Finished, but
the security properties of that should be the same as for the
hello_finished, so I'm still puzzled.

Sorry for being dense...