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

[Martin Thomson <[e-mail]>]

Thanks Stephen,

Most of this looks good (I'll trust that your representation of the
changes is accurate rather than wade through XML, though I have
reviewed some of the changes).

On Fri, Oct 20, 2017 at 3:24 AM, Banghart, Stephen A. (Fed)
<[e-mail]> wrote:
>> 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.

I'm going to push on this one more time.  0-RTT does not necessarily
compromise forward secrecy.  It is also entirely possible to deploy
0-RTT without risk of replay attack.  But these facts don't seem
persuasive because it is possible to implement the feature with these
risks.

The text you provide indicates that it is replay you are concerned
about.  Do you have any analysis that indicates that someone deploying
a server that enables early data would produce harm?  Does that
analysis suggest any other alternative mitigation strategies?

Again, I would prefer that the draft remain silent on this subject.  I
realize that I'm in the rough here, but I consider this to be a test
case for this.  The next person who uses HTTP will see your text,
notice that it is good, and copy it.  It becomes precedent to forbid
the use of 0-RTT and we forget *why*.  I would prefer that this text
be better motivated if it is included.

>> User authentication is under-specified.

The new text is much more concise and targeted, thank you.

>> 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.)
>
> Atom:content has an attribute for media type, which provides information about the serialization of the content representation. In many cases, we found that different formats can appear for the same content within the same media type. For example, the same piece of information may be represented using two different XML Schemas. The rolie:format element allows the entry to clarify which "format" its using beyond which serialization it is using. Ultimately the format element is not registered anywhere, nor is its contents particularly standardized. We're providing the element as a tool for repository producers to use.

This is, at least in my opinion, a mistake.  It creates another layer
of content negotiation that is not visible to HTTP.  If the same
information can be presented in two different formats, why is it not
possible to have two media types?  Or at least a parameterized media
type that identifies the format.

The problem with defining elements is that they are costly.  Not so
much to specify, but to implement correctly.  If you are able to rely
on existing mechanisms, you should do that as much as possible.

It doesn't sound like you have a concrete use case for this, which
makes me nervous.

>> 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.
>
> The latter example you provide is still possible, as unrecognized elements in ROLIE/Atom don't cause validation to fail, but are just potentially ignored by the client/server. The rolie:property element allows automated systems to have a globally available "vocabulary" of potentially available properties, that can be used to populate tables or fields in automated systems.

I realize that the set of attributes you have might be useful in this
context.  But defining them in XML would be much easier.  You don't
create a new mechanism for expressing key-value pairs, and the
registry that goes with it.  That seems like a minor cost, but like in
the previous case, the choice to define another bespoke mechanism
comes with hidden costs.  Why bother when you have a perfectly
workable mechanism available to you already?

>> 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.
>
> We wanted to stay in line with the requirements in Atom, if this becomes an issue it may be worth re-examining.

This is your chance.  You don't get to go back or re-examine once your
protocol is widely deployed.