[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-krecicki-dnsenc) 00 01

Internet Engineering Task Force                              W. Krecicki
Internet-Draft                               Internet Systems Consortium
Intended status: Standards Track                        October 19, 2015
Expires: April 21, 2016


                        Stateless DNS Encryption
                    draft-krecicki-dprive-dnsenc-01

Abstract

   The DNS is the last common Internet protocol that has no encryption
   scheme and therefore provides no privacy to the users.  This document
   proposes an extensible mechanism providing encryption of DNS queries
   and responses with method for secure retrieval and verification of
   validity of encryption keys.  It is independent of the underlying
   transport protocol.

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 April 21, 2016.

Copyright Notice

   Copyright (c) 2015 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




Krecicki                 Expires April 21, 2016                 [Page 1]


Internet-Draft          Stateless DNS Encryption            October 2015


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Communication process . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Key retrieval . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Query creation  . . . . . . . . . . . . . . . . . . . . .   4
       2.2.1.  Method 1  . . . . . . . . . . . . . . . . . . . . . .   5
       2.2.2.  Method 2  . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Query processing  . . . . . . . . . . . . . . . . . . . .   7
     2.4.  Response creation . . . . . . . . . . . . . . . . . . . .   7
     2.5.  Response processing . . . . . . . . . . . . . . . . . . .   8
   3.  Data types  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  NSK record  . . . . . . . . . . . . . . . . . . . . . . .   8
       3.1.1.  Wire format . . . . . . . . . . . . . . . . . . . . .   8
       3.1.2.  Presentation format . . . . . . . . . . . . . . . . .  10
     3.2.  DNSENC option . . . . . . . . . . . . . . . . . . . . . .  11
   4.  Encryption schemes  . . . . . . . . . . . . . . . . . . . . .  11
     4.1.  Asymmetric schemes  . . . . . . . . . . . . . . . . . . .  11
     4.2.  Symmetric schemes . . . . . . . . . . . . . . . . . . . .  12
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     6.1.  NSK RR type . . . . . . . . . . . . . . . . . . . . . . .  12
     6.2.  DNSENC EDNS option  . . . . . . . . . . . . . . . . . . .  12
     6.3.  ENCRYPT OpCode  . . . . . . . . . . . . . . . . . . . . .  12
     6.4.  BADCRYPT RCODE  . . . . . . . . . . . . . . . . . . . . .  13
     6.5.  DNSENC encryption schemes registry  . . . . . . . . . . .  13
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   The Domain Name System protocol is specified in [RFC1034] and
   [RFC1035].  DNS messages are unencrypted and therefore prone to
   eavesdropping.  Although it's considered only metadata, there is a
   lot of information that can be leaked, as explained by [RFC7626].

   The DNS protocol is very lightweight - the queries are usually less
   than 100 bytes long and the responses are usually less than 1000
   bytes (even with DNSSEC).  Existing transport encryption schemes such
   as TLS for TCP or DTLS for UDP give a huge and unnecessary overhead
   both in the amount of data sent and retrieved and in the number of
   packets exchanged between client and server.





Krecicki                 Expires April 21, 2016                 [Page 2]


Internet-Draft          Stateless DNS Encryption            October 2015


   In DNSENC the query is encrypted using asymmetric cryptography with a
   securely retrieved key and the response is encrypted using symmetric
   encryption with a one-time key provided with the query.  The DNSENC
   protocol is uses standard DNS features and does not requires any
   additional external mechanisms such as a PKI/CA system.

   The DNSENC communication can be split into three phases:

   o  first the client retrieves public key for the server that is
      stored in DNS and is DNSSEC signed; this key can then be cached,

   o  the client creates the query, adds a random response encryption
      key and encrypts the query with the server's public key,

   o  the server decrypts the message, prepares the response and
      encrypts it with the key provided by client.

   It has to be noted that for a resolver to bootstrap itself, it has to
   perform a clear text query to retrieve keys for DNSENC encryption.
   As this query can be for information from the root zone, no sensitive
   information is leaked.

   In an usual case DNSENC will add no additional round-trips to
   communication, besides the query for root zone servers' NSK record.
   The message size overhead is around 140 bytes for encapsulation
   (NOTE: that's using method described in Section 2.2.1), the maximum
   amount of overhead for encryption depends on the method used and
   varies from 16 bytes for AES to 512 bytes for RSA.

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].

2.  Communication process

2.1.  Key retrieval

   To communicate securely with a server, a client first needs to
   retrieve the server's public key for asymmetric encryption.  This key
   is stored in an NSK RR described in Section 3.1.  The NSK RRset might
   contain multiple records.  The key retrieval process is different for
   authoritative servers and for recursive servers.

   For authoritative servers a NSK RRset SHOULD be present at a
   delegation point in the parent zone.  If a NSK RRset is present at
   the delegation point, the name server MUST return both the NSK RRset



Krecicki                 Expires April 21, 2016                 [Page 3]


Internet-Draft          Stateless DNS Encryption            October 2015


   and its associated RRSIG RR(s) in the Authority section along with
   the NS RRset.  This reduces the number of round-trips and allows all
   communication with the child zone's servers to be encrypted.

   All NSK RRsets MUST be signed with DNSSEC, and NSK RRsets MUST NOT
   appear at a zone's apex.

     example.com.  86400   IN  NS   a.iana-servers.net.
     example.com.  86400   IN  NS   b.iana-servers.net.
     example.com.  86400   IN  NSK  (...)
     example.com.  86400   IN  NSK  (...)
     example.com.  86400   IN  RRSIG NSK (...)

   For recursive servers and in cases where it is not possible to put
   the NSK RRset for an authoritative server at a delegation point, the
   NSK RRset SHOULD be present in the reverse DNS record of servers' IP
   address, as described in [RFC3152], [RFC1033] and [RFC2317].  The
   client MUST retrieve this RRset from the server it wants to query.
   This RRset MUST be DNSSEC signed.  For authoritative servers this
   method is only a fallback and client MUST try to retrieve the key at
   a delegation point first.

     5.2.0.192.in-addr.arpa.  86400 IN NSK  (...)

   If the record is not signed the client MUST NOT use the key provided.
   (TODO enforce encryption, protection against downgrade attack).

   As there might be multiple NSK RRs in the RRSet it is the client
   responsibility to choose the highest priority RR that has both query
   and response schemes supported by the client.

2.2.  Query creation

   -----------------------------------------------

   NOTE: two alternatives are currently under discussion.  Both are
   fully compatible with the DNS protocol.  The first one is kind of a
   kludge but has better chances to be compatible with not-fully-
   protocol-compliant forwarders (although it still requires support for
   EDNS).  The second solution is cleaner but might not work with some
   forwarders as the packet is not a regular DNS QUERY.  The author
   prefers the first method.

   -----------------------------------------------

   After choosing an encryption scheme, the client generates a random
   response encryption key (symmetrical, eg.  AES) and prepares a




Krecicki                 Expires April 21, 2016                 [Page 4]


Internet-Draft          Stateless DNS Encryption            October 2015


   regular DNS query with an NSK record containing the response
   encryption scheme and key in the ADDITIONAL section, eg:

                            +-----------------------------------------+
              Header        |      OPCODE=QUERY, ID=997, QR=QUERY     |
                            +-----------------------------------------+
             Question       |  QTYPE=A, QCLASS=IN, QNAME=EXAMPLE.COM  |
                            +-----------------------------------------+
              Answer        |                 <empty>                 |
                            +-----------------------------------------+
             Authority      |                 <empty>                 |
                            +-----------------------------------------+
            Additional      |             . NSK IN NSK-RR             |
                            +-----------------------------------------+

   It has to be noted that this packet is never sent on the wire in raw
   form, so records in the ADDITIONAL section have no impact on
   compatibility with non-conforming forwarders.

2.2.1.  Method 1

   This message is encrypted using chosen query encryption key and
   packed, along with encryption key ID, in a DNSENC OPTION, as
   described in Section 3.2.  A new query is created with:

   o  the query id copied from the encrypted message

   o  a <nonce>.dnsenc.arpa.  TXT query in QUERY section, where <nonce>
      is a random label that guarantees that should the response be
      cached by a forwarder, it will not be reused for any other client.

   o  empty ANSWER and AUTHORITY sections

   o  a DNSENC OPTION in ADDITIONAL section

   eg.:















Krecicki                 Expires April 21, 2016                 [Page 5]


Internet-Draft          Stateless DNS Encryption            October 2015


                            +-----------------------------------------+
              Header        |      OPCODE=QUERY, ID=997, QR=QUERY     |
                            +-----------------------------------------+
             Question       |      QTYPE=TXT, QCLASS=IN,              |
                            |              QNAME=<nonce>.dnsenc.arpa  |
                            +-----------------------------------------+
              Answer        |                 <empty>                 |
                            +-----------------------------------------+
             Authority      |                 <empty>                 |
                            +-----------------------------------------+
            Additional      |      EDNS0 OPT OPTION-CODE=DNSENC       |
                            \       OPTION-DATA=DNSENC-PAYLOAD        \
                            |                                         |
                            +-----------------------------------------+

   ...and sent to server.  The response encryption key is stored on
   client along its identifier for decryption.

2.2.2.  Method 2

   This message is encrypted using query encryption key and packed
   inside a query withi the OPCODE set to ENCRYPT:

                                             1  1  1  1  1  1
               0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                      ID                       |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |QR|  ENCRYPT  |        Z           |   RCODE   |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |           ENCRYPTED PAYLOAD LENGTH            |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                    RESERVED                   |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                    RESERVED                   |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                    RESERVED                   |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |               ENCRYPTION KEY ID               |
             |                                               |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                                               |
             /               ENCRYPTED PAYLOAD               /
             |                                               |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   i...and sent to server.  The response encryption key is stored on
   client along its identifier for decryption.



Krecicki                 Expires April 21, 2016                 [Page 6]


Internet-Draft          Stateless DNS Encryption            October 2015


2.3.  Query processing

   When a server supporting DNSENC receives a query for any name in the
   "dnsenc.arpa." domain it MUST immediately look in ADDITIONAL section
   for DNSENC OPTION.  If the DNSENC OPTION is missing the server MUST
   respond with a status of REFUSED.  The DNSENC OPTION is then decoded.
   If the server does not have a key with identifier provided in query
   or the decryption failed the server MUST respond with BADCRYPT
   response.  If the data contained in the decrypted packet is invalid
   or the query ID is not the same as the encapsulating packet query ID
   the server MUST respond with FORMERR response.

   A server that does not support DNSENC should respond with REFUSED
   response code, although old implementations not supporting [RFC6891]
   might return FORMERR.

   A forwarder/proxy MUST pass the message untouched (along with the
   DNSENC OPTION in the ADDITIONAL section) - as described in [RFC5625].
   A forwarder/proxy MUST NOT cache a result for anything within
   "dnsenc.arpa." domain.

2.4.  Response creation

   -----------------------------------------------

   NOTE: this section describes creating the response for a query
   described in Section 2.2.1, the method for creating a response for a
   query described in Section 2.2.2 is analogous but will be described
   here iff WG decides to go ahead with this method.

   -----------------------------------------------

   After decryption, the NSK record from the query is saved and the
   query is processed normally.  When the response is ready, a regular
   DNS response packet is created.  This packet is encrypted using
   previously saved response encryption key sent by client and stored
   along with the response encryption key ID (to keep the response in
   the same format as query) in a DNSENC OPTION.  A new response packet
   is created with:

   o  the query ID same as in encrypted packet

   o  the QUESTION section copied from original query

   o  an empty ANSWER and AUTHORITY sections

   o  a DNSENC Option in EDNS(0) OPT RR in the ADDITIONAL section
      containing the encrypted respose to the "real" query.



Krecicki                 Expires April 21, 2016                 [Page 7]


Internet-Draft          Stateless DNS Encryption            October 2015


   eg.

                            +-----------------------------------------+
              Header        |    OPCODE=QUERY, ID=997, QR=RESPONSE    |
                            +-----------------------------------------+
             Question       |      QTYPE=TXT, QCLASS=IN,              |
                            |              QNAME=<nonce>.dnsenc.arpa  |
                            +-----------------------------------------+
              Answer        |                 <empty>                 |
                            +-----------------------------------------+
             Authority      |                 <empty>                 |
                            +-----------------------------------------+
            Additional      |       EDNS0 OPT OPTION-CODE=DNSENC      |
                            \        OPTION-DATA=DNSENC-PAYLOAD       \
                            |                                         |
                            +-----------------------------------------+

   This is then sent back to the client.

2.5.  Response processing

   TODO

3.  Data types

3.1.  NSK record

   The NSK RR consist of priority field, key identifier, server names
   for which the key can be used (wildcard '*' is supported, empty value
   means all servers for the zone), query encryption scheme
   (asymmetrical, eg. rsaes-oaep-2048), query key data and possible
   response encryption schemes.  If the server provides multiple NSK
   records, it is the client's responsibility to choose the highest
   priority NSK that has query and response encryption schemes supported
   by client.

3.1.1.  Wire format

   The NSK RR has following format:












Krecicki                 Expires April 21, 2016                 [Page 8]


Internet-Draft          Stateless DNS Encryption            October 2015


                                             1  1  1  1  1  1
               0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                 KEY IDENTIFIER                |
             |                                               |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |      PRIORITY         |        RESERVED       |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                                               |
             /               APPLICABLE NS NAME              /
             |                                               |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |               ENCRYPTION SCHEME               |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                   KEY LENGTH                  |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                                               |
             /                    KEY DATA                   /
             |                                               |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |      NUMBER OF RESPONSE ENCRYPTION SCHEMES    |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |          RESPONSE ENCRYPTION SCHEME 1         |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |          RESPONSE ENCRYPTION SCHEME 2         |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             +                      ...                      +
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |          RESPONSE ENCRYPTION SCHEME N         |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


   where:

   KEY IDENTIFIER              32-bit key identifier, unique for server

   PRIORITY                    8-bit key priority as preferred by server

   APPLICABLE NS NAME          a <domain-name> of NSes that use this
                               key.  This allows for different NSes for
                               a zone to use different keysets (eg. when
                               the secondary is operated by different
                               entity than primary).  This field might
                               contain wildcard symbol '*' at any place
                               (including as a part of a single label -
                               eg. 'ns*.foo*bar.example.com'), which
                               matches zero or more characters and can
                               cross label boundaries ('ns*.example.com'



Krecicki                 Expires April 21, 2016                 [Page 9]


Internet-Draft          Stateless DNS Encryption            October 2015


                               matches 'ns.example.com',
                               'ns1.example.com' and
                               'ns1.foobar.example.com'), single '*'
                               means any.

   ENCRYPTION SCHEME           16-bit identifier of the encryption
                               scheme, as defined in [TBD IANA REGISTRY]

   KEY DATA                    encryption key - raw binary data

   RESPONSE ENCRYPTION SCHEMES list of 16-bit identifiers of response
                               encryption schemes, as defined in [TBD
                               IANA REGISTRY], in order of server
                               preference from most preferred

   For NSK records retrieved by a resolver as described in Section 2.1
   ENCRYPTION SCHEME describes the scheme used by client to encrypt the
   query, which MUST be an asymmetric one.  RESPONSE ENCRYPTION SCHEMES
   MUST contain at least one scheme, and all encryption schemes MUST be
   symmetric.

   For NSK records sent in the ADDITIONAL section of a query and used by
   the server to encrypt response:

   o  PRIORITY MUST be set to 0

   o  APPLICABLE NS NAME MUST be empty

   o  ENCRYPTION SCHEME MUST be symmetric and be one from the list of
      RESPONSE ENCRYPTION SCHEMES in a NSK record with key used to
      encrypt this query.

   o  KEY DATA MUST be a one-time, random key

   o  RESPONSE ENCRYPTION SCHEMES MUST be empty

3.1.2.  Presentation format

   All numerical fields are presented in decimal form, query key data is
   base64 encoded, encryption scheme can be represented as a number or
   as a name, fields are in the same order as in wire format, eg:










Krecicki                 Expires April 21, 2016                [Page 10]


Internet-Draft          Stateless DNS Encryption            October 2015


    example.com.  86400 IN NSK (896417428       ; identifier
                                10              ; priority
                                ns*.example.com ; applicable NS name
                                1               ; query encryption
                                                ; scheme
                                "bnJfZnJlZV9wYWdlcyAyMTU2NjgKbnJf
                                YWxsb2NfYmF0Y2ggNDE1OQpucl9pbmFj
                                dGl2ZV9hbm9uIDM1NzczNwpucl9hY3Rp
                                IDQ4OTAwMQpucl9kaXJ0eSAxMTUKbnJf
                                ZCAwCg=="       ; query key, b64 encoded
                                32769 aes-256   ; response encryption
                                                ; schemes
                                )

3.2.  DNSENC option

   The encrypted packet is transmitted as an EDNS(0) option, with
   OPTION-CODE set to DNSENC (value of [TBD]).  The wire format of
   OPTION-DATA for this option is:

                                             1  1  1  1  1  1
               0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                 KEY IDENTIFIER                |
             |                                               |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                                               |
             /               ENCRYPTED PAYLOAD               /
             |                                               |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   The length of the encrypted payload is determined by the OPTION-
   LENGTH field

4.  Encryption schemes

   This document defines basic encryption schemes to be used for query
   and response encryption.  Those schemes SHOULD be implemented by all
   servers and clients.

4.1.  Asymmetric schemes

   TBD: RSAES-1024-EOAP, ECC as a default?








Krecicki                 Expires April 21, 2016                [Page 11]


Internet-Draft          Stateless DNS Encryption            October 2015


4.2.  Symmetric schemes

   TBD: AES-256

5.  Security Considerations

   The security of this protocol is based deeply on DNSSEC [RFC4033].
   Protection against downgrade attack requires wide adoption of DNSSEC.

6.  IANA Considerations

   NOTE: as for now no actions with IANA has been taken.

6.1.  NSK RR type

   This document defines a new DNS Resource Record Type, named "NSK".
   The IANA has assigned a code point from the "Resource Record (RR)
   TYPEs" sub-registry of the "Domain Name System (DNS) Parameters"
   registry for this record.

      TYPE    Value    Meaning                           Reference
      -----   ------   --------------------------        -----------
      NSK     TBD      Name Server Key                   [this document]

6.2.  DNSENC EDNS option

   This document defines a new EDNS option, named "DNSENC".  The IANA
   has assigned a code point from the "DNS EDNS0 Option Codes (OPT)"
   sub-registry of the "Domain Name System (DNS) Parameters" registry
   for this option.  NOTE: this is required only for Section 2.2.1.

        Value     Name        Status        Reference
        -------   --------    ---------     ----------------
        [TBD]     DNSENC      Standard      [this document]

6.3.  ENCRYPT OpCode

   This document defines a new DNS OPCODE, named "ENCRYPT".  The IANA
   has assigned a code point from the "DNS OpCodes" sub-registry of the
   "Domain Name System (DNS) Parameters" registry for this opcode.
   NOTE: this is required only for Section 2.2.2.

        OpCode  Name                    Reference
        -----   ---------------------   --------------------------
        TBD     ENCRYPT                 [this document]






Krecicki                 Expires April 21, 2016                [Page 12]


Internet-Draft          Stateless DNS Encryption            October 2015


6.4.  BADCRYPT RCODE

   This document defines a new DNS RCODE, named "BADCRYPT".  The IANA
   has assigned a code point from the "DNS RCODEs" sub-registry of the
   "Domain Name System (DNS) Parameters" registry for this opcode.

     OpCode  Name         Description                Reference
     -----   ------------ -------------------------  -------------------
     TBD     BADCRYPT     Encryption error           [this document]

6.5.  DNSENC encryption schemes registry

   The IANA has created and maintains a sub-registry (the "DNSENC
   encryption schemes" registry) of the "Domain Name System (DNS)
   Parameters" registry.  The initial values for this registry are
   below.

   An "Expert Review" [RFC5226] is required for the assignment of new
   scheme value (TBD: Expert or IETF?  We should have a proper
   definition of an encryption scheme).

   This registry holds a set of 16-bit values identifying an encryption
   scheme.  First bit of first octet is set to 0 for asymmetric
   encryption schemes, 1 for symmetric encryption schemes.  First nibble
   of second octet is set to 0xf for experimental or vendor-specific
   schemes.

   The initial assignments in this registry are:

       Octet 1 Octet 2  Algorithm                  Reference
       ------- -------  ------------------------   ---------------
       0x00    0x00     Reserved                   [this document]
       0x00    0x01     RSAES-2048-OAEP            [this document]
       0x00    0x02     RSAES-4096-OAEP            [this document]
       0x80    0x00     Reserved                   [this document]
       0x80    0x01     AES-256                    [this document]
       0x80    0x01     AES-512                    [this document]
       ....    0xf.     experimental
                          or vendor-specific

7.  Normative References

   [RFC1033]  Lottor, M., "Domain Administrators Operations Guide", RFC
              1033, DOI 10.17487/RFC1033, November 1987,
              <http://www.rfc-editor.org/info/rfc1033>.






Krecicki                 Expires April 21, 2016                [Page 13]


Internet-Draft          Stateless DNS Encryption            October 2015


   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

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

   [RFC2317]  Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
              ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/
              RFC2317, March 1998,
              <http://www.rfc-editor.org/info/rfc2317>.

   [RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, DOI
              10.17487/RFC3152, August 2001,
              <http://www.rfc-editor.org/info/rfc3152>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, DOI 10.17487/RFC4033, March 2005,
              <http://www.rfc-editor.org/info/rfc4033>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines", BCP
              152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
              <http://www.rfc-editor.org/info/rfc5625>.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/
              RFC6891, April 2013,
              <http://www.rfc-editor.org/info/rfc6891>.

   [RFC7626]  Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
              DOI 10.17487/RFC7626, August 2015,
              <http://www.rfc-editor.org/info/rfc7626>.







Krecicki                 Expires April 21, 2016                [Page 14]


Internet-Draft          Stateless DNS Encryption            October 2015


Author's Address

   Witold Krecicki
   Internet Systems Consortium
   950 Charter Street
   Redwood City, CA  94063
   USA

   Email: wpk@isc.org
   URI:   http://www.isc.org









































Krecicki                 Expires April 21, 2016                [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/