On 08/23/2013 12:16 AM, Joe St Sauver wrote:
> Hi,
>
> Recently had the chance to eyeball
>
> https://datatracker.ietf.org/doc/draft-young-md-query/
>
> a little. Ian encouraged me to join the list and share my feedback
> directly (looking at the archives, I see some familiar faces :-)).
Excellent feedback Joe, Thank you very much! Some comments
inline.
>
> My feedback (as a total outsider and clueless newb, take it for what
> you will or ignore it entirely, you won't hurt my feelings either way):
>
> -- 2.1 requires ("MUST") use HTTP version 1.1 per RFC2616, but 5.1
> urges ("RECOMMEND[S]") use of SSL/TLS at the transport layer,
> among other possible options. Does the requirement for HTTP 1.1
> per RFC2616 preclude SSL/TLS per RFC5246?
Good point. Suggest we reformulate to make it clear those
are not exclusive
> Will the 2.1 specific requirement that HTTP 1.1 *in particular*
> be used become problematic as the HTTP spec evolves? For example,
> I notice that the HTTPbis Working Group actually kicked out a
> dash 6 rev for the HTTP v2 spec just yesterday, see
> http://www.ietf.org/id/draft-ietf-httpbis-http2-06.txt (so I'm
> hopeful that at some point we'll move beyond RFC2616)
Agree. Lets say "HTTP 1.1 or later"
> -- 2.2 specifies that "all metadata retrieval requests MUST use
> the GET method" -- would this preclude the normal use of HEAD
> as an alternative to test for changed data, etc.?
Agree. Lets describe the use of the HEAD method for cache
validity checks.
> -- 2.5 appears to just recapitulate status codes from RCC2616. If
> so, rather than repeat them verbatim in this draft, I'd suggest
> that a reference simply be made to the appropriate section of
> the RFC.
Also good point.
>
> -- 2.6, Base URL: does the base URL terminate with a / ? If no
> trailing slash is specified, is one imputed/supplied?
I think we should mandate a trailing slash but also say that servers
SHOULD NOT assume that the client does the right thing - i.e the
normal stability paradigm (be conservative in what you send etc).
> -- 3.1, Identifiers: Prohibits an identifier starting with a left
> curly brace, but is silent about other potentially magical
> characters such as plus signs... (I assume that's because 3.2.1
> specifies that the identifier "must be properly URL encoded" but
> that requirement should really be part of of 3.1, not 3.2.1,
> shouldn't it?
I think we need to talk about this in the context of extending
the request format to support entity-attribute lookups.
>
> -- 3.1.1, Transforms: are the identifiers case sensitive? That is,
> 'md5' is mentioned as is 'sha1' -- is that equivalent to
> 'mD5' and 'Md5' and 'MD5', for example?
They should be case-insensitive.
>
> As a wanna-be crypto guy, I also have some concern about
> a newish spec specifying deprecated hashes (e.g., MD5 should
> really not be re the required "lowest common denominator"
> required transform for this or any other purpose)
We should do a threat-analysis....
> -- 3.2.1, Reqest: How long can a request be? Hypothetically, what
> if I have a laundry list of a thousand IDs, all transformed into
> SHA1 hashes? That could make for a long request!
... or sha256
> In 3.2.1, are the curly braces around the IDs literal curly braces
> or is that just a semantic representation issue?
cf note about needing to discuss {} above
> I'd also prefer to see specificity wrt what happens for an ill-formed
> request (e.g., an unterminated or otherwise malformed ID value, for
> example, on a query that requests multiple IDs -- should the query
> fail, or should partial results be returned or ?)
agree
> -- 4.3, Content Compression: nice to see gzip mentioned
strongly agree!
> -- 5.1, Integrity: Seeing that an integrity check is only RECOMMENDED
> rather than REQUIRED bothers me, a lot. I think this is a fundamental
> mistake. Content integrity checks should be MANDATORY IMHO.
agree
> -- 5.2, Confidentiality: The recommendation that requester and
> responder support "SSL/TLS" both in 5.2 and in 5.1 is insufficiently
> specific (I know, I beat up on the document for being TOO specific
> about the HTTP 1.1 aspect, and now I whine about it being too vague
> on the SSL/TLS aspect, sometimes you just can't win :-)).
>
> The reason why I flag the issue of SSL/TLS spec is that there's a
> huge, huge, difference between early versions of the SSL/TLS spec
> and later versions. I'd really like to see a push for 1.2 (or
> later, if we want to worry about what happens in the future) if at
> all possible
agree, although I'm not sure we should mandate TLS if we require
content integrity checks. tls gets in the way of caching architectures
that I've recently become a fan of [*]
> -- 5.3, Authentication: Authentication appears to be optional, should
> it be? I'd also love to see support for something better than just
> HTTP basic and client certs, although I recognize the potential for
> recursive dependencies if you're trying to retrieve metadata about
> auth options, and you need to auth as part of that, etc.
The *only* usecase for autn I've heard for MDX is when you use
client cert using the keys found in the metdata itself.
I'm leaning towards describing that case and no other for authn.
> Thanks for the chance to offer feedback on this, and thanks for all
> the work that folks have already done on this.
Thank you!!! It is by far the best review we've had so far.
Cheers Leif
> Regards,
>
> Joe
> _______________________________________________
> mdx mailing list
> mdx at lists.iay.org.uk
> http://lists.iay.org.uk/listinfo.cgi/mdx-iay.org.uk
[*] shameless plug: http://samlbits.org