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

From: Martin Thomson <[email-masked]>
Date: Sun, 08 Oct 2017 22:08:26 -0700

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.

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.

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.

User authentication is under-specified.

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

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

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.

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. 
This rolie:format element has namespace, format, and schema; these are not
useful to anyone that is ignorant of their contents.  The only advantage I see
is that syntax might be validated, but semantics can't be extracted.  There's a
lot of implied work in adding this element, but that doesn't seem to be
justified by that advantage.  (I see that RFC 7970 doesn't define a media type,
but it seems like it would be easier to correct that than to define an element
like this.)

Section 6.2.4 defines a generic key-value mechanism.  But that is something
that XML is actually good at.  Why can't users that require additional metadata
use additional metadata as originally defined by Atom?  That is, replace
<rolie:property name="urn:ietf:params:rolie:property:csirt-iodef-id"
value="12345"/> with something like
<rolie:csirt-iodef-id>12345</rolie:csirt-iodef-id>.  The final paragraph of the
section recognizes this possibility.

Minor:

Section 5.1.1 recommends the use of workspaces to separate "private" and
"public" information.  But workspaces don't really contain enough information
to signal their status to a consumer of the information.  I would suggest
mentioning this, removing the recommendation, or expanding on the manner in
which the status of information is signaled.

Section 6.1.1 says "zero or more atom:category elements", but this contradicts
the text and amendment to the schema in Section 6.1.

Section 6.1.3 requires updating the "atom:updated" element when the
representation changes.  I don't think that this is what was intended.  I think
that the element needs to be updated when the contents of the feed change in
any way.

Question: it's fairly widely accepted that use of IRIs in Atom has been less
than successful.  Do you want to mandate use of URIs instead?  This would apply
to both link relations and the "src" attribute.

In Section 7.1, the definition of the namespace prefix
"urn:ietf:params:rolie:category:local" seems unnecessary.  Namespace URIs are
cheap and it seems reasonable to experiment with feeds that produce non-ROLIE
information by omitting the "urn:ietf:params:rolie:category:information-type"
category, even if that feed might comply with the requirements of ROLIE.  The
other way to experiment would be to use the category, but define a way to
identify "term" attributes that are for use in private or experimental contexts.

In Section 7.4, how is "...:rolie:property:content-author-name" superior to
"atom:author"?

In Section 8.4,  is there a uniqueness requirement on "name"?  I understand
this to be the thing that being registered.   Assuming that, what purpose does
the "index" serve?

This statement from Section 9, "As described in the discovery section, DNS SRV
Records are a possible secure solution to discovery." is false without further
qualification.  SRV with DNSSEC might be secure, but a lot depends on the input
to the discovery process and its provenance.

In Section 10, the following statement is false (all of the described privacy
violations are available to a client or server, not third parties): "Proper
usage of TLS as described in Section 5.3 will in many cases aid in the
mitigation of these issues."  I think that you can strike this statement (most
of the reason for use of TLS is justified by the security considerations
anyway).

Nits:

Is it "Feed" or "feed"?  RFC 4287 uses the latter, but this document seems to
prefer the Proper Noun form.

Section 6.2 should say what changed in the schema.  It's hard to eyeball the
schema to discover that "atomContent" is no longer optional.  The two new
elements are easy to spot and might cause the first change to be missed.

Section 6.2.1 is the same.  It should explicitly say that it only permits the
atomOutOfLineContent formulation.

I found the formulation of Section 7.1.1 confusing.  It includes a list that
seems to be authoritative, then disclaims any attempt to register these terms. 
Maybe this is because the statement "This document does not specify any
information types." appears too late.  Some reordering might help.

The formatting of the table in Section 8.3 makes most of the columns
unreadable.  I would recommend a simple nested list.

In section 9, the use of the term "well-known" to refer to information that is
either public or widely available risks misinterpretation.

FWIW, I would reword this entire paragraph to say simply "Access control to
information published using ROLIE should use mechanisms that are appropriate to
the sensitivity of the information.  Primitive authentication mechanisms like
HTTP Basic Authentication [RFC7617] are rarely appropriate for sensitive
information."  I didn't find the remainder of the text on authentication
especially helpful.  The text seems to equivocate on the subject of federation,
where it would be easier to say nothing.

Also in Section 9, the use of the term "message" is used in the context of
using additional security controls.  I think that the word "representation" is
what was intended here.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 9 Oct 2017 09:18:50 -0700

> that discovery requires it.

I'll second this. 

Generally,  you only want to register a .well-known when there's a good story for why using a URL isn't possible. Typically, this is when you genuinely need to convey policy or metadata applicable to the whole origin. 

From 5785:

"""
well-known URIs are not intended for general information retrieval or establishment of large URI namespaces on the Web. Rather, they are designed to facilitate discovery of information on a site when it isn't practical to use other mechanisms; for example, when discovering policy that needs to be evaluated before a resource is accessed, or when using multiple round-trips is judged detrimental to performance.

As such, the well-known URI space was created with the expectation that it will be used to make site-wide policy information and other metadata available directly (if sufficiently concise), or provide references to other URIs that provide such metadata.
"""

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 9 Oct 2017 18:57:17 -0500

> requirement on any particular version of TLS, the use of "MUST" here is not

I think that one could make the case that using TLS 1.2 (or higher) greatly
facilitates having a secure system, and so it could plausibly be required
by a consuming protocol.

> needed.  Similarly, the prohibition on the use of 0-RTT is groundless.  The

I am a little surprised to hear you say that this prohibition is "groundless".
Given that we require consumers of TLS 1.3 0-RTT data to explictly specify
an application profile for how it may be used, with the intent to induce
a careful analysis of the security considerations for sending early data
messages, it seems quite reasonable to me that a protocol author might
wish to defer such a painstaking analysis and take the easy choice of
prohibiting early data.

-Ben

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Oct 2017 12:11:24 +1100

> facilitates having a secure system, and so it could plausibly be required

The problem here is that the protocol is actually HTTP.  And that
protocol has requirements already.  A recommendation to use TLS 1.2 is
fine, but that is already part of RFC 7525.

> wish to defer such a painstaking analysis and take the easy choice of

This is quite explicitly using HTTP, which has a profile (work in
progress).  If that profile is somehow inadequate, then a case should
be made in the draft explaining why (hence the choice of the word).  A
reference to TLS 1.3 also has the unfortunate effect of delaying
publication of this draft.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 9 Oct 2017 21:22:53 -0400

> facilitates having a secure system, and so it could plausibly be required

+1 and this has pretty much been standard practice on all protocols
using TLS for at least the last 3 years.  RFC7525 has been a
requirement on most protocols using TLS since it was published.  This
is a protocol that will carry sensitive data and strict requirements
are necessary.  Examples of data that might be exchanged with this
protocol include threat actor information or indicators of compromise.
Strict security is necessary and completely expected by those
deploying this protocol.

> wish to defer such a painstaking analysis and take the easy choice of

+1.  In the case of this protocol, there is no tolerance for replay
attacks.  Many other protocols use TLS and will have similar
requirements.  This is likely to be a theme.  The performance gain
isn't worth the tradeoffs - of defining a profile, risking
configuration mistakes, the careful analysis, and weighing the
security considerations.  The 0-RTT decision in the TLS WG has a big
impact on other protocols using it.

Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 9 Oct 2017 21:32:23 -0400

> publication of this draft.

Can you provide a pointer?  The profile is likely inadequate for this
and many other uses of HTTP/TLS if early data is permitted.  0RTT has
a large impact across many protocols including those that use
HTTP/TLS.

If there is no normative language, then it can continue on to be
published with the draft for TLS 1.3 being used.  This is an
application where security is very important, so decisions like this
that can be made now should be prior to implementers testing TLS 1.3.

Best,
Kathleen

-- 

Best regards,
Kathleen

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Oct 2017 12:55:54 +1100

> a large impact across many protocols including those that use

https://datatracker.ietf.org/doc/draft-ietf-httpbis-replay/
Editor's copy (with a number of changes):
http://httpwg.org/http-extensions/replay.html

> that can be made now should be prior to implementers testing TLS 1.3.

Currently there is normative language, and it wouldn't make sense to
make any sort of statement with respect to 0-RTT without making that
statement normative.  However, I think that it would be wiser to rely
on HTTP doing the right thing here.  I would of course encourage you
and the document authors to review the draft above to see if we're
making completely unsuitable recommendations.

I realize that security is very important here, but I don't think that
it is so significantly special that a whole new application profile of
HTTP is needed.  HTTP can be very secure with the right configuration.
Strong recommendations about good practices for both configuration and
operation are appropriate.  RFC 7525 is what I would use for that.
RFC 7525 covers all that the draft does and more.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 9 Oct 2017 23:05:53 -0400

Sent from my iPhone

> On Oct 9, 2017, at 9:55 PM, Martin Thomson <[email-masked]> wrote:
> 

I'll review and see if the WG participants can as well.  I think there will be many applications to follow with high security requirements and no tolerance for replay attacks.

> HTTP is needed.  HTTP can be very secure with the right configuration.

Configuration mistakes happen and lead to big problems.

> RFC 7525 covers all that the draft does and more.

Yes, I had pointed that out in my review.

Best,
Kathleen

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Oct 2017 14:45:51 +1100

> I'll review and see if the WG participants can as well.  I think there will be many applications to follow with high security requirements and no tolerance for replay attacks.

That is true, but it's not clear to me that this is a protocol that is
intolerant of replay.  AtomPub follows a pattern that limits exposure
fairly well.  The primary thing to safeguard in ROLIE is the
confidentiality of the content, and replay won't generally compromise
that.  The sorts of things you might see is duplicate resource
creation (we recommend against POST in early data for that reason; we
also recommend against PUT), and the sort of traffic analysis and
timing side channel information that reveals if resources exist or
have been updated (which shouldn't be an issue here).

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 13 Oct 2017 10:20:23 -0400

The telechat prep delayed my response.  Inline.

> have been updated (which shouldn't be an issue here).

I see what you are saying and that makes sense, but you also lose
forward secrecy with 0RTT and that is a problem.  I think we need to
accept that there will be uses of HTTP that will not allow for 0RTT.
In the draft you mentioned in the HTTP working group, section 3 even
starts out with, "When a server enables early data", meaning it won't
always be appropriate.  I do think that draft should be more clear on
the risks, with a pointer back to Section 2.3 of TLS 1.3.

I think there will also be cases where HTTP is used and the profile
isn't a fit.  Since some implementations of TLS 1.3 keep the streams
separate (0RTT and full negotiation), just using the full negotiation
stream will reduce configuration problems for implementers.  Lots of
security problems are the result of configuration mistakes and if we
can avoid them in places where it matters, we should.

The systems running ROLIE will be ones that enterprises will regard as
high value assets. Replay attack and lack of forward secrecy aren't
acceptable.  The same will be true of many other HTTP enabled
services.  A performance gain isn't worth the trade off.  Even with
the profile you've created, the server has the option to not enable
early data, although that's not as clear as I think it should be in
the draft and is something that would be good to improve,  If
developers implementing the HTTP profile only look at this draft, they
have to have enough context to understand the implications that they
must in turn ensure implementors of their code/applications using code
have the information to make appropriate decisions for their
environment.  I hope that's helpful enough for an update of your
profile draft.

My opinion is that for ROLIE, there is no need for 0RTT.  I'm not sure
a slight delay in publication would matter much since TLS 1.3 is
getting closer to publication.  If it is, we could also play with the
language so it's an informational reference if there is a rush.

Thanks for your thoughtful review.

-- 

Best regards,
Kathleen

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Oct 2017 11:45:59 +1100

On Sat, Oct 14, 2017 at 1:20 AM, Kathleen Moriarty
<[email-masked]> wrote:
> services.  A performance gain isn't worth the trade off.

My point isn't to reject this sort of analysis, which is possibly
correct, but to point out that this analysis is one that a deployment
makes based on the circumstances

Everyone thinks that their thing is a special snowflake, and that's
OK, but you are asking for a levy on all implementations that would
prevent use of 0-RTT in all deployments.  I think that is
inappropriate.  I don't want to see every draft that the IETF ever
published making its own assessment and a policy statement regarding
this particular feature.  (We don't mandate a particular
authentication mechanism here either.)

Note that TLS 1.3 permits resumption without forward secrecy.  It's
not widely implemented that way, but it is possible.  If you care
about forward secrecy (I'm not sure that it's especially critical in
this context given the time-sensitive nature of the information you
are talking about), then you have to make statements about that as
well.  But again, I would not on the same grounds: the purpose of this
work is to define what interoperability looks like, not to legislate
deployment configuration.  Explain the trade-off and let the
operational teams do their work.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 15 Oct 2017 20:42:57 -0500

Sorry for the slow response to this thread; I wanted to have a closer
read of the ROLIE document itself (and not just the cherry-picked
TLS-specific bits).

> authentication mechanism here either.)

Every draft doesn't have to; in the absense of an explicit statement
it is assumed that 0-RTT should not be used.

But, for protocols built on top of HTTP, perhaps things are not
as clear cut.

> operational teams do their work.

My main consideration is that the ROLIE document we're talking about
is a framework, and does not define any information types itself.  So,
you are asking the operational teams to know and anlayze not just what
events they are currently handling but also all types that might be
handled in the future, which seems like an intractable analysis for
them to perform.  But yes, you are right that a statement about forward
secrecy as a requirement would be appropriate.

I'm also quite reluctant to provide a general recommendation to send
client-authenticated requests in 0-RTT, as it still seems too risky to me.

I also don't see how preventing the use of 0-RTT is supposed to be
a "levy on all implementations".  It seems to only require *not* adding
additional code/logic to handle 0-RTT.  I could perhaps see calling it
a "levy on deployments" that are unable to take advantage of the
performance benefits, but given the large number of unknowns in what
will be conveyed via ROLIE, it seems to me an unwarranted risk to try
to take advantage of those benefits in general.

-Ben

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Tue, 17 Oct 2017 16:18:43 +0000

Martin,

Thanks for the great review. We've been working through your comments and preparing a -11 version. I'll have a full response to your comments out to the list once we've completed addressing them all, but wanted to open a discussion on a few points in the meantime.

The .well-known registration for /servicedocument has a use case/discovery story that we feel is important enough for registration, or at least for standardization. In the case where there is no standardized location template for the service document, a vendor/company/site that wants to stand up a ROLIE repository and provide regular syndicated information must provide a link to the service document somewhere on their regular site, or otherwise distribute the URL. While this potentially provides a means for humans to find the repository (although the link would likely be hidden in some strange place), it doesn't help automated tools locate the repository.

As a user of ROLIE, I'd like to be able to provide a tool with the hostname:port of a vendor whose syndicated information I'd like to receive, and have the tool return the status of any repository that is or in not hosted by that top level site. For example, I'd like to give a tool "www.microsoft.com" and have it provide me all the ROLIE (and non-ROLIE AtomPub if provided in the same ServDoc) Collections provided by that host. Without a .well-known registration, the standard would have to provide a defined non-/.well-known URL template location, which we felt was bad practice.

Its likely that the standard doesn't provide enough context around the /.well-known registration, and that adding more explanatory text around our discovery story would help make the need for a URL template more clear.

If the issue is with the use of /.well-known, and not with the standardized URL template, we could simply remove the .well-known registration and instead provide a non-registered requirement for a {host}/rolie/servicedocument URL template.

We agree that the discovery story for /categorydocument is decidedly weaker, as any out-of-line category documents would be linked to from the Service Document. We would open to dropping this registration/requirement outright as you suggest.

Thanks again for the thorough review,
Stephen Banghart

> -----Original Message-----
> From: mile [mailto:[email-masked]] On Behalf Of Martin Thomson
> Sent: Monday, October 09, 2017 1:08 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10
> 
> Reviewer: Martin Thomson
> 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
> 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
> document, I would say that the need for a .well-known resource is less well-
> justified than the service document.
> 
> 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
> 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.
> 
> being an unnecessary requirement - cipher suites that support certificate-
> based authentication of servers all allow for client authentication - this sort of
> 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.
> 
> 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
> 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.
> 
> 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
> that XML is actually good at.  Why can't users that require additional
> metadata use additional metadata as originally defined by Atom?  That is,
> replace <rolie:property name="urn:ietf:params:rolie:property:csirt-iodef-id"
> "public" information.  But workspaces don't really contain enough
> information to signal their status to a consumer of the information.  I would
> suggest mentioning this, removing the recommendation, or expanding on
> the manner in which the status of information is signaled.
> 
> Section 6.1.1 says "zero or more atom:category elements", but this
> contradicts the text and amendment to the schema in Section 6.1.
> 
> that the element needs to be updated when the contents of the feed
> change in any way.
> 
> than successful.  Do you want to mandate use of URIs instead?  This would
> apply to both link relations and the "src" attribute.
> 
> "urn:ietf:params:rolie:category:local" seems unnecessary.  Namespace URIs
> are cheap and it seems reasonable to experiment with feeds that produce
> non-ROLIE information by omitting the
> "urn:ietf:params:rolie:category:information-type"
> category, even if that feed might comply with the requirements of ROLIE.
> The other way to experiment would be to use the category, but define a way
> to identify "term" attributes that are for use in private or experimental
> contexts.
> 
> This statement from Section 9, "As described in the discovery section, DNS
> SRV Records are a possible secure solution to discovery." is false without
> further qualification.  SRV with DNSSEC might be secure, but a lot depends on
> the input to the discovery process and its provenance.
> 
> violations are available to a client or server, not third parties): "Proper usage
> of TLS as described in Section 5.3 will in many cases aid in the mitigation of
> these issues."  I think that you can strike this statement (most of the reason
> for use of TLS is justified by the security considerations anyway).
> 
> Nits:
> 
> information published using ROLIE should use mechanisms that are
> appropriate to the sensitivity of the information.  Primitive authentication
> mechanisms like HTTP Basic Authentication [RFC7617] are rarely appropriate
> for sensitive information."  I didn't find the remainder of the text on
> authentication especially helpful.  The text seems to equivocate on the
> subject of federation, where it would be easier to say nothing.
> 
> _______________________________________________
> mile mailing list
> [email-masked]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fmile&data=02%7C01%7Cstephen.banghar
> t%40nist.gov%7Caf3af91a1c684592007d08d50ed3d401%7C2ab5d82fd8fa4797
> a93e054655c61dec%7C1%7C0%7C636431225322845891&sdata=SykEasQlo1e
> MarYmKXSA5HsOUpTLyjd9rslyvZPpxak%3D&reserved=0