Subject: [Sidrops] WGLC: draft-ietf-sidrops-https-tal-03 - ENDS 22 June 2018

From: Chris Morrow <[email-masked]>
Date: Fri, 08 Jun 2018 09:45:10 -0400

Howdy Gentle Folks,

The authors of: draft-ietf-sidrops-https-tal-03 would like the WG to
consider a WGLC of their document, 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."

Please have a read through the document and send along
comments/questions/additions/subtractions so the authors can amend if
required with the intent to move this document along the proper path
in short order.

thanks!
-chris
co-chair

---

From: Di Ma <[email-masked]>
Date: Sun, 10 Jun 2018 13:54:00 +0800

I support the publication of this document.

Yet the key words section of this document is supposed to use the following the description:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Besides, I suggest changing

‘an rsync URI [RFC5781], or an HTTPS URI [RFC7230]'

into 

‘either an rsync URI [RFC5781], or an HTTPS URI [RFC7230]'

in Section 2.1 Trust Anchor Locator Format.

The single OR could lead to a different comprehending logically.

Di  Ma
RPSTIR
https://bgpsecurity.net

> 在 2018年6月8日，21:45，Chris Morrow <[email-masked]> 写道：
> 
> 
> Howdy Gentle Folks,
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Job Snijders <[email-masked]>
Date: Sun, 10 Jun 2018 09:25:08 +0000

> required with the intent to move this document along the proper path

Read. I support publication.

Nits:

1/ "one of more" should perhaps be "one or more"?

2/  OLD: "However, a MITM can perform withhold or replay attacks
targeting a Relying Party and keep the Relying Party from learning about
an update CA certificate."

PERHAPS: "However, a MITM attack can be performed to prevent the Relying
Party from learning about an updated CA certificate."

Kind regards,

Job

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 13 Jun 2018 10:43:36 +0200

Hi Job, all,

First off: I will be offline for the coming two weeks until 2 July, so don’t take lack of responses from me personally ;) I realise this not convenient during last call but other co-authors can comment as well of course.

> On 10 Jun 2018, at 11:25, Job Snijders <[email-masked]> wrote:
> 
> 1/ "one of more" should perhaps be "one or more”?

ack

> Party from learning about an updated CA certificate.”
> 

I am okay with your text, but the ‘OLD’ text is more explicit about how the MITM can affect the RP. This text was mostly stolen from the delta protocol:
https://tools.ietf.org/html/rfc8182#section-4.3

And that went through some revisions in the IESG.

I don’t have strong feelings either way as long as it’s clear to readers.

Kind regards,

Tim