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

Patrick McManus <mcmanus@ducksong.com> Mon, 23 March 2015 17:56 UTC

Return-Path: <mcmanus@ducksong.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 4B9561AD05B for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 10:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.256
X-Spam-Level:
X-Spam-Status: No, score=-0.256 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021] 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 aHIiYO_O7OjA for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 10:56:21 -0700 (PDT)
Received: from linode64.ducksong.com (li629-102.members.linode.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 199941AD070 for <tls@ietf.org>; Mon, 23 Mar 2015 10:56:05 -0700 (PDT)
Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) by linode64.ducksong.com (Postfix) with ESMTPSA id EEFF33A1C7 for <tls@ietf.org>; Mon, 23 Mar 2015 13:55:37 -0400 (EDT)
Received: by qgfa8 with SMTP id a8so157139420qgf.0 for <tls@ietf.org>; Mon, 23 Mar 2015 10:55:37 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.31.97 with SMTP id f94mr1032297qkf.10.1427133315943; Mon, 23 Mar 2015 10:55:15 -0700 (PDT)
Received: by 10.140.104.115 with HTTP; Mon, 23 Mar 2015 10:55:15 -0700 (PDT)
In-Reply-To: <CABcZeBOd8eftMhSk++uS6Dhc+2te=oFhA5oUB9BT9kWX2KWSKg@mail.gmail.com>
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>
Date: Mon, 23 Mar 2015 12:55:15 -0500
Message-ID: <CAOdDvNqV1_8kKo=2oXf06z2XWNEDqFgD96AcVJTTX2F9jhEQ3w@mail.gmail.com>
From: Patrick McManus <mcmanus@ducksong.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1147ec1e58141a0511f85e1e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/FmKP74_t-ynVSSLlNt55ItSjEa0>
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:56:22 -0000

It seems to me this is strongly analogous to how applications need to deal
with tcp fast open. And indeed, only applications strongly motivated to
need low latency embrace its complexity.

The tact with TFO is basically that any data sent with the fast open has to
be tolerant to replay.

I like the proposed refinement here, what I perceive of as #3, that the
stack does not replay it (sacrificing reliability). That seems both like
less of a footgun, and gives a chance for a little more application
flexibility on how to handle the exception.