Re: [TLS] WG adoption call: SNI Encryption

Benjamin Kaduk <bkaduk@akamai.com> Wed, 16 August 2017 21:40 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 7545D132710 for <tls@ietfa.amsl.com>; Wed, 16 Aug 2017 14:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HP7Ow-SY3DC2 for <tls@ietfa.amsl.com>; Wed, 16 Aug 2017 14:40:51 -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 A726813271A for <tls@ietf.org>; Wed, 16 Aug 2017 14:40:51 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7GLbw9g032206; Wed, 16 Aug 2017 22:40:50 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=+bnvbVbPjyvF8HyAi2BxFbSUgZNhUVUOAe+Fj1f17ng=; b=BsS5740qa+v2PP+6F7ovpwFVHbvtuL6v5U80HgvKLcrvbwI8cGP9YPtjXVYCzG293+tx mJTxWGUwwhybskOE1MfR3UFovmTpfSmL7n1jJlq0aznnDGvDJ/HVN/6tesZvxA5MCoz8 9KDQ//SdRkOOxqgZocplhRw1imsKvyeDek//HQPey083LgDdfnrBfTgJrXznlBd9PIUM nmwbt8BAjle8yww3KwPAsKoNTwso/hcIUJNAJOG/JxyWkdgO/YZik7b/xwjqFFgrrzZZ wvYUgpbRsdg/1pgrdWj53+fjqCJ14FN8EmrMvxWS9Hxsu8yFOuG34T7nD4aP9efjDQMx Mw==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2cc6dv456e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Aug 2017 22:40:50 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7GLa93I021684; Wed, 16 Aug 2017 17:40:48 -0400
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2cc6cvcjdg-1; Wed, 16 Aug 2017 17:40:48 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 67CA11FC7E; Wed, 16 Aug 2017 21:40:48 +0000 (GMT)
To: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>
References: <BF7B3577-8D84-42AD-A07C-2AD1AC371E81@sn3rd.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <9e7d7c7a-9668-704e-4f38-ee057e48587e@akamai.com>
Date: Wed, 16 Aug 2017 16:40:48 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <BF7B3577-8D84-42AD-A07C-2AD1AC371E81@sn3rd.com>
Content-Type: multipart/alternative; boundary="------------0252F4B1A4BCB924EA564480"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-16_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708160354
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-16_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708160354
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/crFNy1MTvvzW0KINCgWyvu43aMQ>
Subject: Re: [TLS] WG adoption call: SNI Encryption
X-BeenThere: tls@ietf.org
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." <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, 16 Aug 2017 21:40:53 -0000

On 08/04/2017 07:50 AM, Sean Turner wrote:
> At our IETF 99 session, there was support in the room to adopt draft-huitema-tls-sni-encryption [0].  We need to confirm this support on the list so please let the list know whether you support adoption of the draft and are willing to review/comment on the draft before 20170818.  If you object to its adoption, please let us know why.
>

It is before 20170818, and so I make my reply to the call for adoption now.

I think that the WG should discuss this topic and produce a document
with it, but I am not convinced that this document, as it stands, is a
good starting point for a product of the WG.  As has already been
discussed, it is a bit strange to have normative language in the catalog
of known attacks, but removing those is easy and also uncontroversial. 
That said, my main reason for believing that changes are needed before
this is a good starting point for a WG document is that it does not
present itself as a single cohesive solution, but rather a choice. 
This, of course, has also already been noted, but I will note that I
also prefer to have the choice resolved before adopting a WG document. 
(It is possible, of course, that the choice of the WG will be that both
flavors are necessary, or even something not yet included.)

That said, I am happy to review and comment on drafts in this area as
the WG discusses options and settles on a consensus choice.

-Ben