Re: [Sidrops] WGLC: draft-ietf-sidrops-https-tal - ENDS Nov 26 2018 (11/26/2018)

Tim Bruijnzeels <> Tue, 18 December 2018 09:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 146C51310B8; Tue, 18 Dec 2018 01:30:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bB5s0g_iA-5Q; Tue, 18 Dec 2018 01:30:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 93167130E66; Tue, 18 Dec 2018 01:30:30 -0800 (PST)
Received: from [IPv6:2a04:b900::1:9ccd:ff7b:6da7:969a] (unknown [IPv6:2a04:b900:0:1:9ccd:ff7b:6da7:969a]) by (Postfix) with ESMTPSA id 5F1131F01D; Tue, 18 Dec 2018 10:30:28 +0100 (CET)
Authentication-Results:; dmarc=fail (p=none dis=none)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1545125428; bh=sNqdLl0qTfBnm+CCxZktya4cXnUtTSHvddFYPmqh1E0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Me9+MbjpjoTcuYpQvUXP51INgZL2yh9SIRzUn8pWww+wBFcJmyl9SK03yItTFDbBS JzzGLBgY/aVc9cECuCX0wllCIB8AF2sJ6ELJUKGjBNdw4LRaKLtHOiMN9SXD6YAMva 7pmEqhaD8C41njIjiWjfmetw9bbZciW9PcSckoWE=
Content-Type: multipart/alternative; boundary="Apple-Mail=_F1B9236B-ECF2-48C4-B2D9-531E5E2FD973"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Tue, 18 Dec 2018 10:30:27 +0100
Cc:, Christopher Morrow <>, SIDR Operations WG <>,
Message-Id: <>
References: <> <> <>
To: Job Snijders <>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <>
Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-https-tal - ENDS Nov 26 2018 (11/26/2018)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Dec 2018 09:30:38 -0000

Hi Job, all,

Thank you for reviewing!

> On 17 Dec 2018, at 17:14, Job Snijders <> wrote:
> Dear all,
> I reviewed the document (and previously suggested the addition of the
> '#' comment). I'd like to see this document published as IETF RFC.
> Some small nitpicks:
> Section 1.1 terminology should also point to 8174


> Section 2.1 "ASCII" should probably be UTF-8, this is 2018 and we are the IETF

So, the machines will most likely ignore this anyway. I guess that UTF-8 should be okay, provided we restrict the allowed line breaks to <CRLF> or <LF> for these lines as well. So maybe rephrase:


   1.  an optional comment section consisting of one or more lines
       starting with the '#' character, containing human readable
       informational ASCII text, followed by an empty line using a
       "<CRLF>" or "<LF>" line break only.


   1.  an optional comment section consisting of one or more lines
       starting with the '#' character, containing human readable
       informational UTF-8 text, and ending with a "<CRLF>" or 
       "<LF>" line break. Followed by an empty line using a
       "<CRLF>" or "<LF>" line break only.

I don’t have a strong opinion either way.

> Section 4: "Therefore, the Relying Party MUST continue to retrieve the
> data in case of errors." I am not sure software "MUST" continue when
> errors are found - maybe those errors should just be fixed. Generally
> I'm not a fan of being too forgiving, I'd reconsider the RFC 2119/8174
> terminology here, or leave the sentence out.

This section was modeled after section 4.3 in RFC8182: <>

The reasoning was that, since we have object security in the RPKI, data can be validated even if the transport channel is not fully trusted (e.g. rsync). And that having some data to validate would be better than having no data. At the time of writing this we were afraid that it would be more common to encounter TLS verification issues due to misconfigurations as opposed to malice (which can at best withhold or replay data, and manifests protect somewhat against that).

All that being said, I think that these days “Let’s Encrypt” has made it abundantly easy to get this sorted for a production repository, that I am willing to take this all out and suggest that validation be strict. Note though that this means that validation software will rely on the list of (web) Trust Anchors installed on the system, and not all of these are equally trustworthy, and the list may be out of date. That said, systems should be kept up to date, and a possible false positive verification outcome here still leaves the object security in tact. So adds a layer of security, but it’s not the only layer.


> Kind regards,
> Job
> On Mon, Dec 17, 2018 at 5:03 PM Tim Bruijnzeels <> wrote:
>> I don’t remember seeing any comments on this one. What’s the next step?
>> Tim
>>> On 5 Nov 2018, at 03:55, Christopher Morrow <> wrote:
>>> Howdy WG Folks,
>>> Please read/review the document: draft-ietf-sidrops-https-tal
>>> The abstract:
>>>  "This document defines a Trust Anchor Locator (TAL) for the Resource
>>>   Public Key Infrastructure (RPKI).  This document obsoletes RFC 7730
>>>   by adding support for HTTPS URIs in a TAL."
>>> explains the gist, and the document is a short 10 page read/review... Let's have a read/comment and push to get this moved into the IESG process before xmas 2018!
>>> -chris
>>> co-chair-sidrops
>>> _______________________________________________
>>> Sidrops mailing list
>> _______________________________________________
>> Sidrops mailing list
> _______________________________________________
> Sidrops mailing list