Re: [TLS] KeyUpdate and unbounded write obligations
Keith Winstein <keithw@cs.stanford.edu> Sat, 20 August 2016 03:40 UTC
Return-Path: <winstein@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 688DD12D59D for <tls@ietfa.amsl.com>; Fri, 19 Aug 2016 20:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 JCH6ZUwfw0iS for <tls@ietfa.amsl.com>; Fri, 19 Aug 2016 20:40:54 -0700 (PDT)
Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::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 D47E712D593 for <tls@ietf.org>; Fri, 19 Aug 2016 20:40:53 -0700 (PDT)
Received: by mail-yb0-x22c.google.com with SMTP id e31so21695119ybi.3 for <tls@ietf.org>; Fri, 19 Aug 2016 20:40:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+lIoMlbHxKypy9PBnb28hhcThe5rFyqtALDtAiXFIa4=; b=UjWkejuP/+alTJ/TaJxco65FEyCoVMRy9sgy22xssDaraqNgo+9YNpcqQ3PcaWZAe8 YQrmKuq2K1FK/zD3/rAUmuFFIW+kvh++czZBXoqRMpoHgc/hUGJG04qgCQz+Zt6EWwNz QDRFuK6R9AAVaO0tVw/8lk+GijYaHDmV3Mjp93HnBgkHui2vO0/XVAoF4glnGzPSwnnf F5DJpGIgybMf3UzmhocACnLjYnV4WKh2eywPBH/L4Ca+7h+2CpLNp4g9WV58GvucpBWf OuaAJYN620tN2xAdUaUsw8dCFQ1JcOb8rty1rAjIGEbkk8kFWbyl/Flx9woN41uUiN2I UejA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+lIoMlbHxKypy9PBnb28hhcThe5rFyqtALDtAiXFIa4=; b=RXNNnmwahsDyShgtOWWlpl6zfKX3acc9qEL2ObELRFD/SbbtUerEF92rkdOiz+OW4h KmVhpJyX8vHmem4OCD7fFP5uEOm7th5wvyP2KbY2DNACcbaAs6jEIGaGRuq7tVuJuscw 9ngcU0dk1gmf0Uzg1bjxgo6BZUM0PAUanj3Ax6DWqCw2hxRnanf0VZDqrraNMPPoJUwQ NraIGesV4YnuHQnSAGGKE8Nyi5stQbU3D5BaGE0TMkjXEYtTampV0XpV1c2tpSFwL8s6 zE1foLszLvaQbeAGIbTbnyZ8QZLRHSNG9M0vAX8JeRH1+Kfd93OSVZmXStfWY3QB/23C XmLw==
X-Gm-Message-State: AEkoous6NWSX4ovLof4BVleQ5G5/QM7xL9BHesVafWJ3WP0HAg96VJCKn+FFTG1/hsj00txIc6Ona9qjAyeSaw==
X-Received: by 10.37.79.87 with SMTP id d84mr8274826ybb.165.1471664453040; Fri, 19 Aug 2016 20:40:53 -0700 (PDT)
MIME-Version: 1.0
Sender: winstein@gmail.com
Received: by 10.129.79.209 with HTTP; Fri, 19 Aug 2016 20:40:12 -0700 (PDT)
In-Reply-To: <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie>
References: <CAF8qwaDgGHGmuBwhZEz9-=Ss2bfzNAYWfmnbMqQDxTQnMUpH7g@mail.gmail.com> <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> <CAF8qwaDfWdCCQpD8z8iY0BMJjbrf8qi-qf5X7mSe8m+hNZu-FQ@mail.gmail.com> <CAMzhQmPB0GXZzh+g=-TMmAp9HQxpZUPcht4zi3_K7WW_ouGg6A@mail.gmail.com> <CAF8qwaC_NGmx4pW=HwsqWTnvZysFhXayHJ1wPVAakWHo7nunxA@mail.gmail.com> <CAMfhd9UOOXLRmNjJogikQHa8QJx+HSLO-WuwJhgKKgAA-5TeBQ@mail.gmail.com> <CAMzhQmOmOou6SvmZygJ6emfn2xAnU_jT7zb005fD4NRuOLmnPg@mail.gmail.com> <CAMfhd9UQaiWH_CAKNUMymARJAsWv4+3AatjgNEqrD78-rakubA@mail.gmail.com> <CAMzhQmMnG2cgbfOZE0VDgFRpF15B+yjx2E5G-V2fh2TwLiDcBQ@mail.gmail.com> <CAMfhd9UQ3jHLcUObBORi0Z_QQi2n4-fL9_KCwLvcDKTkJN1z5A@mail.gmail.com> <CAMzhQmMaBp0sPca9xb9jVrC=mjtZ8Rq3FnH8R8x6jcOxBO=9nA@mail.gmail.com> <CAMfhd9XxLq-S6c5K-JE50Wgm24JHihN++OawnVgQueMM8BuGuA@mail.gmail.com> <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie>
From: Keith Winstein <keithw@cs.stanford.edu>
Date: Fri, 19 Aug 2016 20:40:12 -0700
X-Google-Sender-Auth: lcjwkQxk_dGL93lj35MQeZKILGU
Message-ID: <CAMzhQmN8=pw4LGHtZHyRQcVsx4DGwE89GNpHPUSENfbxcTHwRA@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/SOKaU6Vj8c2Ox-AbeN3njwTy7wA>
Cc: Adam Langley <agl@imperialviolet.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] KeyUpdate and unbounded write obligations
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: Sat, 20 Aug 2016 03:40:56 -0000
On Fri, Aug 19, 2016 at 2:29 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > And for me, the dodgiest, by far. The scope for an "auditor" > (what is that?) actually being an attacker is IMO way too > high to consider standardising that kind of feature and any > idea that it'd involve informed consent of someone seems to > me fictional. I appreciate the sensitivity of this issue to the WG. My read of your email is that there's a concern that by standardizing a protocol mechanism that allows a node to learn when its own KeyUpdate has happened, the WG would imply approval of features that permit the bad kind of eavesdropping. Here's why I don't think that's the case: Our PR is for a piggyback integer field to provide security property P3: "An implementation can learn that its request to rekey its outgoing traffic has been read by the other side." KeyUpdate is an *instruction* to the other side: "please update my key in a forward-secure manner." We think some implementations will want to know that the instruction has been carried out. And there's an easy opportunity to do that here as a piggyback, without any extra protocol messages. A node will naturally care more about forward secrecy, and confirmation of a forward-secure ratcheting event, the more it has reason to suspect the keys might later be exposed to a third party. In Berlin, I described three escalating cases: the (1) node going to sleep, (2) node closing a connection without a mechanism for secure bidi close, and (3) node that itself intends to release keys to a read-only auditor after a ratchet is complete. By "read-only auditor," we mean a curious person or security researcher who owns an IoT device and wants to know what the heck it is sending out of their house, where the device doesn't want to allow its owner to add trusted certificates for an MITM. (This describes most such devices today.) Obviously I think it's valuable to make this mechanism available for IoT device manufacturers. Having talked to several manufacturers, I'm cautiously optimistic that some would use this. But the WG doesn't have to take a position on this. These use cases are up to implementers. There's nothing stopping an implementer today from releasing session keys, or allowing complete MITM, as is the case in the browser context with user- or admin-installed root CA certificates. The TLS WG hasn't opined on these either. To restate: Property P3 allows a node to learn that its KeyUpdate instruction has actually happened, which in our view is useful and a strict benefit over the status quo. It's also orthogonal to the issue of unbounded write obligations raised in this thread. -Keith
- Re: [TLS] KeyUpdate and unbounded write obligatio… Keith Winstein
- Re: [TLS] KeyUpdate and unbounded write obligatio… Keith Winstein
- Re: [TLS] KeyUpdate and unbounded write obligatio… Stephen Farrell
- Re: [TLS] KeyUpdate and unbounded write obligatio… Adam Langley
- Re: [TLS] KeyUpdate and unbounded write obligatio… Keith Winstein
- Re: [TLS] KeyUpdate and unbounded write obligatio… Adam Langley
- Re: [TLS] KeyUpdate and unbounded write obligatio… Keith Winstein
- Re: [TLS] KeyUpdate and unbounded write obligatio… Adam Langley
- Re: [TLS] KeyUpdate and unbounded write obligatio… Keith Winstein
- Re: [TLS] KeyUpdate and unbounded write obligatio… Jim Schaad
- Re: [TLS] KeyUpdate and unbounded write obligatio… Adam Langley
- Re: [TLS] KeyUpdate and unbounded write obligatio… Benjamin Kaduk
- Re: [TLS] KeyUpdate and unbounded write obligatio… David Benjamin
- Re: [TLS] KeyUpdate and unbounded write obligatio… Keith Winstein
- Re: [TLS] KeyUpdate and unbounded write obligatio… David Benjamin
- Re: [TLS] KeyUpdate and unbounded write obligatio… Benjamin Kaduk
- Re: [TLS] KeyUpdate and unbounded write obligatio… Ilari Liusvaara
- Re: [TLS] KeyUpdate and unbounded write obligatio… Keith Winstein
- [TLS] KeyUpdate and unbounded write obligations David Benjamin
- Re: [TLS] KeyUpdate and unbounded write obligatio… Subodh Iyengar
- Re: [TLS] KeyUpdate and unbounded write obligatio… Judson Wilson
- Re: [TLS] KeyUpdate and unbounded write obligatio… Keith Winstein
- Re: [TLS] KeyUpdate and unbounded write obligatio… Ilari Liusvaara
- Re: [TLS] KeyUpdate and unbounded write obligatio… Keith Winstein
- Re: [TLS] KeyUpdate and unbounded write obligatio… Eric Rescorla
- Re: [TLS] KeyUpdate and unbounded write obligatio… Ilari Liusvaara
- Re: [TLS] KeyUpdate and unbounded write obligatio… Eric Rescorla
- Re: [TLS] KeyUpdate and unbounded write obligatio… Ilari Liusvaara
- Re: [TLS] KeyUpdate and unbounded write obligatio… Eric Rescorla
- Re: [TLS] KeyUpdate and unbounded write obligatio… Adam Langley
- Re: [TLS] KeyUpdate and unbounded write obligatio… Eric Rescorla
- Re: [TLS] KeyUpdate and unbounded write obligatio… Russ Housley
- Re: [TLS] KeyUpdate and unbounded write obligatio… Eric Rescorla
- Re: [TLS] KeyUpdate and unbounded write obligatio… Ilari Liusvaara
- Re: [TLS] KeyUpdate and unbounded write obligatio… Keith Winstein
- Re: [TLS] KeyUpdate and unbounded write obligatio… Eric Rescorla
- Re: [TLS] KeyUpdate and unbounded write obligatio… Ilari Liusvaara
- Re: [TLS] KeyUpdate and unbounded write obligatio… Eric Rescorla
- Re: [TLS] KeyUpdate and unbounded write obligatio… David Benjamin
- Re: [TLS] KeyUpdate and unbounded write obligatio… Ilari Liusvaara
- Re: [TLS] KeyUpdate and unbounded write obligatio… Ilari Liusvaara
- Re: [TLS] KeyUpdate and unbounded write obligatio… Keith Winstein