[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/