Subject: [ietf-dkim] Proposed fingerprint tag description

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 Apr 2006 12:56:32 -0700

Following up on prior discussion, I'd like to start working on some formal 
wording for a fingerprint tag.  This will be used to describe the results of 
verifying a message with multiple signatures present, so that the receiver can 
match up each result to its respective signature even if there's been some 
reordering.

This would be added to the section describing the tags present in signature 
headers, namely "3.5 The DKIM-Signature header field" section:

f=	Signature fingerprint (plain-text; OPTIONAL)
The fingerprint of the signature.  This is a short string which is used to 
distinguish between two different signatures of the same message, which may have 
been added at the same time by the same signer, so that the receiver can decide 
which of two or more conflicting results makes a more desirable assertion.  The 
fingerprint SHOULD be fairly short but MUST be unique among signature headers 
added by the same signer.  Thus, the concatenation of the values of "f=" and 
"i=" will uniquely distinguish this signature from any others that might be 
added between the originator and the receiver.

INFORMATIVE IMPLEMENTATION NOTE: It is likely sufficient to do something akin to 
encoding the first four bytes of the body hash in hexadecimal, e.g. 
f=44:4B:49:4D or f=444b494d.

If the "f=" tag is absent, a verifier can infer its value by using the first 
four bytes of the actual (i.e. base64-decoded) "bh" tag's value when describing 
its results to receivers.  However, since the base64-decoded version of the "bh" 
tag is not easily visible upon simple header inspection, signers SHOULD add this 
tag for clarity.

This would also work even without the "bh" change to the specification; instead 
the signer would just use the first few bytes of the single generated hash that 
we have today.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 12 Apr 2006 13:36:26 -0700 (PDT)

Since fingerprints have specific meaning in cryptography, can you
change the name to something like "Unique Signature ID" (i.e. "u"
although personally I like "u"s for URLs).

How you planning to make reference to specific header field by using
this tag? Are these going to be similar tricks to what I have used?
(i.e. allowing simple regex after header field name in list of fields;
2nd trick was encoding unique id as part of header field name, which
does not apply here).

Is my understanding correct that using "f" would make using "i"
requirement as well? You probably want this mentioned ...

Can you explain why you need this tag and can not put unique info
in timestamp tag (i.e. allow for optional milliseconds to distinguish
signatures)? That seems better then extra tag...

On Wed, 12 Apr 2006, Murray S. Kucherawy wrote:

> verifying a message with multiple signatures present, so that the receiver 
> can match up each result to its respective signature even if there's been 
> some reordering.
>
> distinguish between two different signatures of the same message, which may 
> have been added at the same time by the same signer, so that the receiver can 
> decide which of two or more conflicting results makes a more desirable 
> assertion.  The fingerprint SHOULD be fairly short but MUST be unique among 
> signature headers added by the same signer.  Thus, the concatenation of the 
> values of "f=" and "i=" will uniquely distinguish this signature from any 
> others that might be added between the originator and the receiver.
>
> INFORMATIVE IMPLEMENTATION NOTE: It is likely sufficient to do something akin 
> to encoding the first four bytes of the body hash in hexadecimal, e.g. 
> four bytes of the actual (i.e. base64-decoded) "bh" tag's value when 
> describing its results to receivers.  However, since the base64-decoded 
> version of the "bh" tag is not easily visible upon simple header inspection, 
> signers SHOULD add this tag for clarity.
>
>
> This would also work even without the "bh" change to the specification; 
> instead the signer would just use the first few bytes of the single generated 
> hash that we have today.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 Apr 2006 14:05:30 -0700

> although personally I like "u"s for URLs).

Fine by me.  How about "sid" for Signature ID?

> this tag? Are these going to be similar tricks to what I have used?

The context I'm thinking of is Authentication-Results:, or whatever method you 
prefer to transport verification results back to the MUA or whatever agent will 
be deciding on what to do with them.  If I have an agent that adds two DKIM 
signatures (say, one that knows about "bh" and one that doesn't, or one that 
uses "rsa-sha1" and one that uses "rsa-sha256") from the same host in the same 
second, and one fails while the other succeeds, it's useful to be able to match 
those results to their respective headers so you can make some determination 
about what each one is claiming.

> requirement as well? You probably want this mentioned ...

Last time I checked, "i" had a default value.  Thus, "f" and the (express or 
implied) value of "i" together make something globally unique.

> signatures)? That seems better then extra tag...

I think that's too weak a distinction.  How come we didn't just use time down to 
milliseconds on Message-ID: headers?  Do we really want to mandate that the 
signer has to call gettimeofday() once for each signature?  Or what if it's two 
different signing agents running on the same machine at the same time?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 12 Apr 2006 14:06:15 -0700

On Apr 12, 2006, at 12:56 PM, Murray S. Kucherawy wrote:
>
> If the "f=" tag is absent, a verifier can infer its value by using  
> the first four bytes of the actual (i.e. base64-decoded) "bh" tag's  
> value when describing its results to receivers.  However, since the  
> base64-decoded version of the "bh" tag is not easily visible upon  
> simple header inspection, signers SHOULD add this tag for clarity.

What happens when these values are not unique?  Would these values  
increase in size until they are unique?  The "bh" tag could easily be  
the same for multiple signatures, which would make this a poor choice.

Verification results based upon an added header might be spoofed when  
an MTAs is not configured to remove them.  In addition, these headers  
will not be reliably present  until universally adopted, perhaps many  
years from now.   While the header might be removed normally, there  
could also be backup paths where the header is once again not removed.

Adding another signature at the MDA can include an extension that  
lists verified signatures within the signature header itself, as that  
would be its sole purpose.  This approach can dispel concerns about  
who is being trusted when accepting second-hand verification  
results.  If a verification header is bound to a signature, it could  
be assumed to have been added by the MDA.  Any message being re- 
submitted should remove both the verification header _and_ the  
accompanying signature.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 Apr 2006 14:33:17 -0700

> could also be backup paths where the header is once again not removed.

The transport of the verification results to the MUA or other receiver agent 
that actually makes decisions on acceptance/validity of a message (discard, 
file, whatever) is outside of the scope of DKIM.

However, any such method will require a way to distinguish between signatures 
that is better than "I'm talking about the third one", so that's what I'm hoping 
to introduce here.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Wed, 12 Apr 2006 14:47:31 -0700

Murray --

It sounds like what you really want to do is to cause b= to be unique. That
could be accomplished by just adding some hash-collision resistant number
of random bytes. Or you could use those random bytes directly, I suppose.

       Mike

Murray S. Kucherawy wrote:

> Douglas Otis wrote:
>
>> Verification results based upon an added header might be spoofed 
>> when  an MTAs is not configured to remove them.  In addition, these 
>> headers  will not be reliably present  until universally adopted, 
>> perhaps many  years from now.   While the header might be removed 
>> normally, there  could also be backup paths where the header is once 
>> again not removed.
>
>
> The transport of the verification results to the MUA or other receiver 
> agent that actually makes decisions on acceptance/validity of a 
> message (discard, file, whatever) is outside of the scope of DKIM.
>
> However, any such method will require a way to distinguish between 
> signatures that is better than "I'm talking about the third one", so 
> that's what I'm hoping to introduce here.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Apr 2006 23:00:37 +0100

Hi Murray,

What would be wrong with the option of using the first N bytes of the
actual signature value?

If that were ok (and I've no idea really), then presumably the shortest
N that disambiguates the signatures could be used.

But its not entirely clear to me who's putting this value where, when. I
guess I should go re-read your draft!

Cheers,
Stephen.

Murray S. Kucherawy wrote:
> Following up on prior discussion, I'd like to start working on some 
> formal wording for a fingerprint tag.  This will be used to describe the 
> results of verifying a message with multiple signatures present, so that 
> the receiver can match up each result to its respective signature even 
> if there's been some reordering.
> 
> This would be added to the section describing the tags present in 
> signature headers, namely "3.5 The DKIM-Signature header field" section:
> 
> 
> The fingerprint of the signature.  This is a short string which is used 
> to distinguish between two different signatures of the same message, 
> which may have been added at the same time by the same signer, so that 
> the receiver can decide which of two or more conflicting results makes a 
> more desirable assertion.  The fingerprint SHOULD be fairly short but 
> MUST be unique among signature headers added by the same signer.  Thus, 
> the concatenation of the values of "f=" and "i=" will uniquely 
> distinguish this signature from any others that might be added between 
> the originator and the receiver.
> 
> INFORMATIVE IMPLEMENTATION NOTE: It is likely sufficient to do something 
> akin to encoding the first four bytes of the body hash in hexadecimal, 
> e.g. f=44:4B:49:4D or f=444b494d.
> 
> If the "f=" tag is absent, a verifier can infer its value by using the 
> first four bytes of the actual (i.e. base64-decoded) "bh" tag's value 
> when describing its results to receivers.  However, since the 
> base64-decoded version of the "bh" tag is not easily visible upon simple 
> header inspection, signers SHOULD add this tag for clarity.
> 
> 
> instead the signer would just use the first few bytes of the single 
> generated hash that we have today.

---

From: Mark Delany <[email-masked]>
Date: Wed, 12 Apr 2006 22:37:45 +0000

> N that disambiguates the signatures could be used.

That seems like a reasonable strategy to me. I believe that the domain
is also included in Authentication-Results, so if the disambiguation
selection matches on the d= domain + unique signature bits, then most
of the time one could expect that the number of disambiguation bits
will normally be be zero. The exception being the presence of two
signatures with a common d= domain.

Mark.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 Apr 2006 15:56:36 -0700

> of random bytes. Or you could use those random bytes directly, I suppose.

It may in fact be completely sufficient for the signing agent to use "1" for the 
first signature, "2" for the second, etc.  Then this value coupled with the "i=" 
value makes it a snap to identify each signature as different from the others.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Wed, 12 Apr 2006 17:00:53 -0700

> Fine by me.  How about "sid" for Signature ID?
Likely to be confused with Sender ID?  As in sid-milter?  :-)

-Jim

---

From: <[email-masked]>
Date: Wed, 12 Apr 2006 20:21:41 -0400

Lets not get into cellular mapping id's (SID) 

-----Original Message-----
From: [email-masked] on behalf of Jim Fenton
Sent: Wed 4/12/2006 8:00 PM
To: Murray S. Kucherawy
Cc: [email-masked]
Subject: Re: [ietf-dkim] Proposed fingerprint tag description

-Jim

---

From: "Dennis Dayman" <[email-masked]>
Date: Wed, 12 Apr 2006 20:22:28 -0500

> Fine by me.  How about "sid" for Signature ID?

Microsoft will love that :)

-Dennis