Subject: [sidr] I-D Action: draft-ietf-sidr-delta-protocol-03.txt

From: [email-masked]
Date: Thu, 07 Jul 2016 08:03:00 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Inter-Domain Routing of the IETF.

        Title           : RPKI Repository Delta Protocol
        Authors         : Tim Bruijnzeels
                          Oleg Muravskiy
                          Bryan Weber
                          Rob Austein
	Filename        : draft-ietf-sidr-delta-protocol-03.txt
	Pages           : 18
	Date            : 2016-07-07

Abstract:
   In the Resource Public Key Infrastructure (RPKI), certificate
   authorities publish certificates, including end entity certificates,
   Certificate Revocation Lists (CRL), and RPKI signed objects to
   repositories.  Relying Parties (RP) retrieve the published
   information from those repositories.  This document specifies a delta
   protocol which provides relying parties with a mechanism to query a
   repository for incremental updates, thus enabling the RP to keep its
   state in sync with the repository.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-delta-protocol-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 7 Jul 2016 17:09:08 +0200

Dear WG,

The biggest change in this version is the addition of a section on HTTPS (see below).

We can take 15 minutes in Berlin to talk about this specifically, but in the mind of this author we can put the HTTPS discussions related to this document to rest with this addition. Obviously, if you feel different, speak up ;)

Thanks
Tim

--

4.  HTTPS considerations

   It is RECOMMENDED that Relying Parties and Publication Servers follow
   the Best Current Practices outlined in [RFC7525] on the use of HTTP
   over TLS (https).

   Note that a Man-in-the-Middle (MITM) cannot produce validly signed
   RPKI data, but they can perform withhold or replay attacks targeting
   an RP, and keep the RP from learning about changes in the RPKI.
   Because of this RPs SHOULD do TLS certificate and host name
   validation when they fetch from an RRDP Publication Server

   However, such validation issues are often due to configuration
   errors, or a lack of a common TLS trust anchor.  In these cases it
   would be better that the RP retrieves the signed RPKI data
   regardless, and performs validation on it.

   Therefore RPs SHOULD log any TLS certificate or host name validation
   issues they find, so that an operator can investigate the cause.  But
   the RP SHOULD continue to retrieve the data.  The RP MAY choose to
   log this issue only when fetching the notification update file, but
   not when it subsequently fetches snapshot or delta files from the
   same host.  Furthermore the RP MAY provide a way for operators to
   accept untrusted connections for a given host, after the cause has
   been identified.

> On 07 Jul 2016, at 17:03, [email-masked] wrote:
> 
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr