[Sidrops] Document on HTTPS on TALs (update to RFC7730) - seeking adoption

Tim Bruijnzeels <tim@ripe.net> Thu, 30 November 2017 13:02 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 A7CA21200F3 for <sidrops@ietfa.amsl.com>; Thu, 30 Nov 2017 05:02:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] 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 1p8aKCtk7krd for <sidrops@ietfa.amsl.com>; Thu, 30 Nov 2017 05:02:17 -0800 (PST)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 6D5B81293D6 for <sidrops@ietf.org>; Thu, 30 Nov 2017 05:02:14 -0800 (PST)
Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <tim@ripe.net>) id 1eKOTk-0004CL-2Z for sidrops@ietf.org; Thu, 30 Nov 2017 14:02:13 +0100
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-244.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 1eKOTj-0003B1-Tr; Thu, 30 Nov 2017 14:02:11 +0100
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: Thu, 30 Nov 2017 14:02:11 +0100
Message-Id: <56EB3EEC-A49A-41FE-84FD-42DEF814D333@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 -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071923dea218e47e047c9d2bbc8dcd3c6dc9
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/kBpaG0x_ffD-eOByEfQHPBl-6ZA>
Subject: [Sidrops] Document on HTTPS on TALs (update to RFC7730) - seeking adoption
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: Thu, 30 Nov 2017 13:02:18 -0000

Dear working group,

As discussed at IETF99, and in informal talks with some of you, we would like to update the TAL format (RFC7730) to allow HTTPS.

I worked with George Michaelson on an update. Because RFC7730 contains quite a few references to ‘rsync’ we felt that a new document updating 7730 would be more readable and appropriate then document updating many small bits of text. The -00 version of this document is here: https://tools.ietf.org/id/draft-tbruijnzeels-sidrops-https-tal-00.txt

We would like to ask the co-chairs to make a call to the working group for adoption.

In short this update will allow the use of HTTPS instead of, or in addition to, rsync on TALs. Other than that it contains a section on TLS verification similar to the one that is included in the delta protocol (RFC8182) - essentially saying that TLS verification is done on a best effort basis - and warnings should be uttered in case of issues - but because the TA certificate can still be validated cryptographically it MUST still be downloaded. Note that it is a matter of local policy whether an RP chooses to use different locations if they are present, but we may want to add some text here recommending the use of HTTPS URIs that have no TLS verification issues over ones that do - at this point I am not sure that this is needed, or would need to be normative text, but I think it would be good to have some discussion on this.

For the record, I am not sure what is customary in these cases of relatively small updates to existing standards. But, I tried to approach the other authors of RFC7730 (George is already one of them) and ask them whether they want to remain authors on this new document. Geoff Huston indicated that he does not need to be on the list, but has no objections to us doing this work. I have not seen responses from Sam Weiler or Stephen Kent - it is also possible that they missed my message. In any case we have no objections if they do wish to stay on as authors, but for now they are not on the list of the document linked above.

Kind regards,

Tim