Re: [TLS] Finished stuffing

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 09 September 2016 14:01 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 D3D6012B14F for <tls@ietfa.amsl.com>; Fri, 9 Sep 2016 07:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.109
X-Spam-Level:
X-Spam-Status: No, score=-4.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] 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 0g0ORh_iIGhD for <tls@ietfa.amsl.com>; Fri, 9 Sep 2016 07:01:12 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B95A12B102 for <tls@ietf.org>; Fri, 9 Sep 2016 07:01:12 -0700 (PDT)
Received: from [192.168.91.132] ([80.92.121.21]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MBExR-1bsZd20Qqb-00AGSi; Fri, 09 Sep 2016 16:01:09 +0200
To: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
References: <CABcZeBNqs+6SYsA9SnED8nWkUXifSPuF4gBdRG-gJamtWmxWNw@mail.gmail.com>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Message-ID: <3c93aaf4-dba8-3401-9149-ebf0de7ff873@gmx.net>
Date: Fri, 09 Sep 2016 16:01:07 +0200
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: <CABcZeBNqs+6SYsA9SnED8nWkUXifSPuF4gBdRG-gJamtWmxWNw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:Ezyasp+zll6jRcHyCDIhAyqCwudcYpxIuiSrQUL78u8jRIoO1Yh T45LB7QiDUpydu3QCqhke1iJp+nMW2PhrIxOy+NK4tXlCMK+w9cN6vwW3oV94K7ZcEJLidl 6pvjd5zj1iQeK7ZDEClKjlpyDJajv80srIr6rUQjKpuzJZJhIG/NGY4ZxrwwwZQT++Gzx1D BMfFZItQlZ1MIrxYDUsew==
X-UI-Out-Filterresults: notjunk:1;V01:K0:q8/0rtBBO/k=:2c7VTj2OlBzW7yXAGPYOEO BblLr9J7uUFyIxC7Dzf35G4YFKTmcjTDxK/EqsFGFyJQv6ZeOcZ9Bfra/hoVtDj4ebhPhY3aj PyhdDxFOwNgNdBWyg5yEQtQfaw27W8tarBbRg4rC8uBg5PzN1A54kogsFn6/CfXJPi3oA5hBb U4IoeREz93wKxroUVH2CgiliAFlCQ27NqMOgTUgGiyt0lfarwQ9mC594GqXJO/3MKW++U+7S/ WRpzTB7hJjemQMR5xzz3DXgeLNxK9zt/mUl3xoWIF5qjR3S7XqO9AQp0GEG/hnu9g9uZv0LXr oS8rmjMBZoDa/TGkjsweQDQApnievv53nBABe6a01KrHqQTjOP5TwiNad27HiUPY/fCF9+gHB 2G72Iymd14coyobPNJtOewa4kv74c2KDDa7GtuzqY/SZ9KdsF/k6SvXC+hCmSsYgM8n34pLEU WYxCs3PqgW2zGU4P1VvpR2DaalzOu1bmL9+eAzT6Y12IeNJpu+ZU7NKteqGSa/FK5ax1OoFwG 3jXe2BF6c7GneFEycodIxS82TZWVaHNL+KKXmnNnc2cF8Sj1rTBjSzMe4S35C0O39PO8W7HfS 11MxhQLjSr0mYElO9JTM4U1W9YRNUxzrW5e2LGA+rn6f5NEjqtuyqyLq5YC9Q5M5PmNLTGa7g FdpI+G1x1s3UQvKbJdvWvPmVM61xLFpb72Hs8sW1GE2KDaqjDHvI4vqansjB/qL3pK+YGc1mE JL0qBZkjhQ7+SzyaLNKw9KYwEPwn6CbFVF0Uk91VErzYtIajX+e2EYQQfRu625bPjnE5Lp6p1 c87V+Kc
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/NzUFula2ZqtZojCkT6eP8KsOV-o>
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: Fri, 09 Sep 2016 14:01:17 -0000

Hi Ekr,

I have no problems with the suggested change but I would like to note 
that we are losing one feature with this change.

Limiting the client to only send a single psk_identity prevents the 
client from sending a ticket together with the long-term PSK identity in 
the same message. This was previously possible and useful since the 
server could delete state (based on local policy) prior to the indicated 
ticket lifetime.

Ciao
Hannes

On 09/02/2016 12:04 AM, Eric Rescorla wrote:
> Folks,
>
> I have just posted a WIP PR for what I'm calling "Finished Stuffing"
>
>   https://github.com/tlswg/tls13-spec/pull/615
>
> I would welcome comments on this direction and whether I am missing
> anything important.
>
>
> OVERVIEW
> This PR follows on a bunch of discussions we've had about the redundancy
> of Finished and resumption_ctx. This PR makes the following changes:
>
> - Replace the 0-RTT Finished with an extension you send in the
>   ClientHello *whenever* you do PSK.
> - Get rid of resumption context (because it is now replaced by
>   the ClientHello.hello_finished.
>
>
> RATIONALE
> The reasoning for this change is:
>
> - With ordinary PSK you don't get any assurance that the other side
>   knows the PSK.
>
> - With 0-RTT you get some (subject to the usual anti-replay
>   guarantees) via the Finished message.
>
> - If we were to include the 0-RTT Finished message in the handshake
>   transcript, then we wouldn't need the resumption context because
>   the transcript would transitively include the PSK via the Finished.
>
> So the natural thing to do would be to always send 0-RTT Finished
> but unfortunately:
>
> 1. You can't just send the 0-RTT Finished whenever you do PSK because
>    that causes potential compat problems with mixed 1.3/1.2 networks
>    (the same ones we have with 0-RTT, but at least that's opt-in).
>
> 2. You also can't send the 0-RTT Finished with PSK because you can
>    currently offer multiple PSK identities.
>
> The on-list discussion has suggested we could relax condition #2 and
> only have one identity. And we can fix condition #1 by stuffing the
> Finished in an extension (with some hacks to make this easier). This
> PR enacts that.
>
>
> FAQS
> - What gets included in the handshake transcript?
>   The whole ClientHello including the computed hello_finished extension.
>
> - Isn't this a hassle to implement?
>   It turns out not to be. The basic reason is that at the point where
>   the client sends the ClientHello and the server processes, it doesn't
>   yet know which Hash will be chosen for HKDF and so NSS (and I believe
>   other stacks) buffers the ClientHello in plaintext, so hashing only
>   part of it is easy. I've done it in NSS and this part is quite easy.
>
>
> POTENTIAL VARIATIONS/TODOs
> There are a number of possible variations we might want to look at:
>
> 1. Moving obfuscated_ticket_age to its own extension (out of
>    early_data_indication). This provides additional anti-replay
>    for the CH at the 0.5RTT sending point. I believe we should
>    make this change.
>
> 2. Tweaking the data to be hashed to just hash the ClientHello
>    prefix without the 0-filled verify_data. This is not significantly
>    harder or easier to implement and basically depends on whether
>    you prefer the invariant of "always hash complete messages" or
>    "always hash valid pieces of transcript". See above for notes
>    on buffering.
>
> 3. Allow multiple PSKs. Technically you could make this design
>    work with >1 PSK but stuffing multiple verify_data values in
>    the ClientHello. E.g,,
>
>       opaque FinishedValue<0..255>;
>
>       struct {
>          FinishedValue finisheds<0..2^16-1>;
>       } HelloFinished;
>
>    Based on the list discussion, it seems like nobody wants >1 PSK,
>    so I think one is simpler; I just wanted to note that these
>    changes weren't totally coupled.
>
> 4. External context values. Several people have pointed out that it
>    might be convenient to have an external context value hashed
>    into the transcript. One way to do this would be to include
>    it under the Finished. That's not difficult if people want to,
>    with the default being empty.
>
> 5. Hugo brought up on the list that we need to make very clear that
>    the "hello_finished" is being used to bind the handshakes and
>    that it depends on collision resistance. I have not forgotten this
>    and text on that point would be appreciated.
>
> Comments welcome.
> -Ekr
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>