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

Tim Bruijnzeels <tim@ripe.net> Thu, 07 July 2016 15:09 UTC

Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1BB12D7DA; Thu, 7 Jul 2016 08:09:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7y8IPBBPmbk; Thu, 7 Jul 2016 08:09:13 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB70512D7C8; Thu, 7 Jul 2016 08:09:12 -0700 (PDT)
Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <tim@ripe.net>) id 1bLAvN-0009BY-26; Thu, 07 Jul 2016 17:09:11 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-6.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1bLAvM-00070T-RP; Thu, 07 Jul 2016 17:09:08 +0200
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset="us-ascii"
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <20160707150300.23729.59924.idtracker@ietfa.amsl.com>
Date: Thu, 07 Jul 2016 17:09:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <77A206F0-DFF5-4DEF-B338-8A0C5D4C9A64@ripe.net>
References: <20160707150300.23729.59924.idtracker@ietfa.amsl.com>
To: internet-drafts@ietf.org
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ----------
X-RIPE-Spam-Report: Spam Total Points: -10.7 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719a62c02fad2e8dea7e42b856adac49ede
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/Ms9Pl6WkPlFeFicsDMoz3heDYWQ>
Cc: sidr@ietf.org, i-d-announce@ietf.org
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-delta-protocol-03.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jul 2016 15:09:15 -0000

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-drafts@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