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:14 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 6E6C0120091 for <tls@ietfa.amsl.com>; Wed, 18 Sep 2019 17:14:39 -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=ham 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 2-xYyZGD0w1Y for <tls@ietfa.amsl.com>; Wed, 18 Sep 2019 17:14:37 -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 6DEC412004A for <tls@ietf.org>; Wed, 18 Sep 2019 17:14:37 -0700 (PDT)
Received: from xse144.mail2web.com ([66.113.196.144] helo=xse.mail2web.com) by mx65.antispamcloud.com with esmtp (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1iAk5i-0005n3-L2 for tls@ietf.org; Thu, 19 Sep 2019 02:14:35 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 46Ycm92VVHz3hct for <tls@ietf.org>; Wed, 18 Sep 2019 17:14:33 -0700 (PDT)
Received: from [10.5.2.13] (helo=xmail03.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 1iAk5h-0004FS-7b for tls@ietf.org; Wed, 18 Sep 2019 17:14:33 -0700
Received: (qmail 21475 invoked from network); 19 Sep 2019 00:14:32 -0000
Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender <huitema@huitema.net>) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 19 Sep 2019 00:14:32 -0000
To: Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>
Cc: 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>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <6b59e167-1b69-3762-674e-dfd715c0ce2e@huitema.net>
Date: Wed, 18 Sep 2019 14:14:32 -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: <7cf5b08b-17f5-9d5c-34d4-bfd58aff5a32@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: 66.113.196.144
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.144/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.144/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: ham
X-Spampanel-Outgoing-Evidence: Combined (0.07)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0dWQ8c9lblW44odAlK6ziUapSDasLI4SayDByyq9LIhVmj2dMycLblGT SO/qt+P3vETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4bwlZRWdDxH3RfhEq1jOUbkgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+cqR/Azv01OJhPK4SsoJkVNmdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfCrE2rb Hpkagd3yMuHMqQJIX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8SnwqlUrBK2R/GBg9vCpMGFHw53FxnHnL50HZvyS1o3x98IkV0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm3OZmI6+6AcH EU4XbMnrDarMCwbYZSDsvW0enk+rZHRdhV4Ynm8Z1NX6hq5mqjjseO1q43X2l4CU5qJNUcrS6bcM 7OYFXYdC3tRq275m/U3VTS31mvt+TpfpG7oe1oU5RLdCp3Zd9clP8wSiJZWbJCj+xRrjVmRxpGtS cvUmgj1LWPMRLM1ifcN/zogSpcxW3F2jZAOanSBpz6Rja2u/0jKEsoZZZZhbMgFWwMT882nF9JUJ v+qbGmX4CqjyU8BtQfysta6u1iHEyuS7GD1uvcpETbjT//oj21hbHDB2NaOPJOYIJd4MvQ0Nf4Ec bvHO1diDanHV9KirFAIIecsyj+YNTo81GR+jDXFsz/ZQnbbTizvwlZsrbltGiZoUh+c+5pFVgpT1 b21uZVckGp0ccOa2XhkGbmsUNPNkere1WheNsVXmhO8BzADiszcWR9bz/SDtF09JpSbuuCeiIDK0 C/0=
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qkCzqK3enKiLkm-tKsTcQuUeJiU>
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:14:40 -0000

On 9/18/2019 11:18 AM, 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?

The point is that in several designs, only one of the parties is 
authenticated. This leads to a dilemma. If the clients just identify the 
fronting server, then the fronting server can spoof the hidden server at 
will. If the clients just identify the hidden server, then malevolent 
actors can spoof the fronting server. The fake fronting  server can then 
relay the requests and keep tabs on which clients access the hidden service.

-- Christian Huitema




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