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

Nico Williams <nico@cryptonector.com> Mon, 23 March 2015 19:30 UTC

Return-Path: <nico@cryptonector.com>
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 E62001B29AC for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 12:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 G4dlNCangOqC for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 12:30:30 -0700 (PDT)
Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6DF1B29A7 for <tls@ietf.org>; Mon, 23 Mar 2015 12:30:30 -0700 (PDT)
Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 2B2381612; Mon, 23 Mar 2015 12:30:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=qkpiSAKiwQ9MiP Av9cxwNVneURA=; b=HqbqLSc2yc2jnkQFYiwrjjpJdaDY7Rp856jKfnEojc0nuv JynpBJkim+xkFzDRbofvfn6PAiUhGmIR3IgOxPfMLCzkYDCQsdS4fHtkIrL22NUn M3Slu5q6VxTAeBDiq5Xc7wO6Y82qdY04mMrK0KOpq0SvFBLWh0z/8YZ3HATHo=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id 76ADC163B; Mon, 23 Mar 2015 12:30:29 -0700 (PDT)
Date: Mon, 23 Mar 2015 14:29:36 -0500
From: Nico Williams <nico@cryptonector.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20150323192935.GR21267@localhost>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com> <20150323084716.GM21267@localhost> <CABcZeBO88cvxXJULgpNCxC_Q4HhtOOVnpCoUWmo6=7GkVhFkdQ@mail.gmail.com> <20150323171955.GP21267@localhost> <CABcZeBOd8eftMhSk++uS6Dhc+2te=oFhA5oUB9BT9kWX2KWSKg@mail.gmail.com> <CAK3OfOgnyDDsc-3TTXnyYhY_t0Ooi9pAfegVqC-4WO8GXkzTBw@mail.gmail.com> <CABcZeBOXTj_H10md5Qh5d2b6eCfVrUp7+0TMGjCSdEgTfq5N4w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABcZeBOXTj_H10md5Qh5d2b6eCfVrUp7+0TMGjCSdEgTfq5N4w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/6sefEyilH8dDmMo8GnARoB9GrxQ>
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: Mon, 23 Mar 2015 19:30:31 -0000

On Mon, Mar 23, 2015 at 01:12:57PM -0500, Eric Rescorla wrote:
> If I can refer you back to the diagrams I provided in my e-mail, I
> think you'll see that this doesn't help. The issue is that the first
> time that the client's data is handled there is *no* feedback from the
> server to the client, so nothing that the server says is going to
> help.

Indeed.  If the server ever responds to the client (for that
connection), then there is feedback, but such feedback is too late, and
might never arrive (the client application times out, maybe retries).
Therefore such feedback must not be security-critical, which means that
the data sent must be more than idempotent: it must yield no meaningful
side-effects on the server-side.

Again, optimizing something like a SASL mechanism negotiation, "open
INBOX" (but not "open my-secret-design-for-xyz") -- that's fine.
Optimizing arbitrary application protocols this way is not.

This is really a security consideration, but it should come with API
design advice (since TLS lacks an abstract API).

Nico
--