idnits 2.17.1 draft-ietf-ntp-roughtime-ecosystem-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 70: '...nder is a 64 byte value. Blinder MUST...' RFC 2119 keyword, line 105: '... is RECOMMENDED that trust anchors s...' RFC 2119 keyword, line 107: '... anchors SHOULD subscribe to a zero-...' RFC 2119 keyword, line 109: '... anchors SHOULD list a wide variety ...' RFC 2119 keyword, line 111: '... SHOULD attempt to detect malfeasanc...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 21, 2021) is 1153 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-ntp-roughtime' is defined on line 120, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-ntp-roughtime-03 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. Ladd 3 Internet-Draft Cloudflare 4 Intended status: Informational M. Dansarie 5 Expires: August 25, 2021 February 21, 2021 7 Roughtime Ecosystem 8 draft-ietf-ntp-roughtime-ecosystem-00 10 Abstract 12 This document specifies the roles of Roughtime validators, clients, 13 and servers in providing a ecosystem for secure time. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 25, 2021. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Chaining in roughtime . . . . . . . . . . . . . . . . . . . . 2 51 3. Impeachement . . . . . . . . . . . . . . . . . . . . . . . . 2 52 4. Serialization of chains . . . . . . . . . . . . . . . . . . . 3 53 5. Submission API . . . . . . . . . . . . . . . . . . . . . . . 3 54 6. Viewing Reports . . . . . . . . . . . . . . . . . . . . . . . 3 55 7. Trust Anchors and Policies . . . . . . . . . . . . . . . . . 3 56 8. Normative References . . . . . . . . . . . . . . . . . . . . 3 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 3 59 1. Introduction 61 The Roughtime protocol enables servers to provide cryptographic proof 62 of the times requests were made. This enables clients to expose 63 cheating by servers. This document describes how these proofs are 64 seralized and verified, as well as APIs to access and submit reports 65 of malfeasnce in an automated manner. 67 2. Chaining in roughtime 69 Two responses are chained if the NONC field of the second is SHA- 70 512(blinder || first) where blinder is a 64 byte value. Blinder MUST 71 be generated uniformly at random to prevent tracking. The first 72 response is serialized as a roughtime message. The first response is 73 chained to the second. 75 A chain is a sequence of messages where each message is chained to 76 the one before. Every contiguous subsequence of a chain is a chain. 78 3. Impeachement 80 For each index i, let m_i denote the timestamp of the response, r_i 81 the radius around it. Then we have m_i-r_i the earliest actual time 82 at which the response could have been generated, and m_i+r_i the 83 latest actual time at which the response could have been generated. 85 If all requests are generated honestly m_i+r_i < m_{i+j}-r_{i+j} 86 holds for all indices i and positive numbers j. A failure of this 87 relation to hold demonstrates that at least one of the responses was 88 generated incorrectly. 90 The more distinct servers and responses that are mutually consistent 91 except for the questionable response, the more likey a failure of the 92 generator of the errneous response is. 94 4. Serialization of chains 96 TODO 98 5. Submission API 100 6. Viewing Reports 102 7. Trust Anchors and Policies 104 A trust anchor is any distributor of a list of trusted servers. It 105 is RECOMMENDED that trust anchors subscribe to a common public forum 106 where evidence of malfeasance may be shared and discussed. Trust 107 anchors SHOULD subscribe to a zero-tolerance policy: any generation 108 of incorrect timestamps will result in removal. To enable this trust 109 anchors SHOULD list a wide variety of servers so the removal of a 110 server does not result in operational issues for clients. Clients 111 SHOULD attempt to detect malfeasance and report it as discussed in 112 this document. 114 Because only a single Roughtime server is required for successful 115 synchronization, Roughtime does not have the incentive problems that 116 have prevented effective enforcement of discipline on the web PKI. 118 8. Normative References 120 [I-D.ietf-ntp-roughtime] 121 Malhotra, A., Langley, A., and W. Ladd, "Roughtime", 122 draft-ietf-ntp-roughtime-03 (work in progress), August 123 2020. 125 Authors' Addresses 127 Watson Ladd 128 Cloudflare 129 101 Townsend St 130 San Francisco 131 USA 133 Email: watsonbladd@gmail.com 135 Marcus Dansarie 136 Sweden 138 Email: marcus@dansarie.se 139 URI: https://orcid.org/0000-0001-9246-0263