Re: [TLS] Adam Roach's Yes on draft-ietf-tls-sni-encryption-05: (with COMMENT)

Christian Huitema <huitema@huitema.net> Thu, 19 September 2019 01:27 UTC

Return-Path: <huitema@huitema.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 269911200B2 for <tls@ietfa.amsl.com>; Wed, 18 Sep 2019 18:27:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 6Gqxx_mfTz2s for <tls@ietfa.amsl.com>; Wed, 18 Sep 2019 18:27:43 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 6991012008A for <tls@ietf.org>; Wed, 18 Sep 2019 18:27:43 -0700 (PDT)
Received: from xse129.mail2web.com ([66.113.196.129] helo=xse.mail2web.com) by mx61.antispamcloud.com with esmtp (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1iAkZV-0003Hh-Dn for tls@ietf.org; Thu, 19 Sep 2019 02:45:23 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 46YdRg71kDz1QLY for <tls@ietf.org>; Wed, 18 Sep 2019 17:45:19 -0700 (PDT)
Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1iAkZT-0006Xx-Rq for tls@ietf.org; Wed, 18 Sep 2019 17:45:19 -0700
Received: (qmail 1502 invoked from network); 19 Sep 2019 00:45:19 -0000
Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender <huitema@huitema.net>) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 19 Sep 2019 00:45:19 -0000
From: Christian Huitema <huitema@huitema.net>
To: Benjamin Kaduk <kaduk@mit.edu>, Adam Roach <adam@nostrum.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tls-sni-encryption@ietf.org, tls-chairs@ietf.org, tls@ietf.org
References: <156877530949.17386.10408818675097603080.idtracker@ietfa.amsl.com> <c9dc7cd0-e008-3263-4bb3-8c74a1eb1474@huitema.net> <7cf5b08b-17f5-9d5c-34d4-bfd58aff5a32@nostrum.com> <20190918212749.GA14253@kduck.mit.edu> <402b3a1e-26e4-b547-9eae-468af3183f06@huitema.net>
Message-ID: <c824c5e4-1e2a-acea-49d8-379bb963e4ec@huitema.net>
Date: Wed, 18 Sep 2019 14:45:19 -1000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
MIME-Version: 1.0
In-Reply-To: <402b3a1e-26e4-b547-9eae-468af3183f06@huitema.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: 66.113.196.129
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.129/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.129/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: ham
X-Spampanel-Outgoing-Evidence: Combined (0.05)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0dWQ8c9lblW44odAlK6ziUapSDasLI4SayDByyq9LIhVFjOK6QwUTCSE SLqX7MLgYkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4adgLoCu54bJrEJjsmAfv7DgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+cXQ2Tc+0CTI43RFdWVZDOJmdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfCrE2rb Hpkagd3yMuHMqQJIX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8SnwqlUrBK2R/GBg9vCpMGFHw53FxnHnL50HZvyS1o3x98IkV0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAmwlRxHgmfsZ4 SVWs68EuDrNRwe9Z0gmTfjU2qv1pSEXw/yxYymtKnwJ6mJVl3w5mx2nQPxL7ST1j6JLtacE9/oXE GL9QaZb82ijJkSLDW7QUE6NT2bHitTis9tOSkwtBNhg66gs5OuzYxJgw5atIxeNDvjI/CYe5WPy0 +t1RP0azZs614Wgp8N9XCJ/NdS+gJ5xMPnetLBJMh51NiRRoHIDID42jf8cxXoVU9x4ADlh0miK7 x42VjdzChZMe6O/Did+/hGXTmfhE+Dx2/NyzMXpsrbpibX/ETDkohPghkFhkvOnCUbNPgcPcQwzM gKHyQxUo+ql2ySTkvEFH/23XMww2BnTTFGX5/yI4Ky+1ZJcbGqc5H4PEZHeoI/d6LWFf332z7LMw LGdoi9FMQ5j9dQUvMi1YKAun15JQSJLyCT5k+MTObVKxHy/dols381l9r9ft9daDonlwd6LnuX+J u10=
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YBpi3sXTtcnbJbG2UcN1funxCOw>
Subject: Re: [TLS] Adam Roach's Yes on draft-ietf-tls-sni-encryption-05: (with COMMENT)
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: Thu, 19 Sep 2019 01:27:45 -0000

Due to my moderately competent use of GitHub, draft-06 does not include 
the resolution of Mirja's comments. That will be part of the next draft. 
Sorry.

-- Christian Huitema

On 9/18/2019 2:09 PM, Christian Huitema wrote:
> OK, I just submitted draft-06. As the automated message says:
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-06
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-sni-encryption-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sni-encryption-06
>
> I am going to address the pending comments soon.
>
> -- Christian Huitema
>
> On 9/18/2019 11:27 AM, Benjamin Kaduk wrote:
>> I don't think there's going to be a huge practical difference between
>> pushing a new rev now with the editorial fixes vs. waiting.  My personal
>> inclination is to push the new rev now, acknowledging that another rev
>> after that will likely be needed as well.
>>
>> -Ben
>>
>> On Wed, Sep 18, 2019 at 04:18:03PM -0500, Adam Roach wrote:
>>> No worries!
>>>
>>> I'd work with the responsible AD to coordinate when to publish a new
>>> version.
>>>
>>> I do have one comment below -- regarding the multi-party security
>>> context -- that isn't really editorial and which isn't addressed in the
>>> github version. Do you have any thoughts on it? Am I just missing
>>> something obvious?
>>>
>>> /a
>>>
>>> On 9/18/19 4:10 PM, Christian Huitema wrote:
>>>> Thanks, Adam
>>>>
>>>> I appreciate the feedback, and in fact I need to apologize. We have a
>>>> new version of the draft ready at
>>>> https://github.com/tlswg/sniencryption, which takes into account the
>>>> comments received before Saturday 15, but does not take into 
>>>> account the
>>>> latest round of comments from Alissa, Éric and Roman. It resolves 
>>>> almost
>>>> all the nits that many of you have noticed. I probably hesitated too
>>>> long before publishing a new version of the draft. I knew the 
>>>> ballot was
>>>> in progress, and I was trying to not force everybody to read the 
>>>> draft a
>>>> second time. Also, I was concerned that comments would keep coming as
>>>> long as the ballot progressed, and I kind of hoped resolving all of 
>>>> them
>>>> before cutting a new version. But then, several of you end up 
>>>> stumbling
>>>> on the same issues that are already fixed in the editor copy. My bad.
>>>>
>>>> At that point, I could either publish a new draft version right 
>>>> know, or
>>>> wait a couple of days and address the last comments. I wonder what is
>>>> best for the IESG members. Any opinion?
>>>>
>>>> -- Christian Huitema
>>>>
>>>>
>>>>
>>>> On 9/17/2019 7:55 PM, Adam Roach via Datatracker wrote:
>>>>> Adam Roach has entered the following ballot position for
>>>>> draft-ietf-tls-sni-encryption-05: Yes
>>>>>
>>>>> When responding, please keep the subject line intact and reply to all
>>>>> email addresses included in the To and CC lines. (Feel free to cut 
>>>>> this
>>>>> introductory paragraph, however.)
>>>>>
>>>>>
>>>>> Please refer to 
>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>>
>>>>>
>>>>> The document, along with other ballot positions, can be found here:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------- 
>>>>>
>>>>> COMMENT:
>>>>> ---------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>>
>>>>> Thanks to everyone who worked on this. It seems that it will be a 
>>>>> useful
>>>>> tool for evaluating potential solutions.
>>>>>
>>>>> --------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> §3.1:
>>>>>
>>>>>>    Regardless of the encryption used,
>>>>>>    these designs can be broken by a simple replay attack, which 
>>>>>> works as
>>>>>>    follow:
>>>>> Nit: "...as follows:"
>>>>>
>>>>> --------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> §3.6:
>>>>>
>>>>>>    These solutions offer more protection against a Man-In-The-
>>>>>>    Middle attack by the fronting service.  The downside is the the
>>>>>>    client will not verify the identity of the fronting service with
>>>>>>    risks discussed in , but solutions will have to mitigate this 
>>>>>> risks.
>>>>> This final sentence appears to be missing some kind of citation 
>>>>> before the
>>>>> comma.
>>>>>
>>>>> --------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> §3.6:
>>>>>
>>>>>>    Adversaries can also attempt to hijack the traffic to the
>>>>>>    regular fronting server, using for example spoofed DNS 
>>>>>> responses or
>>>>>>    spoofed IP level routing, combined with a spoofed certificate.
>>>>> It's a bit unclear why this is described as part of the injection of
>>>>> a third party into the scenario. As far as I understand, the 
>>>>> described
>>>>> attack exists today, in the absence of any SNI encrypting schemes.
>>>>> If there's a new twist introduced by a multi-party security context,
>>>>> the current text doesn't seem to explain what it is.
>>>>>
>>>>> --------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> §3.7:
>>>>>
>>>>>>    Multiple other applications currently use TLS, including for 
>>>>>> example
>>>>>>    SMTP [RFC5246], DNS [RFC7858], or XMPP [RFC7590].
>>>>> Nit: "...including, for example, SMTP..."
>>>>> Nit: "...and XMPP..."
>>>>>
>>>>>>    These applications
>>>>>>    too will benefit of SNI encryption.  HTTP only methods like those
>>>>>>    described in Section 4.1 would not apply there.
>>>>> Nit: "...benefit from SNI..."
>>>>> Nit: "HTTP-only..."
>>>>>
>>>>> --------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> §4.2:
>>>>>
>>>>>>    This requires a
>>>>>>    controlled way to indicate which fronting ferver is acceptable 
>>>>>> by the
>>>>>>    hidden service.
>>>>> Nit: "...server..."
>>>>>
>>>>> --------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> §7:
>>>>>
>>>>>>    Thanks to Stephen Farrell, Martin Rex Martin Thomson
>>>>>>    and employees of the UK National Cyber Security Centre for their
>>>>>>    reviews.
>>>>> I think you're missing a comma between the two Martins.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> TLS mailing list
>>>>> TLS@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>