Subject: [Int-area] Roman Danyliw's Discuss on draft-ietf-intarea-provisioning-domains-10: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 22 Jan 2020 09:52:55 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-intarea-provisioning-domains-10: Discuss

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-intarea-provisioning-domains/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 4.4.  Per “When a host retrieves the PvD Additional Information, it
MUST verify that the TLS server certificate is valid for the performed request
(e.g., that the Subject Alternative Name is equal to the PvD ID expressed as an
FQDN).  This authentication creates a secure binding between the information
provided by the trusted Router Advertisement, and the HTTPS server.”, what is
the trust anchor the client is supposed to use to valid the server certificate
is valid?  How is that trust anchor provisioned?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Ben Kaduk and Adam Roach’s DISCUSS positions.

Section 4.1.  Per “If the HTTP status of the answer is between 200 and 299,
inclusive, the host MAY get a file containing a single JSON object”, what
should be the behavior of a host that gets 200 status code  but no JSON object
– should it try again, conclude (like in a 4xx status code) that there is not
further information, etc.?

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 22 Jan 2020 10:03:51 -0800

Hi Roman,

Thanks for the review!

There isn't any assumption that a non-default trust anchor needs to be used by the client for this validation. By default, a client would use its system TLS trust anchors to validate the server. This leaves open the possibility for enterprise scenarios to configure custom trust anchor settings, but that is currently beyond the scope of this document.

Is there anything you'd like to see specifically covered in this text?

Yes, I agree that this should be clarified—that will be covered as part of the discuss from Adam.

Thanks,
Tommy

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 23 Jan 2020 13:21:56 +0000

Hi Tommy!

Thanks for the quick response.  What you are proposing below would address my concern.  See below ...

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Tommy Pauly
> Sent: Wednesday, January 22, 2020 1:04 PM
> To: Roman Danyliw <[email-masked]>
> Cc: Erik Kline <[email-masked]>; draft-ietf-intarea-provisioning-
> [email-masked]; [email-masked]; The IESG <[email-masked]>; intarea-
> [email-masked]
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-intarea-provisioning-
> domains-10: (with DISCUSS and COMMENT)
> 
> Hi Roman,
> 
> Thanks for the review!
> >
> > Section 4.4.  Per “When a host retrieves the PvD Additional
> > Information, it MUST verify that the TLS server certificate is valid
> > for the performed request (e.g., that the Subject Alternative Name is
> > equal to the PvD ID expressed as an FQDN).  This authentication
> > creates a secure binding between the information provided by the
> > trusted Router Advertisement, and the HTTPS server.”, what is the
> > trust anchor the client is supposed to use to valid the server certificate is
> valid?  How is that trust anchor provisioned?
> 
> There isn't any assumption that a non-default trust anchor needs to be used
> by the client for this validation. By default, a client would use its system TLS
> trust anchors to validate the server. This leaves open the possibility for
> enterprise scenarios to configure custom trust anchor settings, but that is
> currently beyond the scope of this document.
> 

Including a version of the text you wrote above would address my concern.  The two key issues you hit are that (1) (obviously) a trust anchor should be used otherwise you not getting the authenticity you think you are; and (2) this anchor might need to be provisioned, whose complexity is out of scope (like you said).

> > Section 4.1.  Per “If the HTTP status of the answer is between 200 and
> > 299, inclusive, the host MAY get a file containing a single JSON
> > object”, what should be the behavior of a host that gets 200 status
> > code  but no JSON object – should it try again, conclude (like in a
> > 4xx status code) that there is not further information, etc.?
> >
> >
> 

Makes sense.

Thanks,
Roman