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

[Roman Danyliw <[e-mail]>]

Hi Tommy!

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

> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of Tommy Pauly
> Sent: Wednesday, January 22, 2020 1:04 PM
> To: Roman Danyliw <[e-mail]>
> Cc: Erik Kline <[e-mail]>; draft-ietf-intarea-provisioning-
> [e-mail]; [e-mail]; The IESG <[e-mail]>; intarea-
> [e-mail]
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-intarea-provisioning-
> domains-10: (with DISCUSS and COMMENT)
> 
> Hi Roman,
> 
> Thanks for the review!
> >
> > ----------------------------------------------------------------------
> > 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?
> 
> 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?

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).

> >
> >
> > ----------------------------------------------------------------------
> > 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.?
> >
> >
> 
> Yes, I agree that this should be clarified—that will be covered as part of the
> discuss from Adam.

Makes sense.

Thanks,
Roman

> Thanks,
> Tommy