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

Adam Roach <adam@nostrum.com> Wed, 18 September 2019 21:18 UTC

Return-Path: <adam@nostrum.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 F240D1200B7; Wed, 18 Sep 2019 14:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 MOWR7eC9Pqs3; Wed, 18 Sep 2019 14:18:13 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0319A120052; Wed, 18 Sep 2019 14:18:12 -0700 (PDT)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x8ILI9Lj083170 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 18 Sep 2019 16:18:10 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1568841491; bh=6XUnBITGiVu5lZZ8aELnqe97wU4Q2Wb1BsBta6MqdCY=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=HtEgtBj5HoYfJScdKWHLhLqQR/gmKXct38vXXwQlPziF9HyjpTcxuJkt6Zn2RVLfZ 7xeedRNYKpD+fPb3QSftun88BD6mWmwDLFLi8HrulKo0lF7z2nDPOMCaD93zVzCjkj PPzmIzC1Oap99+kBxkHNubQDD9Uydq9KXvqC/f1Q=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Christian Huitema <huitema@huitema.net>, 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>
From: Adam Roach <adam@nostrum.com>
Message-ID: <7cf5b08b-17f5-9d5c-34d4-bfd58aff5a32@nostrum.com>
Date: Wed, 18 Sep 2019 16:18:03 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <c9dc7cd0-e008-3263-4bb3-8c74a1eb1474@huitema.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0OzGQdrD5_s4uSj68ABZdhB65I0>
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: Wed, 18 Sep 2019 21:18:15 -0000

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