<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc category="info" docName="draft-ietf-ntp-roughtime-ecosystem-00" ipr="trust200902">
  <front>
    <title>Roughtime Ecosystem</title>

    <author fullname="Watson Ladd" initials="W." surname="Ladd">
      <organization> Cloudflare</organization>
      <address>
        <postal>
          <street>101 Townsend St</street>
          <city>San Francisco</city>
          <region></region>
          <country>USA</country>
        </postal>
        <email>watsonbladd@gmail.com</email>
      </address>
    </author>
       <author fullname="Marcus Dansarie" initials="M." surname="Dansarie">
      <address>
        <postal>
          <street />
          <city />
          <region />
          <code />
          <country>Sweden</country>
        </postal>
        <email>marcus@dansarie.se</email>
        <uri>https://orcid.org/0000-0001-9246-0263</uri>
      </address>
    </author>

    <date year="2021" month="February" day="21"/>

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>roughtime</keyword>

    <keyword>time synchronization</keyword>

    <abstract>
      <t>
        This document specifies the roles of Roughtime validators, clients, and servers
        in providing a ecosystem for secure time.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t> The Roughtime protocol enables servers to provide cryptographic proof of the times requests were made. This enables clients to expose cheating by servers. This document describes how these proofs are seralized and verified, as well as APIs to access and submit reports of malfeasnce in an automated manner.
      </t>
    </section>
    <section title="Chaining in roughtime">
      <t>
        Two responses are chained if the NONC field of the second is
        SHA-512(blinder || first) where blinder is a 64 byte
        value. Blinder MUST be generated uniformly at random to
        prevent tracking. The first response is serialized as a
        roughtime message. The first response is chained to the second.
      </t>
      <t> A chain is a sequence of messages where each message is
      chained to the one before. Every contiguous subsequence of a
      chain is a chain.
      </t>
    </section>
    <section title="Impeachement">
      <t>
      For each index i, let m_i denote the timestamp of the response, r_i the radius
      around it. Then we have m_i-r_i the earliest actual time at which the response could
      have been generated, and m_i+r_i the latest actual time at which the response could
      have been generated.
      </t>
      <t> If all requests are generated honestly m_i+r_i &lt;
      m_{i+j}-r_{i+j} holds for all indices i and positive numbers
      j. A failure of this relation to hold demonstrates that at least one of
      the responses was generated incorrectly.</t>
      <t> The more distinct servers and responses that are mutually consistent
      except for the questionable response, the more likey a failure of the generator of the
      errneous response is.</t>
    </section>
      <section title="Serialization of chains">
        <t> TODO</t>
      </section>
      <section title="Submission API">
      </section>
      <section title="Viewing Reports">
      </section>
      <section title="Trust Anchors and Policies">
      <t>
        A trust anchor is any distributor of a list of trusted servers. It is
        RECOMMENDED that trust anchors subscribe to a common public forum where
        evidence of malfeasance may be shared and discussed. Trust anchors
        SHOULD subscribe to a zero-tolerance policy: any generation of incorrect
        timestamps will result in removal. To enable this trust anchors SHOULD
        list a wide variety of servers so the removal of a server does not
        result in operational issues for clients. Clients SHOULD attempt to
        detect malfeasance and report it as discussed in this document.
      </t>
      <t>
        Because only a single Roughtime server is required for successful
        synchronization, Roughtime does not have the incentive problems that
        have prevented effective enforcement of discipline on the web PKI.
      </t>
    </section>
  </middle>
  
    <back>
      <references title="Normative References">
        <?rfc include="reference.I-D.ietf-ntp-roughtime"?>
      </references>
    </back>
</rfc>
