Subject: [TLS] I-D Action: draft-ietf-tls-sni-encryption-03.txt

From: [email-masked]
Date: Sun, 20 May 2018 12:10:27 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : Issues and Requirements for SNI Encryption in TLS
        Authors         : Christian Huitema
                          Eric Rescorla
	Filename        : draft-ietf-tls-sni-encryption-03.txt
	Pages           : 14
	Date            : 2018-05-20

Abstract:
   This draft describes the general problem of encryption of the Server
   Name Identification (SNI) parameter.  The proposed solutions hide a
   Hidden Service behind a Fronting Service, only disclosing the SNI of
   the Fronting Service to external observers.  The draft lists known
   attacks against SNI encryption, discusses the current "co-tenancy
   fronting" solution, and presents requirements for future TLS layer
   solutions.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-03
https://datatracker.ietf.org/doc/html/draft-ietf-tls-sni-encryption-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sni-encryption-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Christian Huitema <[email-masked]>
Date: Sun, 20 May 2018 12:13:54 -0700

This new version of the SNI encryption draft implements the changes
discussed in London. It removes the "solution" part of the draft, for
which consensus was elusive, and keeps the "problem statement" part, for
which we apparently have wide consensus.

-- Christian Huitema

On 5/20/2018 12:10 PM, [email-masked] wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 23 May 2018 10:38:27 -0400

Thanks for this document, Christian.  I think this is a very clear and
cogent exposition of the SNI Encryption problem.

There have been some questions about whether this SNI encryption work is in
conflict with the Alt-Svc-SNI proposal in HTTPBIS.  My view is that there
is no conflict: that proposal is HTTP-specific and does not alter TLS,
whereas this work is aimed toward TLS changes that may also conceal other
ClientHello parameters, like ALPN.

---

From: Sean Turner <[email-masked]>
Date: Wed, 23 May 2018 10:49:33 -0400

> On May 23, 2018, at 10:38, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> Thanks for this document, Christian.

+1 for keeping this going.

spt

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 23 May 2018 14:10:16 -0400

Hi Christian,

Thanks for including text on the known uses of SNI.  Hopefully if
there are other known uses, they will be contributed for evaluation of
this problem space.

In section 2.2, enterprises can still use proxy based or active
interception solutions to enable inspection of traffic on their
network.  I suspect that will be the method of choice over the
endpoint for some time to come.  I also don't think it would be
universally accepted that enterprise interception, where they have
agreements from users to monitor (employment agreements - common in US
and EU, with Germany being an exception here as apparently they have a
law for users to have an expectation of privacy when doing personal
business from the work place), should be classified as an 'attack'.  I
think rephrasing for that use case would be helpful for the neutrality
of the document.

Section 3.8.1 - TLSv1.3 already encrypts the ALPN response via
EncryptedExtensions.  Is this argument for TLSv1.2?  The response is
where the answer on the negotiated protocol is provided and it's
already hidden, so I'm not clear on why this is here except if it is
for earlier versions.  This draft just says hide the ALPN, are you
concerned about the request too with the list of possible protocols?

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Artyom Gavrichenkov <[email-masked]>
Date: Wed, 23 May 2018 22:44:05 +0300

Hello Kathleen,

On Wed, May 23, 2018 at 9:11 PM Kathleen Moriarty <
[email-masked]> wrote:
> In section 2.2,

Do you mean 2.1?

> enterprises can still use proxy based or active
> network.

Or, they can easily set up some group policy to inspect and/or block some
specific resources.
Or, in most cases they just had an unrestricted physical access to a user's
machine before, so they could have installed an arbitrary inspection app
onto it.

In case of BYOD approach, an enterprise is not in any way different from
just an arbitrary ISP.

I support removal of this case, it's virtually impossible to protect
against it.

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: [email-masked]
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58