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

[Martin Thomson <[e-mail]>]

I just wanted to follow up on this.  I see that the draft has been
revised a few times, but I haven't seen any response to my comments
about the XML, or any changes related to them.

I ask, because IANA is asking about the XML registrations.  If the
working group consensus is that I'm in the rough, let me know and I'll
tell IANA that the schema is good to go.

On Fri, Oct 20, 2017 at 10:53 AM, Martin Thomson
<[e-mail]> wrote:
> 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.