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, internet-dra...@ietf.org 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
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
