Re: [TLS] Finished stuffing

Martin Thomson <> Fri, 09 September 2016 08:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 498A712B1F1 for <>; Fri, 9 Sep 2016 01:40:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id slESme5FAiDx for <>; Fri, 9 Sep 2016 01:39:59 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CBB6212B1A7 for <>; Fri, 9 Sep 2016 01:39:58 -0700 (PDT)
Received: by with SMTP id 1so19717460wmz.1 for <>; Fri, 09 Sep 2016 01:39:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=msikXrYG9ifT5KheoIVQm63ZTwB3MhDGUAb/096Nmvo=; b=mHCuTCT7cxGVLHGU/iTXPJKVnY3/2qK6l9MqhglQnOrCTJmGToUFasPz4bE5DyyzkC ieCp8p68hb319ba4aZmiNAnS1TxxskKTdn/HwwTxhFiyoG2f6RpRh2MRqyArzFHxu5f8 Uu8WbkAEJGLWg0hzg30rLGt3goDC95C65NVu3/DwN6rlMj236SJEbRDqLkdlqW/1Wjtq PZBQYDIh+4szw+7WP3jFOHqX2JYonL7Zwxk96n0ytvEBsk9Pzz95ag5GxJMwcw9xlM16 3AuifHKszon3XRhNpbM0nG6Yvw31WWB+dIwEv/89wjGncs9bP/R2s6WZz1qmt/WEw7JU iu0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=msikXrYG9ifT5KheoIVQm63ZTwB3MhDGUAb/096Nmvo=; b=lefuDdw9QrzAwC9fFIRiz1pKUpL/Fc33jzdSnMNAOImUlOAaltbK6QPgO7IhOaHeX+ O6pwdT8F2sHU/Pg6aF3V9Ek8b/Gk9H3LrfL7mxC9mmTV/7AFbRV/UIzIml5tKVx5xZ17 5kE6WcpDjSIwcLI3pjmkpeJVDPG5Rn0Lm2sj8DfyWvr32f5kqXq2neBI87l2bu8BGp9p l/19LhonBn7jaM9XgLrD2KH6OTLXVnDAjTrq6nPYAkCDxoGUWRZtbQXXlgfb9+rgh9uv wBJriZvhNb1oqv0htKdggc5LKyeXJMCo6xT356UJ2RtRUA2rjTtgd9C0gcucxycZfgwf 6HWA==
X-Gm-Message-State: AE9vXwMOt+0rSITKLBlVMHFDOxIzEUDOqGHZ0IDIIEWOQMn5QLhsA2iKp5/ff2BvbIOC6i4CDvRyvmGjGYP6+w==
X-Received: by with SMTP id kt4mr1895760wjb.122.1473410397209; Fri, 09 Sep 2016 01:39:57 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 9 Sep 2016 01:39:56 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Martin Thomson <>
Date: Fri, 09 Sep 2016 18:39:56 +1000
Message-ID: <>
To: Ilari Liusvaara <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: Antoine Delignat-Lavaud <>, "" <>
Subject: Re: [TLS] Finished stuffing
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Sep 2016 08:40:00 -0000

On 9 September 2016 at 18:22, Ilari Liusvaara <> wrote:
> Basically, one can't make a distinction between static ("non-resumption)
> and dynamic ("resumption") PSKs here. Because such distinction would
> run into security problems with some other features.

You mean that there is no inherent property that forces separation
between sessions that use resumption vs. those that use a regular PSK.
Though the former is bound to an ALPN value and cipher suite (and
maybe some other things, like server identity) and cannot be used
unless those values remain fixed, whereas the latter is not.

We're imposing those restrictions artificially for convenience for the
most part, though 0-RTT can be used to justify the two values I
mentioned.  Given that you need the same coupling of PSK to
ALPN+cipher suite if you intend to use a non-resumption PSK for 0-RTT,
maybe instead we can fix your "problem" by identifying what needs to
be bound and forcing them to remain bound for all PSKs.  (I use scare
quotes here because I'm not convinced that it is a problem worth
worrying about.)

That limits choice, but it would remove any divergence between the two.

Note that we already couple the hash function to a PSK for very good
reasons.  So you can't use both ChaCha and AES-256 with the same PSK.