Re: [TLS] Additional warnings on 0-RTT data

Colm MacCárthaigh <colm@allcosts.net> Thu, 24 November 2016 04:12 UTC

Return-Path: <colm@allcosts.net>
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 04B1B12943A for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 20:12:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 i3QWdAehtaxL for <tls@ietfa.amsl.com>; Wed, 23 Nov 2016 20:12:01 -0800 (PST)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 4FE37129413 for <tls@ietf.org>; Wed, 23 Nov 2016 20:12:01 -0800 (PST)
Received: by mail-yw0-x22b.google.com with SMTP id a10so29223040ywa.3 for <tls@ietf.org>; Wed, 23 Nov 2016 20:12:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+6I4ISd4rD0rRrcjGtm4PyxkO8FO0Kqkku/17RoQ8HA=; b=X9uXJsFKz1qEVCCEk7GW4ewbG2/wbDgq1uTU2nqB1OvV+Rm2iLKxKgc+fvOBdbKwhV aVE/sBG3C/wbQ2AWBRI8mHaFuFnqZmFw3o5r8kburdLRjf5CyhdLJb84NRYaaLmjxyg0 Mw+OofUsiRT9ElQEMEm8bjOU6QbH+u1XVJASaH6OpuKchWX08eswhO9eQPI7+h/jl0ge /dq6XfI1g191O3eM5bA8PAxF9RRZsysfhbO4OJM44zyQInn5sRVV2PAaGgbln9xV4IDA r/+uHJTJCrvTS0sU9Sy8fEk5TnXsckTQR/Qstcahv41bUUKo+CSh3/N/hwl0fdxJ+ej1 LsjQ==
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; bh=+6I4ISd4rD0rRrcjGtm4PyxkO8FO0Kqkku/17RoQ8HA=; b=MTBZ4QTtoRf14Qil/ImhZGlzoSHRab9UrvErmuv0zzgr/RoklsYKDbLBuF5LVb3hZi wYtybVoqvnYXr4qKjFNfiV9TAxPSelbW1qIySHs80PUTHvcdNUdscR3hLQKPxE5Ap2C0 rLowujoTtwFSLSfoIg0XGfKFzw5qZooJpQwWGijxszUh80vYRBBtqnzc0MmN64aFDHgu LT3x7yAGLvKtGidJ2Hp6iA4NDuAlwaMzj01gjd6LJnFMx+v62kAP4qpUJLIofcVjXTZE Ym9LucEHpb3uJRdelTO5qlBGJgVist8MHkHYCoYH0XR+FA4dpbh5t+xCxT+kJjHugih/ 1qMQ==
X-Gm-Message-State: AKaTC02JUYwwTrpME8M6DbdJJg7pmlfwaEtu7njykgQA52wbEBWqN8ix5A9ZQubHUcrBykG3PyvU3IYeFX1SbA==
X-Received: by 10.13.199.193 with SMTP id j184mr439402ywd.339.1479960719979; Wed, 23 Nov 2016 20:11:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.115.3 with HTTP; Wed, 23 Nov 2016 20:11:59 -0800 (PST)
In-Reply-To: <CABkgnnUhnFY5H6ew2uAhvPuqm8E1dP2-9OupaNfvF7qdKvggBg@mail.gmail.com>
References: <CAAF6GDeAbbwnUaCGg4sVxzP6S3ECoQ2nzCi3FyB1gRV9mJHxGA@mail.gmail.com> <CABkgnnXuL9jE04omz3n4FRWBKuJtpEV-bS2tSVvN7AJhW_4GUA@mail.gmail.com> <CAAF6GDcbJm7YWmUZ66JK9hUbU+Gt_-ERmjWxz9YnJe2KCtru-g@mail.gmail.com> <CABkgnnUhnFY5H6ew2uAhvPuqm8E1dP2-9OupaNfvF7qdKvggBg@mail.gmail.com>
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Wed, 23 Nov 2016 20:11:59 -0800
Message-ID: <CAAF6GDdrPO+eYMmWmvmwL2RVB5UV8184Xc5uOz99PhkkZfNY9w@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="001a114e544aff267a05420434b6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Kn67AGDghejedgufnwxqOfVEffU>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Additional warnings on 0-RTT data
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 24 Nov 2016 04:12:03 -0000

On Wed, Nov 23, 2016 at 7:31 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> OK, let's be clear: I don't agree that the level of paranoia
> surrounding 0-RTT is warranted.


Do you disagree that the three specific example security issues provided
are realistic, representative and impactful? If so, what would persuade you
to change your mind?


> I'm of the belief that end-to-end
> replay is a property we should be building in to protocols, not just
> something a transport layer does for you.  On the web, that's what
> happens, and it contributes greatly to overall reliability.
>

The proposal here I think promotes that view; if anything, it nudges
protocols/applications to actually support end-to-end replay.


> The reaction to perceived problems in 0-RTT is disproportionate. You

are asking for a license to replay here at some arbitrary layer of the
> stack.  That's not principled, it's just on the basis that you don't
> like 0-RTT and want to innoculate other people's software against the
> ill effects it might create.


The problems of 0-RTT are disproportionately under-estimated. I've provided
what I think are three concrete and realistic security issues. If we
disagree on those, let's draw that out, because my motivation is to
mitigate those new issues that are introduced by TLS1.3.


> What I object to here is the externalizing that this represents.  Now if I
> have the audacity to
> deploy 0-RTT, I have to tolerate some amount of extra trash traffic
> from legitimate clients?
>

I think there is a far worse externalization if we don't do this. Consider
the operations who choose not (or don't know) to add good replay
protection. They will iterate more quickly and more cheaply than the
diligent providers who are cautious to add the effective measures, which
are expensive and difficult to get right. That is a perverse incentive, and
ultimately users would pay the price.

I have the same gut reaction against sending duplicate data and having a
sort of "tax on everyone" for the sake of safety as you, it's icky, but I
haven't been able to think of another mitigation for the problems that
would be as effective.

-- 
Colm