---------- Forwarded message ---------- From: Anthony Bryan <[email protected]> Date: Sat, Jan 2, 2010 at 1:16 PM Subject: Metalink: Security Considerations To: [email protected], Tatsuhiro Tsujikawa <[email protected]>, "Neil M." <[email protected]>, Peter Pöml <[email protected]>, Eran Hammer-Lahav <[email protected]>, Lisa Dusseault <[email protected]>
Hi everyone, & happy new year! Here's an issue from the AD review by Lisa that I've been meaning to address. I removed Section 5, Securing Metalink Documents (which was incomplete & untested), and funneled part of it into the Security Considerations section. This version can be found at http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ I welcome your comments in refining this text. 7. Security Considerations Because Metalink is an XML-based format, existing XML security mechanisms can be used to secure its content. Producers of Metalink Documents may have sound reasons for signing otherwise-unprotected content. For example, a merchant might digitally sign a Metalink that lists a file download to verify its origin. Other merchants may wish to sign and encrypt Metalink Documents that list digital songs that have been purchased. Of course, many other examples are conceivable as well. Publishers are encouraged to offer Metalink documents via authenticated HTTP under TLS as specified in [RFC2818]. The choice of a secure content layer is entirely possible for content providers. Publishers are also encouraged to include digital signatures of the files within the Metalink Documents, if they are available, as described in Section 4.2.13. 7.1. URIs and IRIs Metalink Processors handle URIs and IRIs. See Section 7 of [RFC3986] and Section 8 of [RFC3987] for security considerations related to their handling and use. 7.2. Spoofing There is potential for spoofing attacks where the attacker publishes Metalink Documents with false information. Malicious publishers might create Metalink Documents containing inaccurate information anywhere in the document. Unaware downloaders could be deceived into downloading a malicious or worthless file. Malicious publishers could attempt a distributed denial of service attack by inserting unrelated IRIs into Metalink Documents. 7.3. Signing Metalink Documents SHOULD be signed using XML-Signature and Syntax Processing [REC-xmldsig-core] and are subject to the security considerations implied by its use. This addresses the issue of spoofing. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. 7.4. Cryptographic Hashes Currently, some of the hash types defined in the IANA registry named "Hash Function Textual Names" are considered insecure. These include the whole Message Digest family of algorithms which are not suitable for cryptographically strong verification. Malicious people could provide files that appear to be identical to another file because of a collision, i.e. the weak cryptographic hashes of the intended file and a substituted malicious file could match. If a Metalink Document contains hashes, it SHOULD include "sha-256" which is SHA-256, as specified in [FIPS-180-3], or stronger. It MAY also include other hashes from the IANA registry named "Hash Function Textual Names". -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads -- You received this message because you are subscribed to the Google Groups "Metalink Discussion" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/metalink-discussion?hl=en.
