Internet DRAFT - draft-kazuho-protected-sni
draft-kazuho-protected-sni
Network Working Group K. Oku
Internet-Draft July 19, 2017
Intended status: Standards Track
Expires: January 20, 2018
TLS Extensions for Protecting SNI
draft-kazuho-protected-sni-00
Abstract
This memo introduces TLS extensions and a DNS Resource Record Type
that can be used to protect attackers from obtaining the value of the
Server Name Indication extension being transmitted over a Transport
Layer Security (TLS) version 1.3 handshake.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 20, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Oku Expires January 20, 2018 [Page 1]
Internet-Draft Protected SNI July 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 2
3. TLS-Bootstrap DNS Resource Record . . . . . . . . . . . . . . 3
4. Changes to ClientHello . . . . . . . . . . . . . . . . . . . 4
4.1. Semi-Static Key Share Extension . . . . . . . . . . . . . 5
4.2. Encrypted SNI Extension . . . . . . . . . . . . . . . . . 5
5. Things to Consider . . . . . . . . . . . . . . . . . . . . . 6
5.1. Downgrade Attack Protection . . . . . . . . . . . . . . . 6
5.2. Encrypting Other Extensions . . . . . . . . . . . . . . . 6
5.3. Mitigating Short-term Performance Impact . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
As discussed in SNI Encryption in TLS Through Tunneling
[I-D.huitema-tls-sni-encryption], it is becoming important to protect
from observers the name of the server a client is attempting access.
However, Transport Layer Security (TLS) version 1.3
[I-D.ietf-tls-tls13] transmits the Server Name Indication extension
(([RFC6066], section 3) unencrypted.
This memo defines the TLS-Bootstrap DNS Resource Record and two TLS
extensions: the Encrypted SNI Extension, the Semi-Static Key Share
Extension, that when being used together provides a way to transmit
the server name in an encrypted form.
1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Protocol Overview
In the proposed scheme, the server operator publishes its X.509
certificate [RFC5280] chain and a semi-static (EC)DH key using the
TLS-Bootstrap DNS Record Record.
Oku Expires January 20, 2018 [Page 2]
Internet-Draft Protected SNI July 2017
When a client tries to access the server, it queries the DNS resolver
for the TLS-Bootstrap DNS Resource Record in addition to the IP
address of the server. The two queries can be issued simultaneously.
Once the client obtains the address of the server and also the TLS-
Bootstrap DNS Resource Record, the client connects to the server and
starts a TLS handshake. Instead of sending the Server Name
Indication extension, the client will send the server name using the
Encrypted SNI Extension, which is encrypted using a symmetric key
derived from the result of the (EC)DH key exchange, the two (EC)DH
keys being the one embedded in the TLS-Bootstrap DNS Resource Record
and the other included in the KeyShare extension of the ClientHello
message.
3. TLS-Bootstrap DNS Resource Record
The DNS Resource Record Type is used to convey the server certificate
chain and (EC)DH public keys associated to a hostname.
The structure of the record type is:
struct {
KeyShareEntry key_share;
opaque cookie<0..2^16-1>;
} SemiStaticKeyShareEntry;
struct {
CertificateEntry certificate_list<0..2^24-1>;
SemiStaticKeyShareEntry semi_static_shares<1..2^16-1>;
CipherSuite cipher_suites<2..2^16-2>;
SignatureScheme signature_algorithm;
opaque signature<0..2^16-1>;
} TLSBootstrapRecord;
key_share A (EC)DH public key and its type.
cookie An identifier associated to the key_share. The value is
transmitted from the client to the server during the TLS handshake
so that the server can identify which key share as been used.
certificate_list The certificate chain of the server certificate
along with extensions to verify the validity of the certificate
(e.g., OCSP Status extensions ([RFC6066], [RFC6961])).
semi_static_shares list of key_shares that the server offers to the
client
Oku Expires January 20, 2018 [Page 3]
Internet-Draft Protected SNI July 2017
signature The signature is a digital signature using the algorithm
specified in the signature_algorithm field. The digital signature
covering from the beginning of the structure to the end of the
signature_algorithm field.
The set of semi-static (EC)DH keys included in the DNS Resource
Record MUST be a common value between the server names that are
served by the server. For example, if a server hosts three server
names: example.com, example.org, example.net, the keys that are
published using the DNS Resource Record will be identical for the
three server names.
4. Changes to ClientHello
When a client attempts to connect to a server, it at first queries
the DNS resolver to obtain the TLS-Bootstrap DNS Resource Record as
well as the IP address of the server. The two DNS queries can be
issued simultaneously.
Once the client obtains the IP address of the server and also the
TLS-Bootstrap DNS Resource Record, it MUST verify the certificate
chain and the signature of the TLS-Bootstrap DNS Resource record.
After a successful verification, the client will connect to the
server and start a TLS 1.3 handshake, by sending a ClientHello
handshake message with the following changes.
o The "key-share" extension MUST include exactly one KeyShareEntry.
The algorithm of the KeyShareEntry MUST be one among the semi-
static key shares offered by the server through the TLS-Bootstrap
DNS Resource Record.
o The "cipher_suite" field MUST include exactly one cipher-suite.
It should be one among the cipher-suites offered by the server
through the TLS-Bootstrap DNS Resource Record.
o The Server Name Indication Extension MUST NOT be used.
o The Semi-Static Key Share Extension and the EncryptedSNI Extension
MUST be used.
A client can use the Cached Information Extension [RFC7924] in hope
that the server will try to send the certificates that are identical
to the ones that are found in the TLS-Bootstrap DNS Resource Record,
and that instead of sending the certificate, the server will use the
extension to just send the hash values of the certificate.
Oku Expires January 20, 2018 [Page 4]
Internet-Draft Protected SNI July 2017
4.1. Semi-Static Key Share Extension
The extension identifies the semi-static (EC)DH key that was being
selected by the client.
struct {
select (Handshake.msg_type) {
case client_hello:
opaque cookie<0..2^16-1>;
case encrypted_extensions:
Empty;
}
} SemiStaticKeyShare;
A server MUST abort the handshake with a "unknown-semi-static-key"
alert if it find an unknown or an invalid cookie in the extension. A
server MUST send an empty Semi-Static Key Share Extension in the
EncryptedExtensions handshake message, when the extension appeared in
the ClientHello handshake message.
4.2. Encrypted SNI Extension
The extension contains the Server Name Indication Extension encrypted
using a shared key derived from the (EC)DH key exchange.
struct {
ServerName server_name;
opaque padding<0..2^8-1>;
} PlaintextEncryptedSNI;
struct {
select (Handshake.msg_type) {
case client_hello:
opaque encrypted_payload<0..2^16-1>;
case encrypted_extensions:
Empty;
}
} EncryptedSNI;
server_name the raw (un-encrypted) value of the Server Name
Indication Extension
cipher_suite The AEAD algorithm and the hash algorithm to encrypted
the encrypted_payload
encrypted_payload Contains a PlaintextEncryptedSNI structure
encrypted using the only cipher-suite specified by the
"cipher_suites" field of the ClientHello message.
Oku Expires January 20, 2018 [Page 5]
Internet-Draft Protected SNI July 2017
The key that is being used for protecting the encrypted_payload is
calculated as follows by using the HKDF functions [RFC5869], whereas
the semi_static_master_key being calculated by applying HKDF-Extract
to the result of the (EC)DH key exchange with an empty salt.
HKDF-Expand-Label(semi_static_master_key, "encrypted-sni", "",
Hash.length)
A client MUST pad the PlaintextEncryptedSNI structure so that the
length of the server name cannot be observed.
A server MUST abort the handshake with a "decode_error" alert if it
sees an Encrypted SNI Extension but not the Semi-Static Key Share
Extension. A server MUST abort the handshake with a "decrypt_error"
alert if it fails to decrypt the encrypted SNI.
Once the server successfully decrypts the EncryptedSNI extension, it
will use the value of the contained ServerName extension and continue
the handshake.
A server MUST send an empty EncryptedSNI extension using the
EncryptedExtension handshake message to indicate that it has seen the
extension in ClientHello.
If a client observes an EncryptedExtension handshake message with a
Semi-Static Key Share Extension but without a Encrypted SNI extension
in response to a ClientHello message containing an Encrypted SNI
extension, it MUST abort the handshake by sending a
"handshake_failure" alert.
5. Things to Consider
5.1. Downgrade Attack Protection
Attackers might want to block the transmission of a TLS-Bootstrap
Record to prevent a server name from being sent in an encrypted form.
To mitigate such attacks, we should consider extending HTTP Strict
Transport Security [RFC6797] so that the servers can enforce the
client the use of the Encrypted SNI extension.
5.2. Encrypting Other Extensions
We might want to refactor the proposed method to send an arbitrary
number of extensions protected within a ClientHello message, rather
than just encrypting the Server Name Indication extension. Doing so
opens up the possibilty of protected more types of extensions such as
the Application-Layer Protocol Negotiation Extension [RFC7301]. Or,
Oku Expires January 20, 2018 [Page 6]
Internet-Draft Protected SNI July 2017
it would be possible to use the key to invoke a 0-RTT handshake even
when resumption is impossible.
5.3. Mitigating Short-term Performance Impact
Today, most DNS requests / responses are sent using UDP in cleartext.
That fact has two impacts on the proposed method.
Firstly, transmitting a TLS-Bootstrap Record will require multiple
roundtrips, since the record is unlikely to fit in a single packet.
Secondly, the merit of hiding the server name that appears in the
ClientHello somewhat diminishes by the fact that the same value might
be transmitted unencrypted in the DNS query.
Considering the facts, in might make sense to define the transfer of
the certificate and the signature as an optional feature, so that the
only mandatory field that needs to be conveyed in the TLS-Bootstrap
Record will be the (EC)DH public key and the associated cookie.
It is likely that such a reduced format will fit into a single UDP
packet. Hence the performance degradation will be negligble
considering the fact that the query for the TLS-Bootstrap Record can
happen simultaneously with the address resolution.
The downside of the approach will be that the server name would not
be protected from an active attacker. However, until DNS queries
start getting transmitted over an encrypted channel, the risk of such
attacks might be very low, considering the fact that server names can
be found unencrypted in the DNS packets anyways.
After DNS over secure transport becomes popular, we can start
embedding certificates and digital signatures in the TLS-Bootstrap
Record to prevent active attacks, as well as start using the semi-
static EC(DH) key for other purposes.
6. Security Considerations
By using the value of the cookie, servers MUST detect and reject the
use of outdated TLS-Bootstrap DNS Resource Records. Otherwise, an
attacker might be able to inject an old record to force the peers to
agree on using a key-share or a cipher-suite that has turned out to
be vulnerable after the record was published on the authoritative
server.
The injection of malformed or outdated TLS-Bootstrap DNS Resource
Record can be used as an attack vector to cause denial-of-service
attacks, since misuse of such records by a client ends up in a TLS
handshake failure. However, it could be argued that injection of a
Oku Expires January 20, 2018 [Page 7]
Internet-Draft Protected SNI July 2017
wrong A record will essentially have the same effect in terms of
denial-of-service attacks. In other words, use of a DNS record to
transmit TLS handshake parameters does not make us more prone to
attacks.
7. IANA Considerations
The TLS ExtensionType Registry will be updated to contain the
codepoints for the Semi-Static Key Share Extension Type and the
Encrypted SNI Extension type.
The TLS Alert Registry will be updated to contain the "unknown-semi-
static-key" alert.
The DNS Parameters Registry will be updated to contain the codepoint
for the TLS-Bootstrap Resource Record Type.
8. Acknowledements
Thank you to Subodh Iyengar for suggesting that the certificate chain
and the signature could be optional fields of a TLS-Boostrap record.
9. References
9.1. Normative References
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
July 2017.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
Oku Expires January 20, 2018 [Page 8]
Internet-Draft Protected SNI July 2017
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>.
9.2. Informative References
[I-D.huitema-tls-sni-encryption]
Huitema, C. and E. Rescorla, "SNI Encryption in TLS
Through Tunneling", draft-huitema-tls-sni-encryption-02
(work in progress), July 2017.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012,
<http://www.rfc-editor.org/info/rfc6797>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013,
<http://www.rfc-editor.org/info/rfc6961>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <http://www.rfc-editor.org/info/rfc7301>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016,
<http://www.rfc-editor.org/info/rfc7924>.
Author's Address
Kazuho Oku
Email: kazuhooku@gmail.com
Oku Expires January 20, 2018 [Page 9]
