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

Colm MacCárthaigh <colm@allcosts.net> Mon, 23 March 2015 16:44 UTC

Return-Path: <colm@allcosts.net>
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 3AE6C1ACD73 for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 09:44:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 DtZhpQWAopjT for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 09:44:21 -0700 (PDT)
Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (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 DD60D1ACD77 for <tls@ietf.org>; Mon, 23 Mar 2015 09:44:16 -0700 (PDT)
Received: by obcxo2 with SMTP id xo2so127491127obc.0 for <tls@ietf.org>; Mon, 23 Mar 2015 09:44:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=yjlpzE1QtF2o29QvemvFg86a119reR8rIOHn2eqYVFU=; b=RiXqdBsf5vzE6UEGGI33hyotvbqmuihicxBin1edTAbHuaec8HC8x0mXQZXsdneUuJ HkFlNrCido1Fdqjwlvmz2jsi7dffpWu2yjcE6HA6cQK+wFaVOOC8VuJm+YzIow758yHE WyDvBhDSHTxp5ms7IFRToMMXfdPpWu3Cm65xgB7g5dQpVFUuxIhfuR8Okp3jk7rg+OVw sKr8HKPKIlMPbIfZ0peTfDQiE3tfZig5YDKH/pnSBdQadU93xI1p0gXhAShfKrEOROce QGq/CovGN3i+XIYCI8Uy+rOTmO9jcDFMj/WLnSrY0lBJ7mUv1CoVmg0T9R+V1QWkrWnE FqnA==
X-Gm-Message-State: ALoCoQngpF5b6bYaCDEPV9rufo923JrYd1CK2akoo8HUeo4PNYM1jc25Q4r+S7An128cpma1l7J/
MIME-Version: 1.0
X-Received: by 10.202.210.215 with SMTP id j206mr43108367oig.131.1427129056364; Mon, 23 Mar 2015 09:44:16 -0700 (PDT)
Received: by 10.76.129.235 with HTTP; Mon, 23 Mar 2015 09:44:16 -0700 (PDT)
In-Reply-To: <20150323162200.GI9387@mournblade.imrryr.org>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com> <550F6582.9040602@brainhub.org> <CABcZeBNn92Zu7Hfu5z8qD=AZDn=jUkZ3phk18G7S1z7XJNQ9sQ@mail.gmail.com> <CABkgnnWXtpuSKH-eEou9O7qncUSeuiv=4kw_GE6Um8VW3dcohQ@mail.gmail.com> <20150323083308.GL21267@localhost> <20150323144052.GF9387@mournblade.imrryr.org> <55102E3A.70300@zinks.de> <20150323152831.GG9387@mournblade.imrryr.org> <55103A6E.4060409@zinks.de> <20150323162200.GI9387@mournblade.imrryr.org>
Date: Mon, 23 Mar 2015 09:44:16 -0700
Message-ID: <CAAF6GDdg7mBJuH9D0vDHE9G5dsQUd_iTGadeDjtYsT5ecZYkzw@mail.gmail.com>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/NDlWvOXTEiNbfx_s4PwoYq7sPtg>
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 16:44:28 -0000

On Mon, Mar 23, 2015 at 9:22 AM, Viktor Dukhovni <ietf-dane@dukhovni.org>; wrote:
> Deliberately so, for people who know what they are doing, to support
> latency sensitive idempotent requests that don't need request replay
> protection.

Should using TLS securely rely on that level of expertise? it is also
an incredible temptation to have the possibility of optimistic
execution, and just not pay any attention to the idempotent (or
reliability) issues.

Are there that many applications that are this latency sensitive that
can't use long-lived connections/sessions?

-- 
Colm