Re: [Sidrops] Adam Roach's Yes on draft-ietf-sidrops-https-tal-07: (with COMMENT)

Hi Adam, all,

> On 10 Apr 2019, at 19:21, Adam Roach via Datatracker <noreply@ietf.org> wrote:
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-sidrops-https-tal-07: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks to everyone who worked on this document.
> 
> ---------------------------------------------------------------------------
> 
> I find it curious and somewhat problematic that there is not a section,
> equivalent to the existing section 4, that deals with RSYNC considerations. In
> particular, the attack described in the first paragraph of section 4 appears
> to be unavoidable when the TAL contains an RSYNC URI. Minimally, this document
> should draw attention to that fact, at least in the Security Considerations
> section. Ideally, it would deprecate -- or at least discourage -- the use of
> RSYNC URIs for this reason.

Good point.

How about if we change the name of section 4 from "HTTPS Considerations" to "URI Scheme Considerations"

And start off with:

Please note that the RSYNC protocol provides neither transport security nor any means by which the Relying Party can validate that they are connected to the proper host. There it is RECOMMENDED that HTTPS is used as the preferred scheme.

And change:
   Note that a Man in the Middle (MITM) cannot produce a CA certificate
   that would be considered valid according to the process described in    
   Section 3.  However, a MITM attack can be performed to prevent the
   Relying Party from learning about an updated CA certificate.  Because
   of this, Relying Parties MUST do TLS certificate and host name
   validation when they fetch a CA certificate using an HTTPS URI on a
   TAL.

To:

   Relying Parties MUST do TLS certificate and host name validation when
   they fetch a CA certificate using an HTTPS URI on a TAL. Note that,
   although a Man in the Middle (MITM) cannot produce a CA certificate
   that would be considered valid according to the process described in    
   Section 3, this attack can prevent that the Relying Party learns about
   an updated CA certificate.

Some background - I don't think the following needs to be in the document:

In my mind it was implicit and obvious that rsync should be discouraged, to the point that I forgot to mention this completely.. The end goal is to phase out rsync. But this document still allows both. 

I proposed at some point that it should allow HTTPS only - in my mind this would just mean that for some time TALs could be presented in both RFC7730 format and this new format. But the WG preferred the approach where this update allows both schemes, and a future update can be done to remove RSYNC.

With this in mind we introduced the "Trust Anchor URI" in this document and only specify once (section 2.2) which schemes are allowed. This should make a future update easy.

> 
> [This would be a discuss-level comment if this were a green-field document, but
> I don't want to stand in the way of improving an existing mechanism, so I'm only
> leaving it as a comment. The authors may choose to move forward without fixing
> this issue]
> 
> ---------------------------------------------------------------------------
> 
> §2.2:
> 
>> In this document we define a Trust Anchor URI as a URI that can be
>> used to retrieved a current Trust Anchor certificate
> 
> Nit: "...to retrieve..."

ack

Kind regards,

Tim Bruijnzeels

> 
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops