[TLS] Finished stuffing

Eric Rescorla <ekr@rtfm.com> Thu, 01 September 2016 22:05 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0F11C12DB24 for <tls@ietfa.amsl.com>; Thu, 1 Sep 2016 15:05:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UWGDNoiVBr6z for <tls@ietfa.amsl.com>; Thu, 1 Sep 2016 15:05:03 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 DAF3212B014 for <tls@ietf.org>; Thu, 1 Sep 2016 15:05:02 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id r9so59348742ywg.0 for <tls@ietf.org>; Thu, 01 Sep 2016 15:05:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=co0+7bhKUrKnSR6L136+F5ZVb1KZjZMVQCcJgBZluQE=; b=DOCoAHYi55p2npmA4FXmpfB4TAIL1GPQzi28EUofaZ4UdeLBR2sqIHMHIHRU2Ra1hg yZjZRul/ts8eY6ea4q2fmndV043YY5zrshP/ipcN3JTa+/AXdicOb73NF/hyKYl9kgb/ moOxyjvWLs+yxOezzfJr7RIYDqArcoTMungRuHdHSyyholaatDqO1GLjGMWATcIgzDh4 21AZppL76zFa6XrpS9HLxXycSLPscC8BWTNu0RVBUPEfStJ+1hEI2P6UkoQLaNpRkAX8 roI6LXx2/JI5zgK9sPzWFyEJs/VAZ6CGQfmYqhvyq7w3n2XnHttBTS/BR+DBEsydBlbc YLIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=co0+7bhKUrKnSR6L136+F5ZVb1KZjZMVQCcJgBZluQE=; b=FERc4q8MWLmwobaCBFym80/NHafrVVlnlK9fCggL94TciWqCV8r9tRz2yX+rRK7nML Ha+AkFWYzuTY7mpcBnZ5XW+uQmdX6GlYV8da278N7/lxp4qxy3l+gGpIRyPKVRIFu5bQ /r/m5cTId4OIFMOYs0LfHDzhWzSmWvITgKo0hGAgNXQSR1LP7aG1x1SapNKeRUzVSrpy qZLJMHmecVhM6etuS1J9EqY3FjzaLdBrPqwieGGghmnrOMF1JQMfWd6VTsyPNDeH9kYJ 1zXqG69whRRpxPTY5sFSdBLE1KRceHYVmb/0mSvi/jqOXm1zKumQHnYoBoexcr+3lueC xWog==
X-Gm-Message-State: AE9vXwMefsBiVcOPjY08rKQXGhHdXliQ/RJNkAp3R+IngLIycTlMxPWvrKIL1qA9rTcOFpmoqfNB+uznCnWmTQ==
X-Received: by with SMTP id y123mr17013910ywg.214.1472767501964; Thu, 01 Sep 2016 15:05:01 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 1 Sep 2016 15:04:21 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 01 Sep 2016 15:04:21 -0700
Message-ID: <CABcZeBNqs+6SYsA9SnED8nWkUXifSPuF4gBdRG-gJamtWmxWNw@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114f8db2cac95f053b796750"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Ks-C_qTomgn3QPy4yYMeX61J25Q>
Subject: [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:05:05 -0000


I have just posted a WIP PR for what I'm calling "Finished Stuffing"


I would welcome comments on this direction and whether I am missing
anything important.

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.

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.

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

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.