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

Tim Bruijnzeels <tim@ripe.net> Thu, 07 December 2017 09:17 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 645551293D8 for <sidrops@ietfa.amsl.com>; Thu, 7 Dec 2017 01:17:01 -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 aSoq7ieFtA3C for <sidrops@ietfa.amsl.com>; Thu, 7 Dec 2017 01:16:58 -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 53D96120454 for <sidrops@ietf.org>; Thu, 7 Dec 2017 01:16:58 -0800 (PST)
Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <tim@ripe.net>) id 1eMsIZ-00019V-1h; Thu, 07 Dec 2017 10:16:56 +0100
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-199.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <tim@ripe.net>) id 1eMsIY-0003Iu-Mx; Thu, 07 Dec 2017 10:16:54 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <a1ca5abc5f21482caa634126e99c123a@XCH-RTP-011.cisco.com>
Date: Thu, 07 Dec 2017 10:16:43 +0100
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <782CCC97-4BA2-4EF0-9B99-F0D17AE10D86@ripe.net>
References: <a1ca5abc5f21482caa634126e99c123a@XCH-RTP-011.cisco.com>
To: "Roque Gagliano (rogaglia)" <rogaglia@cisco.com>
X-Mailer: Apple Mail (2.3445.4.7)
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: 784d7acfe6559f2a0b602ec6519a07195c504adb85bfda6b8dc83cbfd86b1494
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/64KbUA4ad-2mWNY5YTSPGtqBvsc>
Subject: Re: [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, 07 Dec 2017 09:17:01 -0000

Hi Roque, WG,

As I said I believe that you’re right and it should say “obsoletes”.

Co-chairs, can you initiate a call for adoption on this?

I am happy to change “updates” to “obsoletes” when adopted.

Tim




> On 6 Dec 2017, at 21:11, Roque Gagliano (rogaglia) <rogaglia@cisco.com> wrote:
> 
> Hi Tim,
> 
> IMHO, If it replaces rather than complements, it should be obsoletes.
> 
> I guess there is a formal definition somewhere.
> 
> Roque
> 
> 
> 
> 
> Sent from my Samsung Galaxy smartphone.
> 
> -------- Original message --------
> From: Tim Bruijnzeels <tim@ripe.net>
> Date: 11/30/17 14:39 (GMT+01:00)
> To: "Roque Gagliano (rogaglia)" <rogaglia@cisco.com>
> Cc: sidrops@ietf.org
> Subject: Re: [Sidrops] Document on HTTPS on TALs (update to RFC7730) - seeking adoption
> 
> 
> > On 30 Nov 2017, at 14:31, Roque Gagliano (rogaglia) <rogaglia@cisco.com> wrote:
> > 
> > Hi Tim,
> > 
> > Not sure I understand why you are “updates” RFC 7730 and not “obsoletes” RFC7730. Could you please elaborate on this decision?
> 
> I believe you’re right and it should indeed say ‘obsoletes’ - as in replaces - rather than updates (parts) of it. That said, most of the text is a straight copy of the text in 7730.
> 
> Tim
> 
> 
> > 
> > Regards,
> > Roque
> > 
> > 
> > On 30/11/17 14:02, "Sidrops on behalf of Tim Bruijnzeels" <sidrops-bounces@ietf.org on behalf of tim@ripe.net> wrote:
> > 
> >    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 
> > 
> > 
> > 
> > 
> >    _______________________________________________
> >    Sidrops mailing list
> >    Sidrops@ietf.org
> >    https://www.ietf.org/mailman/listinfo/sidrops
> > 
> > 
> > _______________________________________________
> > Sidrops mailing list
> > Sidrops@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops