Re: [TLS] Closing on 0-RTT

Dave Garrett <davemgarrett@gmail.com> Sun, 11 June 2017 18:40 UTC

Return-Path: <davemgarrett@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C14127419 for <tls@ietfa.amsl.com>; Sun, 11 Jun 2017 11:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Dr8Vcc5ww9GF for <tls@ietfa.amsl.com>; Sun, 11 Jun 2017 11:40:05 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 78ABF128616 for <tls@ietf.org>; Sun, 11 Jun 2017 11:40:05 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id u19so106570091qta.3 for <tls@ietf.org>; Sun, 11 Jun 2017 11:40:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=h4DBcN4fI97b1YKP0lzyVpeT/isa1swiLHRFVsN91LY=; b=d0nsN63BXFaMiOou0YTPkFCU4FebAHjz0DkG/cXq5zOeXT7G1JLuyO0nf3K4dUqLah 8jbmVqC/rs4FGnL5+wMbzt1NxWIS/koc9LUm+aibEqgakJt03kcJ/Y0bRtwhOTzDROs6 hsc0WzgRidu1jkU0fYTX0JALvbpfyIpVUqJKVxhPQAKNqvXqMMXQG85T59Js2IqGXvzT Wjvg3xzwGhxg6dBwRuSlGseNeWsAuyFoow0DWCM3Tu7O/u1/7eJjemp8orRKnAG8U6j0 zkMucQqmA0gOT5QjXQBTe9yT6u1koGksi+tcLTcPS7fK4nq61RsO2Ow4nIwwhClFri5E ADLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=h4DBcN4fI97b1YKP0lzyVpeT/isa1swiLHRFVsN91LY=; b=BpJ7U5DJY4KZW6kJz9BpfSlckuplYSnuTdijEUqd55OIwllq/n9YBkkVOQItvgHxeJ M0nDGIcdN3t+g0jynMxOQWwPBamXyCYShtOv+Ba+i2hZ2kDZPEeC5vF1FbnMVvloHMZj GPYN8ei7BkLBvfyvua9SjYJp50ENxpmuTCDoU371zKrFm0BnF6xSYLE7Hb/YpgQ5hHMA KxeImlrMWJ76eAphIdAnfaiYj+k6HDfSPn0ejfDBqK5x6WnKa2CaBqk3cXp6eM45cJj1 blREPqPXDv1XC7yWeI84A+w9L18vr6J1z4nRV65igO08uT6xbi48BM/ruiGpTw2Enjcl fyDQ==
X-Gm-Message-State: AODbwcDjYiUQn2tZHbq/nv6zofyr9QxLOFuFll25QFpkvDfJ0zMJXATr 0/Rzy9UOUsx8Zfb8
X-Received: by 10.200.37.1 with SMTP id 1mr14175935qtm.216.1497206404553; Sun, 11 Jun 2017 11:40:04 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-175-70-41.phlapa.fios.verizon.net. [71.175.70.41]) by smtp.gmail.com with ESMTPSA id 8sm4947719qki.40.2017.06.11.11.40.03 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 11 Jun 2017 11:40:03 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Sun, 11 Jun 2017 14:40:02 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <CABcZeBNLo51y4-MYS6NTQn9OWg5jTYYpwxn1fiKKNL5bWA37TA@mail.gmail.com>
In-Reply-To: <CABcZeBNLo51y4-MYS6NTQn9OWg5jTYYpwxn1fiKKNL5bWA37TA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-6"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201706111440.02647.davemgarrett@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/g2XxeV_bdTFfRdQohbC8v1gywLk>
Subject: Re: [TLS] Closing on 0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 11 Jun 2017 18:40:07 -0000

On Sunday, June 11, 2017 11:18:03 am Eric Rescorla wrote:
> Here's what I propose to do:
[...]
> - Mandate (SHOULD-level) that servers do some sort of bounded
>   (at-most-N times) anti-replay mechanism and emphasize that
>   implementations that forbid replays entirely (only allowing
>   retransmission) are superior.
[...]
> Here's what I do not intend to do.
[...]
> - Mandate (MUST-level) any anti-replay mechanism. I do not believe
>   there is any WG consensus for this.

Whilst bounded replay protection isn't ideal, I wasn't aware of it being opposed to the point where we couldn't make it the bare minimum. There really needs to be some floor to the mess here.

If I've followed all of the discussion accurately, there may be a rough consensus that mandating with a MUST-level _some_ kind of anti-replay mechanism which MAY be implemented at the application layer as appropriate. (with a SHOULD-level requirement that it be done in the TLS implementation; MUST-level if we can actually agree to mandate bounded as a minimum, with better handling at the application level) In other words, either the TLS implementation MUST have replay protection or the application protocol profile MUST have its own replay protection (instead, or preferably in addition to a bare minimum). Replay protection would be required by TLS, but could be delegated to the application; people that want to do really unsafe stuff can define its replay handling mechanics there. This (heavily qualified) set of requirements would define TLS to be safe, so long as people stay within the known bounds laid out by the spec and profile(s) (with the potential for dubious profiles hand waved away...).


Dave