Re: [mile] Working group last call for ROLIE

[Adam Montville <[e-mail]>]

Thanks for the additional perspective. It's all good, and I like the idea
of upping the game. Just felt, for some reason, compelled to ask about it.

On Fri, Apr 21, 2017 at 11:47 AM John Field <[e-mail]> wrote:

> Hi All,
>
> Thanks Adam for the review comments.
>
> With regard to your specific comments on page 11 of the draft, i.e. MUST
> versus SHOULD, this is a very good point.  I too struggled with this
> question in the earlier drafts.  I can see the motivation to not exclude
> legitimate use cases or specific deployments that for whatever reason might
> not require mutually authenticated TLS.  But, at the end of the day, I
> agree with Stephen's response that as ROLIE is a security service endpoint,
> we should keep this as a MUST in terms of conformance.  Here's my rationale:
>
> In general, we want to raise the bar -- in terms of current best practice,
> and use "TLS everywhere."  This ensures privacy (and, depending upon
> specific cipher suite, perfect forward secrecy). Going the next step, and
> requiring mutually authenticated TLS, helps by defining at least 1
> specific, and consistent client authentication mechanism, and so should
> promote better interoperability.
>
> As a practical matter, there are many tools and libraries available to
> implementers, and so the associated certificate issuance is just not as big
> a burden as it might first seem.
>
> Also, ensuring data integrity will be an important security characteristic
> for any ROLIE implementation.  Although specific audit requirements are out
> of scope, requiring mutually authenticated TLS will provide a
> standards-based way for a server to associate an identity with a client
> endpoint and provide accountability/audit of client actions. This could be
> useful as a remember-me, even if the identity provisioning process does not
> involve strong vetting.
>
> Of course, implementations may choose to support additional authentication
> mechanisms as needed.  There is a brief discussion of this in the 3rd
> paragraph of section 9, security considerations, where guidance is given to
> align the client authentication requirement to the threat model.
>
> Regards,
> John
>
>
> On Thu, Apr 20, 2017 at 3:16 PM, Adam Montville <
> [e-mail]> wrote:
>
>> More inline :-)
>>
>> On Thu, Apr 20, 2017 at 10:57 AM Banghart, Stephen A. (Fed) <
>> [e-mail]> wrote:
>>
>>> Hey Adam,
>>>
>>>
>>>
>>> Thanks for the review, responses inline.
>>>
>>>
>>>
>>> -Stephen
>>>
>>>
>>>
>>> *From:* mile [mailto:[e-mail]] *On Behalf Of *Adam
>>> Montville
>>> *Sent:* Wednesday, April 19, 2017 2:14 PM
>>>
>>>
>>> *To:* Nancy Cam-Winget (ncamwing) <[e-mail]>; [e-mail]
>>> *Subject:* Re: [mile] Working group last call for ROLIE
>>>
>>>
>>>
>>> Hi all.
>>>
>>>
>>>
>>> I've read through the entire draft and found it to be a decent draft.
>>> Keep in mind that I've not attempted an implementation, and must rely on
>>> implementers to pick out any technical impacts from this specification.
>>> That said, I have two broad categories of feedback. The first includes
>>> suggestions and concerns that are something more than nits. The second are
>>> really just nits and stylistic (i.e. take them or leave them) types of
>>> concerns.
>>>
>>>
>>>
>>> Suggestions/Concerns More Than Nits...
>>>
>>>
>>>
>>> Page 6: There are two similar terms in the second paragraph of section
>>> 4.2: "endpoint management system" and "endpoint monitoring system". Are
>>> they intended to be distinct, or interchangeable in this context? I could
>>> conclude either way, but if they are intended to be interchangeable, then I
>>> recommend picking and using one.
>>>
>>>
>>>
>>> They were originally meant to be interchangeable, I’ve changed them both
>>> to “endpoint management system” to avoid confusion.
>>>
>>
>> Thanks!
>>
>>
>>>
>>>
>>> Page 10: I've probably missed something along the way -- perhaps out of
>>> a secdir lunch or other discussion -- but it really seems like section 5.3
>>> could be dramatically reduced by saying, follow RFC7589. There are a lot of
>>> non-ROLIE-specific things happening in this section, which mostly amount to
>>> good practice overall (so I don't necessarily mind having the information
>>> in here), but imagine this information being available in every draft
>>> intended to be, in part, secured using TLS. That sounds like a nightmare
>>> for managing requirements.
>>>
>>>
>>>
>>> We’ve selectively chosen pieces out of RFC7589 to put into ROLIE, so
>>> referencing the whole document may include unintended requirements. That
>>> said, there may be a way to shorten this section slightly if you are
>>> concerned about section length.
>>>
>>
>> Understood. Also, my comments were not so much about length as about
>> contributing to a potential rats nest of requirements. But, shortening
>> would be good too. :-)
>>
>>
>>>
>>>
>>> Page 11: First paragraph at the top of that page (part of section 5.3)
>>> says, "The server MUST support certificate-based client authentication..."
>>> Why is this not a SHOULD? Yes, we'd like them to, but there are perfectly
>>> valid cases where they needn't support client authentication. Of course, if
>>> a proper TLS server implementation does this already, then my previous
>>> comment applies here as well.
>>>
>>>
>>>
>>> Page 11: First pargraph of section 5.4. A similar concern to the
>>> previous, the first sentence reads, "Implementations MUST support user
>>> authentication." Why not SHOULD? Again, there are valid cases where
>>> authentication is not, strictly speaking, needed.
>>>
>>>
>>>
>>> We decided that implementations MUST support the authentication in both
>>> of these cases to maintain secure interoperability between implementations.
>>> A given ROLIE repo does *not* have to actually use the authentication.
>>> Panos had similar comments to these two as well, so I’ve added a paragraph
>>> in section 2 that clarifies that all requirements in the ROLIE
>>> specification are conformance requirements for implementations, and are not
>>> usage requirements.
>>>
>>
>> Right, but therein is sort of the rub. Maybe it's a red herring, but if
>> there's code sitting there that'll never really be used, isn't that a bad
>> thing?
>>
>>
>>
>>>
>>>
>>> Page 12: Section 5.5 treats GET and POST, but ignores the other methods
>>> that may be treated similarly by stating, in section 5.6, "Servers MAY
>>> accept request methods beyond those specified in this document." Do we
>>> really want to leave those undefined? PUT? DELETE? I'm not an expert in
>>> this area, but PUT could be treated similarly to POST. DELETE is probably
>>> something that SHOULD be implemented only for user agents properly
>>> authenticated and authorized, etc.
>>>
>>>
>>>
>>> Section 5.5 only applies to requests sent to the “/” resource to
>>> maintain RID compatibility. GET,POST,PUT,DELETE,etc are all defined for
>>> general usage in the Atom Publishing Protocol specification
>>>
>>>
>>>
>>> Sections 6.1 and 6.2 and maybe others I can't recall: These sections
>>> provide an informative syntax for a given element that is a "stricter
>>> representation" than the original RFC, but they don't ever really state
>>> which part of that element is stricter, which forces the reader out to that
>>> original RFC. If there is a way to make the statement right there, please
>>> do so.
>>>
>>>
>>>
>>> The definitions for elements we’ve provided in ROLIE are full
>>> definitions, so a reader shouldn’t need to flip back to RFC4287 in order to
>>> get the whole picture. Any element defined in ROLIE does a full override of
>>> the 4287 element, and any element not defined in ROLIE fully inherits from
>>> 4287. Would it help if I added some text describing that relationship in
>>> more detail somewhere?
>>>
>>
>> It might, but I'm a voice of one, so if others are like "dude, what's
>> this guy talking about?" then I wouldn't worry about it.
>>
>>
>>
>>>
>>>
>>> Page 15: First sentence of section 6.1.3 indicates that "the
>>> atom:updated element MUST be populated with the current time at the instant
>>> the Feed representation was last updated..." Is "instant" sufficient
>>> definition?
>>>
>>>
>>>
>>> Time being the beast that it is I’m not sure how to better describe the
>>> requirement. Do you have any suggestions/recommendations on how to define
>>> it?
>>>
>>
>> LOL. Nope. If we're not concerned, then that's fine. Does the Atom spec
>> indicate the timestamp format? That's probably sufficient.
>>
>>
>>>
>>>
>>> Nits and Such...
>>>
>>>
>>>
>>> Page 5: Second sentence of section 3.2. Strike "However, " from the
>>> beginning.
>>>
>>>
>>>
>>> Changed
>>>
>>>
>>>
>>> Page 5: Last sentence of section 3.2. Proposed change: "A non-normative
>>> RELAX NG Compact Schema..." or "An informative RELAX NG Compact Schema..."
>>>
>>>
>>>
>>> Added
>>>
>>>
>>>
>>> Page 5: Last sentence of only paragraph in Section 4 (proper). Proposed
>>> change: "...human-in-the-loop sharing arise...". It just reads funny (to
>>> me) using "become apparent" followed by something else that "becomes
>>> apparent".
>>>
>>>
>>>
>>> Agreed, changed the sentence to avoid the repetition.
>>>
>>>
>>>
>>> Page 19: First sentence of first bullet point in section 6.2.5. Proposed
>>> change: "...have an atom:link element...".
>>>
>>>
>>>
>>> Changed
>>>
>>>
>>>
>>> Page 26: Last sentence in first paragraph of section 9. Proposed change:
>>> "...All that follows is guidance.  More specific instruction is out of
>>> scope for this document."
>>>
>>>
>>>
>>> Changed
>>>
>>>
>>>
>>> Page 26: The term CSIRT is used in the last paragraph on this page. Not
>>> sure whether we would prefer to use a more generalized example, as CSIRTs
>>> may not be the only type of sharing consortium.
>>>
>>>
>>>
>>> Agreed, changed to “consortium”.
>>>
>>>
>>>
>>> Kind regards,
>>>
>>>
>>>
>>> Adam
>>>
>>>
>>>
>>> On Tue, Mar 28, 2017 at 6:27 PM Nancy Cam-Winget (ncamwing) <
>>> [e-mail]> wrote:
>>>
>>> Colleagues,
>>>
>>>
>>>
>>> Given the significant changes made to the last draft, we are doing
>>> another 30day WGLC for
>>>
>>> https://tools.ietf.org/html/draft-ietf-mile-rolie-06
>>>
>>>
>>>
>>> Please provide comments before May 1st and provide your support and/ or
>>> raise any issue you feel are yet to be addressed.
>>>
>>>
>>>
>>> Regards, Nancy
>>>
>>> _______________________________________________
>>> mile mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mile
>>>
>>>
>> _______________________________________________
>> mile mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mile
>>
>>
>
>
> --
>
> John P. Field | Security PM | Pivotal
>
> Direct: [phone] | jfield@ <[e-mail]>pivotal.io
>