Re: [TLS] KeyUpdate and unbounded write obligations

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 19 August 2016 21:29 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 5F82F12D1B7 for <tls@ietfa.amsl.com>; Fri, 19 Aug 2016 14:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.548
X-Spam-Level:
X-Spam-Status: No, score=-5.548 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_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 SNovbxr9eiNv for <tls@ietfa.amsl.com>; Fri, 19 Aug 2016 14:29:53 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8967F127058 for <tls@ietf.org>; Fri, 19 Aug 2016 14:29:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 42335BE5F; Fri, 19 Aug 2016 22:29:52 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbOlgJCexE_F; Fri, 19 Aug 2016 22:29:51 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 73E2DBE5C; Fri, 19 Aug 2016 22:29:50 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1471642190; bh=knxkSikjvweksYkSNdPDMCNsirO/Ptp2Mt5k677GH1Q=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=37JLy+lBEobWvJ9R9aCd/scXVqaBw9HFjsBQCzVqYb2JE5bX6acfKJaJCdEj8Y4YZ 8FG+R9Md7JmjuI7OBlojX9/oDG1tq4nlFrg20AlHbRa9iP8ZGb1++px2Rn1UY3M2PO m9s9jSYQ8zL6Cn5/4/s2N8KWKzFD3kE34WRomZY0=
To: Adam Langley <agl@imperialviolet.org>, Keith Winstein <keithw@cs.stanford.edu>
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>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie>
Date: Fri, 19 Aug 2016 22:29:50 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAMfhd9XxLq-S6c5K-JE50Wgm24JHihN++OawnVgQueMM8BuGuA@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030703000102080503030500"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HlfatLlWtSPE-gxVIb1Ymqgry3Q>
Cc: "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: Fri, 19 Aug 2016 21:29:55 -0000


On 19/08/16 19:05, Adam Langley wrote:
>> > Right, exactly. (Ideally, the device doesn't even know it's being
>> > audited until the user logs in to the Web UI and says, "okay, now,
>> > ratchet the session and then share the old keys with this auditor that
>> > I am going to introduce you to, so it can decrypt some earlier
>> > ciphertext I've been capturing." So we don't want a parallel channel
>> > and we don't even want the device to have to know about the audit
>> > beforehand.)
>> >
> I think that this is the most interesting case.

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'd be opposed to that fwiw, as an individual participant.

As an AD, I'd look excruciatingly closely at the process for
demonstrating that there's a real WG and IETF consensus for
that kind of feature and that its potential for conflicting
with other BCPs and well established IETF positions is very
carefully considered.

S.