Subject: [secdir] Digital signature advice and review for content delivery application

From: Lisa Dusseault <[email-masked]>
Date: Mon, 29 Sep 2008 10:56:27 -0700

Hi,

Is there somebody on secdir who could volunteer to review and provide  
advice on the digital signature functionality in this proposal?

http://tools.ietf.org/html/draft-bryan-metalink-03

Thanks,
Lisa D
_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Barry Leiba <[email-masked]>
Date: Tue, 30 Sep 2008 11:24:35 -0400

> http://tools.ietf.org/html/draft-bryan-metalink-03

I've given it a brief reading, and here are my initial thoughts:

First, I find quite a bit of the document to be sketchy and unclear.  That's 
certainly because I haven't been involved in any of the discussions, but neither 
will most future readers of it have been.  In particular, the descriptions of the 
elements don't seem to be adequate.

For example:
> 4.1.6. The "metalink:pieces" Element
>
>    The "metalink:pieces" element is a Text construct that conveys a
>    human-readable piece information for a file.
>

I don't know what "human-readable piece information" is, why it's put there, what 
anyone will do with it, nor whether there'd be value in any particular format for 
the information.  I also don't know whether there's any corresponding 
machine-readable piece information.

For signatures, in particular:
> 4.2.14. The "metalink:signature" Element
>
>    The "metalink:signature" element is a Text construct that conveys a
>    digital signature for a file described in a Metalink Document.
>
>    metalinkSignature =
>       element metalink:signature {
>       attribute type { "pgp" },
>       metalinkTextConstruct
>       }

I gather from that that "pgp" is the only signature type supported; that's 
unfortunate.

Are there no other attributes that will be needed in order to support different 
signature types?  Planning that now will help extensibility later.

>From section 6:
>    Producers of Metalinks may have sound reasons for signing and/or
>    encrypting otherwise-unprotected content.

I think this downplays the importance of signing these things; I rather think 
that signing them should become the norm, not the exceptional case that's only 
used if there are "sound reasons".

>    Metalink Processors MUST NOT reject an Metalink Document containing
>    such a signature because they are not capable of verifying it; they
>    MUST continue processing and MAY inform the user of their failure to
>    validate the signature.

Ooh.  I'd want to know why.  This is certainly a MUST that I would violate if I 
had a system that decided it would only accept metalink documents that were 
signed.  And I can definitely see sound reasons for having such a system.

>    Other elements in an Metalink Document MUST NOT be signed unless
>    their definitions explicitly specify such a capability.

I don't understand this.  What is the scope of a signature on a metalink 
document, then?  I should think it would protect the whole document.  Is this 
trying to say that there must not be embedded signatures inside a signed 
document?  If so, then it should be clearer.  If it means something else, I don't 
understand.

>    Section 4.4.2 of [REC-xmldsig-core] requires support for DSA
>    signatures and recommends support for RSA signatures.  However,
>    because of the much greater popularity in the market of RSA versus
>    DSA

Yeh, that's odd.  I initially thought it was because of the RSA patent, but that 
expired in 2000, and the W3C document is from 2002.  [shrug]  I do think it's 
reasonable for this document to reverse the requirements for RSA and DSA, as it 
does.

Section 9, Security Considerations, seems inadequate.  The base section says, 
essentially, "you're encouraged to use authenticated HTTP under TLS, and you're 
encouraged to sign the files you're going to transfer" (but not the metalink 
documnts).  There are perfectly good reasons not to use authenticated HTTP 
(distributing public documents, for instance), but TLS will often still make 
sense (to confirm the server's identity), signatures on the metadata are still 
important (preventing attacks that present spurious documents), and so on. 
Section 9.2 does address that last point somewhat, but (1) I disagree with the 
"at best" and "at worst" cases there, and (2) there's no recommendation about 
what to do.  I think the severity of potential attacks is greater than what's 
presented here.

I see no reason there shouldn't be a SHOULD here for signing the metalink 
document, and that would address the broader spoofing issue.  Section 9.3 says 
they "can" be signed, but makes no recommendation.

Those are comments from an first look.

Barry Leiba
IAB member, and DKIM working group chair