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 protected] wrote: > > > 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/ > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
