Re: [TLS] KeyUpdate and unbounded write obligations

Adam Langley <agl@imperialviolet.org> Thu, 18 August 2016 21:26 UTC

Return-Path: <alangley@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 2EAA312D1AF for <tls@ietfa.amsl.com>; Thu, 18 Aug 2016 14:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 QUebbeKy8bkh for <tls@ietfa.amsl.com>; Thu, 18 Aug 2016 14:26:46 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 9AD4A12D0FF for <tls@ietf.org>; Thu, 18 Aug 2016 14:26:46 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id u25so2899581qtb.1 for <tls@ietf.org>; Thu, 18 Aug 2016 14:26:46 -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=WGuc14OgVhCtqNXH1/jEzWn6hOHNrzzs8TJcE0tQHNQ=; b=fCv8y2+gqcqwCLsonp2fyiCoMWjHD4AX0s9IyIUe1lWr4+4ELK2tUs/yNMU1Ith+NF bnOIw7YThwbFSgayvlqUeCdarLigV0HlT+dWPEfYOoLNTObadekYIcJM1iQCIL0xrDHt Mf6KM20GFuQLR7kFCH4f2mYUSslqFN8fBjRbFIxB9HxaHe1olob01jDtvywAnBOWDe1a o+WaYTXjoAuetDWN2Bd4mJhhmMVWUArN57l4sk5w/ETSu8KAHsceSjg4vdgWunPGHhpL WSYg7hFyOxGASDA2wH8L0OVc6A8cvkc4FJulkiy5ukjMOC84koNBL9iyg815cszLrM4S A4SA==
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=WGuc14OgVhCtqNXH1/jEzWn6hOHNrzzs8TJcE0tQHNQ=; b=DCUqoBMcuyIzdd5jvIKZBvIHaO3aziomDCUUZYonwGjUxKpc7tax1XqD9s4Vc4KECn Biee1JQTWc3ueFkBhI1vKXxgFQ/XGPm8dSHlLJEkKrHTLOYpf9PQ4mDtKZLkJVSCGcFx /txtugec2leOmZngBsqxdTjqFnd4m3Q1kd0DNX0LFnc6XUmPl9lVJPLjoTInKbrmzzQr MEymUg1z1ZI5b9LpmoD9HTL7gfEiIXFGlcog6brYlMlMuBy1uAEeqH2Wv1Cu0eiXRq/h K/3Swslt+AYBl/sMMZzm5TbH3c9SMUj27Q9cUWzNhDbF7oefQKzOeNOsybdJ0Ur6OnjU ME1Q==
X-Gm-Message-State: AEkoousZPk1PTQdx0ffnxetQtGQvEY0EEBqnp1ANTyqwADy+kZbBXV6jkwFNuS1Rbc1L3zM2sU6eaDoijFhl/g==
X-Received: by 10.200.34.135 with SMTP id f7mr5012721qta.141.1471555605747; Thu, 18 Aug 2016 14:26:45 -0700 (PDT)
MIME-Version: 1.0
Sender: alangley@gmail.com
Received: by 10.200.36.199 with HTTP; Thu, 18 Aug 2016 14:26:45 -0700 (PDT)
In-Reply-To: <CAMzhQmMnG2cgbfOZE0VDgFRpF15B+yjx2E5G-V2fh2TwLiDcBQ@mail.gmail.com>
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>
From: Adam Langley <agl@imperialviolet.org>
Date: Thu, 18 Aug 2016 14:26:45 -0700
X-Google-Sender-Auth: cnnC9qjtVwkwby58rG8oi-9K91U
Message-ID: <CAMfhd9UQ3jHLcUObBORi0Z_QQi2n4-fL9_KCwLvcDKTkJN1z5A@mail.gmail.com>
To: Keith Winstein <keithw@cs.stanford.edu>
Content-Type: multipart/alternative; boundary="001a113f420c25df9e053a5f3df1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2jSuwTTb0U0AhMLKvnkbdHymq9k>
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: Thu, 18 Aug 2016 21:26:49 -0000

On Thu, Aug 18, 2016 at 1:36 PM, Keith Winstein <keithw@cs.stanford.edu>
wrote:

> On the value of P3, I think you're giving us a crimped reading. We
> gave three use cases in Berlin and in my email:
>

I think I was because I hadn't seen your Berlin presentation. But I'm still
going to hijack this thread and ask you to expand on some of these points
so that I understand your motivation :)

- An embedded device may wish to fully rotate the session keys before
> going to sleep.
>

I imagine the argument here goes:

1) Sleep is good because it saves power.
2) To sleep we need to power down (and erase) most memory.
3) So to keep a TLS connection across sleep/wake secrets have to be saved
to flash, but that's hard to erase so we don't want to expose keys that
were used to encrypt traffic.

For that I see why one needs KeyUpdate to be echoed: as the embedded
device, you want the peer to rotate keys so that you can write only fresh
keys to flash. On wake you want the other side to rotate again so that the
keys in flash were only used to authenticate a new KeyUpdate.

But why do you need the other side to have confirmed that it has erased
your keys? I think you only care that it echos your KeyUpdate messages
promptly.

- A paranoid device might fully rotate the session keys before closing
> the session. (If confirmation is absent, the device might use a
> higher-level mechanism to forcibly log out all open sessions from that
> user.)
>

The worry here is that a peer might be seized and subject to a cold-boot
attack to lift the TLS connection keys? So if you don't hear from it every
$x seconds you'll log it out?

Again does the confirmation here help? What if you send a KeyUpdate and
receive a change password request? The peer might well have sent it before
receiving your KeyUpdate, or maybe it was seized and will just choose not
to echo your KeyUpdate.

(I might well be misunderstanding the details here.)

On this last use case, I agree that incumbent IDS vendors may not be
> eager to support it. But adoption would probably come from a different
> direction. IoT devices today forbid anybody, including a middlebox
> controlled by the device owner, from auditing their own traffic and
> seeing what the devices are sending and receiving. (Unlike a browser,
> they don't let the user add a private CA cert to be able to MITM.) In
> my conversations with IoT device vendors, some expressed interest in
> allowing device owners to grant read-only access to themselves. I
> really do think this would be a good thing.
>

If they have a channel to the user where they are sending a stream of old
keys, couldn't they just mirror the plaintext of the connection to keep
things simple? I guess you worry about a device that's cooperative enough
to put in the effort to have their audit channel but lies about the
plaintext?


Cheers

AGL