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

Nico Williams <nico@cryptonector.com> Mon, 23 March 2015 17:09 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 6B88A1ACE2A for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 10:09:56 -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 CBLoB7lN-gO4 for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 10:09:55 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 708581ACE11 for <tls@ietf.org>; Mon, 23 Mar 2015 10:09:55 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 411E65408A; Mon, 23 Mar 2015 10:09:55 -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=0hLTwmy/LNj3b4 mY7fbl15/aUYQ=; b=RfaGCU0CLikIE3v6ILyWTf75mgw/uAS7+XJUDgBlWomHk+ IQu+zTGdxukvfgyRB8sqi1W0eD4dfACKOfqC35XGAswLpXng/EL2zfFUchwyF2kZ OpPFezujqq93jm0gifob5fMryg11pEpEG1eV2csQKf0wVhFFHh5OkbzzqZPqU=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPA id 817615408B; Mon, 23 Mar 2015 10:09:54 -0700 (PDT)
Date: Mon, 23 Mar 2015 12:08:52 -0500
From: Nico Williams <nico@cryptonector.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20150323170851.GN21267@localhost>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/7v5SkmwDoJNRw8Fi-2nvHB-Rpgw>
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 17:09:56 -0000

I'm missing some of the context.  Is this 0-RTT fast reconnect (a la
TCP-FO) or is this 0-RTT even for first-meet?  Regardless:

 - I don't really believe that distributed replay caches, are feasible
   without adding back a lot of the latency to be gained from having
   0-RTT.  Fast non-distributed replay caches are feasible, but from the
   discussion so far it seems like that's not interesting anyways.

   This is Kerberos experience talking.  Kerberos, you'll recall, hearts
   replay caches.  We do know how to make fast local replay caches, and
   even adaptive ones that respond to load.

 - I've made this point in the past that 0-RTT data has to be of the
   sort that is safe to use in this way, and therefore I agree strongly
   with comments made so far that this must show up in the API (client-
   and server-side) as such.

 - Idempotence isn't necessarily enough.  "Launch missiles" might be
   idempotent (e.g., world ending) or not ("accidental launch?"), but in
   the latter case a replay might then be idempotent (not accidental ->
   world ending).

 - And just in case anyone is proposing it, I object to TLS interpreting
   supposed-to-be-idempotent HTTP requests as idempotent.  As others
   have mentioned, there exist plenty of "HTTP APIs" that violate HTTP
   idempotence requirements.  Perhaps we should point and laugh, but
   ignoring them seems unwise.

 - Data to be delivered in a 0-RTT way really must be used with care.

   Any API must require that the application [developer] be aware of
   this.

FYI, I had an I-D once about combining SASL mechanism negotiation into
the TLS handshake so as to speed up LDAP, IMAP, and other SASL
applications.  There the 0-RTT data was the SASL mechanism negotiation,
and though it was used prior to handshake completion, its integrity was
also confirmed before any incorrectly-chosen SASL mechanism could yield
success and access for the attacker.  My I-D was specifically about
SASL.  Generalizing this to "any protocol" without taking care to
explain what kind of data can be used is dangerous.

Also FYI, GSS-API has ways to send/receive generic 0-RTT data with
complete handshakes, and has the same considerations that we are
describing for TLS.  The GS2 SASL mechanism uses this, again, for
negotiation purposes, not for application data, but the technique used
works for application data as well, with the caveats that we're
discussing.

The GSS case has not had a full treatment in any RFCs, but there's some
hints about it here and there.  At least GSS got the API right: the
application has to take extra steps to send and use 0-RTT data.  TLS is
much more widespread than GSS, therefore the potential harm of misuse of
0-RTT data is much higher.

Nico
--