Skip to main content

Metalink/HTTP: Mirrors and Hashes
draft-bryan-metalinkhttp-22

Revision differences

Document history

Date Rev. By Action
2012-08-22
22 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
22 (System) post-migration administrative database adjustment to the No Objection position for Robert Sparks
2012-08-22
22 (System) post-migration administrative database adjustment to the No Objection position for Peter Saint-Andre
2012-08-22
22 (System) post-migration administrative database adjustment to the No Objection position for Ralph Droms
2012-08-22
22 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-08-22
22 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2011-03-18
22 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2011-03-17
22 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2011-03-17
22 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2011-03-17
22 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-03-17
22 (System) IANA Action state changed to In Progress
2011-03-17
22 Cindy Morgan IESG state changed to Approved-announcement sent
2011-03-17
22 Cindy Morgan IESG has approved the document
2011-03-17
22 Cindy Morgan Closed "Approve" ballot
2011-03-17
22 Cindy Morgan Approval announcement text regenerated
2011-03-16
22 Alexey Melnikov Removed from agenda for telechat
2011-03-16
22 Alexey Melnikov Note field has been cleared
2011-03-16
22 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss
2011-03-12
22 Alexey Melnikov [Note]: changed to 'Lars, please review the RFC Editor note to see if it addresses your concern'
2011-03-11
22 Alexey Melnikov Ballot writeup text changed
2011-03-10
22 Lars Eggert
[Ballot comment]
My original comment said:

  The document is generally pretty sloppy in its use of
  RFC2119 terms; it would be very good …
[Ballot comment]
My original comment said:

  The document is generally pretty sloppy in its use of
  RFC2119 terms; it would be very good if the authors would go over it
  once more.

The specific instances that I mentioned have been fixed, but I don't see
any other changes. Did the authors go over the document once more?
2011-03-10
22 Lars Eggert
[Ballot discuss]
Discuss text: (last edited 2011-03-10)

Section 7.:
>    Metalink clients MUST limit the number of parallel connections to
>    mirror servers, …
[Ballot discuss]
Discuss text: (last edited 2011-03-10)

Section 7.:
>    Metalink clients MUST limit the number of parallel connections to
>    mirror servers, ideally based on observing how the aggregate
>    throughput changes as connections are opened.  It would be pointless
>    to blindly open connections once the path bottleneck is filled.

I of course agree with this requirement, which came out of the follow-up
discussion of my original discuss.

Can we suggest an actual mechanism, however? For example, could we
agree to say something like "after establishing a new connection, a
client SHOULD monitor whether the aggregate throughout over all connections
that are part of the download increases. The client SHOULD NOT open additional
connections during this period. If the aggregate throughput has increased,
the client MAY open an additional connection and repeat these steps. Otherwise,
the client SHOULD NOT open a new connection until an established one closes."

Basically, I'd like us to give client implementors some more guidelines about
what we think a suitable mechanism would be.
2011-03-09
22 Dan Romascanu
[Ballot comment]
If the draft is based on the experiences made in a project the community would like to know more on the project. It …
[Ballot comment]
If the draft is based on the experiences made in a project the community would like to know more on the project. It would be good to mention in the Introduction section of the draft the open source project, what it does and the experience made based on the project, and also provide a reference to the project in the references section.
2011-03-04
22 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Discuss
2011-03-04
22 Alexey Melnikov Ballot writeup text changed
2011-03-04
22 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-03-04
22 (System) New version available: draft-bryan-metalinkhttp-22.txt
2011-03-04
22 Alexey Melnikov Placed on agenda for telechat - 2011-03-17
2011-03-04
22 Alexey Melnikov [Note]: 'Lars, please review the updated version to see if it addresses your concern' added
2011-03-03
22 Cindy Morgan Removed from agenda for telechat
2011-03-03
22 Cindy Morgan State changed to IESG Evaluation - Defer::Revised ID Needed from IESG Evaluation - Defer.
2011-03-03
22 Lars Eggert
[Ballot discuss]
INTRODUCTION, paragraph 4:
>    This document specifies Metalink/HTTP: Mirrors and Cryptographic
>    Hashes in HTTP header fields, a different way to …
[Ballot discuss]
INTRODUCTION, paragraph 4:
>    This document specifies Metalink/HTTP: Mirrors and Cryptographic
>    Hashes in HTTP header fields, a different way to get information that
>    is usually contained in the Metalink XML-based download description
>    format.  Metalink/HTTP describes multiple download locations
>    (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures,
>    and other information using existing standards for HTTP header
>    fields.  Clients can use this information to make file transfers more
>    robust and reliable.

  DISCUSS: The document title and this summary aren't really accurate.
  In addition to describing how to store Metalink info in HTTP header
  fields, a large part of the document (Section 7) is actually
  specifying how Metalink clients MUST/SHOULD/MAY operate.


Section 7., paragraph 13:
>    If the object is large and gets delivered slower than expected, then
>    the Metalink client MAY start a number of parallel ranged downloads
>    (one per selected mirror server other than the first) using mirrors
>    provided by the Link header fields with "duplicate" relation type.
>    Metalink clients SHOULD use the location of the original GET request
>    in the "Referer" header field for these ranged requests.

  DISCUSS: I realize that this spec doesn't really cover the client, but
  I find this description of permitted client operation problematic.
  What it basically says is "if the download is slow, open more
  connections." This is NOT a good general practice. There need to be
  limits on the number of parallel connections, ideally based on
  observing how the aggregate throughput changes as connections are
  opened - blindly opening connections once the path bottleneck is
  filled is pointless. (There is some text later in this section that
  goes in this direction, but not far enough.)
2011-03-03
22 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss
2011-03-03
22 Ralph Droms
[Ballot comment]
I've cleared my DISCUSS.

1) Resolved.

2) Is there a registry for the various attributes references in this
document, including "pri", "pref", "geo", …
[Ballot comment]
I've cleared my DISCUSS.

1) Resolved.

2) Is there a registry for the various attributes references in this
document, including "pri", "pref", "geo", etc.?  If not, in my opinion
it would be beneficial to give a list and some formal definitions of
the attriubtes; at least, some indication that the attributes are
defined in this document.

(added 2011/3/3) The latest rev almost resolves this comment.  My
remaining comment is admittedly pedantic and just a nit, based on
avoiding the use of passive voice:

  The following OPTIONAL attributes are defined:

    o  "depth" : mirror depth in Section 3.4.
    o  "geo" : mirror geographical location in Section 3.2.
    o  "pref" : a preferred mirror server in Section 3.3.
    o  "pri" : mirror priority in Section 3.1.

Is this text the authoritative definition for the OPTIONAL attributes
or are they defined somewhere else and the definitions repeated here?
2011-03-03
22 Ralph Droms [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss
2011-03-03
22 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-03-02
22 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-03-02
22 Alexey Melnikov Ballot writeup text changed
2011-03-02
22 Alexey Melnikov Ballot writeup text changed
2011-03-02
22 Alexey Melnikov Ballot writeup text changed
2011-03-02
22 Alexey Melnikov [Ballot discuss]
From the GenArt review:

Also, is there a risk the initial server could cause a loop by pointing to _itself_?
2011-03-02
22 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Discuss from Yes
2011-03-02
22 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-03-02
22 Dan Romascanu
[Ballot comment]
1. If the draft is based on the experiences made in a project the community would like to know more on the project. …
[Ballot comment]
1. If the draft is based on the experiences made in a project the community would like to know more on the project. It would be good to mention in the Introduction section of the draft the open source project, what it does and the experience made based on the project, and also provide a reference to the project in the references section.

2. The document does not have a Terminology and Abreviations section, which would be very useful to make it more readable
2011-03-02
22 Dan Romascanu
[Ballot discuss]
The OPS-DIR review performed by Mehmet Ersue pointed to a number of problems and in-accuracies in the text. Many of them were fixed …
[Ballot discuss]
The OPS-DIR review performed by Mehmet Ersue pointed to a number of problems and in-accuracies in the text. Many of them were fixed in the last revision, there is one left which must be addressed before I can approve this document.

1. In section 3.1:

  Entries for mirror servers are listed in order of priority (from most
  preferred to least) or have a "pri" value, where mirrors with lower
  values are used first.

This is too vague and risks to be interpreted differently. What does 'mirrors with lower values' mean? Is this about the value of the "pri" optional attribute assigned to each mirror server, where lower value of the attribute equals higher prioroty? Or something else? Please explain to avoid mis-interpretations.
2011-03-02
22 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded
2011-03-01
22 Adrian Farrel
[Ballot comment]
Section 1...

"extremely minimal" means what? It either minimal or it isn't.

---

Section 3.1

  Entries for mirror servers are listed in …
[Ballot comment]
Section 1...

"extremely minimal" means what? It either minimal or it isn't.

---

Section 3.1

  Entries for mirror servers are listed in order of priority (from most
  preferred to least) or have a "pri" value, where mirrors with lower
  values are used first.

  This is purely an expression of the server's preferences; it is up to
  the client what it does with this information, particularly with
  reference to how many servers to use at any one time.

There is a contradiction between "are used first" and the second
paragraph that says the client can do what it likes. Maybe the word
"priority" and the "pri" value are poor choices since they reflect only
a preference.
2011-03-01
22 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-03-01
22 Alexey Melnikov Ballot writeup text changed
2011-03-01
22 Alexey Melnikov Ballot writeup text changed
2011-03-01
22 Alexey Melnikov Ballot writeup text changed
2011-03-01
22 Robert Sparks
[Ballot comment]
(I'm moving these points to a comment based on -21 and the email conversation that followed. The changes discussed
in that email thread …
[Ballot comment]
(I'm moving these points to a comment based on -21 and the email conversation that followed. The changes discussed
in that email thread will satisfy these points.)

1) What prevents a malicious server from returning a 200 with many Link: headers, all indicating rel=duplicate, perhaps indicating non-overlapping subsets of the entity, and all pointing to a victim, driving many, possibly parallel, connection attempts?

2) When a Link (indicating an HTTP resource) is followed, does anything prevent that referenced server from also replying with MetaLink headers in its response? If not, what prevents loops, intentionally or unintentionally created, from being followed? If a client would automatically follow these, especially in parallel, exponential attacks against the victims in item 1) are possible.  At the very least, a client could be sent into an infinite ping-pong loop.
2011-03-01
22 Robert Sparks [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss
2011-03-01
22 Peter Saint-Andre [Ballot Position Update] Position for Peter Saint-Andre has been changed to No Objection from Discuss
2011-03-01
22 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2011-03-01
22 Alexey Melnikov Ballot writeup text changed
2011-03-01
22 Alexey Melnikov Ballot writeup text changed
2011-03-01
22 Alexey Melnikov Ballot writeup text changed
2011-03-01
22 Alexey Melnikov Ballot writeup text changed
2011-02-28
22 Sean Turner
[Ballot discuss]
This is an updated discuss:(the author apparently knows how to use the datatracker ;)  Numbering is retained.

#9) SHA-256 is a SHOULD, but …
[Ballot discuss]
This is an updated discuss:(the author apparently knows how to use the datatracker ;)  Numbering is retained.

#9) SHA-256 is a SHOULD, but there's no MUST implement hash alg.  How are you going to get interoperability with a MUST hash alg?
2011-02-27
21 (System) New version available: draft-bryan-metalinkhttp-21.txt
2011-02-19
22 Alexey Melnikov Ballot writeup text changed
2011-02-17
22 Alexey Melnikov State changed to IESG Evaluation - Defer from In Last Call.
2011-02-17
22 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2011-02-16
22 Tim Polk
[Ballot comment]
I support Sean's discuss on signature formats.  There is nothing wrong with OpenPGP, and it would be fine to make that the mandatory …
[Ballot comment]
I support Sean's discuss on signature formats.  There is nothing wrong with OpenPGP, and it would be fine to make that the mandatory to implement, but the installed base with X.509 would seem to justify including S/MIME signatures.

I also share Robert's and Peter's concerns about amplification and DoS attacks.
2011-02-16
22 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded
2011-02-16
22 Tim Polk
[Ballot comment]
I support Sean's discuss on signature formats.  There is nothing wrong with OpenPGP, and it would be fine to make that the mandatory …
[Ballot comment]
I support Sean's discuss on signature formats.  There is nothing wrong with OpenPGP, and it would be fine to make that the mandatory to implement, but the installed base with X.509 would seem to justify including S/MIME signatures.
2011-02-16
22 Ralph Droms
[Ballot comment]
1) In section 2:

  ETags could be based on the file
  contents (cryptographic hash) and not server-unique filesystem
  metadata.

I'm …
[Ballot comment]
1) In section 2:

  ETags could be based on the file
  contents (cryptographic hash) and not server-unique filesystem
  metadata.

I'm not sure about the intention of this statement.  Perhaps:

  For example, it would be better to derive an ETag from a
  cryptographic hash of the the file contents than on server-unique
  filesystem metadata.

2) Is there a registry for the various attributes references in this
document, including "pri", "pref", "geo", etc.?  If not, in my opinion
it would be beneficial to give a list and some formal definitions of
the attriubtes; at least, some indication that the attributes are
defined in this document.
2011-02-16
22 Ralph Droms
[Ballot discuss]
Following up on Lars' DISCUSS, this text from section 2 also
describes requirements on ETags:

  To have the same ETag policy means …
[Ballot discuss]
Following up on Lars' DISCUSS, this text from section 2 also
describes requirements on ETags:

  To have the same ETag policy means that ETags are
  synchronized across servers for resources that are mirrored, i.e.
  byte-for-byte identical files will have the same ETag on mirrors that
  they have on the Metalink server.

This text needs to be reconciled with the answer to Lars' DISCUSS.
2011-02-16
22 Ralph Droms [Ballot Position Update] New position, Discuss, has been recorded
2011-02-16
22 Sean Turner
[Ballot comment]
#5) I was curious if there were any privacy considerations that need to be addressed with the use of the geo tag?  Turns …
[Ballot comment]
#5) I was curious if there were any privacy considerations that need to be addressed with the use of the geo tag?  Turns out it only identified country.

#6) Sec 9.4: Technically, digital signatures don't provide non-repudiation they enable it.  This was long discussion in PKIX ;)
2011-02-16
22 Sean Turner
[Ballot discuss]
This is an updated discuss (the author apparently knows how to use the datatracker ;)  Numbering is retained.

#1) Sec 2 Says:

Valid …
[Ballot discuss]
This is an updated discuss (the author apparently knows how to use the datatracker ;)  Numbering is retained.

#1) Sec 2 Says:

Valid algorithms are found
in the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest
Algorithm Values" at
.

Then, Sec 10.3 says:

Currently, some of the digest values defined in Instance Digests in
HTTP [RFC3230] are considered insecure.

This could confuse some people.  Section 2 should be modified to say:

  Algorithms used in the Instance Digest field are registered in the IANA registry
named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values"
at .
This document restricts the use of these algorithms.

Author agreed to make change, but it's not reflected in -20.

#4) Sec 5: Only specifies OpenPGP signatures.  I'm curious why this choice?  I would think you'd want to reuse existing security built in browsers based on TLS and OpenPGP isn't the mandatory to implement scheme it's X.509.  Also, any reason S/MIME isn't there?  For example:

5. Signatures

5.1. OpenPGP Signatures

As in the draft

5.2. S/MIME Signatures

S/MIME signatures [RFC5751] are specified with the Link header
fields [RFC5988] and a relation type of "describedby" and a type
parameter of "application/pkcs7-mime".

A brief Metalink server response with OpenPGP signature only:

Link: ; rel=describedby;
type="application/pkcs7-mime"

Metalink clients MAY support the use of S/MIME signatures.

#5) There are multiple schools of thought about putting requirements in the security considerations.  If you're going to put them in the security considerations, then I think a pointer to the algorithm requirements from section 6 to section 10 needs to be included.  Or, move "If a Metalink contains whole file hashes as described in Section 6, it SHOULD include SHA-256, as specified in [FIPS-180-3], or stronger. It MAY also include other hashes. " up to Section 2, paragraph 2. Which ever you think is simpler?

#6) Sec 7: Need to say something about what to do if the signature is included.  Does it to validate back to a trust anchor.  Point to OpenPGP/RFC5280 for validation rules.

#7) Section 10:  (I wrote this before I got to section 7 - will revisit it)

a) Because Mirrors "SHOULD" include an Instance Digest instead of "MUST" include them, then I think you need to say something about using Mirrors can lead to substitution attacks and how you might mitigate them (user performs some action).  Maybe this could be worked in to the spoofing paragraph (i.e., the case when no instance digest is specified).

b) You also need to say something about using multiple mirrors when downloading.  What happens when one supports an instance digest and the other doesn't (as in the last para of Section 2).  What happens when the 1st one the client connected to supports it but the second doesn't.  How is this supposed to work and can the client do anything to figure out that they got something they can cryptographically verify?

#8) Sec 5: Need to specify what is the signature covering?
2011-02-16
22 Sean Turner
[Ballot comment]
#5) I was curious if there were any privacy considerations that need to be addressed with the use of the geo tag?  Turns …
[Ballot comment]
#5) I was curious if there were any privacy considerations that need to be addressed with the use of the geo tag?  Turns out it only identified country.
2011-02-16
22 Sean Turner
[Ballot discuss]
This is an updated discuss (the author apparently knows how to use the datatracker ;)  Numbering is retained.

#1) Sec 2 Says:

Valid …
[Ballot discuss]
This is an updated discuss (the author apparently knows how to use the datatracker ;)  Numbering is retained.

#1) Sec 2 Says:

Valid algorithms are found
in the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest
Algorithm Values" at
.

Then, Sec 10.3 says:

Currently, some of the digest values defined in Instance Digests in
HTTP [RFC3230] are considered insecure.

This could confuse some people.  Section 2 should be modified to say:

  Algorithms used in the Instance Digest field are registered in the IANA registry
named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values"
at .
This document restricts the use of these algorithms.

Author agreed to make change, but it's not reflected in -20.

#4) Sec 5: Only specifies OpenPGP signatures.  I'm curious why this choice?  I would think you'd want to reuse existing security built in browsers based on TLS and OpenPGP isn't the mandatory to implement scheme it's X.509.  Also, any reason S/MIME isn't there?  For example:

5. Signatures

5.1. OpenPGP Signatures

As in the draft

5.2. S/MIME Signatures

S/MIME signatures [RFC5751] are specified with the Link header
fields [RFC5988] and a relation type of "describedby" and a type
parameter of "application/pkcs7-mime".

A brief Metalink server response with OpenPGP signature only:

Link: ; rel=describedby;
type="application/pkcs7-mime"

Metalink clients MAY support the use of S/MIME signatures.

#5) There are multiple schools of thought about putting requirements in the security considerations.  If you're going to put them in the security considerations, then I think a pointer to the algorithm requirements from section 6 to section 10 needs to be included.  Or, move "If a Metalink contains whole file hashes as described in Section 6, it SHOULD include SHA-256, as specified in [FIPS-180-3], or stronger. It MAY also include other hashes. " up to Section 2, paragraph 2. Which ever you think is simpler?

#6) Sec 7: Need to say something about what to do if the signature is included.  Does it to validate back to a trust anchor.  Point to OpenPGP/RFC5280 for validation rules.

#7) Section 10:  (I wrote this before I got to section 7 - will revisit it)

a) Because Mirrors "SHOULD" include an Instance Digest instead of "MUST" include them, then I think you need to say something about using Mirrors can lead to substitution attacks and how you might mitigate them (user performs some action).  Maybe this could be worked in to the spoofing paragraph (i.e., the case when no instance digest is specified).

b) You also need to say something about using multiple mirrors when downloading.  What happens when one supports an instance digest and the other doesn't (as in the last para of Section 2).  What happens when the 1st one the client connected to supports it but the second doesn't.  How is this supposed to work and can the client do anything to figure out that they got something they can cryptographically verify?
2011-02-16
22 Peter Saint-Andre
[Ballot discuss]
Overall I don't see any insuperable problems with this specification, although the protocol introduces the possibility of several kinds of amplification attacks and …
[Ballot discuss]
Overall I don't see any insuperable problems with this specification, although the protocol introduces the possibility of several kinds of amplification attacks and denial of service attacks (see RFC 4732, which could usefully be added to the references). Robert Sparks and I chatted about those a bit today and I concur with the DISCUSS he has posted.

In addition, I have a concern with the following text from Section 7.1.1:

  ETags can not be used for verifying the integrity of the received
  content.  But it is a guarantee issued by the Metalink server that
  the content is correct for that ETag.  And if the ETag given by the
  mirror server matches the ETag given by the Metalink server, then
  there is a chain of trust where the Metalink server authorizes these
  responses as valid for that object.

The term "chain of trust" is a bit strong here, given that "trust chain" is a synonym for "certification path" according to RFC 4949. In addition, the presence of an identical ETag does not guarantee that the mirror is truly *authorized* by the Metalink server, because a malicious mirror could simply copy whatever ETag it finds at the Metalink server (this is noted later in the section). The concepts of trust and authorization are weak here, so I suggest that we use other terms, except in cases where the client really can determine that the mirror is authorized (e.g., via a cryptographically signed Metalink XML file or HTTP header).
2011-02-16
22 Peter Saint-Andre
[Ballot discuss]
Overall I don't see any insuperable problems with this specification, although the protocol introduces the possibility of several kinds of amplification attacks and …
[Ballot discuss]
Overall I don't see any insuperable problems with this specification, although the protocol introduces the possibility of several kinds of amplification attacks and denial of service attacks (see RFC 4732, which could usefully be added to the references). Robert Sparks and I chatted about those a bit today and he plans to post a DISCUSS, with which I concur in advance.

In addition, I have a concern with the following text from Section 7.1.1:

  ETags can not be used for verifying the integrity of the received
  content.  But it is a guarantee issued by the Metalink server that
  the content is correct for that ETag.  And if the ETag given by the
  mirror server matches the ETag given by the Metalink server, then
  there is a chain of trust where the Metalink server authorizes these
  responses as valid for that object.

The term "chain of trust" is a bit strong here, given that "trust chain" is a synonym for "certification path" according to RFC 4949. In addition, the presence of an identical ETag does not guarantee that the mirror is truly *authorized* by the Metalink server, because a malicious mirror could simply copy whatever ETag it finds at the Metalink server (this is noted later in the section). The concepts of trust and authorization are weak here, so I suggest that we use other terms, except in cases where the client really can determine that the mirror is authorized (e.g., via a cryptographically signed Metalink XML file or HTTP header).
2011-02-16
22 Peter Saint-Andre [Ballot Position Update] New position, Discuss, has been recorded
2011-02-16
22 Robert Sparks
[Ballot discuss]
The automated handling of the Link headers by MetaLink clients suggested by this document may need some more discussion, at least in the …
[Ballot discuss]
The automated handling of the Link headers by MetaLink clients suggested by this document may need some more discussion, at least in the security considerations section. Apologies if I've missed where this is already discussed.

1) What prevents a malicious server from returning a 200 with many Link: headers, all indicating rel=duplicate, perhaps indicating non-overlapping subsets of the entity, and all pointing to a victim, driving many, possibly parallel, connection attempts?

2) When a Link (indicating an HTTP resource) is followed, does anything prevent that referenced server from also replying with MetaLink headers in its response? If not, what prevents loops, intentionally or unintentionally created, from being followed? If a client would automatically follow these, especially in parallel, exponential attacks against the victims in item 1) are possible.  At the very least, a client could be sent into an infinite ping-pong loop.
2011-02-16
22 Robert Sparks [Ballot Position Update] New position, Discuss, has been recorded
2011-02-15
22 Alexey Melnikov [Ballot comment]
IETF LC ends 1 day after the assigned telechat day (i.e. on February 18th).
2011-02-15
22 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Discuss
2011-02-15
22 Lars Eggert
[Ballot comment]
Section 3.2., paragraph 1:
>    Entries for a mirror servers can have a "geo" value, which is a
>    [ISO3166-1] alpha-2 …
[Ballot comment]
Section 3.2., paragraph 1:
>    Entries for a mirror servers can have a "geo" value, which is a
>    [ISO3166-1] alpha-2 two letter country code for the geographical
>    location of the physical server the URI is used to access.  A client
>    can use this information to select a mirror, or set of mirrors, that
>    are geographically near (if the client has access to such
>    information), with the aim of reducing network load at inter-country
>    bottlenecks.

  s/can/MAY/? The document is generally pretty sloppy in its use of
  RFC2119 terms; it would be very good if the authors would go over it
  once more.


Section 4., paragraph 1:
>    Entries for metainfo files, which describe ways to download a file
>    over Peer-to-Peer networks or otherwise, are specified with the Link
>    header fields [RFC5988] and a relation type of "describedby" and a
>    type parameter that indicates the MIME type of the metadata available
>    at the URI.  Since metainfo files can sometimes describe multiple
>    files, or the filename may not be the same on the Metalink server and
>    in the metainfo file but still have the same content, an optional
>    name parameter can be used.

  s/optional/OPTIONAL/ and/or s/may/MAY/


Section 4.1., paragraph 1:
>    Full Metalink/XML files for a given resource can be specified as
>    shown in the example in Section 4.

  Specify-by-example isn't how things are usually done in the IETF.
  It would be good to have an actual specification.
2011-02-15
22 Lars Eggert
[Ballot discuss]
INTRODUCTION, paragraph 4:
>    This document specifies Metalink/HTTP: Mirrors and Cryptographic
>    Hashes in HTTP header fields, a different way to …
[Ballot discuss]
INTRODUCTION, paragraph 4:
>    This document specifies Metalink/HTTP: Mirrors and Cryptographic
>    Hashes in HTTP header fields, a different way to get information that
>    is usually contained in the Metalink XML-based download description
>    format.  Metalink/HTTP describes multiple download locations
>    (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures,
>    and other information using existing standards for HTTP header
>    fields.  Clients can use this information to make file transfers more
>    robust and reliable.

  DISCUSS: The document title and this summary aren't really accurate.
  In addition to describing how to store Metalink info in HTTP header
  fields, a large part of the document (Section 7) is actually
  specifying how Metalink clients MUST/SHOULD/MAY operate.


Section 3.3., paragraph 1:
>    There are two types of mirror servers: preferred and normal.
>    Preferred mirror servers are HTTP mirror servers that MUST share the
>    same ETag policy as the originating Metalink server and/or MUST
>    provide Instance Digests using the same algorithm as the Metalink
>    server.

  DISCUSS: Section 1 said "SHOULD share the same ETag policy" - which is
  it?


Section 7., paragraph 13:
>    If the object is large and gets delivered slower than expected, then
>    the Metalink client MAY start a number of parallel ranged downloads
>    (one per selected mirror server other than the first) using mirrors
>    provided by the Link header fields with "duplicate" relation type.
>    Metalink clients SHOULD use the location of the original GET request
>    in the "Referer" header field for these ranged requests.

  DISCUSS: I realize that this spec doesn't really cover the client, but
  I find this description of permitted client operation problematic.
  What it basically says is "if the download is slow, open more
  connections." This is NOT a good general practice. There need to be
  limits on the number of parallel connections, ideally based on
  observing how the aggregate throughput changes as connections are
  opened - blindly opening connections once the path bottleneck is
  filled is pointless. (There is some text later in this section that
  goes in this direction, but not far enough.)
2011-02-15
22 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded
2011-02-14
22 Sean Turner
[Ballot discuss]
This is a preliminary discuss (and not yet sent to anybody).

#1) Sec 2 Says:

Valid algorithms are found
in the IANA registry …
[Ballot discuss]
This is a preliminary discuss (and not yet sent to anybody).

#1) Sec 2 Says:

Valid algorithms are found
in the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest
Algorithm Values" at
.

Then, Sec 10.3 says:

Currently, some of the digest values defined in Instance Digests in
HTTP [RFC3230] are considered insecure.

This could confuse some people.  Section 2 should be modified to say:

  Algorithms used in the Instance Digest field are registered in the IANA registry
named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values"
at .
This document restricts the use of these algorithms.

#2) Sec 3: Confused by the following:

[[Some organizations have many mirrors.  Only send a few mirrors, or
  only use the Link header fields if Want-Digest is used?]]

Was this supposed to be removed or is additional information required?

#3) Sec 3.2: Are there any privacy considerations that need to be addressed with the use of the geo tag?

#4) Sec 5: Only specifies OpenPGP signatures.  I'm curious why this choice?  I would think you'd want to reuse existing security built in browsers based on TLS and OpenPGP isn't the mandatory to implement scheme it's X.509.  Also, any reason S/MIME isn't there?  For example:

5. Signatures

5.1. OpenPGP Signatures

As in the draft

5.2. S/MIME Signatures

S/MIME signatures [RFC5751] are specified with the Link header
fields [RFC5988] and a relation type of "describedby" and a type
parameter of "application/pkcs7-mime".

A brief Metalink server response with OpenPGP signature only:

Link: ; rel=describedby;
type="application/pkcs7-mime"

Metalink clients MAY support the use of S/MIME signatures.

#5) There are multiple schools of thought about putting requirements in the security considerations.  If you're going to put them in the security considerations, then I think a pointer to the algorithm requirements from section 6 to section 10 needs to be included.

#6) Sec 7: Need to say something about what to do if the signature is included.  Does it to validate back to a trust anchor.  Point to OpenPGP/RFC5280 for validation rules.

#7) Section 10:  (I wrote this before I got to section 7 - will revisit it)

a) Because Mirrors "SHOULD" include an Instance Digest instead of "MUST" include them, then I think you need to say something about using Mirrors can lead to substitution attacks and how you might mitigate them (user performs some action).  Maybe this could be worked in to the spoofing paragraph (i.e., the case when no instance digest is specified).

b) You also need to say something about using multiple mirrors when downloading.  What happens when one supports an instance digest and the other doesn't (as in the last para of Section 2).  What happens when the 1st one the client connected to supports it but the second doesn't.  How is this supposed to work and can the client do anything to figure out that they got something they can cryptographically verify?
2011-02-14
22 Sean Turner
[Ballot comment]
#1) Sec 7: r/A Range limit is optional,/A Range limit is OPTIONAL,

#2) Section 7: r/fieldss)/fields).

#3) Sec 7.1.1: r/merging of ranges from …
[Ballot comment]
#1) Sec 7: r/A Range limit is optional,/A Range limit is OPTIONAL,

#2) Section 7: r/fieldss)/fields).

#3) Sec 7.1.1: r/merging of ranges from
  multiple responses must be verified/
  merging of ranges from
  multiple responses MUST be verified

#4) Sec 7.1.1: r/fieldss is./fields is.
2011-02-14
22 Sean Turner
[Ballot discuss]
This is a preliminary discuss (and not yet sent to anybody).

#1) Sec 2 Says:

Valid algorithms are found
in the IANA registry …
[Ballot discuss]
This is a preliminary discuss (and not yet sent to anybody).

#1) Sec 2 Says:

Valid algorithms are found
in the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest
Algorithm Values" at
.

Then, Sec 10.3 says:

Currently, some of the digest values defined in Instance Digests in
HTTP [RFC3230] are considered insecure.

This could confuse some people.  Section 2 should be modified to say:

  Algorithms used in the Instance Digest field are registered in the IANA registry
named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values"
at .
This document restricts the use of these algorithms.

#2) Sec 3: Confused by the following:

[[Some organizations have many mirrors.  Only send a few mirrors, or
  only use the Link header fields if Want-Digest is used?]]

Was this supposed to be removed or is additional information required?

#3) Sec 3.2: Are there any privacy considerations that need to be addressed with the use of the geo tag?

#4) Sec 5: Only specifies OpenPGP signatures.  Any reason S/MIME isn't there?  For example:

5. Signatures

5.1. OpenPGP Signatures

As in the draft

5.2. S/MIME Signatures

S/MIME signatures [RFC5751] are specified with the Link header
fields [RFC5988] and a relation type of "describedby" and a type
parameter of "application/pkcs7-mime".

A brief Metalink server response with OpenPGP signature only:

Link: ; rel=describedby;
type="application/pkcs7-mime"

Metalink clients MAY support the use of S/MIME signatures.

#5) There are multiple schools of thought about putting requirements in the security considerations.  If you're going to put them in the security considerations, then I think a pointer to the algorithm requirements from section 6 to section 10 needs to be included.

#6) Sec 7: Need to say something about what to do if the signature is included.  Does it to validate back to a trust anchor.  Point to OpenPGP/RFC5280 for validation rules.

#7) Section 10:  (I wrote this before I got to section 7 - will revisit it)

a) Because Mirrors "SHOULD" include an Instance Digest instead of "MUST" include them, then I think you need to say something about using Mirrors can lead to substitution attacks and how you might mitigate them (user performs some action).  Maybe this could be worked in to the spoofing paragraph (i.e., the case when no instance digest is specified).

b) You also need to say something about using multiple mirrors when downloading.  What happens when one supports an instance digest and the other doesn't (as in the last para of Section 2).  What happens when the 1st one the client connected to supports it but the second doesn't.  How is this supposed to work and can the client do anything to figure out that they got something they can cryptographically verify?
2011-02-14
22 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded
2011-02-14
20 (System) New version available: draft-bryan-metalinkhttp-20.txt
2011-02-14
22 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-02-13
22 Alexey Melnikov
[Ballot discuss]
Note that I am holding a DISCUSS on my own document because IETF LC ends 1 day after the assigned telechat day (i.e. …
[Ballot discuss]
Note that I am holding a DISCUSS on my own document because IETF LC ends 1 day after the assigned telechat day (i.e. on February 18th).
2011-02-13
22 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Discuss from Yes
2011-02-13
22 Alexey Melnikov Telechat date has been changed to 2011-02-17 from 2011-03-03
2011-02-10
22 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2011-02-10
22 Alexey Melnikov Ballot has been issued
2011-02-10
22 Alexey Melnikov Created "Approve" ballot
2011-02-07
22 Amanda Baber
IANA understands that, upon approval of this document, there is a single
IANA action that needs to be completed.

In the Link Relation Types subregistry …
IANA understands that, upon approval of this document, there is a single
IANA action that needs to be completed.

In the Link Relation Types subregistry of the Link Relations registry
located at:

http://www.iana.org/assignments/link-relations/link-relations.xhtml

The following registration will be added:

Relation Name: duplicate
Description: Refers to a resource whose available representations are
byte-for-byte identical with the corresponding representations of the
context IRI.
Reference: [RFC-to-be]
Notes: This relation is for static resources. That is, an HTTP GET
request on any duplicate will return the same representation. It does
not make sense for dynamic or POSTable resources and should not be used
for them.

IANA understands that this action is the only one needed upon approval
of this document.
2011-02-01
22 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Jürgen Schönwälder.
2011-01-26
22 David Harrington Request for Last Call review by TSVDIR is assigned to Haibin Song
2011-01-26
22 David Harrington Request for Last Call review by TSVDIR is assigned to Haibin Song
2011-01-25
22 Samuel Weiler Request for Last Call review by SECDIR is assigned to Jürgen Schönwälder
2011-01-25
22 Samuel Weiler Request for Last Call review by SECDIR is assigned to Jürgen Schönwälder
2011-01-21
22 Cindy Morgan Last call sent
2011-01-21
22 Cindy Morgan
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP Header Fields) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP Header Fields'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-02-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-bryan-metalinkhttp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-bryan-metalinkhttp/
2011-01-21
22 Alexey Melnikov Placed on agenda for telechat - 2011-03-03
2011-01-21
22 Alexey Melnikov Last Call was requested
2011-01-21
22 Alexey Melnikov State changed to Last Call Requested from AD Evaluation.
2011-01-21
22 (System) Ballot writeup text was added
2011-01-21
22 (System) Last call text was added
2011-01-21
22 (System) Ballot approval text was added
2011-01-21
22 Alexey Melnikov State changed to AD Evaluation from Publication Requested.
2011-01-21
22 Alexey Melnikov State changed to Publication Requested from AD is watching::AD Followup.
2011-01-20
22 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-01-20
19 (System) New version available: draft-bryan-metalinkhttp-19.txt
2011-01-16
22 Alexey Melnikov State changed to AD is watching::Revised ID Needed from AD is watching::AD Followup.
2011-01-06
22 Alexey Melnikov
State changed to AD is watching::AD Followup from AD is watching::Revised ID Needed.
Need to research use of 2 letter country codes versa 3 letter …
State changed to AD is watching::AD Followup from AD is watching::Revised ID Needed.
Need to research use of 2 letter country codes versa 3 letter country codes
2011-01-02
22 Alexey Melnikov State changed to AD is watching::Revised ID Needed from AD is watching::AD Followup.
2011-01-01
22 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-01-01
18 (System) New version available: draft-bryan-metalinkhttp-18.txt
2010-12-18
22 Alexey Melnikov State changed to AD is watching::Revised ID Needed from AD is watching::AD Followup.
2010-11-17
22 Alexey Melnikov State changed to AD is watching::AD Followup from Publication Requested.
2010-11-17
22 Alexey Melnikov Draft added in state Publication Requested
2010-09-14
17 (System) New version available: draft-bryan-metalinkhttp-17.txt
2010-04-17
16 (System) New version available: draft-bryan-metalinkhttp-16.txt
2010-02-20
15 (System) New version available: draft-bryan-metalinkhttp-15.txt
2009-12-31
14 (System) New version available: draft-bryan-metalinkhttp-14.txt
2009-11-22
13 (System) New version available: draft-bryan-metalinkhttp-13.txt
2009-11-11
12 (System) New version available: draft-bryan-metalinkhttp-12.txt
2009-10-23
11 (System) New version available: draft-bryan-metalinkhttp-11.txt
2009-10-15
10 (System) New version available: draft-bryan-metalinkhttp-10.txt
2009-10-13
09 (System) New version available: draft-bryan-metalinkhttp-09.txt
2009-10-04
08 (System) New version available: draft-bryan-metalinkhttp-08.txt
2009-09-29
07 (System) New version available: draft-bryan-metalinkhttp-07.txt
2009-09-24
06 (System) New version available: draft-bryan-metalinkhttp-06.txt
2009-09-19
05 (System) New version available: draft-bryan-metalinkhttp-05.txt
2009-09-17
04 (System) New version available: draft-bryan-metalinkhttp-04.txt
2009-09-17
03 (System) New version available: draft-bryan-metalinkhttp-03.txt
2009-09-07
02 (System) New version available: draft-bryan-metalinkhttp-02.txt
2009-09-02
01 (System) New version available: draft-bryan-metalinkhttp-01.txt
2009-08-28
00 (System) New version available: draft-bryan-metalinkhttp-00.txt