Re: [TLS] Security review of TLS1.3 0-RTT

Nico Williams <nico@cryptonector.com> Thu, 04 May 2017 20:26 UTC

Return-Path: <nico@cryptonector.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 9E53F1270A3 for <tls@ietfa.amsl.com>; Thu, 4 May 2017 13:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 dSFu8GJn6r1Z for <tls@ietfa.amsl.com>; Thu, 4 May 2017 13:26:55 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE25126BF0 for <tls@ietf.org>; Thu, 4 May 2017 13:26:55 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 09C35A00491C; Thu, 4 May 2017 13:26:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=/3uL9atTJkt8jiTwQ3nQsRu8oCA=; b=Arwc1HrbR/p 1KJnxjqmA7z2iF3dbgw/6HeULrlqKs9hRV8yzMIE/AwpB4XyVuX/0jk7E8qWznSm WYYP2NysZ7lXsPuj5FFJR1a3FdWaIoQWugNvj7K4+7jNs4TVC+Q8u5NMd5FbNMxs n0sgv04MMb1xbgBUr2LBHNP5dRHOIt8k=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 9CA71A00491B; Thu, 4 May 2017 13:26:54 -0700 (PDT)
Date: Thu, 04 May 2017 15:26:52 -0500
From: Nico Williams <nico@cryptonector.com>
To: Colm MacCárthaigh <colm@allcosts.net>
Cc: Erik Nygren <erik+ietf@nygren.org>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20170504202651.GY10188@localhost>
References: <CAAF6GDcKZj9F-eKAeVj0Uw4aX_EgQ4DuJczL4=fsaFyG9Yjcgw@mail.gmail.com> <CABcZeBNcnW9zEPZ4mEje1_ejR3npNFz65rw-6qUPn7cQt1Nz9w@mail.gmail.com> <CAKC-DJhYSCrsXQZS0SMB7ebSTYM49U+dv5iSXx5MSAv4pthabg@mail.gmail.com> <20170504193953.GU10188@localhost> <CAAF6GDcH8q0MwA2bzFjGkRBDD3qV=LWWQPpLF=oHBXn0k1kWpg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
In-Reply-To: <CAAF6GDcH8q0MwA2bzFjGkRBDD3qV=LWWQPpLF=oHBXn0k1kWpg@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/930UbRqYK-bVkE4QO09WjQEN62s>
Subject: Re: [TLS] Security review of TLS1.3 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: Thu, 04 May 2017 20:26:57 -0000

On Thu, May 04, 2017 at 01:21:43PM -0700, Colm MacCárthaigh wrote:
> On Thu, May 4, 2017 at 12:39 PM, Nico Williams <nico@cryptonector.com>
> wrote:
> > The SHOULD should say that the server-side needs to apply a replay cache
> > OR fallback onto a full exchange when the 0-rtt data payload involves a
> > non-idempotent operation.
> 
> I don't mean to be dismissive with this but TLS stands for "Transport Layer
> Security". The transport layer just isn't aware of what the operations are,
> and whether then can be idempotent (99% of the time, the answer is "no").
> Only the application can tell, but this violation of layers is what leads
> to so many problems. I don't think it's workable.

I don't mean to be dismissive, but it doesn't matter what "TLS" stands
for.  It does what we make it do via Standards Action at the IETF.  We
follow our rules for everything to do with development of Internet
Standards and publication of Experimental, Informational and BCP RFCs.

We have a process.  If you don't like what we're doing, you can voice
your opinion.  If you don't like the outcome of consensus calls and/or
IESG decisions, you can appeal those.

Thanks,

Nico
--