Re: [TLS] Finished stuffing/PSK Binders

Eric Rescorla <ekr@rtfm.com> Fri, 07 October 2016 16:36 UTC

Return-Path: <ekr@rtfm.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 407E912956C for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 09:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 PbCC4UYuMwXF for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 09:36:22 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24BBD129529 for <tls@ietf.org>; Fri, 7 Oct 2016 09:36:22 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id w3so8205755ywg.1 for <tls@ietf.org>; Fri, 07 Oct 2016 09:36:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pgVHmP8IK+l3mSCt72rEdmfE16xlLHF90wm+p9pI5UA=; b=ZMrurDi7zcY4VQTrHWbk3/cSYYlQUPp6cAAmuUdYDOeNckYuNK6KmpyDtqLo9ZuSJc rqt8mVPmDzE8bJ5Bo+6C7oENGwRbt6kxgANiZ0P20sNY7kjLTz0Hb9gVHtLVKS74jw/V 1kGdXiM1VbkUYV5hbSybCpUgzZVjJj+pA8LLeFx9puSDTVMiwWo7qMuk8jzO084G2aQf WWZjUVcuYNyfYYr3nwyNdgxo/sK2OzSRfMWejG8Os2E45haojb1hQqSOsTV3je0URSWE zdUu2UnqG4em1Z2nMDyORiawf+6X/cCJPVGT4HyJezeOXz8TrIz3C+03Qo7fkgIsFwAB QlFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pgVHmP8IK+l3mSCt72rEdmfE16xlLHF90wm+p9pI5UA=; b=VGuI3+sLnANxe05tEZ+KJpABub/O1IqNZpEU9y064ftC04BIpfDqt7XY/APClz67+P VYqJZ28Yn/ekP5UuWpPIXFxHTdXMWhv+cKbaRY2ssTr5XIT399/LfroO6a/WtjxgZCYX srLrjOYjnJmS+I4INxrTclxMp7sxI2SRWrFTeHLGHUlnu4JJ92TYDLuxv3yDSemtElzM OIeELMueKAew37sR5gKVqkS1sPILC89dT7ZeNFuRPKYVmYucegcrdOVT0fGb2SJVzF9A ruB8hGFjdSzNfsk8sTlUSONFu4Aaa4PgAW2SR4aNBaY8e+12hVIw0d7YKOI+ffB95UTK b2lg==
X-Gm-Message-State: AA6/9RnGg4XzeSUz0LWgFPgyNM0ZX7Ov8Dm8oe4hHvQ/3sLAbBSKJK3/Odi2cC1PiXM8Z7Ml9awCwHuKig8mhw==
X-Received: by 10.129.125.198 with SMTP id y189mr15456708ywc.234.1475858181380; Fri, 07 Oct 2016 09:36:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.212 with HTTP; Fri, 7 Oct 2016 09:35:40 -0700 (PDT)
In-Reply-To: <20161007152628.GA9408@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBOJPz8DY92LE6531xbRYLU-Wvkqeb-vTX59gU5rYcp+Ww@mail.gmail.com> <20161007152628.GA9408@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 07 Oct 2016 09:35:40 -0700
Message-ID: <CABcZeBO5HEJAm=QO2NjEWHAH_mKBUBoPn0=Zw5mtKmVz9SP=wQ@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="001a114926a0a41bca053e4902a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/SUJzhsJ8BJ9i_3FnkXEI5evaH1k>
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 16:36:24 -0000

On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> 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).
>

I guess this is a matter of taste, but what convinced me was that:

1. It put all the logic on the server side.
2. It removed the auth mod parameter.

Maybe david can say more.


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

Willdo.



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

Yes, this is forbidden by the combination of:

"The parameters for the 0-RTT data (symmetric cipher suite,
ALPN, etc.) are the same as those which were negotiated in the connection
which established the PSK.  The PSK used to encrypt the early data
MUST be the first PSK listed in the client's "pre_shared_key" extension."
(though I think I just recently added cipher suite).

and:
"Any ticket MUST only be resumed with a cipher suite that is identical
to that negotiated connection where the ticket was established."



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

Right. I have some text here but please feel free to suggest more.

-Ekr




>
>
>
>
> -Ilari
>