Re: [mile] Working group last call for ROLIE

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 <adam.w.montville@gmail.com>
wrote:

> More inline :-)
>
> On Thu, Apr 20, 2017 at 10:57 AM Banghart, Stephen A. (Fed) <
> stephen.banghart@nist.gov> wrote:
>
>> Hey Adam,
>>
>>
>>
>> Thanks for the review, responses inline.
>>
>>
>>
>> -Stephen
>>
>>
>>
>> *From:* mile [mailto:mile-bounces@ietf.org] *On Behalf Of *Adam Montville
>> *Sent:* Wednesday, April 19, 2017 2:14 PM
>>
>>
>> *To:* Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com>; mile@ietf.org
>> *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) <
>> ncamwing@cisco.com> 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
>> mile@ietf.org
>> https://www.ietf.org/mailman/listinfo/mile
>>
>>
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile
>
>

-- 

John P. Field | Security PM | Pivotal

Direct: (908) 962-3394 | jfield@ <jfield@gopivotal.com>pivotal.io