Metalink ID: Security Considerations
Anthony Bryan
From: Anthony Bryan <anthon...@gmail.com>
Date: Sat, Jan 2, 2010 at 1:16 PM
Subject: Metalink: Security Considerations
To: apps-d...@ietf.org, Tatsuhiro Tsujikawa
<tatsu...@gmail.com>, "Neil M." <nabb...@gmail.com>, Peter Pöml
<po...@cmdline.net>, Eran Hammer-Lahav <er...@hueniverse.com>, Lisa
Dusseault <lisa.du...@gmail.com>
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