Re: [TLS] 0-RTT and Anti-Replay

Stephen Checkoway <> Sun, 22 March 2015 23:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CA4361A70E1 for <>; Sun, 22 Mar 2015 16:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nFBLrYq3KvIa for <>; Sun, 22 Mar 2015 16:02:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 545DA1A7008 for <>; Sun, 22 Mar 2015 16:02:10 -0700 (PDT)
Received: by qcay5 with SMTP id y5so42384979qca.1 for <>; Sun, 22 Mar 2015 16:02:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=6pZ54j1K/bcPyHRRGeB6OTt7FiHJ2R8bQywoXmyWwo0=; b=K/4EFCfQYVwB27FgifjZenfOQxLTqM+034covHPZEySAztk9OPyNetKUmgwkFtVae9 I75BLvvy7069YImc4PUSsxTnmpfVYOLy+opR/AiGpYviApH/IGxSor85Y1ExkQyMy9sh EeU3xv5f7wQ3sRBa00pNpYsbJPIZbj2SXNF0PZPoLMknJS6wA3RxeJsLUvBVNTDvmxOO IodcyQQuk12zDv+Z8y43/dY9WU0P5bWnqpklQgGEBXsqv6NcX8WRP9CEspHZSx8AXhlK 9A46o8q5kURsKJQnz2CRJLORB4Jgftt+KHQJJqQN3UjdAP+recPCSGheSsqMzualBelK U8YQ==
X-Gm-Message-State: ALoCoQka9nUIwObZ0qtxH0T5eYCS2B4FQqpZKdU7pt3d+k+z/g7+FwXQvm27RnyfySZb4k8GFt2j
X-Received: by with SMTP id z74mr113855654qkz.84.1427065329422; Sun, 22 Mar 2015 16:02:09 -0700 (PDT)
Received: from ( []) by with ESMTPSA id j66sm8006327qgf.25.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Mar 2015 16:02:08 -0700 (PDT)
Received: from [] (hackintosh.local []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id BD133AC282F; Sun, 22 Mar 2015 19:02:06 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Stephen Checkoway <>
In-Reply-To: <>
Date: Sun, 22 Mar 2015 19:02:05 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Eric Rescorla <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] 0-RTT and Anti-Replay
X-Mailman-Version: 2.1.15
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, 22 Mar 2015 23:02:11 -0000

On Mar 22, 2015, at 5:49 PM, Eric Rescorla <>; wrote:

> As I said, I think we do need to supply some sort of limited 0-RTT
> functionality. Given the practical difficulty of making global state
> work, I think it's a mistake to build a system which relies on
> this. The remaining two options require that we relax one of TLS's
> guarantees and of these, relaxing reliable delivery seems safer,
> and it also makes the implementation rather easier.
> Accordingly, I propose that we continue to develop 0-RTT but with the
> server just dropping 0-RTT first-flight data when 0-RTT is not
> possible (and of course telling the client it is doing so).  The
> client application can then retransmit if it believes it is safe.
> In the very limited cases where application domains can in fact
> safely keep state, they can profile the use of TLS to that end
> and require the endpoints to behave appropriately.

None of the options makes me very happy and I'm really concerned that applications and/or implementations will mess this up and it'll lead to a vulnerability.

If we absolutely must support 0-RTT (and I believe that we do), then I agree with ekr that relaxing reliable delivery of the first-flight data is the least bad choice.

I'm not sure how in-scope API recommendations are, but I think that first flight data absolutely needs to be an explicit API call. That is, something like

    c = new TLSConnection(...)

SHOULD NOT send data along with the handshake. Ekr's setUnreliable0RTTData really seems like the way to go.

Stephen Checkoway