idnits 2.17.1 draft-linus-trans-gossip-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 322 has weird spacing: '...browser ct-m...' == Line 326 has weird spacing: '...ansport http...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 27, 2014) is 3469 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 330 -- Looks like a reference, but probably isn't: '1' on line 340 == Unused Reference: 'RFC2119' is defined on line 393, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRANS L. Nordberg 3 Internet-Draft NORDUnet 4 Intended status: Experimental October 27, 2014 5 Expires: April 30, 2015 7 Transparency Gossip 8 draft-linus-trans-gossip-00 10 Abstract 12 This document describes Transparency Gossip, a gossip service for 13 Certificate Transparency and other transparency systems. 15 Gossip peers connect to a gossip service and start sending and 16 receiving gossip messages. Gossip transports register with a gossip 17 service and transfer messages between other gossip services and local 18 peers. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 30, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Transports . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Defined transports . . . . . . . . . . . . . . . . . . . 4 59 5. Message format and processing . . . . . . . . . . . . . . . . 4 60 5.1. Validation of received messages . . . . . . . . . . . . . 4 61 6. Gossip service protocol . . . . . . . . . . . . . . . . . . . 5 62 6.1. AUTHENTICATE-REQUEST . . . . . . . . . . . . . . . . . . 5 63 6.2. AUTHENTICATE-RESPONSE . . . . . . . . . . . . . . . . . . 5 64 6.3. ENUMERATE-TRANSPORTS-REQUEST . . . . . . . . . . . . . . 5 65 6.4. ENUMERATE-TRANSPORTS-RESPONSE . . . . . . . . . . . . . . 5 66 6.5. GOSSIP-MSG . . . . . . . . . . . . . . . . . . . . . . . 5 67 6.5.1. Components of a message . . . . . . . . . . . . . . . 6 68 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7.1. CT clients . . . . . . . . . . . . . . . . . . . . . . . 7 70 8. Security considerations . . . . . . . . . . . . . . . . . . . 8 71 9. Open questions . . . . . . . . . . . . . . . . . . . . . . . 9 72 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 73 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 12.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 Regarding scope, gossiping in any Transparency system, such as 82 Certificate Transparency [RFC6962], can be divided in two distinct 83 pieces; a general gossip protocol and the specifics for the 84 Transparency system at hand. 86 A general gossip protocol defines a message format, validation rules 87 for messages and a mechanism for plugging in different transport 88 protocols. 90 The specifics for a Transparency system include which types of data 91 to gossip about, with whom to gossip, what particular log data to 92 gossip about and how to act on gossip. The last two, what particular 93 data objects to send and how to deal with data objects received fall 94 into the category of strategy or policy and should probably not be 95 standardised. 97 The scope for this document is a general gossip protocol. 99 Terminology used in this document: 101 peer - Actors gossiping about log data. They are the endpoints in a 102 global gossiping system, deciding what to send and how to treat 103 gossip from other peers. 105 transport - Network programs connecting the local gossiping system to 106 other gossiping systems on the internet. 108 gossip service - A server connecting local peers and transports. 110 2. Problem 112 Public append-only untrusted logs have to be monitored for 113 consistency, i.e. that they don't break their promise of not 114 rewriting history. Monitors and other log clients need to exchange 115 information about monitored logs in order to be able to detect a 116 partitioning attack. 118 A partitioning attack is when a log serves different views of the log 119 to different clients. Each client would be able to verify the 120 append-only attribute of the log while being the only client seeing 121 this particular view. 123 The problem of disseminating information about log data that 124 (locally) has been confirmed to be illegitimate is hard to deal with 125 because of privacy implications for log clients and is not addressed 126 by this document specifically. The gossip message format specified 127 can still be useful for this task though. 129 3. Overview 131 This document defines a gossip service and a gossip message format 132 used by peers and transports to exchange data about logs over the 133 internet. 135 Separating the gossiping actors, called peers, from the actual 136 sending and receiving of gossip messages makes it possible to make 137 various transport mechanisms available without having to add 138 knowledge about transport protocols to peers. 140 The gossip service connects peers to one or more transports 141 responsible for communicating with other gossip services with the 142 help of specific internet protocols such as HTTP. 144 4. Transports 146 A gossip transport is responsible for sending and receiving gossip 147 messages over a specific protocol, like HTTP or XMPP. 149 The way a transport uses its external protocol to convey gossip 150 messages is specified by the transport itself and out of scope for 151 this document. 153 A transport registers with a gossip service, either by being compiled 154 into the service, being dynamically loaded into it or by connecting 155 to it over a socket endpoint, local or remote. In the case of a 156 connecting transport, the transport has to authenticate with the 157 service by sending a shared secret in an Section 6.1 message. 159 4.1. Defined transports 161 o gossip-transport-https = "gossip-transport-https" 163 o gossip-transport-tls = TBD 165 o gossip-transport-xmpp = TBD 167 o gossip-transport-dns = TBD 169 o gossip-transport-tor = TBD 171 o gossip-transport-webrtc = TBD 173 5. Message format and processing 175 The message format is described in Section 6.5. 177 5.1. Validation of received messages 179 Peers MUST validate all gossip messages, incoming and outgoing, by 180 verifying GOSSIP-MSG 'gossip-data' according to the rules of the log 181 indicated by 'log-id'. Messages with an unknown log id or which 182 signature don't check out correctly MUST be silently discarded. 184 Transports MAY validate gossip messages before forwarding them. 186 Peers MAY respond to an incoming message by sending one or more 187 messages back to the transport it was received from. 189 [FIXME should this document stick to specifying what the gossip 190 service does and leave peers and transports alone?] 192 6. Gossip service protocol 194 All messages are ASCII messages in S-expression format sent over a 195 reliable data stream. 197 TODO: change to JSON object [RFC7159] encoding since that's used in 198 CT 200 6.1. AUTHENTICATE-REQUEST 202 AUTHENTICATE-REQUEST messages are sent from transports to the gossip 203 service. 205 o command = "gossip-authenticate-request-0" 207 o shared-secret = base64-encoded string 209 6.2. AUTHENTICATE-RESPONSE 211 AUTHENTICATE-RESPONSE messages are sent from the gossip service to a 212 transport as a response to an AUTHENTICATE-REQUEST message. 214 o command = "gossip-authenticate-response-0" 216 o response = "ok" | "bad-auth" 218 6.3. ENUMERATE-TRANSPORTS-REQUEST 220 ENUMERATE-TRANSPORTS-REQUEST messages are sent from peers to the 221 gossip service. 223 o command = "gossip-enumerate-transports-request-0" 225 6.4. ENUMERATE-TRANSPORTS-RESPONSE 227 ENUMERATE-TRANSPORTS-RESPONSE messages are sent from the gossip 228 service to a peer in response to an ENUMERATE-TRANSPORTS-REQUEST 229 message. 231 o command = "gossip-enumerate-transports-response-0" 233 o transports = list of registered transports 235 6.5. GOSSIP-MSG 237 Gossip messages are sent by peers and transports to the gossip 238 service. 240 The gossip service MUST forward messages from peers to all registered 241 transports given in 'destination' of the message. 243 The gossip service MUST forward messages from transports to all 244 connected peers. 246 An outgoing message is sent by a peer and received by a transport. 248 An incoming message is sent by a transport and received by one or 249 more peers. 251 Example of an outgoing message, i.e. sent from a peer and received by 252 a transport: 254 (gossip-msg 255 (command gossip-msg-0) 256 (destination (gossip-transport-https gossip-transport-tbd)) 257 (timestamp 1414396810000) 258 (log-id 259 467a28a27c206a26cdf7b36cc93e8c598e93592ef49ad3a8dc523a35e1f4bc0c) 260 (gossip-data b3V0Z29pbmcgZ29zc2lwIGRhdGEK)) 262 Example of an incoming message, i.e. sent from a transport and 263 received by one or more peers: 265 (gossip-msg 266 (command gossip-msg-0) 267 (source gossip-transport-https) 268 (timestamp 1414396811000) 269 (log-id 270 467a28a27c206a26cdf7b36cc93e8c598e93592ef49ad3a8dc523a35e1f4bc0c) 271 (gossip-data aW5jb21pbmcgZ29zc2lwIGRhdGEK)) 273 6.5.1. Components of a message 275 o command = "gossip-msg-0" 277 o timestamp = 64bit integer in decimal 279 NTP time when the message was received by the gossip service, in 280 milliseconds since the epoch 282 o destination = transports 284 destination specifies which transport(s) to send an outgoing message 285 over 286 destination is meaningful only in outgoing messages and MUST be 287 ignored by peers 289 transports = list of 'transport' 291 transport = string | "all" 293 transport is a string containing the name of a registered transport 294 or the special string "all" 296 transport "all" means that the message should be sent to all 297 registered transports 299 o source = transport | "" 301 an incoming message has source set to the transport it came in over 303 source is meaningful only in incoming messages and MUST be ignored by 304 transports 306 o log-id = SHA-256 hash of a log's public key, 32 octets 308 the log id of the transparency log gossiped about 310 o gossip-data = opaque string, base64-encoded 312 gossip-data exact contents depend on what kind of data is being 313 gossiped but MUST include a signature made by the log indicated by 314 'log-id'. 316 7. Examples 318 This section describes how a gossiping system could be implemented 319 for Certificate Transparency. 321 7.1. CT clients 322 web-browser ct-monitor <-- gossip peer 323 \ / 324 gossip-daemon <-- gossip service 325 / \ 326 socket-transport https-transport <-- gossip transport 327 | | 328 web-browser[0] tls-lib 330 [0] same instance as the gossip peer "web-browser" 332 web-server <-- gossip peer 333 | 334 gossip-daemon <-- gossip service 335 | 336 socket-transport <-- gossip transport 337 | 338 web-server[1] 340 [1] same instance as the gossip peer "web-server" 342 The daemon listens to two separate sockets, one for peers and one for 343 transports. 345 Peers (top row) connect to the daemon client socket and send and 346 receive gossip messages. A message contains one or more transport 347 ids and gossip data. The transport ids in outgoing messages are used 348 to select which transport(s) the gossip data is allowed to be sent 349 over. Transport ids in incoming messages reflect which transport 350 they were received over. 352 Transports are either built into the daemon or registered with the 353 daemon by connecting to the daemon transport socket and identifying 354 itself with a string (the transport id). This registering process 355 will require authentication. 357 (A less complex alternative to such a registering scheme would be to 358 have built-in transports only, one of which is "echo". Adding a tag 359 (think IMAP) to messages would make it possible for peers to match 360 sent and received messages, making an echo transport useful for 361 programs like web browsers which already have the transport ready for 362 use.) 364 8. Security considerations 366 o TODO: sending of sensitive data to the gossip service 368 o TODO: protection against bad actors 369 * flooding attacks flushing gossip pools [belongs in *T-specific 370 specs?] 372 o TODO: gossiping messages being blocked 374 o TODO: transports authenticating with gossip services 376 9. Open questions 378 o remove transports lacking a draft? 380 10. IANA considerations 382 TBD 384 11. Contributors 386 The author would like to thank Ben Laurie for the idea with a gossip 387 daemon. 389 12. References 391 12.1. Normative References 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, March 1997. 396 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 397 Interchange Format", RFC 7159, March 2014. 399 12.2. Informative References 401 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 402 Transparency", RFC 6962, June 2013. 404 Author's Address 406 Linus Nordberg 407 NORDUnet 409 Email: linus@nordu.net