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

Roman Danyliw <rdd@cert.org> Mon, 07 October 2019 19:07 UTC

Return-Path: <rdd@cert.org>
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 6A849120154; Mon, 7 Oct 2019 12:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 wbuw1_q0IGE4; Mon, 7 Oct 2019 12:07:27 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 3291F1200F5; Mon, 7 Oct 2019 12:07:27 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x97J7K4P004002; Mon, 7 Oct 2019 15:07:20 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x97J7K4P004002
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1570475240; bh=EWXqde1C+6NBJfi+w/fD7EP50MUe0t2Bc2kvealK/Kw=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=HZChp5wh/h+OD+Xr2xOl4AcvOi8aT3OH0ThheTNXD6roQwPYzWJ/yreAvRn/QnBW7 t+i2OL4aK90OJxLnisy9SgKibmtWi2ljB4xjAYdXsYf2lc/8n3PYNQu+NaHao/hK9W kDEg9NC5GOd2BVnuHBy2fgniG2te/SA2mUAbzNz0=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x97J7IJf025979; Mon, 7 Oct 2019 15:07:18 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Mon, 7 Oct 2019 15:07:17 -0400
From: Roman Danyliw <rdd@cert.org>
To: Christian Huitema <huitema@huitema.net>, The IESG <iesg@ietf.org>
CC: "draft-ietf-tls-sni-encryption@ietf.org" <draft-ietf-tls-sni-encryption@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)
Thread-Index: AQHVbi8COnMhMIVEW0a3iVa1HwFkKKcyhpWAgADP/5CACcQaAIABZHnAgABh8YCAEMNMkA==
Date: Mon, 07 Oct 2019 19:07:16 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B347B31A@marathon>
References: <156881761812.4630.11745895149419124830.idtracker@ietfa.amsl.com> <c504a433-cc5b-df00-15c2-fcaf3116798c@huitema.net> <359EC4B99E040048A7131E0F4E113AFC01B3467E89@marathon> <81e39835-82e7-03c7-feaf-33980629986c@huitema.net> <359EC4B99E040048A7131E0F4E113AFC01B346A4D0@marathon> <2efdf56d-2846-a08e-2b2d-aa0703281b18@huitema.net>
In-Reply-To: <2efdf56d-2846-a08e-2b2d-aa0703281b18@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01B347B31Amarathon_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/eDBv4DjT_necGmBYocJjOWfwRqo>
Subject: Re: [TLS] Roman Danyliw's No Objection 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: Mon, 07 Oct 2019 19:07:37 -0000

Hi Christian!

Thanks for all of the iteration and updates.  Given what’s proposed in github (https://github.com/tlswg/sniencryption/pull/46/files), consider my comments resolved.  Minor comments inline …

From: Christian Huitema [mailto:huitema@huitema.net]
Sent: Thursday, September 26, 2019 6:53 PM
To: Roman Danyliw <rdd@cert.org>; The IESG <iesg@ietf.org>
Cc: draft-ietf-tls-sni-encryption@ietf.org; tls-chairs@ietf.org; tls@ietf.org
Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)



On 9/26/2019 11:38 AM, Roman Danyliw wrote:

Hi Christian!



Thanks for all of the updates.  I have a remaining items are described inline.



To bring up a new item, there was new text introduced in -06 of Section 5 to which I strongly object.  Specifically:



"Replacing clear text SNI transmission by an encrypted variant will

also thwart MITM interferences that are sometimes described as

legitimate.  As explained in Section 2.3, alternative solutions will

have to be developed.”



I read this paragraph as addressing the operational practices outlined in Section 2.1.  I think it is inappropriate to refer to some of these operational practices as being "sometimes described as legitimate".

Anything performed by MITM is by definition controversial. But I get your point. How about

"Replacing clear text SNI transmission by an encrypted variant will break or reduce the

efficacy of the operational practices and techniques implemented in middle-boxes as

described in Section 2.1. As explained in Section 2.3, alternative solutions will

have to be developed."



[Roman] Looks good to me.  Thanks.



-----Original Message-----

From: Christian Huitema [mailto:huitema@huitema.net]

Sent: Wednesday, September 25, 2019 3:47 PM

To: Roman Danyliw <rdd@cert.org><mailto:rdd@cert.org>; The IESG <iesg@ietf.org><mailto:iesg@ietf.org>

Cc: draft-ietf-tls-sni-encryption@ietf.org<mailto:draft-ietf-tls-sni-encryption@ietf.org>; tls-chairs@ietf.org<mailto:tls-chairs@ietf.org>; tls@ietf.org<mailto:tls@ietf.org>

Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-

encryption-05: (with COMMENT)



Hello Roman,



A lot of the fixes that you suggested are incorporated in the draft-07 that was

just released. I think the last version addresses your concerns, but you may

of course want to verify.



On 9/25/2019 7:27 AM, Roman Danyliw wrote:

Hi Christian!



Thanks for the detailed responses and the helpful background.  Below are a

number of proposed text block replacements to clarify my intent (instead of

more questions).



Roman



-----Original Message-----

From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Christian

Huitema

Sent: Wednesday, September 18, 2019 10:14 PM

To: Roman Danyliw <rdd@cert.org><mailto:rdd@cert.org>; The IESG <iesg@ietf.org><mailto:iesg@ietf.org>

Cc: draft-ietf-tls-sni-encryption@ietf.org<mailto:draft-ietf-tls-sni-encryption@ietf.org>; tls-chairs@ietf.org<mailto:tls-chairs@ietf.org>;

tls@ietf.org<mailto:tls@ietf.org>

Subject: Re: [TLS] Roman Danyliw's No Objection on

draft-ietf-tls-sni-

encryption-05: (with COMMENT)



Thanks for the feedback, Roman. Comments in line.



On 9/18/2019 4:40 AM, Roman Danyliw via Datatracker wrote:

** Section 1.  Per “More and more services are colocated on

multiplexed servers, loosening the relation between IP address and

web service”, completely agree.  IMO, unpacking “multiplexed

servers” is worthwhile to explain the subsequent text because it

motivates the loss of visibility due to encryption with network only

monitoring.

“Multiplex’ happens at two levels:

-- co-tenants (e.g., virtual hosting) – multiple services on the

same server (i.e., an IP/port doesn’t uniquely identify the service)



-- cloud/cdn  – a given platform hosts the services/servers of a lot

of organization (i.e., looking up to what netblock an IP belongs

reveals little)



OK, will try to incorporate your text.

Thanks.



Changes incorporated in first paragraph of section 1.



The text -07 works for me.  Thanks for adding this extra bit.





** Section 2.1.  Per “The SNI was defined to facilitate management

of servers, though the developers of middleboxes soon found out that

they could take advantage of the information.  Many examples of such

usage are reviewed in [RFC8404].”,



-- Can’t middleboxes also help facilitate the management of servers?

This text seems to take a particular view on middleboxes which

doesn't

seem appropriate.



It is pretty clear that the load balancer in front of a server farm

will need access to the service ID, and must be able to retrieve the

decrypted SNI.

There may be other examples, such as DoS mitigation boxes. The

"unanticipated usage" comes typically from middle-boxes that are not

in the same management domain as either the client or the server. Is

there an established way to designate those?

I'm not sure I understand the original of the requirement that the client

and server being in the same management domain.



RFC3546's definition of SNI opens with:

   [TLS] does not provide a mechanism for a client to tell a server the

   name of the server it is contacting.  It may be desirable for clients

   to provide this information to facilitate secure connections to

   servers that host multiple 'virtual' servers at a single underlying

   network address.



It seems to me that if we are trying to channel original intent, then only the

virtual server use case applies.  I'd propose:



OLD

The SNI was defined to facilitate management of servers, though the

developers of middleboxes soon found out that they could take advantage

of the information.  Many examples of such usage are reviewed in

[RFC8404].



NEW

The SNI was defined to facilitate secure connections to servers that host

multiple 'virtual' servers at a single underlying network address [RFC3546].

However, addition management and security practices emerged making use

of this information.  Examples of such usage are reviewed in [RFC8404].



This language would let you distinguish all of the middle box behaviors

done by operators and enterprises from a possible [RFC7258] attacker.



As I noted in my reply to Ben, I don't follow the current language for anticipated/unanticipated.



https://mailarchive.ietf.org/arch/msg/tls/54cEpjUcIZqNW_y7Eb344XLQp0Y



-- RFC8404 describes a number of middlebox practices, but only

Section

6.2 explicitly discusses SNI, and of the examples list here, only

one comes from RFC8404.

A few of the examples also come in the "deep packet inspection"

sections of 8404. But rather than going in a long discussion, I would

rather rewrite the sentence as: Many examples of such usage are

reviewed in [@?RFC8404], other examples came out during discussions of

this draft.



The -07 text works for me.  Thanks.



** Section 2.1. The “monitoring and identification of specific sites”

isn’t symmetric to the other examples – it is rather generic.  The

other examples, identify a what/who (e.g., ISP, firewall) + action

(e.g.,

block, filter).

Also, to implement most of the other example, “monitoring and

identification of specific sites” needs to be done.

I still think this needs to be cleaned up in some way.  IMO, I'd drop it.



Was rewritten in new section 2.1 as "Filtering or censorship of specific

services for a variety of reasons."



I'm still struggling with the specificity here and the overlap.  Dropping the censorship and it reads "filtering of specific services for a variety of reasons".  That's exactly what bullet 2 (content filtering by operators) and bullet 3 (enterprise firewalls for NSFW)



What's unique about this bullet -- is it who is doing this filter/censorship? where it is happening? What tech is being used?

For example, arbitrary filtering of web sites competing with other services preferred by the network provider.  Some filtering and censorship is more controversial than others. But I don't think that listing every controversial usage would be appropriate. I would rather keep the somewhat vague phrasing than try to have a debate about which practice is controversial and which is not.

[Roman]  Understood.  Point made.  The text is neutral enough for me now, and I won’t push further (for editorial clarity).  Thanks.



...

** Section 2.1.  Per “The SNI is probably also included in the

general collection of metadata by pervasive surveillance actors”, I

recommend against speculation and instead simply stating that SNI

would be interesting meta-data for a RFC7258 attacker.

Yes, Mirja made a similar comment. Proposed replacement:



The SNI is probably also included in the general collection of

metadata by pervasive surveillance actors, for example to identify

services used by surveillance targets.

IMO, explicitly linking it to the draft would help.



OLD:

The SNI is probably also included in the general collection of

metadata by pervasive surveillance actors, for example to identify

services used by surveillance targets.



NEW:

The SNI could be included in the general collection of metadata by

pervasive monitoring attacker [RFC7258], for example to identify

services used by surveillance targets.



I missed the reference to 7258. Will add it in the next version.



Recommend adding the RFC7258 reference.  As I noted above, the semantics of "probably" vs. "could".  "probably" suggests a confidence to me.

Yes, there is some confidence, based on the Snowden revelation of systems like Quantum Insert, comments like "recording the whole haystack", or the Korean regulation explicitly targeting the SNI field. It is more probable than not that SNI data is being recorded, and I think that "probably" is just fine.

[Roman] I can live with just the RFC7258 reference.  Thanks for adding it.









** Section 2.2.  Per “One reason may be that, when these RFCs were

written, the SNI information was available through a variety of

other means”, what would those “other means” be?

The list includes at a minimum:



Clear text exchanges amenable to deep packet inspection (DPI), server

certificates send in clear text during TLS/SSL exchanges, DNS names

of servers in clear text DNS queries, and server specific IP

addresses in packet headers.



I guess I could write that all, but it makes the text a bit

redundant, since the following paragraphs do discuss server

certificates, DNS names and IP addresses.

I understand.  I didn't read it that way.  My recommendation isn't to

describe the "other means" (as it is described below), but to be clear on the

obvious, what is the SNI information.



OLD:

One reason may be that, when these RFCs were written, the SNI

information was available through a variety of other means.



NEW:

One reason may be that when the RFCs were written, the name of the

server the being contacted by the client (i.e., the SNI) was evident through

other means.



The new text in -07 reads more clearly to me.  Thanks for this change.



** Section 2.3.  Per “Deploying SNI encryption will help thwarting

most of

the

‘unanticipated’ SNI usages described in Section 2.1, including

censorship

and

pervasive surveillance.”:



-- Why the quotes around "unanticipated" SNI usage?

Removing the quotes. Otherwise, you will be convinced that the

authors believe that all middle-boxes are the spawn of the devil...

Thanks.



-- One person’s censorship is another person’s threat mitigation,

policy enforcement for a network they own, or parental controls (per

the list in Section 2.1) – recommend being more precise on the order

of “Deploying

SNI

encryption will {break | reduce the efficacy of } the operational

practices

and

techniques used in middleboxes described in Section 2.1”.

OK. I will try to make the text just stick to the facts:



Deploying SNI encryption thwarts most of the unanticipated SNI usages

described in (#snileak). It reduces the efficacy of the operational

practices and techniques implement in middle-boxes. Most of these

functions can, however, be realized by other means.



Thanks for this.



Works for me.  However, I'd drop "Most of these functions can, however,

be realized by other means" because this opens the debate on how exactly,

etc.



I still recommend dropping the "other means" text because that opens debate.



** Section 2.3.  Per “It will also thwart functions that are

sometimes described as legitimate”, what functions are those?  I’d

recommend

eliminating

this sentence as it reads like a value judgement on existing

practices (which doesn’t seem germane for discussing requirements).



Now that censorship got added to the list in Section 2.1, you likely want to:



s/including censorship and pervasive surveillance/including pervasive surveillance/



Otherwise, LGTM.  Thanks.

OK.



...
...



"This document does not present the design of a solution, but provides

guidelines for evaluating proposed solutions."  However, the current text in

Section 4 is explicitly states it is providing a solution.  The sub-section of

Section 4.x assume the solution in Section 4.0 and describe the follow-on

work.  Section 2 - 3 do lay out the means for evaluation nicely.  Perhaps,

something on the order of:



OLD:

This document does not present the design of a solution, but provides

guidelines for evaluating proposed solutions.



NEW:

This provides guidelines on evaluating solution and proposes an

architecture to mitigate the threats created by an unencrypted SNI using

existing approaches.





I added the reference to a paper by Fified et al. that describes the "domain

fronting" solution and some of its deployments.



Note that the intent is not to recommend the domain fronting solution. That solution, and the HTTPS tunnel solution, are examined as example of proposed solutions that meet some of the requirement but not all. But I understand that you perceived the text as some kind of endorsement.

[Roman]  Right, but I also think the citation helps that you’re describing an existing practice.  The new language in added in https://github.com/tlswg/sniencryption/pull/46/files works for me.  Thanks.

...





Draft 07 added text describing actual deployments.



The use of the [domfront] citation works for me and addresses my concerns.  Two nits:



** I'd recommend using the URL to the paper from conference site itself: https://petsymposium.org/2015/papers/03_Fifield.pdf
OK.






** I'd also recommend adding a sentence to the last paragraph of Section 1, "This document does not present the design ...", to foreshadow that you'll discuss an alternative approach even if encrypted SNI isn't realized yet.

OK, will try make clear that this is not an endorsement or a proposal.

[Roman] I think you have it covered in the new language in https://github.com/tlswg/sniencryption/pull/46/files.

Regards,

Roman

-- Christian Huitema