Re: [TLS] TLS Impact on Network Security draft updated

Benjamin Kaduk <bkaduk@akamai.com> Wed, 24 July 2019 03:13 UTC

Return-Path: <bkaduk@akamai.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 3339012008F for <tls@ietfa.amsl.com>; Tue, 23 Jul 2019 20:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 Kca5B3oPIp8V for <tls@ietfa.amsl.com>; Tue, 23 Jul 2019 20:13:49 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9246120046 for <tls@ietf.org>; Tue, 23 Jul 2019 20:13:49 -0700 (PDT)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x6O373ZL013489; Wed, 24 Jul 2019 04:13:47 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=MC+Q59qqMJGJweHaT7hr+w9iCjuOa+Qb7N/u1hkEa2M=; b=QKsGPfsvICNRsMgJmJ9OCQLgksePNa4AzKxU6zu0P4596oIktpFsv6eYmiaFnHDwevl3 TqwjMPJ0sPb3b4Eyzh4Cu4kthNznFYqgdQOh3N01Yhih7K3AzMNtVOu1iJwN84zGISVb 4/9x6vZLtfRauTDNoLimfC1DxAxswtD/mHI+R1txF/4Ejq9O0gJTvkJlRqGCa6L7m7Yn digtCOHW+fGfzJfikX2JW0ERWf8WSCGqBV6Hmam9ZifzQ6FlUAy8IpdvJUYzvz8Y4bJv 2uCi+uzJJ6bJsYLSsgUlCRp09IS7oXcdhM1wT7UwT6weS/O3FQ4+NYmtWtK6TxXYT9fQ 9g==
Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2tx60rsx1c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jul 2019 04:13:47 +0100
Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x6O325Dg008159; Tue, 23 Jul 2019 23:13:45 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint6.akamai.com with ESMTP id 2tx62y0fmd-1; Tue, 23 Jul 2019 23:13:45 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id A42511FCDD; Wed, 24 Jul 2019 03:13:45 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1hq7iq-00010Z-GV; Tue, 23 Jul 2019 22:13:44 -0500
Date: Tue, 23 Jul 2019 22:13:44 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Dennis Jackson <dennis.jackson@cs.ox.ac.uk>
Cc: "tls@ietf.org" <tls@ietf.org>
Message-ID: <20190724031343.GD27936@akamai.com>
References: <51f39225-1953-b603-bd15-bbc7d4bf2222@cs.ox.ac.uk> <1300C2AB-ACCD-4F29-96CF-D27A6737A799@gmail.com> <8f95317e-880d-f064-49a1-e51945b06b29@cs.ox.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8f95317e-880d-f064-49a1-e51945b06b29@cs.ox.ac.uk>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-24_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907240034
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-24_01:2019-07-23,2019-07-24 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=999 mlxscore=0 priorityscore=1501 impostorscore=0 bulkscore=0 clxscore=1011 spamscore=0 lowpriorityscore=0 malwarescore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1907240035
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/cwGfhcqYo68SYwxSTRpVvSGKYnc>
Subject: Re: [TLS] TLS Impact on Network Security draft updated
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 24 Jul 2019 03:13:51 -0000

On Wed, Jul 24, 2019 at 03:35:43AM +0100, Dennis Jackson wrote:
> On 24/07/2019 02:55, Bret Jordan wrote:
> > As a professional organization and part of due diligence, we need to try
> > and understand the risks and ramifications on the deployments of our
> > solutions. This means, understanding exactly how the market uses and
> > needs to use the solutions we create. When we remove or change some
> > technology, we should try hard to provide a work around. If a work
> > around is not possible, we need to cleanly document how these changes
> > are going to impact the market so it can prepare. This is the
> > responsible and prudent thing to do in a professional organization like
> > the IETF. 
> > 
> 
> The IETF is for development of Internet Standards. If you want to
> publish your (subjective) analysis of how a particular standard is going
> to impact your market segment, there are any number of better venues:
> trade magazines, industry associations, your company website, etc.

Actually, the Independent stream of the RFC series is purpose-built for
individual commentary on the consequences of a particular standard
[including in a particular segment], and would be superior (at least in
my opinion) to any of the venues you list.  (See RFC 4846.)  But I
believe the current ISE asks authors to try fairly hard to publish their
work in the IETF before accepting it to the Indepndent stream.

> > The draft that Nancy and others have worked on is a great start to
> > documenting how these new solutions are going to impact organizational
> > networks. Regardless of whether you like the use-cases or regulations
> > that some organizations have, they are valid and our new solutions are
> > going to impact them. 
> 
> This isn't a question of quality. The IETF simply doesn't publish
> documents of this nature (to my knowledge).

The IETF can publish whatever there is IETF consensus to publish.  (And
a little bit more, besides, though that is probably not relevant to the
current discussion.)

I don't have a great sense of what you mean by "documents of this
nature".  If you were to say "the IETF does not publish speculative and
subjective discussion of possible future impact", I'd be fairly likely
to agree with you (but I have also seen a fair bit of speculation get
published).  I'd feel rather differently about "the IETF does not
publish objective analysis of the consequences of protocol changes on
previously deployed configurations", and would ask if you think a
document in the latter category is impossible for the TLS 1.2->1.3
transition.  (My understanding is that the latter category of document
is the desired proposal, regardless of the current state of the draft in
question.)

-Ben