Re: [TLS] Industry Concerns about TLS 1.3

Melinda Shore <melinda.shore@nomountain.net> Wed, 28 September 2016 23:27 UTC

Return-Path: <melinda.shore@nomountain.net>
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 BE26A12B2AE for <tls@ietfa.amsl.com>; Wed, 28 Sep 2016 16:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.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 nHd48iF_G6RZ for <tls@ietfa.amsl.com>; Wed, 28 Sep 2016 16:27:28 -0700 (PDT)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 AF88112B28E for <tls@ietf.org>; Wed, 28 Sep 2016 16:27:28 -0700 (PDT)
Received: by mail-pf0-x22e.google.com with SMTP id q2so22021673pfj.3 for <tls@ietf.org>; Wed, 28 Sep 2016 16:27:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=hQkW3PlPTcoL3xkPNR2zubERkhIcHmH456+lsG+8hlg=; b=xUug1HdblmATYR3g7OWtn8wPmP4fPH2bR1QusmbsvbYbhwxDrgiF7AmTTV93apNaJB wEySZ41bcg2Fz5XO/vtsZav1sABgY08JfFSEYNYQNPpfenBQE/xLkGRNu0Sjv4L6met4 SylwkRhT8T8bpyp5XQbZobLDhq4qGdOSNDLpUbLw6LrsU2Id7rxT6JN8FornrWOMv6ya lkBNdBNd5Ikz2lZSt/9XnkTecGg3n/W3z+/uJHpMAuvgeUctuKgP0PCEpA3TLliXj3I5 jhU3QrWxS/sV0xg+M1rreJk70R0qb0jbMkEUcWN6HV9EK9OAN8wjr8Oajj0fZi40bqJJ Bh+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=hQkW3PlPTcoL3xkPNR2zubERkhIcHmH456+lsG+8hlg=; b=Dz0iH1TWgcs3FDKbbV/Xj82VL6bj4gs6B2DHzU1BDUQjWBEBlfzf+SfCHRyx/Q/Oqv ZuliGeXRCdgEP6YgGE0ib9Vq6qlfjo8ysR+mWj2USOOsPUyU0HxsU99Sld7Vbz82hgk9 Ft5tv07d4opLJ84DVUqAcjofdiZg9HgvLXWbqkpj7AtdoB0nDyxkUgE8+x3lkOEr4K9s jq3pD89T1shhHC/uLbvrs7jYpD+jWvT9yTk56F0ATXPgoCL+b54qixN2N752t6oUlwZt RB25jOXD6oFrCN3u0wAovtmqAU94nKp7dqsig6qHUBIl3M0BJANSd05YcyV/ImKaKSDI +JMA==
X-Gm-Message-State: AE9vXwOXNNWuICsBPbQ/IhgK+b8W56ZvC9dv3WJJcNnWyRk4FLJxNLTXkahITGluum+5Yg==
X-Received: by 10.98.10.145 with SMTP id 17mr60795214pfk.144.1475105248071; Wed, 28 Sep 2016 16:27:28 -0700 (PDT)
Received: from Melindas-MacBook-Pro.local (209-193-50-87-radius.dynamic.acsalaska.net. [209.193.50.87]) by smtp.gmail.com with ESMTPSA id c28sm14960031pfj.6.2016.09.28.16.27.27 for <tls@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Sep 2016 16:27:27 -0700 (PDT)
To: tls@ietf.org
References: <r470Ps-10116i-D1400872992D4A999C16CBD8D0E8C6D1@Williams-MacBook-Pro.local>
From: Melinda Shore <melinda.shore@nomountain.net>
Message-ID: <282ff05b-f013-7af8-2c44-64ee814323a9@nomountain.net>
Date: Wed, 28 Sep 2016 15:27:09 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <r470Ps-10116i-D1400872992D4A999C16CBD8D0E8C6D1@Williams-MacBook-Pro.local>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oiru6GKBONCBqFkXavtfUefVHuq3rWm60"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/awWpeq-gFmLpcOlrmaKKJeIgM_Y>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
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: Wed, 28 Sep 2016 23:27:31 -0000

On 9/28/16 3:08 PM, Bill Frantz wrote:
> On 9/28/16 at 2:01 AM, mrex@sap.com wrote:
>> I'm sorry, but I'm still violently opposed to the IETF endorsing
>> backdooring of security protocols.
> I find myself in violent agreement with Martin, and many others in the
> IETF.

This seems uncontroversial and frankly somewhat low-information.
Yay, crypto backdoors are bad.

That said, IETF participation is dominated by large equipment and
software vendors and the problem space, at least until recently
(there's been a crop of data center-related problems coming up in
OPS and routing), has tended to cover service provider-related
questions.  We have poor participation and representation from
enterprise networks.  So now we've got someone showing up from
the enterprise space and saying "I have this problem related to
protocol changes."  And yeah, he's very, very late in this
process, although it's worth pointing out that it's in the best
tradition of the IETF to deal with technical problems that crop
up with documents at any point in their development.

It seems to me that the discussions of alternatives to modifying
the protocol to meet his needs has been extremely helpful, and it
also seems to me that in some sense this ought to be an object
lesson to large enterprises dealing with fairly sophisticated
protocol problems that they really need to get involved and make
their requirements known.  If there's a need here for a new
monitoring framework that doesn't involve compromising the
security of IETF protocols, that strikes me as an interesting
question.  In the meantime I'd hate to see this level of hectoring
continue - we need more participation from other kinds of network
operators, not less.

Melinda