Re: [TLS] chairs - please shutdown wiretapping discussion...

Kyle Rose <> Wed, 12 July 2017 12:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A82A4131690 for <>; Wed, 12 Jul 2017 05:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mBn7JlaHWceB for <>; Wed, 12 Jul 2017 05:24:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 27DFA12EC30 for <>; Wed, 12 Jul 2017 05:24:26 -0700 (PDT)
Received: by with SMTP id 16so20218095qkg.2 for <>; Wed, 12 Jul 2017 05:24:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pg6Puo3fjGe/fYzESalEACdZ0KaVRNYLVb1+sUaueXQ=; b=oIWBzzywum0NiSjdLAl07hwZuvjr+GtZ9aAKNIvqjZamcxr7t3TtV0TQTN1Kxf2hty ZPmiq8qCFz9Xw8AlKTHDIrWyRWyRxla5Fowt6SXu8wxVOilLjqmqkIYbeyvkm9z4e1Lf ve409bpdArM/cYF9eA0Jvf8xmfPBjt2tctM2I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pg6Puo3fjGe/fYzESalEACdZ0KaVRNYLVb1+sUaueXQ=; b=o+OAEXIbb6tLfa9hAV0j/nLE6AH/vZB6cEu959D6CNlmxDy2z6QpQNAspfl8brMqal x6RzO61id233iNuFtVAxcYO1HmzDGHmbD/aqy/QkJHgCkzazRz8ebFacvK393+aa9Ykj OEJiduz9W3PbXqANN6spGf6v1yQPs15izwYopo7XnXeE8E89hfOnRWHU1NAC+uiHTkKw cWm26gkb4msVAN9nqsJ1yIcF6L6/XLsSzTms5S9qtxsGn4Hk17jIZJd+g/gdFUmzmk1R pVnTEVWe9N19CFcCc9g6z4HVU47wAA9tXVIxTqcy0DelCvfk+AmKdYBHo3WA+2H9Ksua jHsg==
X-Gm-Message-State: AIVw112UM4APHJrOEUj2iWdCa0YGMq4XadWajJ2d9GSEg6ln5r9tDMr5 AaK2UiULBtcjwiSARUUYgzwp7qB5NWtf
X-Received: by with SMTP id v13mr5464104qkb.107.1499862265143; Wed, 12 Jul 2017 05:24:25 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 12 Jul 2017 05:24:24 -0700 (PDT)
X-Originating-IP: [2001:470:1f07:121:5cb5:ecff:fe89:28ca]
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Kyle Rose <>
Date: Wed, 12 Jul 2017 08:24:24 -0400
Message-ID: <>
To: Ted Lemon <>
Cc: Stephen Farrell <>, "Polk, Tim (Fed)" <>, IETF TLS <>
Content-Type: multipart/alternative; boundary="94eb2c05760686b79905541de5e5"
Archived-At: <>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Jul 2017 12:24:29 -0000

On Tue, Jul 11, 2017 at 9:11 AM, Ted Lemon <>; wrote:

> It’s also true that you can just exfiltrate every key as it’s generated,
> but that’s not what’s being proposed and would not, I think, suit the needs
> of the operators who are making this proposal.
> I don’t see how you could mitigate against deliberate key exfiltration.
>  At some point you really are relying on the security of the endpoint.
>  But being able to detect repeated keys is useful for preventing pervasive
> monitoring: it requires the monitored either to have access to the key
> generation stream in realtime, or to request the key for a particular
> conversation.

Much of this conversation seems to conflate wiretapping with collaboration.
2804 has a clear definition of wiretapping:

q( Wiretapping is what occurs when information passed across the
   Internet from one party to one or more other parties is delivered to
   a third party:

   1. Without the sending party knowing about the third party

   2. Without any of the recipient parties knowing about the delivery to
      the third party

   3. When the normal expectation of the sender is that the transmitted
      information will only be seen by the recipient parties or parties
      obliged to keep the information in confidence

   4. When the third party acts deliberately to target the transmission
      of the first party, either because he is of interest, or because
      the second party's reception is of interest. )

This proposal (and related proposals involving encrypting session keys to
inspection boxes, either in-band or OOB) violates condition 2 because one
endpoint would have to intentionally take action to deliver the session key
or private DH share to the third party. If one endpoint is feeding
cryptographic material to a third party (the only way that information gets
out to the third party, vulnerabilities notwithstanding), they are
collaborating, not enabling wiretapping.

(I'd argue the inspection box also fails to be a third party, as it is part
of the infrastructure of one endpoint, but that's largely irrelevant to the
question of whether this is wiretapping once we've determined the delivery
of keys is not a secret.)

I think this issue of static DH being an attack (maybe; not taking a
position) is something of a red herring, because shipping individual
session keys to a third party like a government doesn't add any substantive
hurdle beyond shipping them a single static DH share. That said, I agree
that an infrastructure for detecting the loss of forward secrecy, perhaps
in a CT-like manner, may make sense to protect against unintentional key
compromise or compromise of one endpoint: the problems that forward secrecy
is intended to address, which specifically do *not* include collaboration.