Re: [TLS] Finished stuffing

Eric Rescorla <ekr@rtfm.com> Thu, 01 September 2016 22:19 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 D0F4312D58E for <tls@ietfa.amsl.com>; Thu, 1 Sep 2016 15:19:33 -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 NfN9CD77KTK5 for <tls@ietfa.amsl.com>; Thu, 1 Sep 2016 15:19:31 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 2CC1C12DB08 for <tls@ietf.org>; Thu, 1 Sep 2016 15:19:31 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id j12so59455415ywb.2 for <tls@ietf.org>; Thu, 01 Sep 2016 15:19:31 -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; bh=P6ncEPQxJWUuKQqmY3pIicDBHWeyDfS+v/rLXI2M3YQ=; b=NMk8x7WEs3wGWYA6vNdmJiHlRntKXDsAm09FFhf4TGUZPuYOMakgrDeVojND993Sgh Lsy8jp6KoeAvOobQ5lm9tE50YqmOTiwkckE9pSIdjk7wWsox+c+q+MIntvDITCZldwkv CzDYy9SYrzng0q+kO9qmywU2M5RPIzBibr9pbA0C75UQd6rDx51nu+pn3ykJbcQK9xJp 4gALp2NBUkQrHOr8vlBRUSkGI344eAnhYvRHEdHgieYDyFYXLv9AGtXKb+duBrvdsocD pi3zTNrlc0o1j/zAw4pyvaUfZIolDt82aRectNEmwj40n9MLyx46gY2R8xn2tUJs8Wwu QQIA==
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; bh=P6ncEPQxJWUuKQqmY3pIicDBHWeyDfS+v/rLXI2M3YQ=; b=lrd9TtBf14DXJ5A/acZIvlh8g7U4wqUpj7uW0Cl7fzHv8ONWApMygJ5KuaHTqHQHsk a5CkUNqewNgzOCj/yOxx2aKWtMt8GlaQdqWyDXn+mL4xBhhd4YHucV76/k7cuDX5eUhk CY3BWMGOOJU+9YhP+VGTZ8Oasp/itL5z1FB9MZsKbg267hbbR4MwvcvzqarJwvYrmVnm Tiz9A0Z9YPUjgIr/coWnbP9mpF4RU1DDrITNh4bgi9lmBSF3RVmh0jQkFAgBb0ppvzh2 Nh3GnSzpigb/ttUFXvqW0dmiCEZrgY3J2ZI+1nOQM7uLAnIlC66S8uAUgdDnjvqAw2vi hzxA==
X-Gm-Message-State: AE9vXwPBhAAfaZ9lae5umsnplaQqmA5owrRP7RMEd5acx8eclg5piqXNsFR2EIto9P7GU9NMBEtGNQ+enNwfVA==
X-Received: by 10.129.161.129 with SMTP id y123mr17070686ywg.214.1472768370251; Thu, 01 Sep 2016 15:19:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.48.193 with HTTP; Thu, 1 Sep 2016 15:18:49 -0700 (PDT)
In-Reply-To: <CABcZeBNqs+6SYsA9SnED8nWkUXifSPuF4gBdRG-gJamtWmxWNw@mail.gmail.com>
References: <CABcZeBNqs+6SYsA9SnED8nWkUXifSPuF4gBdRG-gJamtWmxWNw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 1 Sep 2016 15:18:49 -0700
Message-ID: <CABcZeBP890QrcbpGR9Ht2RkfHShavkkDmvvKPP+81x8Bz+SeDA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a114f8db28bca23053b799bff
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/r6Us_2qXEnzNDWtfv0LgycG0dEc>
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: Thu, 01 Sep 2016 22:19:34 -0000

I should also mention that this makes the implementation a fair bit simpler
because:

1. You can make all the decisions on the server side immediately upon
receiving the ClientHello
without waiting for Finished.
2. You don't need to derive early handshake traffic keys.

>From an implementor's perspective, this outweighs the messing around with
the ClientHello buffer.
-Ekr


On Thu, Sep 1, 2016 at 3:04 PM, Eric Rescorla <ekr@rtfm.com> 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
>
>