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

Tim Bruijnzeels <tim@ripe.net> Mon, 22 January 2018 10:43 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 D64FA1241FC; Mon, 22 Jan 2018 02:43:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 K0rNCXL1YOOI; Mon, 22 Jan 2018 02:43:57 -0800 (PST)
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 A385C1201F8; Mon, 22 Jan 2018 02:43:57 -0800 (PST)
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 1edZZz-0009P1-5Q; Mon, 22 Jan 2018 11:43:56 +0100
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-180.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 1edZZz-0002Xe-1R; Mon, 22 Jan 2018 11:43:55 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <1F0086D3-A2C4-4329-8A1C-8338FAE5ECC9@cisco.com>
Date: Mon, 22 Jan 2018 11:43:54 +0100
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8E2DC236-A63E-4139-AF67-D2489F0CB3A6@ripe.net>
References: <a1ca5abc5f21482caa634126e99c123a@XCH-RTP-011.cisco.com> <782CCC97-4BA2-4EF0-9B99-F0D17AE10D86@ripe.net> <1F0086D3-A2C4-4329-8A1C-8338FAE5ECC9@cisco.com>
To: sidrops-chairs@ietf.org
X-Mailer: Apple Mail (2.3445.5.20)
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 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719a504e141666e6d966f62c48a57d35e50
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/x_9J2TY23yYwZG1rZ_aTRv5qcak>
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: Mon, 22 Jan 2018 10:44:00 -0000

Dear co-chairs,

Can I ask for an official call for adoption of this item:
https://tools.ietf.org/id/draft-tbruijnzeels-sidrops-https-tal-00.txt

When adopted, we can include the change that Roque suggested and make it “obsoletes” RFC7730, rather than updates - it’s a self-contained document for readability, though most of the text is straight out of RFC7730. Or I can spin up a -01 if it is needed for process..

Thanks
Tim





> On 7 Dec 2017, at 12:37, Roque Gagliano (rogaglia) <rogaglia@cisco.com> wrote:
> 
> I support adoption with this change.
> 
> Roque
> 
> 
> 
> 
> On 07/12/17 10:17, "Tim Bruijnzeels" <tim@ripe.net> wrote:
> 
>    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
> 
> 
>