[TLS] Barry Leiba's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)

Barry Leiba via Datatracker <noreply@ietf.org> Thu, 05 September 2019 03:41 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F3C1208FA; Wed, 4 Sep 2019 20:41:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tls-sni-encryption@ietf.org, Joseph Salowey <joe@salowey.net>, Sean Turner <sean@sn3rd.com>, tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.100.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <156765486733.22748.1412979182718163650.idtracker@ietfa.amsl.com>
Date: Wed, 04 Sep 2019 20:41:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YhRQluTCxVyk0tiVOXBpcod-IAI>
Subject: [TLS] Barry Leiba's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 05 Sep 2019 03:41:08 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-tls-sni-encryption-05: No Objection

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

Lovely document; thanks.  Just a collection of nits here:

— Section 1 —

   These attempts have generally floundered,

I think the word you want here is “foundered”, without the “l”.

— Section 2.1 —

      which inspection would intrude with the privacy of employees.

“Intrude on”.

— Section 2.2 —

   and protection of server certificates transmissions

“certificate”

— Section 2.3 —

   Deploying SNI encryption will help thwarting most of the

Will “help thwart” or “help in thwarting”; I think the former sounds better.

   can however be realized by other means.

Needs commas around “, however,” .

— Section 3.1 —

   these designs can be broken by a simple replay attack, which works as
   follow:

“as follows”

   attacks breaks that goal

“break”

— Section 3.2 —

   the multiplexed server, and by every users of the protected services.

By “every user” or “all users”.

— Section 3.4 —

   of TLS handshakes use SNI encryption.  If that was the case, the

“If that were the case,” subjunctive mood.

— Section 3.5 —

   If the corresponding private key was compromised,

“is compromised,” or, better, “should be compromised,” subjunctive again.

— Section 3.6 —

   We can design solutions in which a fronting service act as a relay

“acts”

   Middle attack by the fronting service.  The downside is the the

“that the”

   client will not verify the identity of the fronting service with
   risks discussed in , but solutions will have to mitigate this risks.

You’re missing something here, a reference after “in”?  And “those risks.”

   regular fronting server, using for example spoofed DNS responses

Needs commas around “, for example,” .

— Section 3.7 —

   Multiple other applications currently use TLS, including for example
   SMTP [RFC5246], DNS [RFC7858], or XMPP [RFC7590].

Needs commas around “, for example,” .
Also, “and”, rather than “or”.

   These applications too will benefit of SNI encryption.

Needs commas around “, too,” .  Or make it, “These applications will also benefit...”

   HTTP only methods like those

“HTTP-only” needs a hyphen.

   to the need of an application-agnostic solution, that would be
   implemented fully in the TLS layer.

“need for”, and “which would”.

— Section 3.7.1 —

   specific port numbers exposed in some network.

Should this be “networks”?

   Applications would not need to do that if the ALPN was hidden

“were hidden”

— Section 3.7.2 —

   Support other transports than TCP

“Support Transports Other than TCP”

   requirement to encrypt the SNI apply just as well

“applies”

— Section 4 —

   when the fronting server and the hidden server are "co-tenant" of the

“co-tenants”

   There are however a few issues regarding discovery

Needs commas around “, however,” .

   o  The client browser's has to be directed to access

The “client’s browser”.

      cryptographic proof that the content does in fact come from

Needs commas around “, in fact,” .

      The solution does thus not mitigate

Needs commas around “, thus,” .

   support HTTP Fronting

“supports”

   applications over HTTP, such as for example DNS over HTTPS

Needs commas around “, for example,” .

— Section 4.1 —

   It also requires that the fronting server decrypts and relay
   messages to the hidden server.

“decrypt”, more subjunctive.

— Section 4.2 —

   be performed by distributing fake advice, such as "to reach example
   hidden.example.com, use fake.example.com as a fronting server",

There’s an extra “example” on the first line.

   We can observe that content distribution network have a similar

“networks”

— Section 5 —

   The current HTTP based

“HTTP-based” needs a hyphen.