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

[Kathleen Moriarty <[e-mail]>]

Hi Stephen,

On Thu, Oct 19, 2017 at 1:39 PM, Banghart, Stephen A. (Fed)
<[e-mail]> wrote:
> 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?

I should have looked back at the draft.  I thought you had a normative
statement for 0-RTT and that it had changed from the phrasing in your
email.  If nothing of substance changed, then we're fine.

Thanks,
Kathleen

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



-- 

Best regards,
Kathleen