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

Andrey Jivsov <crypto@brainhub.org> Mon, 23 March 2015 03:48 UTC

Return-Path: <crypto@brainhub.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 914471A87AF for <tls@ietfa.amsl.com>; Sun, 22 Mar 2015 20:48:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 JC5ucGWEt_M9 for <tls@ietfa.amsl.com>; Sun, 22 Mar 2015 20:48:15 -0700 (PDT)
Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D1F1A87BB for <tls@ietf.org>; Sun, 22 Mar 2015 20:48:15 -0700 (PDT)
Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-04v.sys.comcast.net with comcast id 6roF1q0025AAYLo01roFHZ; Mon, 23 Mar 2015 03:48:15 +0000
Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-15v.sys.comcast.net with comcast id 6roE1q00F4uhcbK01roE63; Mon, 23 Mar 2015 03:48:15 +0000
Message-ID: <550F8CFE.60201@brainhub.org>
Date: Sun, 22 Mar 2015 20:48:14 -0700
From: Andrey Jivsov <crypto@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Martin Thomson <martin.thomson@gmail.com>, Eric Rescorla <ekr@rtfm.com>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com> <550F6582.9040602@brainhub.org> <CABcZeBNn92Zu7Hfu5z8qD=AZDn=jUkZ3phk18G7S1z7XJNQ9sQ@mail.gmail.com> <CABkgnnWXtpuSKH-eEou9O7qncUSeuiv=4kw_GE6Um8VW3dcohQ@mail.gmail.com>
In-Reply-To: <CABkgnnWXtpuSKH-eEou9O7qncUSeuiv=4kw_GE6Um8VW3dcohQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1427082495; bh=DWxQMOEvI5papH6QYTjtDF87vqLOwjzJIrt7T75Pl74=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DTpCPnsDKbi5Ic/p/i0MD+By1OE3F0W4QokaB2w1vI78CO+gQ8ZTsMVtXffiha8W9 WXxubxJIB65gRC/bRB7ix8+QKAhCu2VCj9XEsS9jQtqaCzgAT1aL7/VKq9+CSkNgCO J6xjMiGCKgvWo/pxUDHo9tcMlzQEE9G2FXxgMW+d1ZVC4cj7s3V/i2HUiQ+Mtr4Nbg EEzknRM7eXzONrOWum59jE+C1c4QoZ/34Ady/40EFe7IuvOTEXbl5MNH37u5YwNiaj hfAsEPZu4Hxbp4c+I8Qkm1vx6+KFyHx0CT7FhEuIeO/XuVnCS5j/YJRpRvd/8MMSCM P2hnYGRhbsZaQ==
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/pAULZYN59jqjyMHfj1WLKQCLtnQ>
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 03:48:17 -0000

On 03/22/2015 08:35 PM, Martin Thomson wrote:
> On 22 March 2015 at 20:19, Eric Rescorla <ekr@rtfm.com>; wrote:
>>> One way to solve this is to say that the server must *fail* 0-RTT, as
>>> opposed to fallback to 1-RTT, if the "orbit" indicated in the ClientHello is
>>> not that of this server.
>>
>> Yeah, this is what I claimed is "implausible" in my original message.
>>
>> My concern here is that this basically means that implementations get
>> punished with random failures for any data center/routing instabilities...
> I don't see any way that we can support a mode that fails with
> increased probability like this.  I think that the only real options
> here are #2 and #3.  I'm tending toward a requirement for marking the
> data as being explicitly replayable, simply because I don't think we
> should leave applications with the awkward choice of deciding between
> resend and something else.  Mainly because I don't know what that
> something else looks like.
>
> For HTTP, I think we can use that first flight for idempotent queries
> quite easily and (at worst) the HTTP/2 connection preface.


I was thinking about in terms of two websites from different companies A 
and B.  They are independent and they get different orbit IDs. If A sees 
an orbit ID of B that A would never have sent, this is a replay. An 
error is appropriate on such mismatch.

Likewise, A, B can be divisions in the same company, in which case, 
again, there are different Orbit IDs and an error on mismatch.

When A and B are load-balanced, e.g. by DNS entries, then A, B are in 
the same orbit. In this case they should use the same DB.

(I probably re-defined the "orbit". In my proposal it's a persistent ID 
that survives the reboot ).

If the data center is misconfigured or a client confused the origin of 
the 0-RTT state, isn't an error appropriate? Otherwise, yes, there would 
need to be restrictions on data sent in 0-RTT.