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

[Kathleen Moriarty <[e-mail]>]

Hi Stephen,

On Thu, Oct 19, 2017 at 12:24 PM, Banghart, Stephen A. (Fed)
<[e-mail]> wrote:
> Martin,
>
> I've put the rest of my comments inline, and uploaded a -11 version of ROLIE to the Github with the changes. Providing there are no additional major comments I'll post this version to datatracker today.
>
> Thanks again for the great review,
> Stephen
>
>> -----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.
>
> Discussed in a separate thread.
>
>> 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.
>
> We agree, removed the registration for the category document location.
>
>> 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.
>
> The majority of the section has been reduced to a RFC 7525 reference. We believe that the benefits provided by 0-RTT don't outweigh the loss of forward secrecy. The text currently places this as a suggestion from the authors, and not a normative requirement.

This is a substantial change as a result of just one reviewer.  The
only thing the MUST does is hold up final publication until an RFC #
is assigned for TLS 1.3.  TLS 1.3 shouldn't be too far off, so waiting
may be worth having the normative language.  I think this is one the
WG needs to weigh in on to change and tradeoffs of waiting for final
publication.  It's not just the editors that recommend this, I do as
am sure others do as well.

Best regards,
Kathleen
>
>> User authentication is under-specified.
>
> As any repository using user authentication is already inherently pre-communicating with its consumers, we felt that underspecifying authentication mechanisms allowed for each sharing consortium to control their own repositories. Whatever system they are using already for internal/external sharing authentication can be used here as long as it meets the ROLIE requirements.
>
>> * 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.
>
> Removed cipher suite text as these recommendations are provided by RFC 7525.
>
>> * 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.
>
> While its true that this is a "don't do anything stupid" requirement, I think that its valuable as a reminder that the authorization checks need to support full granularity through the entire resource tree.
>
>> 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.
>
> Cleaned up the text describing this requirement to be more clear that they only trigger when an implementation has decided to support RFC 6546. Removed the 404 requirement when not supporting RFC6546, as I agree that it was overly restrictive.
>
>> 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



-- 

Best regards,
Kathleen