Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

Bill Cox <> Mon, 14 March 2016 15:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D60D12DC6C for <>; Mon, 14 Mar 2016 08:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 yNSJvz6bJQkh for <>; Mon, 14 Mar 2016 08:41:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6BEAF12DC7E for <>; Mon, 14 Mar 2016 08:35:26 -0700 (PDT)
Received: by with SMTP id m184so227064279iof.1 for <>; Mon, 14 Mar 2016 08:35:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=6BGMRbJ7yimhgvZbmHDr/gixS+P/wszt83/9cF2eQmw=; b=TyH0r7JorbcZGmmdf9wnhP6ceSz33J73vWzWDLrm1yv80kThTrAotPte9W7Fmin2ZS WEgtz0G1NMkV9HqveszVg7pBCxLNG+Tv8l8vL03HIxKr2U5twE4jnNuflQYUSU51QvfL LPdH2BlEJRfikSNkdiIGkRY9M2RIYte2br+dt7N7GEThWAgX+szsW0Rlj7xjGNufk90S 0H2G3j/zuXmpNc1k7al5/P2f46xh8AmYhcTcckQrGBoK/rVnXr14fO/G3n9TcuR8ppem 22wKoGW12W3aISSrE2kh/Yzzv4HmZj7GaFQ1k0KUDge01E9zC4OxHpQkVgODIF2hkd+i TuEg==
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:date :message-id:subject:from:to:cc; bh=6BGMRbJ7yimhgvZbmHDr/gixS+P/wszt83/9cF2eQmw=; b=mEGHcQvtrDW54W5QHGA3ZlKcelyACApumtHHzRtYv1zIepLbZ+4YK78hrxgQPVy1h5 jPLR6zJCiaFBmt+tF+YddbUwTerZV4zRYUemZgMfR1nhh9Zm4k8GJ42u1fdF9CuGvL9l ZFFoqDigFcPMowk107/oCXbpBW/BsUc4K1mhJiPkwTjRNcra7hoMB5u8RMYD75f83VT/ bs/c/wUcnSH03YSG8zG8jiuktLSUW7YnmalmFrbR/EPZnCoq85GQdvP/cqtG4pDi08aS bBp2i6cDhj9QUvKwVgTGMzHW92mSq8npmOFBOT7aSF+looDKhMhMfCgfpMzi/PiuACHC mdmA==
X-Gm-Message-State: AD7BkJJBdtPcydH6eMzuhpaQPrs3gaWRb+1wtTXjtR2D+HCG0W+MjvEBwoOKCRbbypYLO5jEdO1tb8XtMGVmleSv
MIME-Version: 1.0
X-Received: by with SMTP id n41mr8297179ioi.132.1457969725610; Mon, 14 Mar 2016 08:35:25 -0700 (PDT)
Received: by with HTTP; Mon, 14 Mar 2016 08:35:25 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Mon, 14 Mar 2016 08:35:25 -0700
Message-ID: <>
From: Bill Cox <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary=001a113ebf8496ed08052e0407b6
Archived-At: <>
Cc: Scott Schmit <>, "" <>
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
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: Mon, 14 Mar 2016 15:41:36 -0000

On Mon, Mar 14, 2016 at 4:39 AM, Eric Rescorla <> wrote:

> This is just my opinion, not Google's.  Here is a dumb idea I just had:
>> The current 0-RTT modes described in TLS 1.3 are clearly only for admins
>> who really know what they are doing.  If the current 0-RTT modes are deemed
>> to dangerous, then how about going back to session IDs, and doing 0-RTT
>> resumption from the session cache?
> Isn't this more or less what we have been calling PSK-resumption? Can you
> explain
> the difference?
> -Ekr

Sometimes all you need is to rename a thing to make it acceptable to
everyone.  What should we call stateful 0-RTT resumption vs stateless 0-RTT
resumption to make the difference clear?  We have all been calling "0-RTT
resumption" the stateless version, whether DH-0RTT or PSK-resumption based

Stateless PSK-resumption has all the "new and exciting" security holes.
Stateful PSK-resumption is boring, just like 1-RTT.  Stateless DH-0RTT and
PSK-resumption is well documented in the spec, but is dangerous.  Stateful
PSK-resumption is not documented in any way, and appears to have been
depreciated.  Users who want it will have to build it as a non-standard way
to use tickets, by encoding the session-ID in the ticket.  All I am
suggesting is to change the documentation so that the standard 0-RTT
resumption mode is the safe stateful version that puts the session-ID in
the ticket (and of course, drop the DH-0RTT mode).

As we all know, what matters most in security is the default mode.  I am
suggesting making the default 0-RTT resumption mode stateful, with a
documented session-ID (and let's bring back the timestamp, too, since we'll
need it).