A UTC Timestamp Option For EDNS
draft-liman-dns-utcstamp-00

Document Type Active Internet-Draft (individual)
Last updated 2018-11-20
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Domain Name Operations                                        L-J. Liman
Internet-Draft                                                    Netnod
Intended status: Informational                               R. Sundblad
Expires: May 24, 2019                      Royal Institute of Technology
                                                       November 20, 2018

                    A UTC Timestamp Option For EDNS
                      draft-liman-dns-utcstamp-00

Abstract

   UTCSTAMP is an EDNS extension to allow a client to request from a
   server that it includes a timestamp in the response message, and for
   the server to provide it, if requested and deemed appropriate.  This
   is primarily intended as a debugging tool.

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 https://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 May 24, 2019.

Copyright Notice

   Copyright (c) 2018 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
   (https://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.

Liman & Sundblad          Expires May 24, 2019                  [Page 1]
Internet-Draft           EDNS(0) UTCSTAMP Option           November 2018

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  General Behavior  . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Resolver Behavior . . . . . . . . . . . . . . . . . . . .   3
     3.3.  Name Server Behavior  . . . . . . . . . . . . . . . . . .   3
     3.4.  The UTCSTAMP Option . . . . . . . . . . . . . . . . . . .   4
     3.5.  Presentation Format . . . . . . . . . . . . . . . . . . .   4
   4.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Data Payload  . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Presentation format . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  Change History  . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Document Timestamp  . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Network security based on encryption depends heavily on the
   requirement that all involved parties have a common understanding of
   the time of day.  This is true also for the domain name system (DNS)
   and its transaction signature (TSIG) is no exception.  If the time
   difference between the DNS server and the DNS client is too large,
   TSIG signatures will not validate.  When debugging security-related
   issues with the DNS, knowing what a remote party believes to be the
   current time can be very helpful.  This documents describes an option
   to Extended DNS (EDNS) [RFC6891] that allows a client to request that
   the server includes a timestamp in the response packet, and for the
   server to provide it, if requested and deemed appropriate.

   This document is modeled after the NSID option, described in RFC 5001
   [RFC5001].

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

Liman & Sundblad          Expires May 24, 2019                  [Page 2]
Internet-Draft           EDNS(0) UTCSTAMP Option           November 2018

3.  Protocol

   This protocol uses an EDNS RFC 6891 [RFC6891] option to signal a
   resolver's desire for information identifying a server's
   understanding of the current date and time of day, and to hold the
   name server's response, if any.

3.1.  General Behavior

   The semantics of a UTCSTAMP request are not transitive.  That means
   that any DNS server that receives a incoming query with a UTCSTAMP
   request, to which it intends to honour it, MUST report its own
   understanding of the current time, and not relay information obtained
   from a different host.

   UTCSTAMP responses MUST NOT be cached.

3.2.  Resolver Behavior

   A resolver signals its desire for information about the server's
   understanding of the current time by sending an empty UTCSTAMP option
   (Section 3.4) in an EDNS OPT pseudo-RR in the query message.

   The resolver MUST NOT include any UTCSTAMP payload data in the query
   message.

   The resolver MUST NOT expect the server to respond with a valid
   UTCSTAMP response.

   The resolver MUST be able to handle the situation that the request is
   ignored by the server.

   The resolver SHOULD be able to handle unsolicited UTCSTAMP data sent
   by the server.

3.3.  Name Server Behavior

   A name server that understands the UTCSTAMP option, and chooses to
   honour a particular UTCSTAMP request, responds by including time
   information in a UTCSTAMP option (Section 3.4) in an EDNS OPT pseudo-
   RR in the response message.

   The name server MUST ignore any UTCSTAMP payload data that might be
   present in the query message.

   A name server MUST NOT send a UTCSTAMP option back to a resolver
   unless it was requested.

Liman & Sundblad          Expires May 24, 2019                  [Page 3]
Internet-Draft           EDNS(0) UTCSTAMP Option           November 2018

   The UTCSTAMP option is not transitive.  In particular, a recursive
   name server MUST consider UTCSTAMP incoming transactions its client
   as a separate from its outgoing transactions towards authoritative
   servers and/or forward resolvers.  An incoming UTCSTAMP received from
   an authoritative (or forward) server MUST NOT be forwarded in an
   outgoing response to a client.

   If a server doesn't have an understanding of the current time, it
   MUST either ignore the request, OR signal the fact that it cannot
   honour the request by responding with NOTIME data (see Section 3.4).

3.4.  The UTCSTAMP Option

   The OPTION-CODE for the UTCSTAMP option is 65394 (provisional and
   experimental, a permanent one to be assigned by the IANA, should this
   document be adopted as an RFC.).

   OPTION-LEN MUST always be zero (0) in UTCSTAMP requests and MUST be
   at least eight (8) in responses.  UTCSTAMP options with OPTION-LENs
   that deviate from these rules MUST be ignored.

   The OPTION-DATA section for a UTCSTAMP request must be empty.  For
   responses the UTCSTAMP OPTION-DATA is always an unsigned integer, in
   network byte order, at least 64-bits long, which represents the
   number of seconds since 1970-01-01 00:00:00 UTC, with the exception
   of the value with all bits set (i.e., FFFFFFFFFFFFFFFF (HEX) for a
   64-bit number) which SHOULD be sent and received as a signal that the
   server giving out the information understands the request but is
   incapable of providing the information.  The signal is referred to as
   "NOTIME".  If the server understands the request and is able to
   provide the requested information, but is unwilling to do so
   (typically due to its configuration), the incoming UTCSTAMP request
   SHOULD be ignored, and no UTCSTAMP option response given at all.

3.5.  Presentation Format

   User interfaces SHOULD present the UTCSTAMP information using human
   readable ISO 8601 format and UTC time: "YYYY-MM-DD HH:MM:SS UTC"
   (e.g., "2018-11-15 15:52:23 UTC").  In addition to this, user
   interfaces MAY also offer to provide the compact ISO 8601 format:
   "YYYYMMDDTHHMMSSZ" (e.g., "20181115T155223Z"), and/or the pure data
   from the OPTION-DATA section of the message, in decimal notation
   (e.g., "1542383543").

   The first format is preferred, as UTCSTAMP is intended as a debugging
   tool for humans, and that version is easier for humans to read.  The
   latter may be useful in automated monitoring scenarios.

Liman & Sundblad          Expires May 24, 2019                  [Page 4]
Internet-Draft           EDNS(0) UTCSTAMP Option           November 2018

   Software that present this information should examine data carefully,
   before processing it, and should not assume that the data is neither
   correct nor sensible.

   The UTCSTAMP payload is binary data.  Any automated comparison
   between UTCSTAMP payloads SHOULD be a comparison of the raw binary
   data or the raw data converted to the native byte order for the
   machine in question.  Copy operations MUST NOT assume that the raw
   UTCSTAMP payload is null-terminated.

4.  Discussion

   This section discusses certain aspects of the protocol and explains
   considerations that led to the chosen design.

4.1.  Data Payload

   The choice of "epoch time" (number of seconds since 1970-01-01
   00:00:00 UTC) was based on simplicity.  Epoch time is a simple
   integer, that will fit in fixed 64-bit container for a long time to
   come.  Epoch time needs no meta information, such as day of week or
   time zone, and there are no options or alternatives associated with
   epoch time.  By eliminating options and alternatives, there is very
   little chance of misinterpretation on the recipient side, and since
   it is a simple number, comparison with other similar timestamps is
   very straightforward.  In certain cases, which are arguably common,
   it also imposes very little need for computation at the server end.

   There are of course arguments for making it more complex.  An obvious
   one is that the server may not have, or be able to compute, the
   specified value.  It may have no notion what so ever of a time zone.
   It may have an internal format that is based on a totally different
   format than epoch seconds, and may therefore have to perform some
   computations in order to produce the value.

   For the former case, time comparison is of more limited value.  If
   the server doesn't even know which time zone it sits in, it has no
   notion of universal time, and universal time is needed for
   timestamped signatures to work universally.  There may be cases where
   a limited cluster of servers share a common understanding of time
   which is not based on time zones, but this protocol is intended to be
   generic and possible to use on the public global Internet.

   For the case with a different internal time system, computation will
   indeed be necessary, but the authors argue that that case is less
   common, and that the computations are only moderately complex.

Liman & Sundblad          Expires May 24, 2019                  [Page 5]
Internet-Draft           EDNS(0) UTCSTAMP Option           November 2018

4.2.  Presentation format

   The presentation format was chosen based on readability and
   international standards.  This protocol is primarily intended to be
   used by humans when debugging DNS systems.  The international
   standard ISO 8601 specifies different ways to express time and date.
   The chosen model is a common version of ISO 8601 "extended version",
   where standardised punctuation is utilised to facilitate readability.
   It retains the important property that the order of significance is
   monotonously decreasing.  The most significant value (the year) is to
   the far left, and the least significant value (seconds) is to the far
   right.  This makes it easy for humans to compare two dates.

   The alternative forms suggested are intended for programmatic use,
   and may be easier for computers to parse.

5.  IANA Considerations

   This memo includes a request to the IANA to assign an EDNS option
   code for UTCSTAMP.

6.  Security Considerations

   This protocol is intended as and aid in debugging scenarios.  If this
   protocol signals that the server's notion of current time differs
   significantly from that of the client, that is an indicator of a
   possible problem.  If the time given by the server matches that of
   the client, no knowledge has been gained.

   This protocol is not intended to be a way to obtain trustworthy time
   information.  There is no guarantee that the server responds with
   correct data, and the transport of the result is questionable.  The
   transport of data can normally be secured by using TSIG, but as a
   logical somersault, the primary intent of the protocol is to aid in
   debugging scenarios where TSIG doesn't work.  Therefore TSIG cannot
   be depended on to provide secure transport.

   This protocol SHOULD NOT be used to try obtain correct time, as there
   is no way to ensure that the information is correct.  Trusting time
   obtained with this protocol may lead to complex fault scenarios where
   incorrect time makes signature validation fail - a situation that can
   be very difficult to get out without manual intervention - or
   scenarios where replay attack may succeed.

   This protocol is primarily intended to be used to compare time
   between two DNS parties.

Liman & Sundblad          Expires May 24, 2019                  [Page 6]
Internet-Draft           EDNS(0) UTCSTAMP Option           November 2018

7.  Change History

   draft-liman-dns-utcstamp-00

          Initial version.  Released 2018-11-20.

8.  Document Timestamp

   (This is support for the author.  To be removed before publication.)

   Document Time-stamp: "2018-11-20 16:10:42 liman"

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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

9.2.  Informative References

   [RFC5001]  Austein, R., "DNS Name Server Identifier (NSID) Option",
              RFC 5001, DOI 10.17487/RFC5001, August 2007,
              <https://www.rfc-editor.org/info/rfc5001>.

Authors' Addresses

   Lars-Johan Liman
   Netnod
   Box 30194
   SE-104 25 Stockholm
   SE

   Phone: +46 8 562 860 00
   Email: liman@netnod.se
   URI:   https://www.netnod.se/

Liman & Sundblad          Expires May 24, 2019                  [Page 7]
Internet-Draft           EDNS(0) UTCSTAMP Option           November 2018

   Ragnar Sundblad
   Royal Institute of Technology
   SE-100 44 Stockholm
   SE

   Phone: +46 8 790 60 00
   Email: ragge@kth.se
   URI:   https://www.kth.se/

Liman & Sundblad          Expires May 24, 2019                  [Page 8]