IETF Logo Mail Archive

[TLS] Finished stuffing/PSK Binders

Eric Rescorla <ekr@rtfm.com> Fri, 07 October 2016 15:02 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 397FB1295F0 for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 08:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] 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 fBnLwkUT8kHW for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 08:02:25 -0700 (PDT)
Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (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 928E5129426 for <tls@ietf.org>; Fri, 7 Oct 2016 08:02:25 -0700 (PDT)
Received: by mail-yb0-x22c.google.com with SMTP id e2so17129460ybi.1 for <tls@ietf.org>; Fri, 07 Oct 2016 08:02:25 -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=S6my0EkbGT5Eby0qeZtjQ4FDBwNq/JnlJGn3RlukSGA=; b=oyTxActuAARLQ/jnFl0yzzvepLKNyTdLMFZWxvX3bUzQebahqWgh3mwR0Jd8JFIBna YdZ5hru3kach/AacHyE8ai7ul9CTxPzm+ig3anh+6BmWHQyh8z5oMFdBKdm//29ba06G hSxSuk5gvZXJmeoIYqgaD2LAaplWppsE5UT/mISZ9cjDIMiasPv7ypwF6sgym7QK2RK1 Rw6n775TVsMpLbzIenKHolCZYQTDM12wxbek8p51P3ceOqJtWQeA9c4m6T9zKglC45rR ZbXcyWC+vonRawteRMUoZLX3w+v0AnPrRAy75CP1hJqsbiRNwGp3EHKkgb1umeRkVZ0b 4jNg==
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=S6my0EkbGT5Eby0qeZtjQ4FDBwNq/JnlJGn3RlukSGA=; b=PONH/TXg6ml3w/1hzBiKqB1/GJtm7gy5eIr5O/bQ05q3Eze7b8S2QioVwb9271rIQU 5WrS1jSOr0uY7yzLvk3ZEJlcZP8vKSmqbVGd08J3H9eupR8D3RlaweCYG4olmo8ecWL6 Pr+hHcc4YintWUfW81pawjn1MoWVX13+J9Rk37SXOjPhYpxtFXE96Ev2y6ArX99QCV7i q5DXFiwtCwhiyVuf4ME7cB0XD7t3239y7sgYVpkiYrFam1HgyDeOw3DefyfanQoxea+K +ggTRMdRI77uzpKpKt4I+PEKG6GNfbeOueSahwxS0tUIo4RLJiYBILj+oKaGOlAQjxUQ kJ8A==
X-Gm-Message-State: AA6/9RlMk0fqdQimuiEMXeFzszZpUg/AhS9fAkBoacZ9/6yX5R0VKIp0oMtVBJ+cy0pRNITMm8bjkab+yCSMpQ==
X-Received: by 10.37.174.11 with SMTP id a11mr4221283ybj.180.1475852544541; Fri, 07 Oct 2016 08:02:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.212 with HTTP; Fri, 7 Oct 2016 08:01:43 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 07 Oct 2016 08:01:43 -0700
Message-ID: <CABcZeBOJPz8DY92LE6531xbRYLU-Wvkqeb-vTX59gU5rYcp+Ww@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="f403045db83ea8d580053e47b211"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ICWPHD60ryGfsYL8QxbnNZxIxOs>
Subject: [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:02:28 -0000

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.

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

As usual, comments welcome, but I think the key question we need
to resolve is whether we really need multiple PSKs. It's clearly
simpler not to support them but it seems like we need to worry about
the case where we are resuming a session created with a PSK. I've come
to the conclusion that if we want to have multiple concurrent PSKs at
all, then this is the right structure, rather than having one PSK and
using HRR to fix it.

ISTM that the other major alternatives are to say:

1. You can't resume sessions created with a PSK.
2. Tickets created in sessions created with a PSK have a hard lifetime
   value and it's a failure if the server forgets during the lifetime
   (this seems like it's going to interact badly with clock skew).

Note that if we decide that we only want one PSK, I'll just revise the
PreSharedKey section to have one, not a list [0].

Thanks,
-Ekr

[0] In fairness, it's also worth noting that if we decide to only
have one, it's possible in the future to replace the PreSharedKey
extension with a MultiplePreSharedKey extension.

v2.23.0 | Report a Bug | By Email