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

Eric Rescorla <ekr@rtfm.com> Mon, 23 March 2015 18:16 UTC

Return-Path: <ekr@rtfm.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 0F21F1ACED0 for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 11:16:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 SDVAW9o_0K8m for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 11:16:48 -0700 (PDT)
Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (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 7562A1AD0A7 for <tls@ietf.org>; Mon, 23 Mar 2015 11:16:48 -0700 (PDT)
Received: by wetk59 with SMTP id k59so144824828wet.3 for <tls@ietf.org>; Mon, 23 Mar 2015 11:16:47 -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:from:date :message-id:subject:to:cc:content-type; bh=zEdOYfCYW08nIQVdQEA+z0bFWUU6IjNEB1qts3mM2h4=; b=NC/1dMf+iw3mjLI8rS2DHGdUwiQW1nEpQHGBe29LaNK+lestqjC3Ic4dOZvkBuhlNH kdo/nWOPkxxavfilhJWnOaQtldcPx7FdT4FyhRYA4OdL+m2dSB/3oBtJzDt6xrp+mN2+ AaQZ9u/xhDdkB9XFoulCscyR8bG07ybVSd4D3s13BVYldB0en7vLYUyCUJEiB0y3nXOI THqoA8KXCZuYqUZtAA5r2ZrUjezoRwjKrNYJkBTU/Ad8LTTaB3K+A49UDlkFuN7iNqkI HD8v621vDpAPK7UB73daWAOH2JWBTGiU/BMv1pOhro16bmYU8oIdPAwJADM4CBNUDSWA uRvQ==
X-Gm-Message-State: ALoCoQld0lOqGyiOtwr4E0xpr1LwUK+ioPqRYeuNlRXklI2wK5XcAByizRsNWYEbIIHm2hSOqHyu
X-Received: by 10.194.191.228 with SMTP id hb4mr778219wjc.116.1427134607207; Mon, 23 Mar 2015 11:16:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.205.198 with HTTP; Mon, 23 Mar 2015 11:16:07 -0700 (PDT)
In-Reply-To: <201503231359.19484.davemgarrett@gmail.com>
References: <201503231359.19484.davemgarrett@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 23 Mar 2015 13:16:07 -0500
Message-ID: <CABcZeBN3mq1DuNjYawtyTK_vCLK5HFhxSBHqytcR9wb15w-Hig@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b8750be4f49cc0511f8ab58
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/UAyZP3IvjfuS5O_nJMmgZPQdehU>
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 18:16:50 -0000

Dave,

Thanks for raising this. In the interim I actually proposed ditching
Early Data and pushing ClientKeyShare into the ClientHello directly
and having the rest of the data go directly on the wire as TLS records,
so I think this is generally a good idea.

The idea here is that clients will never send unsolicited
Replayable/Idempotent
data to naive servers, and that servers which indicate support for 0-RTT
must be able to at least tolerate these messages and fall back to
1-RTT.

-Ekr




On Mon, Mar 23, 2015 at 12:59 PM, Dave Garrett <davemgarrett@gmail.com>;
wrote:

> At this point in the discussion, it might be a good idea to fork the
> currently proposed Early Data extension. Instead of one general box, have
> two specialized boxes. The first would be an Early Handshake Data extension
> and would be explicitly limited to handshake messages. The second would be
> an Early Idempotent Application Data extension and would be explicitly
> limited to application data messages that must be safe and idempotent. The
> purpose of this is to reduce consideration of early data as a generic
> mechanism without specific considerations needed for proper usage. Servers
> that wish to refuse the latter could do so more easily.
>
>
> Dave
>