Internet DRAFT - draft-linus-trans-gossip
draft-linus-trans-gossip
TRANS L. Nordberg
Internet-Draft NORDUnet
Intended status: Experimental October 27, 2014
Expires: April 30, 2015
Transparency Gossip
draft-linus-trans-gossip-00
Abstract
This document describes Transparency Gossip, a gossip service for
Certificate Transparency and other transparency systems.
Gossip peers connect to a gossip service and start sending and
receiving gossip messages. Gossip transports register with a gossip
service and transfer messages between other gossip services and local
peers.
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 http://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 April 30, 2015.
Copyright Notice
Copyright (c) 2014 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
(http://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
Nordberg Expires April 30, 2015 [Page 1]
Internet-Draft Transparency Gossip October 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Transports . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Defined transports . . . . . . . . . . . . . . . . . . . 4
5. Message format and processing . . . . . . . . . . . . . . . . 4
5.1. Validation of received messages . . . . . . . . . . . . . 4
6. Gossip service protocol . . . . . . . . . . . . . . . . . . . 5
6.1. AUTHENTICATE-REQUEST . . . . . . . . . . . . . . . . . . 5
6.2. AUTHENTICATE-RESPONSE . . . . . . . . . . . . . . . . . . 5
6.3. ENUMERATE-TRANSPORTS-REQUEST . . . . . . . . . . . . . . 5
6.4. ENUMERATE-TRANSPORTS-RESPONSE . . . . . . . . . . . . . . 5
6.5. GOSSIP-MSG . . . . . . . . . . . . . . . . . . . . . . . 5
6.5.1. Components of a message . . . . . . . . . . . . . . . 6
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. CT clients . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security considerations . . . . . . . . . . . . . . . . . . . 8
9. Open questions . . . . . . . . . . . . . . . . . . . . . . . 9
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Regarding scope, gossiping in any Transparency system, such as
Certificate Transparency [RFC6962], can be divided in two distinct
pieces; a general gossip protocol and the specifics for the
Transparency system at hand.
A general gossip protocol defines a message format, validation rules
for messages and a mechanism for plugging in different transport
protocols.
The specifics for a Transparency system include which types of data
to gossip about, with whom to gossip, what particular log data to
gossip about and how to act on gossip. The last two, what particular
data objects to send and how to deal with data objects received fall
into the category of strategy or policy and should probably not be
standardised.
Nordberg Expires April 30, 2015 [Page 2]
Internet-Draft Transparency Gossip October 2014
The scope for this document is a general gossip protocol.
Terminology used in this document:
peer - Actors gossiping about log data. They are the endpoints in a
global gossiping system, deciding what to send and how to treat
gossip from other peers.
transport - Network programs connecting the local gossiping system to
other gossiping systems on the internet.
gossip service - A server connecting local peers and transports.
2. Problem
Public append-only untrusted logs have to be monitored for
consistency, i.e. that they don't break their promise of not
rewriting history. Monitors and other log clients need to exchange
information about monitored logs in order to be able to detect a
partitioning attack.
A partitioning attack is when a log serves different views of the log
to different clients. Each client would be able to verify the
append-only attribute of the log while being the only client seeing
this particular view.
The problem of disseminating information about log data that
(locally) has been confirmed to be illegitimate is hard to deal with
because of privacy implications for log clients and is not addressed
by this document specifically. The gossip message format specified
can still be useful for this task though.
3. Overview
This document defines a gossip service and a gossip message format
used by peers and transports to exchange data about logs over the
internet.
Separating the gossiping actors, called peers, from the actual
sending and receiving of gossip messages makes it possible to make
various transport mechanisms available without having to add
knowledge about transport protocols to peers.
The gossip service connects peers to one or more transports
responsible for communicating with other gossip services with the
help of specific internet protocols such as HTTP.
Nordberg Expires April 30, 2015 [Page 3]
Internet-Draft Transparency Gossip October 2014
4. Transports
A gossip transport is responsible for sending and receiving gossip
messages over a specific protocol, like HTTP or XMPP.
The way a transport uses its external protocol to convey gossip
messages is specified by the transport itself and out of scope for
this document.
A transport registers with a gossip service, either by being compiled
into the service, being dynamically loaded into it or by connecting
to it over a socket endpoint, local or remote. In the case of a
connecting transport, the transport has to authenticate with the
service by sending a shared secret in an Section 6.1 message.
4.1. Defined transports
o gossip-transport-https = "gossip-transport-https"
o gossip-transport-tls = TBD
o gossip-transport-xmpp = TBD
o gossip-transport-dns = TBD
o gossip-transport-tor = TBD
o gossip-transport-webrtc = TBD
5. Message format and processing
The message format is described in Section 6.5.
5.1. Validation of received messages
Peers MUST validate all gossip messages, incoming and outgoing, by
verifying GOSSIP-MSG 'gossip-data' according to the rules of the log
indicated by 'log-id'. Messages with an unknown log id or which
signature don't check out correctly MUST be silently discarded.
Transports MAY validate gossip messages before forwarding them.
Peers MAY respond to an incoming message by sending one or more
messages back to the transport it was received from.
[FIXME should this document stick to specifying what the gossip
service does and leave peers and transports alone?]
Nordberg Expires April 30, 2015 [Page 4]
Internet-Draft Transparency Gossip October 2014
6. Gossip service protocol
All messages are ASCII messages in S-expression format sent over a
reliable data stream.
TODO: change to JSON object [RFC7159] encoding since that's used in
CT
6.1. AUTHENTICATE-REQUEST
AUTHENTICATE-REQUEST messages are sent from transports to the gossip
service.
o command = "gossip-authenticate-request-0"
o shared-secret = base64-encoded string
6.2. AUTHENTICATE-RESPONSE
AUTHENTICATE-RESPONSE messages are sent from the gossip service to a
transport as a response to an AUTHENTICATE-REQUEST message.
o command = "gossip-authenticate-response-0"
o response = "ok" | "bad-auth"
6.3. ENUMERATE-TRANSPORTS-REQUEST
ENUMERATE-TRANSPORTS-REQUEST messages are sent from peers to the
gossip service.
o command = "gossip-enumerate-transports-request-0"
6.4. ENUMERATE-TRANSPORTS-RESPONSE
ENUMERATE-TRANSPORTS-RESPONSE messages are sent from the gossip
service to a peer in response to an ENUMERATE-TRANSPORTS-REQUEST
message.
o command = "gossip-enumerate-transports-response-0"
o transports = list of registered transports
6.5. GOSSIP-MSG
Gossip messages are sent by peers and transports to the gossip
service.
Nordberg Expires April 30, 2015 [Page 5]
Internet-Draft Transparency Gossip October 2014
The gossip service MUST forward messages from peers to all registered
transports given in 'destination' of the message.
The gossip service MUST forward messages from transports to all
connected peers.
An outgoing message is sent by a peer and received by a transport.
An incoming message is sent by a transport and received by one or
more peers.
Example of an outgoing message, i.e. sent from a peer and received by
a transport:
(gossip-msg
(command gossip-msg-0)
(destination (gossip-transport-https gossip-transport-tbd))
(timestamp 1414396810000)
(log-id
467a28a27c206a26cdf7b36cc93e8c598e93592ef49ad3a8dc523a35e1f4bc0c)
(gossip-data b3V0Z29pbmcgZ29zc2lwIGRhdGEK))
Example of an incoming message, i.e. sent from a transport and
received by one or more peers:
(gossip-msg
(command gossip-msg-0)
(source gossip-transport-https)
(timestamp 1414396811000)
(log-id
467a28a27c206a26cdf7b36cc93e8c598e93592ef49ad3a8dc523a35e1f4bc0c)
(gossip-data aW5jb21pbmcgZ29zc2lwIGRhdGEK))
6.5.1. Components of a message
o command = "gossip-msg-0"
o timestamp = 64bit integer in decimal
NTP time when the message was received by the gossip service, in
milliseconds since the epoch
o destination = transports
destination specifies which transport(s) to send an outgoing message
over
Nordberg Expires April 30, 2015 [Page 6]
Internet-Draft Transparency Gossip October 2014
destination is meaningful only in outgoing messages and MUST be
ignored by peers
transports = list of 'transport'
transport = string | "all"
transport is a string containing the name of a registered transport
or the special string "all"
transport "all" means that the message should be sent to all
registered transports
o source = transport | ""
an incoming message has source set to the transport it came in over
source is meaningful only in incoming messages and MUST be ignored by
transports
o log-id = SHA-256 hash of a log's public key, 32 octets
the log id of the transparency log gossiped about
o gossip-data = opaque string, base64-encoded
gossip-data exact contents depend on what kind of data is being
gossiped but MUST include a signature made by the log indicated by
'log-id'.
7. Examples
This section describes how a gossiping system could be implemented
for Certificate Transparency.
7.1. CT clients
Nordberg Expires April 30, 2015 [Page 7]
Internet-Draft Transparency Gossip October 2014
web-browser ct-monitor <-- gossip peer
\ /
gossip-daemon <-- gossip service
/ \
socket-transport https-transport <-- gossip transport
| |
web-browser[0] tls-lib
[0] same instance as the gossip peer "web-browser"
web-server <-- gossip peer
|
gossip-daemon <-- gossip service
|
socket-transport <-- gossip transport
|
web-server[1]
[1] same instance as the gossip peer "web-server"
The daemon listens to two separate sockets, one for peers and one for
transports.
Peers (top row) connect to the daemon client socket and send and
receive gossip messages. A message contains one or more transport
ids and gossip data. The transport ids in outgoing messages are used
to select which transport(s) the gossip data is allowed to be sent
over. Transport ids in incoming messages reflect which transport
they were received over.
Transports are either built into the daemon or registered with the
daemon by connecting to the daemon transport socket and identifying
itself with a string (the transport id). This registering process
will require authentication.
(A less complex alternative to such a registering scheme would be to
have built-in transports only, one of which is "echo". Adding a tag
(think IMAP) to messages would make it possible for peers to match
sent and received messages, making an echo transport useful for
programs like web browsers which already have the transport ready for
use.)
8. Security considerations
o TODO: sending of sensitive data to the gossip service
o TODO: protection against bad actors
Nordberg Expires April 30, 2015 [Page 8]
Internet-Draft Transparency Gossip October 2014
* flooding attacks flushing gossip pools [belongs in *T-specific
specs?]
o TODO: gossiping messages being blocked
o TODO: transports authenticating with gossip services
9. Open questions
o remove transports lacking a draft?
10. IANA considerations
TBD
11. Contributors
The author would like to thank Ben Laurie for the idea with a gossip
daemon.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014.
12.2. Informative References
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, June 2013.
Author's Address
Linus Nordberg
NORDUnet
Email: linus@nordu.net
Nordberg Expires April 30, 2015 [Page 9]