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

Watson Ladd <> Mon, 10 July 2017 20:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2814E12ECB5 for <>; Mon, 10 Jul 2017 13:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r67xRwEKlxqJ for <>; Mon, 10 Jul 2017 13:11:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 724FC12ECBE for <>; Mon, 10 Jul 2017 13:11:22 -0700 (PDT)
Received: by with SMTP id q86so55152156pfl.3 for <>; Mon, 10 Jul 2017 13:11:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q9+BT33C11wkJx1NTxudUfAYAP6UU4gDc11+h00RU3M=; b=EvwhwGjT4HzmHWOpYwzf66GOuOSyHjxsq+PltNofBY7PR7ho0s6O5ZPFhwVjoswsac fGdKl28SRoIHZ1ccKygZ3eMQv992cpXWendDmvc946ECZJBPZG0gZpKpiIusxRBCA3tT lY88opqaSVqJuIVabsF+Oz3cXSqjUXJISeU54yEUx0p6/E9cGuHXp47ly+tGZ/YNBlC6 6bgNQp/H5V/z8NHM/qp0uu/3HA4dm2t8MLCB0QKKzCt9q8GunqlsKzhBjJQqNggWX5dv AojhkvfJiLYYg3aA1wQb8fv1YeRdB64tnJIE2FQkSQj2NVDNt/aa5fB4SE2kJqLPooNS 2LmA==
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=q9+BT33C11wkJx1NTxudUfAYAP6UU4gDc11+h00RU3M=; b=Jj98/v/jDL3VapnBVIE75vlsS184mD9L66vDNg+iOHi8Abh6gun06TSugfrbTJG1yQ 22Q/+7REJjZu+zeTS1zXiMxQsdcRKbcRV8bBom4o7f2hcyuTU2Pn30Ai8aQTJD65pCqk v04vzDt2h05pBhXKsRdeSJrkuMMRdYbAQkj/PzxLZo8Azjp1/x3unboNkzabr0qO9r/A 0TWB4OIEe8QMjndjZn22hbcesdZ4eJ96j/0qsA/BkV3KOg5K2qcQPctN1Wi5EC9+V+tN NGeKPy3Nf9r/LdgLQ1VUKxot7CDfQRRMNli/EYhm226AYR2sZ3i/7uld75LOyv4vZkMT /0/A==
X-Gm-Message-State: AIVw113doYknj9yjfxbU7osOKC1U9mlAG39E7jpx7fZgB5Q6AS2NmVay IpHIcTN8o/k4CDTPiufB+qf7sTe6cLQO
X-Received: by with SMTP id p68mr40106877pfb.209.1499717482071; Mon, 10 Jul 2017 13:11:22 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 10 Jul 2017 13:11:21 -0700 (PDT)
Received: by with HTTP; Mon, 10 Jul 2017 13:11:21 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Watson Ladd <>
Date: Mon, 10 Jul 2017 13:11:21 -0700
Message-ID: <>
To: "Ackermann, Michael" <>
Cc: "Polk, Tim (Fed)" <>,
Content-Type: multipart/alternative; boundary="94eb2c03a092c84abc0553fc2ffe"
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: Mon, 10 Jul 2017 20:11:25 -0000

On Jul 10, 2017 8:46 AM, "Ackermann, Michael" <>; wrote:

+1 !!!


For the enterprise situations,  we typically own, operate and manage the
involved “Facilities”:

The Servers

The Applications

The Networks

The Keys

The Data
and in Many cases the clients as well

Given the above scenario,  I do not understand how this can be construed as
“Wiretapping”.    2804 seems to make this clear.

What Enterprises want in this space, is the ability to continue to have
access to their aforementioned facilities,  to perform diagnostics,
monitoring and security functions.   (i.e. continue to effectively operate
and manage our networks).  Although I believe the Matt Green draft proposes
a very good, viable and well thought out solution for TLS 1.3,  I suspect
most of us are open to different or better solutions,  if such exists or
can be conceived.

There seems to be good discussion, requirements and ideas on both sides of
this issue,  albeit in sharp disagreement in many cases.      Such critical
colloquy,  with significant long term impact,  should not be prematurely
terminated,  IMHO.

Finally an editorial comment from those of us TRYING to get Enterprises
involved at IETF.   We finally have some interest and engagement from
Enterprise perspectives.     Killing discussion on this issue,  which is
clearly important to Enterprises, will send the message that IETF did not
really want this input or feedback.      I hope this is not the case.

One vertical is not all enterprises. Plenty of companies can trace requests
via logging systems and do not need mirroring for diagnostics.

Perhaps if we weren't faced with a last minute request to include static
ciphersuites things would be different. But the technique exists and can be
used regardless of approval. (Have you considered Dual EC+extended random?)

The problem->box model has never been well-suited for the internet. There
are serious policy considerations here and a long agenda for this WG.
Stopping discussion is not about ignoring the problem: it's stopping a
discussion going nowhere from eating up all the bandwidth.

*From:* TLS [] *On Behalf Of *Polk, Tim (Fed)
*Sent:* Monday, July 10, 2017 9:54 AM
*Subject:* Re: [TLS] chairs - please shutdown wiretapping discussion...

First, I do not see this as a “wiretapping discussion” based on my reading
of 2804, although others may disagree.

Second, I believe that this discussion should go forward based on several

   1. this proposal does not involve any changes to the bits on the wire
   specified in the TLS 1.3 document
   2. this proposal offers significantly better security properties than
   current practice (central distribution of static RSA keys)
   3. alternative solutions with significantly worse security properties
   are also feasible under TLS 1.3, and I would like to avoid them!

We should be in the business of developing pragmatic, interoperable
solutions with appropriate security properties.  Balancing cryptographic
security with other security requirements to achieve such solutions should
be an acceptable path, and pursuing this work in the TLS working group
gives the IETF the best opportunity to influence these solutions.

The information contained in this communication is highly confidential and
is intended solely for the use of the individual(s) to whom this
communication is directed. If you are not the intended recipient, you are
hereby notified that any viewing, copying, disclosure or distribution of
this information is prohibited. Please notify the sender, by electronic
mail or telephone, of any unintended receipt and delete the original
message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
nonprofit corporations and independent licensees of the Blue Cross and Blue
Shield Association.

TLS mailing list