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

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Nov 2017 09:28:43 +1100

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
<[email-masked]> 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)
> <[email-masked]> 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.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Nov 2017 09:28:43 +1100

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Fri, 3 Nov 2017 15:52:24 +0000

Martin,

Could you clarify which XML issues you mean? The rolie:format / rolie:property elements or something else?

rolie:format is necessary beyond media types for differentiating between formats that don't have their own media type, and for making clear the difference between a "media type" and a "format". Media types provide information about the serialization of content, but don't actually define the model of the content. Schemas can be used to help the parser understand the content, rolie:format provides a means to describe both the model and the schema of the content. We could solve this by providing some modified media type, but this would require just as much specification as our current solution. As an example, how would we best specify to a consumer that the content element links to an IODEF document? It's media type is XML, but there remains information that can only be gleaned  by downloading the entire content file.

rolie:property has a couple of advantages over defining the key-value pairs in XML. Defining new elements in XML is expensive. In the ROLIE core document we define 4 new properties, which would yield 4 new elements in the schema. In our Software Descriptor we define another software specific property, and we may add more as we iterate the draft. There are two other extensions in development that may add new properties as well. rolie:property provides a means to easily define new properties without generating a huge number of new elements. 

Would it be useful to clarify this further in the specification, or do you still have technical concerns?

Thanks,
Stephen

> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: Thursday, November 02, 2017 6:29 PM
> To: Banghart, Stephen A. (Fed) <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10
> 
> 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.
> 
> >>> 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.
> >
> >>> 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.
> >
> >>> 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"
> >>> <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.
> >
> >>> 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.
> >>

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Fri, 3 Nov 2017 15:52:24 +0000

Martin,

Thanks,
Stephen

---

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Nov 2017 11:58:12 +1100

> rolie:format is necessary beyond media types for differentiating between formats that don't have their own media type, and for making clear the difference between a "media type" and a "format". Med…

You describe the exact purpose of a media type.  The advantage of
media types being that the type is available in more places than just
a ROLIE Feed.  For instance, you can use content negotiation in HTTP
to ensure that you get something you can consume.

I'm not saying that this is more or less specification, it's just that
you get more value from a media type than you do with this sort of
mechanism.  Even if it means minting a few more media types.

Furthermore, identifying a schema is usually inadequate to describe
the relevant parts of an XML format.  There are many generic container
formats in XML for which listing the top-level schema is pointless.
ROLIE itself suffers from this because it uses Atom.  It's not even
possible to list schemas, because that loses critical information
about what elements are used in what contexts.  In order to properly
capture the full transitive closure of formats, you need something
considerably richer (I once thought that this worth doing/possible,
but that idea was quickly abandoned without really testing it fully:
https://tools.ietf.org/html/draft-thomson-simple-expressing-xml-support-00).

> rolie:property has a couple of advantages over defining the key-value pairs in XML. Defining new elements in XML is expensive. In the ROLIE core document we define 4 new properties, which would yie…

I disagree on the XML - the amount of effort you put in to define your
XML properties is pretty minimal: a namespace and schema, plus
semantics of each of the fields.  You gain the ability to properly
constrain the grammar (for example, you could use xs:dateTime for
content-updated-date instead of prose).  You have demonstrated how
easy that can be in this document (by defining rolie:property itself).

I've dealt with extensible fields like this in the past (see RFC
6848), and it's no more difficult to pair up ns+localname and simple
value than it is to pair up URN and simple value.

As proposed, you also have a new registry for these fields, which is
strictly more costly.

p.s., I thought you were going to remove
"urn:ietf:params:rolie:property:local", but it is still in -13.  That
would of course be moot if you did as I suggest.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Nov 2017 11:58:12 +1100

https://tools.ietf.org/html/draft-thomson-simple-expressing-xml-support-00)