Re: [TLS] Finished stuffing/PSK Binders

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 07 October 2016 15:26 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 076CC12962F for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 08:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.396
X-Spam-Level:
X-Spam-Status: No, score=-4.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, 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 LPy3BsH0AFJp for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 08:26:37 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDEC129426 for <tls@ietf.org>; Fri, 7 Oct 2016 08:26:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id E0D2816313; Fri, 7 Oct 2016 18:26:35 +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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id f_Ts1Kdf_ExC; Fri, 7 Oct 2016 18:26:34 +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 920C52310; Fri, 7 Oct 2016 18:26:34 +0300 (EEST)
Date: Fri, 07 Oct 2016 18:26:28 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20161007152628.GA9408@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBOJPz8DY92LE6531xbRYLU-Wvkqeb-vTX59gU5rYcp+Ww@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBOJPz8DY92LE6531xbRYLU-Wvkqeb-vTX59gU5rYcp+Ww@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/LgncngjAbFQKexVC55-hMgPwSkQ>
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: Fri, 07 Oct 2016 15:26:40 -0000

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
> 
> 
> Key changes in this PR:
> 
> 1. I have merged the HMAC into the PreSharedKey message, where it is
> now called "PSK Binder" to make very clear what the purpose of the
> HMAC it is (this suggestion due to Karthik Bhargavan) This also makes
> implementation somewhat easier and avoids creating another extension.
> 
> 2. It is now possible to have >1 PSK, each with its own binder.
> 
> 3. The binder is now computed over the ClientHello prefix rather than
> filling the MAC with zeroes.
> 
> 4. I've taken a suggestion from David Benjamin to move the negotiation
> of the PSK key exchange parameters out of the PSK itself and into a
> separate message. This cleans things up and also lets us drop the
> currently non-useful auth_mode parameter.

Eeh... From the text, it seems to currently require the kex modes
extension if PSK extension is present. Which seems worse than useless
if the meaning is to get rid of the kex mode parameter from PSK
extension (since you will have the value anyway, but need to dig it
from another extension... Blech).

> This text is still a bit rough but I think shows the right direction.

I would talk about PSKs established by NST, not resumption PSKs.
 

Also, didn't notice what prevents pathology like this (I presume this
is not allowed):

(Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256)

ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication] --->
[0-RTT data, encrypted using AES-128-GCM-SHA256]
<-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256]
<-- EncryptedExtensions[EarlyDataIndication]

Note the record protection algorithm mismatch.


Also, to straightforwardly prove that collision resistance of HKDF and
HMAC (as used) follows from collision resistance of the underlying hash
function, yon need to take the output to be at least the hash output
size. As otherwise it is not guaranteed that any collision in HKDF or
HMAC can be reduced into collision of the underlying hash.




-Ilari