[Sidrops] Signed TAL

Tim Bruijnzeels <tim@ripe.net> Wed, 16 August 2017 14:10 UTC

Return-Path: <tim@ripe.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36501252BA for <sidrops@ietfa.amsl.com>; Wed, 16 Aug 2017 07:10:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 F0LXEchMz509 for <sidrops@ietfa.amsl.com>; Wed, 16 Aug 2017 07:10:51 -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 786001241FC for <sidrops@ietf.org>; Wed, 16 Aug 2017 07:10:51 -0700 (PDT)
Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <tim@ripe.net>) id 1dhz21-000C8z-9u for sidrops@ietf.org; Wed, 16 Aug 2017 16:10:50 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-102.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <tim@ripe.net>) id 1dhz21-0005vI-49; Wed, 16 Aug 2017 16:10:49 +0200
From: Tim Bruijnzeels <tim@ripe.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 16 Aug 2017 16:10:48 +0200
Message-Id: <0439F08A-FA21-42C5-A22A-3208F32F712D@ripe.net>
To: sidrops@ietf.org
X-Mailer: Apple Mail (2.3273)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: -------
X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719e9b2fae579c131bbf3bb93aef3dcb336
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Vlsh5hvbtkkE4mh-QF9hfp53FcE>
Subject: [Sidrops] Signed TAL
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Aug 2017 14:10:53 -0000

Dear working group,

Following the discussion at the microphone at IETF99, we have uploaded an updated version of the signed TAL document:
https://datatracker.ietf.org/doc/draft-tbruijnzeels-sidrops-signed-tal/

Two issues were brought up:

1) magic numbers used for staging periods

We removed the time after which a Signed TAL should be removed - opting instead for a model where a TA can publish what it believes should be considered its current TAL at all times. RPs that have already learned this TAL can just ignore it. 

We kept 24 hour staging period in key rolls (section 6.2). I don’t think we strictly need it to be honest, but it is in-line with how things are done in CA key rolls (RFC6489).

We also kept a 24 hour period when withdrawing a publication point. Although there is no explicit guarantee about how frequently RPs re-sync, most RPs do use a much high frequency than this. The 24 hour value is in-line with key rolls, and should be more than enough time.

2) Lessons from RFC5011 (Automated Updates of DNS Security (DNSSEC) Trust Anchors)

As I read the mechanisms described here are not applicable to RPKI because we do not have explicit TTLs defined, and we do not have the concept of Trust Anchor Sets. Therefore we still propose a model based on the existing TAL format that we believe is simpler.


We would now like to ask for working group adoption of this document.

Kind regards

Tim