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]