idnits 2.17.1 draft-ietf-ntp-roughtime-ecosystem-01.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 69: '...nder is a 64 byte value. Blinder MUST...' RFC 2119 keyword, line 104: '... is RECOMMENDED that trust anchors s...' RFC 2119 keyword, line 106: '... anchors SHOULD subscribe to a zero-...' RFC 2119 keyword, line 108: '... anchors SHOULD list a wide variety ...' RFC 2119 keyword, line 110: '... 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 (September 2021) is 953 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-ntp-roughtime' is defined on line 119, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-ntp-roughtime-05 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: 18 March 2022 September 2021 7 Roughtime Ecosystem 8 draft-ietf-ntp-roughtime-ecosystem-01 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 5 March 2022. 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 (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Chaining in roughtime . . . . . . . . . . . . . . . . . . . . 2 50 3. Impeachement . . . . . . . . . . . . . . . . . . . . . . . . 2 51 4. Serialization of chains . . . . . . . . . . . . . . . . . . . 3 52 5. Submission API . . . . . . . . . . . . . . . . . . . . . . . 3 53 6. Viewing Reports . . . . . . . . . . . . . . . . . . . . . . . 3 54 7. Trust Anchors and Policies . . . . . . . . . . . . . . . . . 3 55 8. Normative References . . . . . . . . . . . . . . . . . . . . 3 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 3 58 1. Introduction 60 The Roughtime protocol enables servers to provide cryptographic proof 61 of the times requests were made. This enables clients to expose 62 cheating by servers. This document describes how these proofs are 63 seralized and verified, as well as APIs to access and submit reports 64 of malfeasnce in an automated manner. 66 2. Chaining in roughtime 68 Two responses are chained if the NONC field of the second is SHA- 69 512(blinder || first) where blinder is a 64 byte value. Blinder MUST 70 be generated uniformly at random to prevent tracking. The first 71 response is serialized as a roughtime message. The first response is 72 chained to the second. 74 A chain is a sequence of messages where each message is chained to 75 the one before. Every contiguous subsequence of a chain is a chain. 77 3. Impeachement 79 For each index i, let m_i denote the timestamp of the response, r_i 80 the radius around it. Then we have m_i-r_i the earliest actual time 81 at which the response could have been generated, and m_i+r_i the 82 latest actual time at which the response could have been generated. 84 If all requests are generated honestly m_i+r_i < m_{i+j}-r_{i+j} 85 holds for all indices i and positive numbers j. A failure of this 86 relation to hold demonstrates that at least one of the responses was 87 generated incorrectly. 89 The more distinct servers and responses that are mutually consistent 90 except for the questionable response, the more likey a failure of the 91 generator of the errneous response is. 93 4. Serialization of chains 95 TODO 97 5. Submission API 99 6. Viewing Reports 101 7. Trust Anchors and Policies 103 A trust anchor is any distributor of a list of trusted servers. It 104 is RECOMMENDED that trust anchors subscribe to a common public forum 105 where evidence of malfeasance may be shared and discussed. Trust 106 anchors SHOULD subscribe to a zero-tolerance policy: any generation 107 of incorrect timestamps will result in removal. To enable this trust 108 anchors SHOULD list a wide variety of servers so the removal of a 109 server does not result in operational issues for clients. Clients 110 SHOULD attempt to detect malfeasance and report it as discussed in 111 this document. 113 Because only a single Roughtime server is required for successful 114 synchronization, Roughtime does not have the incentive problems that 115 have prevented effective enforcement of discipline on the web PKI. 117 8. Normative References 119 [I-D.ietf-ntp-roughtime] 120 Malhotra, A., Langley, A., Ladd, W., and M. Dansarie, 121 "Roughtime", Work in Progress, Internet-Draft, draft-ietf- 122 ntp-roughtime-05, 24 May 2021, 123 . 126 Authors' Addresses 128 Watson Ladd 129 Cloudflare 130 101 Townsend St 131 San Francisco, 132 United States of America 134 Email: watsonbladd@gmail.com 136 Marcus Dansarie 137 Sweden 139 Email: marcus@dansarie.se 140 URI: https://orcid.org/0000-0001-9246-0263