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

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 17 Dec 2018 17:03:05 +0100

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Job Snijders <[email-masked]>
Date: Mon, 17 Dec 2018 17:14:52 +0100

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

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.

Kind regards,

Job

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 18 Dec 2018 10:30:27 +0100

Hi Job, all,

Thank you for reviewing!

> On 17 Dec 2018, at 17:14, Job Snijders <[email-masked]> wrote:
> 
> Dear all,
> 

Ack!

> 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:

Current:

   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.

New:

   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.

> terminology here, or leave the sentence out.

This section was modeled after section 4.3 in RFC8182:
https://tools.ietf.org/html/rfc8182#section-4.3 <https://tools.ietf.org/html/rfc8182#section-4.3>

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.

Tim

---

From: Martin Hoffmann <[email-masked]>
Date: Thu, 20 Dec 2018 16:02:48 +0100

Tim Bruijnzeels wrote:
> 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:
> 
> Current:
> 

I don’t quite see why the empty line after the comment is necessary at
all. Since all the comment lines start with a hash, the end of the
comment section can be identified by the first line not starting with a
hash.

Kind regards,
Martin