draft-ietf-conneg-feature-sets-at-urls-00.txt

At 11:18 26/02/99 -0800, Bill Newman wrote:
>I've just submitted my feature-sets-at-URLs proposal as an Internet
>Draft.
[...]

Bill,

I've just read through the version of your draft submitted to the list --I
don't know if there are any changes in the published I-D-- and would like
to make some observations.  In making these observations, I don't think we
have any fundamental difference about the goals, or the broad means of
achieving them.

My primary observation is that your draft covers two matters which I would
prefer to see treated separately:
  (1) feature set syntax extensions, and
  (2) profiling of mechanisms for resolving URLs in feature set expressions
I think that matters of representation and mechanism should be separated so
that they can be developed independently of each other.

I note that the syntax extensions you propose very much overlap the
proposals in my submission <draft-ietf-conneg-feature-hash-00.txt>.  In the
scheme of things, the differences I see are quite small so finding
consensus between these proposals should not be a problem.

The profiling of resolution mecahisms is a reasonable goal that I have not
addressed.  This suggests that between us we might aim for two WG submissions:

   Syntax extensions for abbreviating media feature sets ...
   Resolving URLs in media feature sets

The remainder of this message contains comments about specific portions of
your text:

>Abstract
>
>   Other Internet Drafts from the CONNEG working group describe a
>   syntax[SYNTAX] and vocabulary[FEATURES] for negotiating media feature
................................................[---------]
I'd suggest "representing".  Negotiation, per se, is not covered there.

>   sets which can be used for transmission of a message.
[...]

>   ... For example, a
>   feature set may specify that full color output up to 800x600 pixels
>   is supported, or that output can have up to 300 dots per inch. These
>   feature sets can be arbitrarily complex, and typical feature set
.................................................[-----]
I think it's too soon to say "typical".  Your legitimate meaning is still
present if this word is deleted.

>   expressions may be hundreds of bytes in length.
[...]


>Syntax changes
>
>   In section 4.1 of the syntax document[SYNTAX], "Textual
>   representation of predicates", the definition of "filter" is to be
>   amended so that it reads
>
>      filter       = "(" filtercomp ")" *( ";" parameter )
>                   / "<" absoluteURL ">" *1( ";" "md5" "=" md5value )
>      md5value     = 16*HEX
......................^^
MD5 is a 128-bit value, which needs 16 bytes or 32 hex digits to represent.



[...]
>   syntax document[1]. Thus, it is possible for an implementation to
>   support both this extension and the extension described in 6.1.3, in
>   which case a filter will be described by
>
>      filter = "(" filtercomp ")" *( ";" parameter )
>             / "<" absoluteURL ">" *1( ";md5=" md5value )
....................................^^^..................^
RFC2234 allows "[ ... ]" as equivalent, which IMO is easier to read.

>             / "(" filtercomp *( ";" parameter ) ")"
>               "where" named-pred-sequence "end"

Some observations about this syntax:

(a) Using the notation of RFC2234, this can be described as:
       filter =/ "<" absoluteURL ">" ...
i.e. without need to repeat other elements from [SYNTAX].

(b) this formulation syntactically binds "md5" to the URL form, and
prohibits other parameter values in this position.  Here is another
possible approach:
       filter    =/ "<" absoluteURL ">" *( ";" parameter )
       parameter =/ "md5" "=" 32*HEX
This would syntactically allow "md5" to be applied to any "filter", and
allow any other parameter (e.g. "q=") to be applied to the URL form.
QUESTION:  is this an appropriate approach?

>   The absoluteURL field holds a URL where a filter description may be
>   found. The md5value field, if present, holds a hexidecimal
>   representation of an MD5 digest[MD5] of the contents of the URL.

You do not mention whether the md5 is calculated over a normalized form of
the identified resource.  (I assume that you intend not;  if so, I'd state
this explicitly so that it is made clear that the resource must be
transferred *exactly*, with any embedded layout, whitespace, etc.)
Personally, I favour some simple normalization so that, for example,
whitespace munging by feature set transports does not affect the validity
of the result.

>Interpretation of URLs
>
>   Any implementation of this extension MUST be able to process URLs
>   with an "http" scheme. Other forms of URL MAY be supported.

My initial response to this was "why MUST http"?  But, on reflection, I
accept that it is useful to have some common mechanism defined.  But I can
imagine cases where "http" is not appropriate to support:  this is one
reason that I would prefer to see the access mechanisms defined separately,
so that the syntax can be used without a specific mechanism for
applications where this is appropriate.

In summary, I am content with this IFF it is stated separately from feature
set syntax extensions.

>   Any implementation of this extension MUST be able to process data
>   returned with the MIME type "text". Other types MAY be supported.

Seems reasonable.

One thought I had was that a multipart containing human- and machine-
readable parts might be used (a bit like multipart/report), so that systems
without content negotiation could offer the user a choice.


>Security Considerations

I thought this section had some good material, and may be an important
aspect of this memo.

>   Further, by specifying the MD5 hash, storing a literal copy of the
>   desired feature set locally, and being able to repeat a failed
>   request without URL abbreviation, the device requesting content
>   negotiation can reduce all these new attacks to degradation of
>   service. When the adversary doesn't interfere, negotiation would
>   require a single round trip over the primary communications link,
>   carrying roughly 40 bytes of compressible URL and 16 bytes of
>   uncompressible MD5 hash. When the adversary does interfere,
>   negotiation requires the first round trip (which fails), followed by
>   retransmissing of the entire literal feature set over the primary
>   link. Thus, the effect of interference is merely to slow the
>   negotiation, not to change its result.

I *think* you are saying here that the MD5 can be used as a cache
validator, and hence optimize feature set transfers or provide a recovery
mechanism if a URL cannot be resolved (for reasons of system failure or
active attack).

>From a security viewpoint, I don't believe this use of md5 alone can defeat
an active attack.  Any active attack would, I presume, be capable of
substituting both features AND md5 values.  But in this case, the attacker
would need to intercept the negotiation exchange AND the URL resolution
exchange -- increasing the difficulty of such an attack but by no means
preventing it.  To fully prevent active attacks, I think some form of
signature is required.

>   It is expected that only a small minority of content negotation
>   applications will be sufficiently critical that such interference
>   will be a significant concern. After all, given that you have an
>   adversary with the capable of tampering with communications between
>   your servers, you are likely to have a long list of problems, and
>   interference with content negotiation may be far from the most
>   serious problem on that list. For this reason, and because the
>   primary motivation for this extension is to allow content negotiation
>   to proceed with minimal bandwidth usage on the primary channel, the
>   MD5 checksum is optional.

I think you make a fair point and I don't argue your conclusion, but I
don't fully agree with its justification.  I'm not sure where the
expectations of criticality of content negotiation come from.

If content negotiation becomes a generally used feature of a widely used
messaging system then its operation starts to become critical, I believe.
Under these circumstances, I suggest that negotiation exchanges should be
protected by some form of signature.  Ultimately, this is a feature of the
application that uses content negotiation.

#g

------------
Graham Klyne
([email protected])