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

Stephen Checkoway <s@pahtak.org> Sun, 22 March 2015 23:02 UTC

Return-Path: <s@pahtak.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4361A70E1 for <tls@ietfa.amsl.com>; Sun, 22 Mar 2015 16:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFBLrYq3KvIa for <tls@ietfa.amsl.com>; Sun, 22 Mar 2015 16:02:10 -0700 (PDT)
Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (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 545DA1A7008 for <tls@ietf.org>; Sun, 22 Mar 2015 16:02:10 -0700 (PDT)
Received: by qcay5 with SMTP id y5so42384979qca.1 for <tls@ietf.org>; Sun, 22 Mar 2015 16:02:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.55.51.77 with SMTP id z74mr113855654qkz.84.1427065329422; Sun, 22 Mar 2015 16:02:09 -0700 (PDT)
Received: from zbox.pahtak.org (c-73-213-90-80.hsd1.md.comcast.net. [73.213.90.80]) by mx.google.com with ESMTPSA id j66sm8006327qgf.25.2015.03.22.16.02.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Mar 2015 16:02:08 -0700 (PDT)
Received: from [192.168.1.7] (hackintosh.local [192.168.1.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (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 <s@pahtak.org>
In-Reply-To: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com>
Date: Sun, 22 Mar 2015 19:02:05 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <1872FE63-1C6C-4D6C-AA8E-A4F768674444@pahtak.org>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/9WkvKXmywMM7kFWZRbG_q2xrHF0>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] 0-RTT and Anti-Replay
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Sun, 22 Mar 2015 23:02:11 -0000

On Mar 22, 2015, at 5:49 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> RECOMMENDATION
> 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(...)
    c.write(data)

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

-- 
Stephen Checkoway