Re: [ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms
I think I've come around to +1 on keeping h= in key records. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms
-Original Message- From: Douglas Otis [mailto:do...@mail-abuse.org] 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, 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms
On Jun 8, 2009, at 2:53 AM, Murray S. Kucherawy wrote: -Original Message- From: Douglas Otis [mailto:do...@mail-abuse.org] 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, 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? 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms
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. 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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 4, 2009, at 2:55 PM, Murray S. Kucherawy wrote: 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. 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 -BEGIN PGP SIGNATURE- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFKKEz3sTedWZOD3gYRAnSXAJ41g5EDKKX4ZNCHe4hSFJzuRCtl7gCgr1dg uyXYARgVPEsA2kwnagYUhVY= =zPOv -END PGP SIGNATURE- ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms
On Jun 4, 2009, at 2:55 PM, Murray S. Kucherawy wrote: TXT RR tags h: Acceptable hash algorithms 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms
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. Though the spec discusses an empty p= as giving an explicit revoke indication. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms
Disagree. This feature is about better informing recipients as to the status of the signature. 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? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms
On Jun 4, 2009, at 4:32 PM, Murray S. Kucherawy wrote: Disagree. This feature is about better informing recipients as to the status of the signature. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 -BEGIN PGP SIGNATURE- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFKJFINsTedWZOD3gYRAla4AJ9yvw+h7dMYit+zrvp3zTuDdJc6PACghYJd ns+FvzyHgSeT03feHK6kyuY= =Jxxh -END PGP SIGNATURE- ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms
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. Please discuss arguments for and against dropping this. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
