Re: [mile] Artart last call review of draft-ietf-mile-rolie-10

["Banghart, Stephen A. (Fed)" <[e-mail]>]

Martin,

Thanks for truncating the extra mailing lists.

The client authorization requirements in ROLIE are intended to be implementation requirements and not use requirements, which I think is causing some of the confusion.

Ultimately, ROLIE will be wearing one of two hats in the wild, a secure security information exchange for CSIRTs and sharing consortiums, and a public facing security information exchange for public disclosure. In order for a given implementation to support both of these use cases strong user authentication needs to be supported/implemented, but in order to support the public facing use case, these authentication requirements can't be required to be turned on.

Our goal was to attempt to support both use cases in a way that (hopefully) doesn't compromise the core usage of the other use case. We tried to allow the requirements to be adjudicated on a workspace by workspace basis so a single site could be taking advantage of both use cases simultaneously.

I've taken your suggestion to clean up the Transport Layer Security section and parts of the Security Considerations section by removing our reinvention of the wheel and leaning more heavily on referencing other RFCs for best practices, it's possible that the cleaned up text contradicts itself less and mitigates the issue. Perhaps more explanatory text around these two core use cases in the authentication section would help too?

Thanks,
Stephen

> -----Original Message-----
> From: Martin Thomson [mailto:[e-mail]]
> Sent: Wednesday, October 18, 2017 1:03 AM
> To: Banghart, Stephen A. (Fed) <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10
> 
> (-ietf@ and art@ to save those inboxes)
> 
> Hi Stephen,
> 
> Thanks for the explanation.  I somewhat expected that this would be the use
> case, but I couldn't reconcile that with the long list of requirements for client
> authentication.  Can you go into some more detail about that as well?  Happy
> to hash that out here (I'm not subscribed to mile@ though).
> 
> If the intent is to have the information for a web site (as opposed to the
> organization) accessible in a location that can be readily found, then I think
> that you have justification for using .well-known for the service document.
> The category document can be linked from the service document, so I think it
> would be best if you did remove that .well-known registration.  You might
> also consider using simply .well-known/rolie once you have just one
> resource.
> 
> On Wed, Oct 18, 2017 at 3:18 AM, Banghart, Stephen A. (Fed)
> <[e-mail]> wrote:
> > Martin,
> >
> > Thanks for the great review. We've been working through your comments
> and preparing a -11 version. I'll have a full response to your comments out to
> the list once we've completed addressing them all, but wanted to open a
> discussion on a few points in the meantime.
> >
> > The .well-known registration for /servicedocument has a use
> case/discovery story that we feel is important enough for registration, or at
> least for standardization. In the case where there is no standardized location
> template for the service document, a vendor/company/site that wants to
> stand up a ROLIE repository and provide regular syndicated information must
> provide a link to the service document somewhere on their regular site, or
> otherwise distribute the URL. While this potentially provides a means for
> humans to find the repository (although the link would likely be hidden in
> some strange place), it doesn't help automated tools locate the repository.
> >
> > As a user of ROLIE, I'd like to be able to provide a tool with the
> hostname:port of a vendor whose syndicated information I'd like to receive,
> and have the tool return the status of any repository that is or in not hosted
> by that top level site. For example, I'd like to give a tool
> "https://na01.safelinks.protection.outlook.com/?url=www.microsoft.com&d
> ata=02%7C01%7Cstephen.banghart%40nist.gov%7Cba46aafebe734b3f68050
> 8d515e59246%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C6364389
> 98107607337&sdata=WM0xsrsPHcL52oU82C8VlFlVKYHeTdZomTDx6WQgJYs%
> 3D&reserved=0" and have it provide me all the ROLIE (and non-ROLIE
> AtomPub if provided in the same ServDoc) Collections provided by that host.
> Without a .well-known registration, the standard would have to provide a
> defined non-/.well-known URL template location, which we felt was bad
> practice.
> >
> > Its likely that the standard doesn't provide enough context around the
> /.well-known registration, and that adding more explanatory text around our
> discovery story would help make the need for a URL template more clear.
> >
> > If the issue is with the use of /.well-known, and not with the standardized
> URL template, we could simply remove the .well-known registration and
> instead provide a non-registered requirement for a
> {host}/rolie/servicedocument URL template.
> >
> > We agree that the discovery story for /categorydocument is decidedly
> weaker, as any out-of-line category documents would be linked to from the
> Service Document. We would open to dropping this
> registration/requirement outright as you suggest.
> >
> > Thanks again for the thorough review,
> > Stephen Banghart
> >
> >> -----Original Message-----
> >> From: mile [mailto:[e-mail]] On Behalf Of Martin Thomson
> >> Sent: Monday, October 09, 2017 1:08 AM
> >> To: [e-mail]
> >> Cc: [e-mail]; [e-mail]; [e-mail]
> >> Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10
> >>
> >> Reviewer: Martin Thomson
> >> Review result: Almost Ready
> >>
> >> I have reviewed this document, and - despite what appears to be a
> >> lengthy list of issues - I think that it is in pretty good shape.
> >> It's clear, readable, and addresses the requirements well.  Most of
> >> my comments should be trivial to resolve.
> >>
> >> Major:
> >>
> >> The decision to define a .well-known URI without a discovery story is
> >> - in my opinion - inadvisable.  Such a registration is usually
> >> appropriate if you design a protocol that depends on discovery by
> >> hostname and port.  As such, this does not use that at all.  A
> >> configuration system can (and should) accept a complete URI for the
> >> service endpoint.  It would be better to defer creation of yet
> >> another .well-known URI registration until the working group is certain
> that discovery requires it.
> >>
> >> The same comment applies to the .well-known resource for the category
> >> document.
> >>  Given that this sort of document is readily discoverable via the
> >> service document, I would say that the need for a .well-known
> >> resource is less well- justified than the service document.
> >>
> >> The requirements in Section 5.3 on TLS use are unnecessarily strict.
> >> It's great to recommend the use of TLS 1.2, but given that the
> >> document has no real requirement on any particular version of TLS,
> >> the use of "MUST" here is not needed.  Similarly, the prohibition on
> >> the use of 0-RTT is groundless.  The lengthy list of requirements
> >> around certificate validation only risk creating a conflict with
> >> advice in other RFCs.  Many, if not all, of these requirements are
> >> transitively included by way of referencing HTTPS documents.  I would
> prefer to see this entire section reduced to a simple RFC 7525 reference.
> >>
> >> User authentication is under-specified.
> >>
> >> * Section 5.3 mandates the use of TLS cipher suites that support
> >> client authentication using certificates, but offers no further
> >> advice.  Aside from being an unnecessary requirement - cipher suites
> >> that support certificate- based authentication of servers all allow
> >> for client authentication - this sort of requirement is rarely
> >> sufficient for interoperation.  For instance, you need to specify how
> >> a server will request a certificate such that clients can select the
> >> correct certificate.  If a client and server have agreed to share
> >> information on terms that rely on authentication of clients, it is better for
> those peers to arrange the terms on which they will authenticate.
> >>
> >> * Section 5.4 uses "SHOULD" regarding client authentication using
> >> federation, but offers no hints about what this entails.  It also
> >> uses "SHOULD" regarding authorization checks, which isn't an
> >> interoperability requirement.  It's more of a "don't be silly" type
> >> of requirement, which doesn't need to be written down in an RFC.
> >>
> >> Section 5.5 prohibits the use of GET on "/".  This prohibits use of
> >> the resource for other purposes.  It seems reasonable to accept POST
> >> messages as defined in RFC 6546, but this requirement is overly
> >> strict (and further entrenches the violation of RFC 7320).  If, for
> >> instance, the server operator wishes to provide HTML in response to a
> >> GET request to "/", this would prohibit that.  The requirement to
> >> return 404 if RFC 6546 is not supported is worse; not supporting RFC
> >> 6546 might be a choice that a deployment makes to avoid the need to
> reserve "/" for that protocol.
> >>
> >> In Section 6.2.3, what is the advantage of "rolie:format" over having
> >> a well- defined media type?  Media types can take advantage of
> >> content negotiation, existing support in link relations, and other existing
> tools.
> >> This rolie:format element has namespace, format, and schema; these
> >> are not useful to anyone that is ignorant of their contents.  The
> >> only advantage I see is that syntax might be validated, but semantics
> >> can't be extracted.  There's a lot of implied work in adding this
> >> element, but that doesn't seem to be justified by that advantage.  (I
> >> see that RFC 7970 doesn't define a media type, but it seems like it
> >> would be easier to correct that than to define an element like this.)
> >>
> >> Section 6.2.4 defines a generic key-value mechanism.  But that is
> >> something that XML is actually good at.  Why can't users that require
> >> additional metadata use additional metadata as originally defined by
> >> Atom?  That is, replace <rolie:property
> name="urn:ietf:params:rolie:property:csirt-iodef-id"
> >> value="12345"/> with something like
> >> <rolie:csirt-iodef-id>12345</rolie:csirt-iodef-id>.  The final
> >> paragraph of the section recognizes this possibility.
> >>
> >> Minor:
> >>
> >> Section 5.1.1 recommends the use of workspaces to separate "private"
> >> and "public" information.  But workspaces don't really contain enough
> >> information to signal their status to a consumer of the information.
> >> I would suggest mentioning this, removing the recommendation, or
> >> expanding on the manner in which the status of information is signaled.
> >>
> >> Section 6.1.1 says "zero or more atom:category elements", but this
> >> contradicts the text and amendment to the schema in Section 6.1.
> >>
> >> Section 6.1.3 requires updating the "atom:updated" element when the
> >> representation changes.  I don't think that this is what was
> >> intended.  I think that the element needs to be updated when the
> >> contents of the feed change in any way.
> >>
> >> Question: it's fairly widely accepted that use of IRIs in Atom has
> >> been less than successful.  Do you want to mandate use of URIs
> >> instead?  This would apply to both link relations and the "src" attribute.
> >>
> >> In Section 7.1, the definition of the namespace prefix
> >> "urn:ietf:params:rolie:category:local" seems unnecessary.  Namespace
> >> URIs are cheap and it seems reasonable to experiment with feeds that
> >> produce non-ROLIE information by omitting the
> >> "urn:ietf:params:rolie:category:information-type"
> >> category, even if that feed might comply with the requirements of ROLIE.
> >> The other way to experiment would be to use the category, but define
> >> a way to identify "term" attributes that are for use in private or
> >> experimental contexts.
> >>
> >> In Section 7.4, how is "...:rolie:property:content-author-name"
> >> superior to "atom:author"?
> >>
> >> In Section 8.4,  is there a uniqueness requirement on "name"?  I
> understand
> >> this to be the thing that being registered.   Assuming that, what purpose
> >> does
> >> the "index" serve?
> >>
> >> This statement from Section 9, "As described in the discovery
> >> section, DNS SRV Records are a possible secure solution to
> >> discovery." is false without further qualification.  SRV with DNSSEC
> >> might be secure, but a lot depends on the input to the discovery process
> and its provenance.
> >>
> >> In Section 10, the following statement is false (all of the described
> >> privacy violations are available to a client or server, not third
> >> parties): "Proper usage of TLS as described in Section 5.3 will in
> >> many cases aid in the mitigation of these issues."  I think that you
> >> can strike this statement (most of the reason for use of TLS is justified by
> the security considerations anyway).
> >>
> >> Nits:
> >>
> >> Is it "Feed" or "feed"?  RFC 4287 uses the latter, but this document
> >> seems to prefer the Proper Noun form.
> >>
> >> Section 6.2 should say what changed in the schema.  It's hard to
> >> eyeball the schema to discover that "atomContent" is no longer
> >> optional.  The two new elements are easy to spot and might cause the
> first change to be missed.
> >>
> >> Section 6.2.1 is the same.  It should explicitly say that it only
> >> permits the atomOutOfLineContent formulation.
> >>
> >> I found the formulation of Section 7.1.1 confusing.  It includes a
> >> list that seems to be authoritative, then disclaims any attempt to
> >> register these terms.
> >> Maybe this is because the statement "This document does not specify
> >> any information types." appears too late.  Some reordering might help.
> >>
> >> The formatting of the table in Section 8.3 makes most of the columns
> >> unreadable.  I would recommend a simple nested list.
> >>
> >> In section 9, the use of the term "well-known" to refer to
> >> information that is either public or widely available risks misinterpretation.
> >>
> >> FWIW, I would reword this entire paragraph to say simply "Access
> >> control to information published using ROLIE should use mechanisms
> >> that are appropriate to the sensitivity of the information.
> >> Primitive authentication mechanisms like HTTP Basic Authentication
> >> [RFC7617] are rarely appropriate for sensitive information."  I
> >> didn't find the remainder of the text on authentication especially
> >> helpful.  The text seems to equivocate on the subject of federation,
> where it would be easier to say nothing.
> >>
> >> Also in Section 9, the use of the term "message" is used in the
> >> context of using additional security controls.  I think that the word
> >> "representation" is what was intended here.
> >>
> >> _______________________________________________
> >> mile mailing list
> >> [e-mail]
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >> i
> etf.org%2Fmailman%2Flistinfo%2Fmile&data=02%7C01%7Cstephen.banghar
> >>
> t%40nist.gov%7Caf3af91a1c684592007d08d50ed3d401%7C2ab5d82fd8fa4797
> >>
> a93e054655c61dec%7C1%7C0%7C636431225322845891&sdata=SykEasQlo1e
> >> MarYmKXSA5HsOUpTLyjd9rslyvZPpxak%3D&reserved=0