Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay)

Martin Thomson <martin.thomson@gmail.com> Mon, 13 April 2015 18:24 UTC

Return-Path: <martin.thomson@gmail.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 E53271B2A43 for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 11:24:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_82=0.6, SPF_PASS=-0.001] 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 IBhWa5r4meH0 for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 11:24:14 -0700 (PDT)
Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (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 D42BC1B29AD for <tls@ietf.org>; Mon, 13 Apr 2015 11:24:13 -0700 (PDT)
Received: by obbeb7 with SMTP id eb7so43061204obb.3 for <tls@ietf.org>; Mon, 13 Apr 2015 11:24:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f9H7M+BBB0Z+1vwl8O1H8llOJjRoAwmB0MFKaSl3e9Y=; b=OofpfUhhFjZuDUn6+NMitBIBuW9pKS24UD+nG26IfqamGDK8U255uK16GIhMhpYavr WgRLmSbHGtpnb820cKYgLWcfwg5Dnm39inFJebfZG9ZTW45hd2dg66lgVrpmgY++aCux eJrqtB3Q4zh20IQZzRo7J4//x4QFFfEc342weFvrfx1tifh6soZVm3exCis9NpQ/RcVK tOYSZJAtbt4fe6qB+sPWCVEUO1bxNu1nl2v9YxRGJAYICv5Ygq6K8ME3zzor1RIbpxVl fK4gAbhTRPvaE/8l0JuGRzzdBec2RMnnsLqgxas3aDya/QDqyBwLceNX+V9hl1bdKvX0 Dv2A==
MIME-Version: 1.0
X-Received: by 10.182.68.103 with SMTP id v7mr12423285obt.82.1428949453365; Mon, 13 Apr 2015 11:24:13 -0700 (PDT)
Received: by 10.202.212.212 with HTTP; Mon, 13 Apr 2015 11:24:13 -0700 (PDT)
In-Reply-To: <20150413181144.GA720@LK-Perkele-VII>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com> <20150412165542.GA19481@LK-Perkele-VII> <CABkgnnUr4wYkVwBGvH0MSmBnzNBd+T1s4aZJ5OvT_Gw3UyMSjQ@mail.gmail.com> <20150413181144.GA720@LK-Perkele-VII>
Date: Mon, 13 Apr 2015 11:24:13 -0700
Message-ID: <CABkgnnX6TqtUAV7zK8Cp6z25fJotiC22AXdkkXUhK6nnso9mBg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/xtSQ2a27VPy1wbnPHB6DEqj5pfQ>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] 0-RTT (Was: Re: 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, 13 Apr 2015 18:24:15 -0000

On 13 April 2015 at 11:11, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>; wrote:
> I thought the recommended client-side interface called for auto-
> retransmit, which would mean that if application handled 0RTT as anything
> else than a prefix, it would now create two cases serverside.

That retransmit doesn't make sense in DTLS.  I believe that the
current situation is "replayable in TLS", "unreliable in DTLS".

> You mean 0-RTT "KeyIDs" include the application? Note that ALPN is one
> of the very few extensions that is not invariant across resumption
> (might even be the only one that isn't resumption mechanism itself).

They probably need to include the application and more.

> Or guidance that one is to send at most one ALPN identifier if trying
> to send 0-RTT data?

I wouldn't do that: if the 0-RTT state is rejected, then protocol
negotiation is still possible.  I would instead recommend that both
peers remember(or encrypt) certain state to the key identifier and use
that state.

> Also, there's the case 0-RTT is attempted without resumption. Or is
> 0-RTT intended only for session resumption attempts (which would cut
> quite a bit of complexity)?

I don't know how this is intended to work, but I always think of 0-RTT
as resumption.  Nothing much else makes sense.

> There's the case where there are multiple servers behind a load-
> balancer (working at TCP or even IP level).
>
> Inability to gracefully fall back would imply that all servers serving
> something need to be upgraded at once.

Yes, all servers in that farm would need to be upgraded at least to
the level that they would be able to ignore the TLS 1.3 garbage.
Before allowing any node to enable 0-RTT.

>> >  8) If resumption attempt has 0-RTT data, what keying material is
>>    used for the 0-RTT?
>>
>> That combination might not be valid.  If it is, I'm guessing that the
>> first client flight is encrypted and authenticated as a "normal" 0-RTT
>> handshake.
>
> One can't attempt resumption with 0-RTT data?

I don't actually know the answer to this.

> Also, if session is resumed, I think the server won't appreciate having
> to decode "normal" 0-RTT data transmission, since that is relatively
> expensive operation (much more expensive than symmetric decryption of
> reasonable amounts of data).

The server decided to allow that possibility; so it has to deal with
the fallout from it.