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

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

Kathleen,

Just to clarify, there were no normative changes to the use of TLS 1.3 or TLS 1.2 in this -11 update. The latter three paragraphs were truncated as it was duplicated text out of RFC 7525 and RFC 7589.

The normative requirements for TLS remain as follows:

A "MUST" for implementing TLS 1.2 with a "SHOULD" for following the BCPs as described in RFC 7525
A "RECOMMENDED" for implementing the most recent version of TLS (At the moment, TLS 1.3) also being supported.

The non-normative recommendation that 0-RTT be disabled remains unchanged. When you mention that "waiting may be worth having the normative language" are you referring to this recommendation or another requirement?

Thanks,
Stephen

> -----Original Message-----
> From: Kathleen Moriarty [mailto:[e-mail]]
> Sent: Thursday, October 19, 2017 1:17 PM
> To: Banghart, Stephen A. (Fed) <[e-mail]>
> Cc: Martin Thomson <[e-mail]>; [e-mail]; draft-
> [e-mail]
> Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10
> 
> 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