Re: [Gen-art] Gen-ART LC Review of draft-bryan-metalinkhttp-19

[Ben Campbell <[e-mail]>]

Update: I looked at the diffs for version 20, and I think the discussion below accurately reflect the changes--so please consider this a followup review of version 20.

Thanks!

Ben.

On Feb 16, 2011, at 5:15 PM, Ben Campbell wrote:

> Thanks for the quick response. I haven't had a chance to look at the new version yet, but here are my responses to your email comments. I removed sections where I had no further (non-trivial) comment. Please consider any removed parts to be the same as an "Okay" response.
> 
> Thanks!
> 
> Ben.
> 
> On Feb 14, 2011, at 4:43 PM, Anthony Bryan wrote:
> 
> [...]
> 
>> was there supposed to be a comment along with
>> 
>> -- section 2, 4th paragraph: "HTTP mirror servers SHOULD share the
>> same ETag policy as the originating Metalink server."
>> ?
> 
> I responded to this one below.
> 
>> 
>> On Fri, Feb 11, 2011 at 6:46 PM, Ben Campbell <[e-mail]> wrote:
> 
> [...]
> 
>>> 
>>> -- Section 1, paragraph 1, first sentence:
>>> 
>>> Is this really intended as an alternative to Metalink/XML? It seems like more of a complementary approach than an alternative one.
>> 
>> well...you could use either, or both :)
>> 
>> "Metalink/HTTP is an alternative and complementary representation of
>> Metalink information,"...
>> ?
> 
> WFM
> 
>> 
>>> -- section 2, third paragraph:
>>> 
>>> If they must have the same eTag policy, should this document not specify at least one mandatory-to-implement policy?
>> 
>> SHOULD share the same ETag policy.
>> 
>> I added:
>> 
>> "It is up to the administrator of the Metalink server to communicate
>> the details of the shared ETag policy to the administrators of the
>> mirror servers so that the mirror servers can be configured with the
>> same ETag policy."
> 
> My comment was about policy implementation, not policy configuration. 
> 
> Do you expect the method to generate ETags to be configurable in most implementations? Is that the case among common HTTP servers today? (That's not rhetorical--I don't know the answer.) And even if it is, is there a risk that there won't be a common selection between implementations? It doesn't help to tell an administrator to select a certain policy unless his software can actually do it. If there was a mandatory-to-implement policy, then that shouldn't happen.
> 
> 
> [...]
> 
>> 
>>> -- section 10.2:
>>> 
>>> What can an implementor do to mitigate spoofing?
>> 
>> nothing, I'm aware of?
>> 
>> added:
>> As with all downloads, users should only download from trusted sources.
> 
> Hmm. What does "trusted" mean in context? Does that have implications on authentication of the source and integrity protection of the download session? (i.e. TLS)?
> 
> [...]
> 
>>> --- Nits/editorial comments:
>>> 
>>> -- section 2, 4th paragraph: "HTTP mirror servers SHOULD share the same ETag policy as the originating Metalink server."
>> 
>> what's wrong here?
> 
> Oops, sorry, cut-and-paste error. My comment was "This seems redundant with a similar statement in the previous paragraph"
> 
> [...]
> 
> 
>>> -- section 7.1.1, general:
>>> 
>>> This whole section switches to an almost stream-of-consciousness style. It has very long sentences with many comma separated clauses that are hard to follow. It really needs to be rewritten to be more readable and precise.
>> 
>> hahaha :)
>> 
>> this is my fault as a bad editor & a non-native English speaker co-author.
>> 
> 
> On reflection, I think my comment was a little harsh. But another pass with some attention to style in the section would help.
> 
> 
>>> -- section 7.1.1, paragraph 3:
>>> 
>>> Paragraph seems self contradictory. How is guaranteeing correct content different than verifying integrity?
>> 
>> the server sends the correct content  but there can be errors during transfer.
>> 
>> maybe this is not explicit enough. might need to condense some of this down.
> 
>> earlier we state:
>> Error detection requires Instance Digests to detect errors in transfer
>> after the transfers have completed.
>> 
> 
> I think a rewording would help, as I took "guaranteeing correct content" to mean "guaranteeing the client receives correct content" rather than "guaranteeing the server sends correct content".
> 
> [...]
> 
>> 
>>> -- section 7.1.2, 2nd paragraph: "If the object cryptographic hash does not match the Instance Digest then fetch the Metalink/XML if available, where partial file cryptographic hashes can be found, allowing detection of which server returned incorrect data."
>>> 
>>> I can't parse this sentence.
>> 
>>  If the cryptographic hash of the object does not match the Instance
>>  Digest from the Metalink server, then the client SHOULD fetch the
>>  Metalink/XML (if available) that could contain partial file
>>  cryptographic hashes which will allow detection of which mirror
>>  server returned incorrect data.  Metalink clients SHOULD figure out
>>  what ranges of the downloaded data can be recovered and what needs to
>>  be fetched again.
> 
> That's better, but how about breaking it up a bit more, as in the following:
> 
> "  If the cryptographic hash of the object does not match the Instance Digest from the Metalink server, then the client SHOULD fetch the Metalink/XML (if available). This may contain partial file cryptographic hashes which will allow detection of which mirror server returned incorrect data.  Metalink clients SHOULD use the Metalink/XML data to figure out what ranges of the downloaded data can be recovered and what needs to be fetched again. "
> 
> [...]
> 
>> 
>>> -- section 10.2 "In that case, this could deceive unaware downloaders that they are downloading a malicious or worthless file."
>>> 
>>> Sentence does not make sense. Does the attacker with to deceive them into downloading a malicious file, or convince them that they are when they are not?
>> 
>> "In that case, this could deceive unaware downloaders into downloading
>> a malicious or worthless file."
>> 
> 
> WFM