On Fri, Mar 19, 1999 at 12:14:10PM +0000, Charles Lindsey wrote:
Is this not correct? Such a step is a non-necessary complexity. If
the header list is tampered with, the signature will be immediately
invalidated anyway.
No it is essential (and it is in pgpverify too).
From: <good-guy>
Message-Id: <fkew;lwfkew;kf>
Signed: foobar From,Message-ID,Reply-To
rdskfrekerkgkrf;vker;
erkgvc,g[er5krlv;dllerpk';cd';lc';welv';r,';
Now a malicious interloper gets in the way and changes the message:
From: <good-guy>
Message-Id: <fkew;lwfkew;kf>
Reply-To: <bad-guy>
Signed: foobar From,Message-ID
rdskfrekerkgkrf;vker;
erkgvc,g[er5krlv;dllerpk';cd';lc';welv';r,';
And if the first part of the Signed header was not covered in the
signature, it will still verify.
That's the case if you use inclusive header lists. However, the whole
reason people advocated inclusive header lists was that it would allow
later parties to add more headers to the article, so this consequence
is not totally unexpected. What's salient about your example is that
the user explicitly listed reply-to on their list of headers signed but
did not include it. Which is to say this is a hole that only occurs
through this deliberate action by the original poster.
In addition, the party reading the later article knows the Reply-to is not
signed, and they should not treat it as valid.
However, I agree that's not as good as we would like, it would be nice
if the article were entirely discarded and the end recipient did not have
to bother even noticing that the reply-to is in the untrusted portion of
the header.
(One reason I think the concept of an untrusted portion of a header is
asking for trouble.)
Still, I am loath to have anything but the simplest of canonicalized
hashing algorithms. I think trying hash the header you are still trying
to generate is potentially as troublesome as the risk above but would ideally
want to fix both. Though it's hard to find a way to do that, other than
to say "don't accept articles where any of the classic optional headers
are unsigned" Ie. if Reply-to, Distribution, References, Summary etc. are
unsigned, reject it.
It might be a bit easier if you move to a tagged parameter Signed
header -- all new headers should use tagged parameters, not positionals.
That way you might be able to more easily do the exclusion of the
signature. (In your proposal, excluding the sig from the end, you stop
the header from being extensible)