Subject: Re: [ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms

From: Jon Callas <[email-masked]>
Date: Mon, 1 Jun 2009 15:11:23 -0700

On May 30, 2009, at 10:15 AM, Dave CROCKER wrote:

> Folks,
>
>
> In:
>
>   <http://mipassoc.org/pipermail/ietf-dkim/2009q2/011959.html>
>
> Steve Atkins posted a list of suggested DKIM features to drop.
>
> This note is intended to anchor a discussion thread for discusses  
> one of those
> features, namely:
>
>
>>   TXT RR tags
>>
>>     h: Acceptable hash algorithms
>>
>> The spec needs to define the supported set of hash algorithms. There
>> may be some value in a signer being able to state that they're using
>> an algorithm that isn't supported, perhaps.
>>
>> But unless there is a viable attack such that an attacker can craft a
>> message that validates correctly against the domain owner public key
>> using a hash supported by the spec (sha1 or sha256), without access  
>> to
>> the domain owners private key, then there's no need for this to be in
>> the TXT record.

I agree that there's no need for that to be in a TXT record.

	Jon

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 4 Jun 2009 14:55:28 -0700

> >> to the domain owners private key, then there's no need for this to be in
> >> the TXT record.
> 

If a site wanted to revoke instantly any signature previously generated with rsa-craphash, couldn't it just revoke its old keys and generate new keys, and begin signing with rsa-goodhash?

What's the advantage of having a mechanism to disallow future verifications using a particular hash without just changing the keys you're using?  Both times you have to touch DNS and reconfigure your signers, so I don't see that leaving "h=" in there gives you anything you can't already do some other way.

---

From: Jon Callas <[email-masked]>
Date: Thu, 4 Jun 2009 15:38:41 -0700

On Jun 4, 2009, at 2:55 PM, Murray S. Kucherawy wrote:

> If a site wanted to revoke instantly any signature previously  
> generated with rsa-craphash, couldn't it just revoke its old keys  
> and generate new keys, and begin signing with rsa-goodhash?

Yes, it is a design feature of DKIM that an operational crypto error  
can be instantly "revoked" by merely yanking the keys from DNS (modulo  
cache timeouts etc). The only thing I would correct in your statement  
is the word "revoke." DKIM bypasses the very notion of revocation by  
being key-centric.

>
>
> What's the advantage of having a mechanism to disallow future  
> verifications using a particular hash without just changing the keys  
> you're using?  Both times you have to touch DNS and reconfigure your  
> signers, so I don't see that leaving "h=" in there gives you  
> anything you can't already do some other way.

None.

	Jon

---

From: Douglas Otis <[email-masked]>
Date: Thu, 4 Jun 2009 15:41:46 -0700

> anything you can't already do some other way.

Disagree.  This feature is about better informing recipients as to the  
status of the signature.

A DKIM signature may contain algorithms unimplemented by all  
receivers.   The algorithm may replace those that have become  
vulnerable.  Who knows, since would be speculating about future events  
in the face of massive bot-nets.  Until receivers are upgraded during  
the transition, it would be possible for the DKIM protocol to  
establish which message signatures are unverifiable, from those that  
are really invalid.  Unverifiable would be confirmed when the signing  
domain's key matches against the DKIM signatures header.  Whenever the  
domain's key's assertion is found not to match against the DKIM  
signature header, this message could be rejected as an attempt to  
spoof an unverifiable signature.

While a problem today, but this might be in the future.  There is  
nothing gained by removing it.  This feature will need to remain  
documented, where it just might prove its value some time in the future.

By allowing it to be possible to defend against spoofed unverifiable  
signatures, users will remain better able to employ ancillary services  
that could bolster the abilities of the receiving MTA.   This key  
related feature would help minimize the amount of confusion that might  
be generated during algorithm transitions that might extend over long  
periods of time.  Otherwise, bad actors will exploit this situation by  
spoofing a flood of unverifiable signatures.  Without this feature,  
the situation would be more generally known as the "invalid" signature  
problem, where some messages would be unverifiable, but most would be  
spoofs of unverifiable messages, and everyone wondering what to make  
of the mess.

-Doug

---

From: Mark Delany <[email-masked]>
Date: Thu, 4 Jun 2009 15:53:24 -0700

> is the word "revoke." DKIM bypasses the very notion of revocation by

Though the spec discusses an empty p= as giving an explicit "revoke"  
indication.

Mark.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 4 Jun 2009 16:32:19 -0700

> Disagree.  This feature is about better informing recipients as to the

For the sake of enumerating implementations, the current libdkim implementation does make a distinction between a signature that failed to verify and one that couldn't be verified because the key's approved hashes and the signature's methods don't line up and one that simply failed DKIM verification.

So if I am to apply my earlier arguments, I have to support your point because it puts more information in the hands of the assessor.

However, unlike x= and l=, I don't see any possible benefit in making the distinction.  For example, how can you tell an attacker that created a signing algorithm of "rsa-whatever" from a site that accidentally posted a public key with "h=watever"?  Are you sure you want to consider those as equivalent and apply the maximum punishment rather than just treat the message as unsigned in both cases?

---

From: Douglas Otis <[email-masked]>
Date: Thu, 4 Jun 2009 17:10:55 -0700

On Jun 4, 2009, at 4:32 PM, Murray S. Kucherawy wrote:

> For the sake of enumerating implementations, the current libdkim  
> implementation does make a distinction between a signature that  
> failed to verify and one that couldn't be verified because the key's  
> approved hashes and the signature's methods don't line up and one  
> that simply failed DKIM verification.
>
> So if I am to apply my earlier arguments, I have to support your  
> point because it puts more information in the hands of the assessor.
>
> However, unlike x= and l=, I don't see any possible benefit in  
> making the distinction.

Whenever the DKIM key asserts the algorithm supported by the domain,  
attackers are prevented from spoofing "unverifiable" signatures from  
domains that have as of yet not made the transition.

>  For example, how can you tell an attacker that created a signing  
> algorithm of "rsa-whatever" from a site that accidentally posted a  
> public key with "h=watever"?

Consider the key's assertion represents a means to contain the level  
of potential confusion that a algorithm transition might make.   
Especially when being done within an exigent timeframe.

>  Are you sure you want to consider those as equivalent and apply the  
> maximum punishment rather than just treat the message as unsigned in  
> both cases?

It seems suitable to either reject or annotate a stern warning, those  
messages where the domain refutes the algorithm claimed in the DKIM  
signature.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Jun 2009 02:53:12 -0700

> -----Original Message-----
> From: Douglas Otis [mailto:[email-masked]]
> 

Doug,

I'm still not convinced, but you have me thinking about it.

You're claiming that an attacker might craft a message claiming to use a hash called something like MD6, and the absence of "h=md6" in the corresponding key named by "d=" and "s=" in the signature should cause a rejection or an appropriate annotation.  But that would presuppose the "a=" in the signature contains something like "rsa-md6" and, further, that the verifier knows what that means.  Otherwise, wouldn't the verifier in that case just kick the signature out claiming an unknown signing algorithm?

Given that there are currently only two possible values for "a=" in a signature, the only actual attack vector here is an "rsa-sha1" signature from a site that claims "h=sha256" or vice-versa.

Is that still something about which we should be concerned?

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Mon, 8 Jun 2009 10:16:11 -0700

On Jun 8, 2009, at 2:53 AM, Murray S. Kucherawy wrote:

>> It seems suitable to either reject or annotate a stern warning,  
>> those messages where the domain refutes the algorithm claimed in  
>> the DKIM signature.
>
> Doug,
>
> You're claiming that an attacker might craft a message claiming to  
> use a hash called something like MD6, and the absence of "h=md6" in  
> the corresponding key named by "d=" and "s=" in the signature should  
> cause a rejection or an appropriate annotation.  But that would  
> presuppose the "a=" in the signature contains something like "rsa- 
> md6" and, further, that the verifier knows what that means.   
> Otherwise, wouldn't the verifier in that case just kick the  
> signature out claiming an unknown signing algorithm?
>
> Given that there are currently only two possible values for "a=" in  
> a signature, the only actual attack vector here is an "rsa-sha1"  
> signature from a site that claims "h=sha256" or vice-versa.
>

This feature provides a means to thwart exploits that will likely  
leverage an introduction of a new algorithm.  Email is replete with  
examples of adoption taking years.  As such, Jon is wrong about there  
only being two states for a signature.  As you have indicated,three  
states are already supported :

  1) Invalid
  2) Valid
  3) Algorithm Refuted

While initially, "Algorithm Refuted" may not play a major role, in the  
coming years it might.  No one can predict the future, so why not be  
prepared?  After all, the DKIM standard will need to retain the tags  
for this feature.  This feature assists with a difficult problem  
created by the lack of negotiations for algorithm support between  
sender and receiver.  Since DKIM strives to be widely applied and  
relied upon, providing a means to improve algorithm agility remains  
prudent, nor is having this feature in place harmful.

This feature provides an enhanced agility only when senders start  
asserting algorithms not initially listed by the standard.  This  
feature becomes especially useful when these new algorithms are not  
always supported receivers, such as the example of MD6.  Since all  
compliant deployments of DKIM support both sha256 and sha1, this  
feature does not offer an value at this time.  In these cases, the  
receiver should be able to determine whether the signature in  
invalid.  This feature will have value only when a new algorithm is  
asserted by the sender that is not supported by the receiver.

In the case of a new algorithm, only the domains using the new  
algorithm would be exposed to bad actors spoofing their new  
algorithm.  These domains should be able to take additional steps,  
such the inclusion of as pass-phrases, to mitigate the potential  
spoofing.  Without this feature,  other domains would be unable to  
refute the use of the new algorithm, and so email handling would be  
unable to refuse what should have otherwise been detected as an  
obvious spoof.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Jun 2009 02:11:15 -0700

I think I've come around to +1 on keeping "h=" in key records.

-MSK