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
- [TLS] Adam Roach's Yes on draft-ietf-tls-sni-encr… Adam Roach via Datatracker
- Re: [TLS] Adam Roach's Yes on draft-ietf-tls-sni-… Christian Huitema
- Re: [TLS] Adam Roach's Yes on draft-ietf-tls-sni-… Adam Roach
- Re: [TLS] Adam Roach's Yes on draft-ietf-tls-sni-… Benjamin Kaduk
- Re: [TLS] Adam Roach's Yes on draft-ietf-tls-sni-… Christian Huitema
- Re: [TLS] Adam Roach's Yes on draft-ietf-tls-sni-… Christian Huitema
- Re: [TLS] Adam Roach's Yes on draft-ietf-tls-sni-… Christian Huitema