Issues and Requirements for Server Name Identification (SNI) Encryption in TLS
draft-ietf-tls-sni-encryption-09

[Ballot comment]
Section 1:

s/servers rely on the Service Name Information (SNI) TLS extension/servers rely on the Server Name Indication (SNI) TLS extension [RFC 6066]/

Section 2.1:

Why is parental controls in quotes?

Section 2.2:

s/Encrypting the SNI now will complete this push/Encrypting the SNI completes this push/

(for timelessness)

Section 2.3:

In the first paragraph I would suggest trying to use the present tense more so that this still makes sense far in the future.

s/At the moment/At the time of this writing/

[Ballot comment]
** 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)

** 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.

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

** 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.

** Section 2.1.  Why is parental controls in quotes?  In RFC8404, it is not.  The quotes could be read as a judgement on the practice.

** 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.

** 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?

** 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?

-- 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”.

** 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).

** Section 3.  Per “Over the past years, there have been multiple proposals to add an SNI encryption option in TLS.”, can these past proposals be cited so future readers can learn from them.

** Section 3.4. The existence of designs were alluded to but not cited.  Be specific with citation.

** Section 3.7.1. The rational for including this discussion about ALPN isn’t clear as it doesn’t suggest new requirements for SNI encryption.

** Section 4.  I got hung-up on the description of Section 4 describing a “solution”.  Is Section 4 (and the related subsections) describing an operational practice or a notional reference architecture?  The text reads one part “people are doing” and another part “people could do”.

** Section 4.  Per “In the absence of TLS-level SNI encryption, many sites rely on an "HTTP Co-Tenancy" solution”, this seems like a strong of a statement about utilization of this architecture explicitly to hide the hidden.example.com SNI.  Can you provide a citation for a sense penetration.

** Section 4.  Per the bullet “since this is an HTTP-level solution”, I recommend citing that it fails on the requirement identified in Section 3.7 (instead of enumerating a list of protocols)

** Section 4.  The opening of this section noted that “many sites” rely on the architecture described in this section. Later, it is noted that “a browser extension that support[s] HTTP Fronting” is a necessary architecture component.  Can a few citations be made to the popular extensions.

** Section 4.2.  Per "to reach example  hidden.example.com, use fake.example.com as a fronting server", shouldn’t this read: “to reach hidden.example.com, use fake.example.com as a fronting server"?

** Editorial Nits
-- Section 2.  Typo.  s/mutiple/multiple.

-- Section 2.1. Typo.  s/fradulent/fraudulent/

-- Section 3.1.  “Hidden Service” is capitalized in a few places like it is a proper noun?  Is it meant to be?  If so, define or cite it.

-- Section 3.6. s/the the/

-- Section 4.1. s/tunnelling/tunneling/

-- Section 4.2. s/ferver/server/

-- Section 7.  s/Martin Rex Martin Thomson/Martin Rex, Martin Thomson/

[Ballot 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.

[Ballot comment]
Thank you for the work put into this document. It is well-written and easy to follow. Please find below a couple of comments and nits.

Reading
"  In practice, it may well be that no solution can meet every
  requirement, and that practical solutions will have to make some
  compromises."
in the abstract brought a smile on my face ;-) Same for "employees of the UK National Cyber Security Centre" at the end ;-)

Regards,

-éric

== COMMENTS ==

-- Section 2.1 --
C.1) I would suggest to use the words "network operators" rather than ISP as enterprise or parents for home networks are also relying on clear-text SNI to enforce some policies.

-- Section 2.2 --
C.2) The word "abuses" seems a little strong in the first paragraph, I prefer the wording used in 2.1 "unanticipated usage". But, this is only one comment.

-- Section 3.6 --
C.3) It is rather a question for my own curiosity... "The fronting service could be pressured by adversaries. " is an obvious attack but even if SNI is protected, the fronting service can still apply any policy to a protected service as it has the knowledge of protected services by design. Hence, I wonder why this case is mentioned here.

-- Security section --
Like Warren, I find the content of this section unusual.

== NITS ==

-- Section 2.1 --
Probably worth expanding "MITM" at first use.

--Section 3.3 --
Probably worth expanding "DOS" at first use.

[Ballot comment]
Firstly, thank you for writing this -- I think that it is useful and important...

I have some comments -- mostly nits and questions.

1: "As the other methods of monitoring get blocked, monitoring focuses on the clear text SNI.  The purpose of SNI encryption and privacy is to prevent that."
I don't think the purpose of privacy is to prevent that -- perhaps "The purpose of SNI encryption is to prevent that." or "to prevent that and aid privacy."?

2: "Encrypting the SNI now will complete this push for privacy and make it harder to censor or otherwise provide differential treatment to specific internet services."
Does encrypting the SNI really "complete" this in the "we can all declare success and go home" sense?

3: Also, I think I'm missing something -- RFC3552 is "Security Considerations Guidelines" --- I don't think it actually describes *an* adversary, rather it describes a number of different  attacks / adversaries (including things like DDoS). I think this needs words (e.g MITM / active attacker / something) (yes, I know that people sometimes use this term, and that EKR is an author...)

4: "The downside is the the client will not verify the identity of the fronting service with risks discussed in , but solutions will"
a: "the the" b: this seems to be missing a word / reference.

[Ballot comment]
Thanks for clearly writing down attacks and requirements in this document.

One small technical comment on this sentence:
Sec 2.3: "Per-stream
  QoS can be provided by a combination of packet marking and end-to-end
  agreements."
If this sentence is meant to mean use of DSCP, I don't think this is true, as DSCP is usually not available end-to-end but most often gets changed or bleached somewhere on the path.

And two editorial comments:

Sec 2.1: "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."
"soon found out" does sound a bit story-telling like to me. I recommend a more objective phrasing like:
"The SNI was defined to facilitate management of servers, though other usages by middleboxes also take
  advantage of the information."
or something similar...

Also sec 2.1: "The SNI is probably also included in the general collection of
  metadata by pervasive surveillance actors."
This sentence is phrased a bit speculatively and at the same kind seems inherently true as a "pervasive surveillance actor" usually just collect all available data/traffic... I guess the more interesting question would be if and how this information is used. Anyway I recommend some rephrasing like:
"The SNI could also be utilised by the general collection of
  metadata by pervasive surveillance actors."

[Ballot comment]
Thanks for clearly writing down attacks and requirements in this document.

One small technical comment on this sentence:
Sec 2.3: "Per-stream
  QoS can be provided by a combination of packet marking and end-to-end
  agreements."
If this sentence is meant to mean use of DSCP, I don't think this is true, as DSCP is usually not available end-to-end but most often gets changed or bleached somewhere on the path.

And two editorial comments:

Sec 2.1: "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."
"soon found out" doe sound a bit story-telling like to me. I recommend a more objective phrasing like:
"The SNI was defined to facilitate management of servers, though other usages by middleboxes also take
  advantage of the information."
or something similar...

Also sec 2.1: "The SNI is probably also included in the general collection of
  metadata by pervasive surveillance actors."
This sentence is phrase a bit speculatively and at the same kind of inherently true. A pervasive surveillance actor usually just collect all available data/traffic... I guess the more interesting question would be if and how this information is used. Any I recommend some rephrasing like:
"The SNI could also be utilised by the general collection of
  metadata by pervasive surveillance actors."

[Ballot 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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-tls-sni-encryption-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-09-02):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tls-sni-encryption@ietf.org, tls-chairs@ietf.org, Sean Turner , Joseph Salowey , kaduk@mit.edu, joe@salowey.net, tls@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Issues and Requirements for SNI Encryption in TLS) to Informational RFC


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Issues and Requirements for SNI
Encryption in TLS'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-09-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This draft describes the general problem of encrypting the Server
  Name Identification (SNI) TLS 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.

  In practice, it may well be that no solution can meet every
  requirement, and that practical solutions will have to make some
  compromises.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The document describes the general problem associated with encrypting the SNI. As a problem statement the requested status is informational. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  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.


Working Group Summary

Some working group members are not in favor of encrypting the SNI.  However, the topic of SNI encryption has consensus within the working group for continued work on SNI encryption.

Document Quality

This document describes the problem and does not define a protocol.  The document has been reviewed by the TLS working group.

Personnel

Document Shepherd: Joseph Salowey
Responsible AD: Ben Kaduk

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has reviewed the document and believes it is ready for IESG evaluation.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

This document should go though secdir review.  OPSDIR review may also be appropriate.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

Some members of the working group feel that privacy benefits of SNI encryption do not outweigh potential operational difficulties in encrypting the SNI.  This has been discussed in the working group and the consensus is that the privacy benefits are significant enough to continue work in this area.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

I have received confirmation  from each author

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The working group has consensus around this document, however there are some that feel that privacy benefits of SNI encryption do not outweigh potential operational difficulties in encrypting the SNI.  This has been discussed in the working group and the consensus is that the privacy benefits are significant enough to continue work in this area.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The document references obsolete versions of TLS.  This is intentional to provide historical background for the discussion in the document.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None Required

(13) Have all references within this document been identified as
either normative or informative?

Yes,  there are only informative references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No IANA action is required

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No formal language

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The document describes the general problem associated with encrypting the SNI. As a problem statement the requested status is informational. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  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.


Working Group Summary

Some working group members are not in favor of encrypting the SNI.  However, the topic of SNI encryption has consensus within the working group for continued work on SNI encryption.

Document Quality

This document describes the problem and does not define a protocol.  The document has been reviewed by the TLS working group.

Personnel

Document Shepherd: Joseph Salowey
Responsible AD: Ben Kaduk

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has reviewed the document and believes it is ready for IESG evaluation.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

This document should go though secdir review.  OPSDIR review may also be appropriate.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

Some members of the working group feel that privacy benefits of SNI encryption do not outweigh potential operational difficulties in encrypting the SNI.  This has been discussed in the working group and the consensus is that the privacy benefits are significant enough to continue work in this area.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

I have received confirmation  from each author

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The working group has consensus around this document, however there are some that feel that privacy benefits of SNI encryption do not outweigh potential operational difficulties in encrypting the SNI.  This has been discussed in the working group and the consensus is that the privacy benefits are significant enough to continue work in this area.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The document references obsolete versions of TLS.  This is intentional to provide historical background for the discussion in the document.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None Required

(13) Have all references within this document been identified as
either normative or informative?

Yes,  there are only informative references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No IANA action is required

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No formal language

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The document describes the general problem associated with encrypting the SNI. As a problem statement the requested status is informational. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  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.


Working Group Summary

Some working group members are not in favor of encrypting the SNI.  However, the topic of SNI encryption has consensus within the working group for continued work on SNI encryption.

Document Quality

This document describes the problem and does not define a protocol.  The document has been reviewed by the TLS working group.

Personnel

Document Shepherd: Joseph Salowey
Responsible AD: Ben Kaduk

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has reviewed the document and believes it is ready for IESG evaluation.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

This document should go though secdir review.  OPSDIR review may also be appropriate.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

Some members of the working group feel that privacy benefits of SNI encryption do not outweigh potential operational difficulties in encrypting the SNI.  This has been discussed in the working group and the consensus is that the privacy benefits are significant enough to continue work in this area.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

In progress

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The working group has consensus around this document, however there are some that feel that privacy benefits of SNI encryption do not outweigh potential operational difficulties in encrypting the SNI.  This has been discussed in the working group and the consensus is that the privacy benefits are significant enough to continue work in this area.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The document references obsolete versions of TLS.  This is intentional to provide historical background for the discussion in the document.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None Required

(13) Have all references within this document been identified as
either normative or informative?

Yes,  there are only informative references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No IANA action is required

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No formal language