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

Christian Huitema <huitema@huitema.net> Thu, 19 September 2019 00:09 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 00A921200B3 for <tls@ietfa.amsl.com>; Wed, 18 Sep 2019 17:09:51 -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 k8hok8UC2HZJ for <tls@ietfa.amsl.com>; Wed, 18 Sep 2019 17:09:45 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 8ECC3120091 for <tls@ietf.org>; Wed, 18 Sep 2019 17:09:45 -0700 (PDT)
Received: from xse410.mail2web.com ([66.113.197.156] helo=xse.mail2web.com) by mx66.antispamcloud.com with esmtp (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1iAk10-0008Lz-8D for tls@ietf.org; Thu, 19 Sep 2019 02:09:44 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 46YcfW5kDTz3hcq for <tls@ietf.org>; Wed, 18 Sep 2019 17:09:39 -0700 (PDT)
Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1iAk0x-0006I5-MU for tls@ietf.org; Wed, 18 Sep 2019 17:09:39 -0700
Received: (qmail 17121 invoked from network); 19 Sep 2019 00:09:39 -0000
Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender <huitema@huitema.net>) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 19 Sep 2019 00:09:38 -0000
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>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <402b3a1e-26e4-b547-9eae-468af3183f06@huitema.net>
Date: Wed, 18 Sep 2019 14:09:39 -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: <20190918212749.GA14253@kduck.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: 66.113.197.156
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: ham
X-Spampanel-Outgoing-Evidence: Combined (0.05)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0dWQ8c9lblW44odAlK6ziUapSDasLI4SayDByyq9LIhVTwHx72/pNS1c 7yz055ZznETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4bCt44nu3kFAaZ7otpHCepsgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+eXohGLM8tFKoQ6vM7cAlL2mdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfCrE2rb Hpkagd3yMuHMqQJIX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8SnwqlUrBK2R/GBg9vCpMGFHw53FxnHnL50HZvyS1o3x98IkV0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm3OZmI6+6AcH EU4XbMnrDapXSV0lPHjGZLkASD9YtLp9cj66IJaVu8C9JDpxHun0xfvemWogbRBWdol5u13CYiwv UwPy3x0FYtCNEb10sHyQCLHEvD1OqP6bgZ4L66GcgBg66gs5OuzYxJgw5atIxeNDvjI/CYe5WPy0 +t1RP0azcmO95GB48+zqESs6FO6qqpxMPnetLBJMh51NiRRoHICf0qY9SfEf3NsfnBCfUpL/miK7 x42VjdzChZMe6O/Did+/hGXTmfhE+Dx2/NyzMXqC3j3gfLHnJQaeyVJURKIbvOnCUbNPgcPcQwzM 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/NvQVZVK8UTtCvtvU1HvY6dm_SbI>
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 00:09:51 -0000

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
>>