Re: [TLS] TLS@IETF101 Agenda Posted

Ted Lemon <> Tue, 13 March 2018 17:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 915C7127601 for <>; Tue, 13 Mar 2018 10:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 uZeoONZlJTSy for <>; Tue, 13 Mar 2018 10:52:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1CE31124C27 for <>; Tue, 13 Mar 2018 10:52:48 -0700 (PDT)
Received: by with SMTP id b198so529409qkg.9 for <>; Tue, 13 Mar 2018 10:52:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JPf6FFtsWjhGY/nXKm3tLKuaEBibkdy56mdUDkiiFXE=; b=tX7LRWYS5jZTAiOY4CGUvfWnEJ8VDB7/RITqpVM1rP2qj3uEBTGPemSBQrS/rs919v eDWDq8nb3TDEC7rP60IijfJqlOcqt6AuWcqDJs+rKiVTdpQi0NAP1god6Sc4KRSnoMBN KlpF7QpS5+Ew07HMszn6uHxS+sDSi9s8zvvXWmTTzseiWUVc20fVrN3FmR5+6hOHPA7/ QrWh/qjWk+jDAC+bh7zuBd8tRi1zOW3r11lyR8pitMTdi9bXFn+kj5TTJmsI+s+v1vR0 P0qYWayBxhk0ESgUwTQ0qGscYpelqPXDg8CpJ5DTTEZ8xhHgmjcxH09HVPOHYjCGpBuL rzAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JPf6FFtsWjhGY/nXKm3tLKuaEBibkdy56mdUDkiiFXE=; b=qhvBXoHpmuuu9x08aRFUNXAvJNlYDVmdHBaDzPGcznbEMqgAiIYNokF+dNrtfWS6Vg 4a5wVMoz+kK0g3bfgeslcCf58E4wwgTdGx7fgR3Lglj9CuY/X6cDilz4/O8gEfl75hxR ijhWKebDiWw4qpjXuyWTPIg8pR9HpQqQ4+isjlnAIwfxwOoJsuQlF5beM69Txm/n149c 3g6Li/7FDNjyQ3wksa5pMp/dlyb85FvvydGn5R5eUkjrsob00cWjAaKTr2M/wDY4lcXw ARtssmug0AVA6eZ2MEUSNoF6RM4mGPNy2zOmaFjBtskLsmQrnVcrObX6SOgijh44Xrnl 7KUA==
X-Gm-Message-State: AElRT7E9TZQYmgOrpt8pq42xv5CGeKF08Nah3Sd4j4scmykiQ228ORf2 r28rCNRQBLW2z4NnaBCMnLgYIQ==
X-Google-Smtp-Source: AG47ELu6/16EtnjURpbmXJgmLXAQpbMNBlt7KevxZl7d8pchPscJK8LPJ+NA0CnG6PkvFk0LTsXQYg==
X-Received: by with SMTP id x123mr2165180qkd.254.1520963566722; Tue, 13 Mar 2018 10:52:46 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id s3sm580872qte.95.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 10:52:45 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E43A0E8C-AFCB-45DD-AE6E-524FAC866567"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Tue, 13 Mar 2018 13:52:44 -0400
In-Reply-To: <>
Cc: "Salz, Rich" <>, "<>" <>
To: nalini elkins <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [TLS] TLS@IETF101 Agenda Posted
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: Tue, 13 Mar 2018 17:52:50 -0000

On Mar 13, 2018, at 12:37 PM, nalini elkins <> wrote:
> "We" is a consortium of organizations.   I would say over 50 so far.  They operate large data centers.   They are in manufacturing, insurance, finance, and others.  

Nalini, why don't you (the consortium) define the standard, then?

The reason I ask is that you are essentially asking us (the security folks) to bless something that is pretty obviously a bad idea, and of course we're resisting, and we're going to continue to resist.   I don't think you are ever going to get consensus on a document in the IETF that says what you want it to say.   And this is perfectly fine.   Your consortium can publish its own document that says what you want it to say.

Then when this goes badly wrong, it will be your consortium that is responsible, not the IETF.   Or if it doesn't go badly wrong, you can claim the credit.   But either way, you aren't going to have to keep arguing with us about this.   I don't think there's any reason for you to think that the argument is going to end in consensus; this is the reason that some of us are asking for it to stop.

Also, if what you produce isn't an IETF standard, then a browser can identify whether it implements IETF tls 1.3, or business-consortium-wtls-1.0.   We would hope that browsers that implement the latter would not exist, and that this would be okay for you because you don't actually need this hack in the browser.   That's the value of not doing this work in the IETF.

Also, I just wanted to mention a problem with something you said earlier:

> We feel that there is also an underlying motivation to help the underdog and protect the political dissident. 

This is not a correct description of the situation.   TLS security is needed by whose information is communiced information over the network when revealing that information to an adversary would put them at risk.   When you make TLS security weaker, the set of people who is at risk is everyone, and the risks go from "twitter account compromised" all the way up to "teen with 'shameful secret' commits suicide when outed" or "my aging mom loses her retirement savings."

In addition, you are reducing compartmentalization with your keying strategy—in order to make communications easily decryptable, you have to have broadly-shared keys, and that reduces the amount of compartmentalization that TLS can provide between disparate elements in your networks.

We have seen the result of poor compartmentalization on network security—the most recent really egregious example being the Equifax, which would have been a lot less bad if Equifax had employed the sort of basic compartmentalization precautions that the NIST recommends.   Reducing compartmentalization inevitably makes it easier for an adversary to infiltrate your network and exfiltrate private user data.   Maybe it will never happen if you are careful enough.

The point is that your characterization of our objections as being about a certain special corner case is simply not an accurate characterization.   What you are proposing to do will weaken your network security too, and this weakening is quite likely to result in my personal data being compromised.

It would be really great if we could start talking seriously about ways to solve your problem, but that conversation can't take the form "how can we avoid making any changes?"   When I've tried to have serious conversations with you and others in your consortium about how to solve this problem in the past, any solution that requires you to implement new technology is always off the table.   That's no good.