However, Phill has created a cute case that isn't *quite* a classic
downgrade attack, but is at least a kissing cousin of one. The
solution to it he proposes is that the policy language be rich enough
to say, "I always sign with A and B." If we want to be complete, the
policy statement could merely say, "I always sign with all of set S"
and if you only use one algorithm, then it trivially falls out of it.
Good suggestion, let's do it. End of story.
Hold on a minute. The SSP discussion is chronically plagued by
proposals for sender declarations that are useless to receivers, and I
think it's just happened again. I'm trying to envision how a
recipient makes use of an assertion about signing algorithms, and
failing.
I'm a receiver, a message shows up with some signatures. For each
signature that uses an algorithm I understand, I check and see if it
verifies, which either it does or it doesn't. For each one that uses
an algorithm I don't understand, what should I do? I can't verify it.
I can't assume it's good unless I want to create a whale-sized
security hole. So I ignore it.
So now let's say I have a message that has at least one good
signature. As far as I'm concerned, I'm done, it's verified. If I
were to check the SSP, the most that could happen is a variation on
the "I sign nothing" scenario, if the SSP claims there's some set of
signature algorithms other than what I found. That is not useful to
the receiver, other than perhaps to identify senders insufficiently
competent to publish consistent key and SSP records.
Or I have a message that didn't have any good signatures. I can't
tell whether that was because it was unsigned, it had a good signature
that broke in transit, it had a good signature that I didn't know how
to verify, or it had a bogus signature applied by a bad guy. So, as a
receiver, this is all the same situation, it's unsigned. If you
believe that SSP can state "I sign everything", you might throw it
away if that's what the SSP says. Otherwise, what?
How does a SSP list of signing algorithms provide any useful
information to a receiver? Unless I'm missing something rather
fundamental, it doesn't.
Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet
for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html