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

Benjamin Kaduk <bkaduk@akamai.com> Wed, 24 July 2019 11:27 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 DF3021201EF for <tls@ietfa.amsl.com>; Wed, 24 Jul 2019 04:27:41 -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 qeqDDIblK8Nj for <tls@ietfa.amsl.com>; Wed, 24 Jul 2019 04:27:39 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 A230012060E for <tls@ietf.org>; Wed, 24 Jul 2019 04:27:39 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x6OBHNkE010111; Wed, 24 Jul 2019 12:27:36 +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=V4E1iWqEnq1JzWTtoLugTH8uKniTvxyBYS2/uEh8Rfg=; b=LcdYq4/ylxlkkWv+Cr0328oQF0kDEbJwXlGZYjLtx9eV8Hi5yICo8wZMygMvyZ2sjlbG fgtlzbhyBaWHoe0kPtsoA6d9bKH3/8Xxes/SgE11J+W/wxXY+XImntwKzDl98JC7njne Vkpx98zhp0PP0ZjZy6DXBxP+QeL06pebXQgCG3GT+ebZ2IGm3DnkL2tkCNwpGrM9PqqO Xox3xS9tXzRmb51JNV78dxlWBiwHrVWcmrmzCh7cJ+ZHJcPyY9ca6Nl2S7jL4TLEs6F0 JPcjXw8V8e1MAg5rdaBBKw0G3i+oxWuFpWrk9cJVn3ItGqOq1Tlx4XTJUcZ6HOKuOl7F tA==
Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2tx60uk875-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jul 2019 12:27:36 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x6OBGtwS004864; Wed, 24 Jul 2019 07:27:35 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2tx631b5wx-1; Wed, 24 Jul 2019 07:27:35 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 2640120064; Wed, 24 Jul 2019 11:27:35 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1hqFQj-0002qB-QO; Wed, 24 Jul 2019 06:27:33 -0500
Date: Wed, 24 Jul 2019 06:27:33 -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: <20190724112733.GG27936@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> <20190724031343.GD27936@akamai.com> <78479d60-6b30-4a8f-9605-648eaad8624c@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: <78479d60-6b30-4a8f-9605-648eaad8624c@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_04:, , 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-1907240127
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-24_04:2019-07-24,2019-07-24 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 lowpriorityscore=0 bulkscore=0 clxscore=1015 mlxlogscore=999 impostorscore=0 priorityscore=1501 phishscore=0 malwarescore=0 adultscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1907240128
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9BaLcfI9391HdhyPIWL22t9aAtA>
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 11:27:49 -0000

On Wed, Jul 24, 2019 at 05:19:46AM +0100, Dennis Jackson wrote:
> 
> 
> On 24/07/2019 04:13, Benjamin Kaduk wrote:
> > 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.
> 
> I was thinking of 'published by the IETF' to mean the IETF stream.

Thanks for clarifying (more below).

> Publishing in the Independent stream, without any proper review,
> consensus or claim of fitness is a different matter altogether.

My understanding is that the ISE insists on getting at least three
reviews from knowledgable people in the field as a condition of
publication.  I don't know what constitutes "proper review" to you, but
I do believe that the ISE takes the job seriously.

> >>> 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).  
> 
> This was my intended meaning.

Thanks (again) for clarifying.

> 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.)
> 
> The authors initiated this discussion by stating their draft was stable
> and requesting publication. Consequently, I think it must be judged on
> the current state, rather than the desired outcome.

Sure, and I appreciate the frank comments; I hope the authors do as
well.  However, my and the chairs' job is to tell them something like
"make these changes and come back" or "make these changes and go to the
ISE", so I have to seek feedback on a broader question than just "is it
ready to go right now".

> Even considering your more generous interpretation... the objective
> discussion is only 3 out of 15 pages and none of the 5 claims appears to
> be correct. (As others have pointed out).

In light of my previous remark, I'll try to summarize that it sounds
like you think that it's not worth trying to make all the changes that
would be needed to meet your expectations for the output of the TLS WG.

Thanks,

Ben