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

From: "Uri Blumenthal" <[email-masked]>
Date: Thu, 2 Oct 2008 16:27:35 -0400

In agreement with Barry, and emphasizing some points. 

This document seems unclear, leaving some serious qustions unanswered. For
example, since it deals with XML documents - why not just use straight
XML-DSig standard (which allows signing the entire document OR a part of
it)? Allowing pgp for signature is good - but limiting to ONLY pgp is bad. I
agree with Barry that adding requirement for RSA suport is good - but
encouraging violating XML-DSig and dropping DSA support doesn't look smart
to me. Etc. etc.

In short: IMHO digital signature approach in this document is not
satisfactory.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Barry Leiba
Sent: Tuesday, September 30, 2008 11:25
To: Lisa Dusseault; [email-masked]
Cc: Anthony Bryan
Subject: Re: [secdir] Digital signature advice and review for content
delivery application

> 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

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

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

_______________________________________________
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: "Uri Blumenthal" <[email-masked]>
Date: Sat, 4 Oct 2008 21:56:39 -0400

I looked at RFC 4287 (Atom Syndication Format, circa 2005) and find that
many of this draft's "offensive" security issues came directly from it. They
look equally bad in RFC 4287.

I know we're in year 2008, not 2005, and Atom is a published RFC. But it
contains security glitches, illustrated by quotations in this draft. Maybe
it's not too late todo anything about it (or maybe it is).

-----Original Message-----

Barry Leiba

---

From: "Anthony Bryan" <[email-masked]>
Date: Fri, 3 Oct 2008 19:17:49 -0400

Hi Barry, thank you for taking the time to review and comments. As you
can see, it needed it.

> corresponding machine-readable piece information.

Thanks for catching that. I was using it as placeholder text. I've
updated it & the next version will have the description, it's where
partial file hashes are contained.

I'll try to catch other sketchy and unclear sections.

> different signature types?  Planning that now will help extensibility later.

Actually, this is why we were requesting review. Only PGP signatures
of files listed in metalinks are used and included now, but we want to
support different signature types. I have already documented what is
in use that I have experience with (PGP).

Can you list, or point me to the other types of signatures and how we
can include them in the metalink?

The text from you commented on in your next four comments is from RFC
4287, Atom.

I have used the text from the Atom RFC because I have no experience
with this section and have not come across any signed Metalinks in the
wild. I assumed since Atom documents and Metalink documents are both
XML, they would be the same or relatively similar.

I want my draft to be correct and need to rely on others for this
section. Are these suggestions that have been learned since the
publication of RFC 4287 or should have been included?

Because of my lack of knowledge and experience, it might even be rude
for me to reply to your comments. I will certainly accept corrections
and changes to the text. Perhaps someone more familiar with these
matters could shepherd this part of the draft, if interested.

> 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.

Should I remove the "at best/worst" cases (or rephrase them?) and
recommend signing the metalinks?

> Those are comments from an first look.

Thank you again.

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads
_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir