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

Bill Cox <> Sun, 13 March 2016 22:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14E7212D869 for <>; Sun, 13 Mar 2016 15:22:50 -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 hnSmY4VjjPwB for <>; Sun, 13 Mar 2016 15:22:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D92912D84B for <>; Sun, 13 Mar 2016 15:22:48 -0700 (PDT)
Received: by with SMTP id g203so203018180iof.2 for <>; Sun, 13 Mar 2016 15:22:48 -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=7ZArWY+CXaLFIecYgyFHP1uC8mHjtFUBzmMcOTF/dgk=; b=MA8YioNXhG8VXh3bDe/8Ya6pgW8aFUcr8Dg/X6F8pvXysBG4eyGYcDqZPdpXghhs3m NzhJwdjLB+tTyibTfxBPqtYijCVqeXvr+b7lJT9TJeecX3r77UjYp7xRcEcHNqMtUiZ4 q2MbcuK73fsufZk8VXlRk6SEpE0noouQidWK+uimIlf2vEs8Kgfw10ViT6Ttxc5UhwJL qZaO33ggpstkBLSD7wt9Ru90Ipl1b2ArSbu5bBiwH3DcwPY2swhuXGRWc8IBpG7FJ7LC +Kt82qpbyXxMKsf2E1bM41JspCbemx5ARnmasBEgmJrHlow4591tegaFnf/h7vkE5lth TfaA==
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=7ZArWY+CXaLFIecYgyFHP1uC8mHjtFUBzmMcOTF/dgk=; b=jngCXHH+UOOS5AOIVnFRfTWmbbM39hUiQx2IRRSvQlpwd87ptDs7HZLx6b+2evr0TO 6amcguVSZUVA50IlTpA4pFfOu0n7Nhq72uZ1bCmwJJ4xAmh/z3CDnM+uW0hEieBnEqa9 oeoy9WUi+LZ6c6wsPJKt+E3gOshR+FZTneMCRD10K+yMvqD7dhIizZOhwBo/EjwmlGz7 r6vxnyVQyS4QyEqZ9qe3WwNjTw+YtGY4YQEgE5mXVfu+YKWH4pH17vfNZheCr78nQsOp HeF0yVrPhnaMe9iVnAj0023QvgVauDdyTMTioDsZNN/WxkLgIKQ9mgA0zZuMQ8Us6K3v sHcA==
X-Gm-Message-State: AD7BkJJJu9a5qD44vdlvDO/utkTCHO9xk6NpiJdwtPxXYENoLmvy4H9+upmglTLkgSgzNTZWl+582a0u2SRz+8NP
MIME-Version: 1.0
X-Received: by with SMTP id m35mr22405915iod.127.1457907767429; Sun, 13 Mar 2016 15:22:47 -0700 (PDT)
Received: by with HTTP; Sun, 13 Mar 2016 15:22:47 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Sun, 13 Mar 2016 15:22:47 -0700
Message-ID: <>
From: Bill Cox <>
To: Scott Schmit <>
Content-Type: multipart/alternative; boundary=001a113f2da898170e052df59a52
Archived-At: <>
Cc: "" <>
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: Sun, 13 Mar 2016 22:22:50 -0000

On Sun, Mar 13, 2016 at 2:23 PM, Scott Schmit <> wrote:

> So why are we adding a protocol optimization known from the start to be
> insecure (or less secure than you'd expect from using a PFS cipher
> suite)?

If you require PFS with resolution on the order of seconds to minutes
rather than hours to days, you probably do not want to use tickets either.
The ticket decryption key rotation schedule limits PFS.  0-RTT resumes do
not make this worse.

What percentage of servers that have a perceived need for 0-RTT will be
> able to securely use and benefit from this feature as their
> infrastructure is actually implemented?

Well, Google already sees a significant fraction.  Going back to 1-RTT
would be a significant downgrade.

If almost everyone should turn it off, why are we including it?

Almost every small site on the Internet should turn it off, but the large
sites that want to enable it could make up a large fraction of all traffic.

Most server admins won't be reading the TLSv1.3 spec.  They're going to
> see "shiny feature added specifically in this version that makes it
> faster!" with *maybe* a warning that there are risks, which they'll
> dismiss because "if it was so insecure, they wouldn't have included it
> in the protocol in the first place."  Unless 0-RTT can be fixed, it
> looks like an attractive nuisance.

I agree.  Instead of dropping 0-RTT, I think we should make it easy for
admins to learn about what is involved in using 0-RTT in ways we believe
are secure.  The two modes I am aware of that are potentially as secure as
TLS 1.2 session resumption are:

- Do 0-RTT session resumption using a session cache, using the ticket as
the session ID.  This should have the same security as TLS 1.2 resume,
- At the HTTP app layer, make all requests that change state transaction
based with unique transaction numbers, so replay attacks fail to change
server state.  Done successfully, this should be more secure than TLS 1.2
resumption, shouldn't it?

Are we aware of other secure ways to do 0-RTT?