SNI Encryption in TLS Through Tunneling
draft-huitema-tls-sni-encryption-02
| Document | Type | Replaced Internet-Draft (tls WG) | |
|---|---|---|---|
| Last updated | 2017-07-20 (latest revision 2017-07-03) | ||
| Replaced by | RFC 8744 | ||
| Stream | IETF | ||
| Intended RFC status | (None) | ||
| Formats |
Expired & archived
pdf
htmlized (tools)
htmlized
bibtex
|
||
| Stream | WG state | Candidate for WG Adoption | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | Replaced by draft-ietf-tls-sni-encryption | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
https://www.ietf.org/archive/id/draft-huitema-tls-sni-encryption-02.txt
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 starts by listing known attacks against SNI encryption, discusses the current "co-tenancy fronting" solution, and then presents two potential TLS layer solutions that might mitigate these attacks. The first solution is based on TLS in TLS "quasi tunneling", and the second solution is based on "combined tickets". These solutions only require minimal extensions to the TLS protocol.
Authors
Christian Huitema
(huitema@huitema.net)
Eric Rescorla
(ekr@rtfm.com)
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)