Subject: [ietf-dkim] New Issue: Base: Upgrade indication and protection against downgrade attacks

From: Mark Delany <[email-masked]>
Date: Wed, 15 Feb 2006 07:46:34 +0000

(This is an idea that germinated from discussions at the DKIM summit
in Santa Clara yesterday, and I'd like to bring it on-list. It's not
my idea, but I think it's a good one).

Hopefully it's obvious to all that the algorithms we pick today for
signature and hash calcs will not survive the lifetime of DKIM. Many
will have seen sha256 popping up as a potential replacement for sha1.

It's been said before that the most obvious solution to supporting
algorithm upgrades consists of three parts:

 o a signer MUST sign with the strongest algorithm and MAY
   additionally sign with a weaker algorithm. In short, multiple
   signature headers.

 o a verifier MUST select the strongest signature they recognize and
   verify with that. All lessor signatures are ignored.

 o A future spec that defines new algorithms MUST define relative
   strengths. Eg, sha256 is stronger than sha1. If relative strength
   is not clear, then why introduce a new alg?

While that provides a transition mechanism and a backward
compatibility mechanism, it is vulnerable to downgrade attacks.

For example, say a vulnerability is found in sha1 and a future spec
defines sha256 as the stronger hash alg. A dutiful signer will
generate a sha256-based signature and an sha1-based signature.

The downgrade attack is to remove the stronger sha256-based signature
and apply the attack to the weaker sha1-based signature.

The problem for the unwitting verifier is that they don't know the
signer originally added a stronger signature. All they see is the
weaker sha1 signature.

The simple solution is to provide an indication to the verifier that
the signer generates a stronger signature. That indication could
possibly go in one of three places:

 o SSP, but that's not normally consulted on a successful verify.

 o The signature header, but all message content is vulnerable to the
   downgrade attack so the indicator cannot be trusted.

 o The Selector of all the signatures excepting the strongest.

The latter seems the best choice and is the crux of the idea.

Picking some random tag, say, U= which indicates that this is a
downgrade Selector. The rules become:

 o a signer MUST sign with the strongest algorithm and if they also
   add signatures with weaker algorithms, the Selectors for those
   weaker algorithms must have a U= tag.

 o a verifier MUST select the strongest signature they recognize and
   verify with that.

Assuming verification success:

 o If the Selector of the strongest recognizable signature has no U=
   tag, then accept the verification.

 o If the Selector of the strongest recognizable signature has a U=
   tag *AND* the verifier is capable of recognizing stronger, then
   reject the verification as a potential downgrade attack.

 o If the Selector of the strongest recognizable signature has a U=
   tag *AND* this is the strongest signature recognized by the
   verifier, suggest to your owner that you upgrade and cautiously
   accept the verification.

With just one algorithm upgrade that logic works just fine. However,
with two or more upgrades, we need to introduce further logic; here's
why.

In a future world, what if DKIM has evolved to support three hash
algs: rsa1, rsa256 and rsa1024? Let's say the verifier recognizes rsa1
and rsa256. The signer OTOH is more modern and additionally knows
about rsa1024.

If the signer were to sign with rsa1024 and rsa1, then the verifier
will think such an email is a downgrade attack as it will recognize
the rsa1-based sig and detect a U= tag. However it will not recognize
the stronger sha1024-based sig and thus conclude a possible downgrade
attack.

The gap created by the signer is the problem here so the rule needs to
be that a signer must sign from strongest to weakest, WITH NO GAPS.
A signer need not use every algorithm, it simply cannot create gaps, so
Asha1024 and sha256 is fine as is a sole sha1024. While sha256 and
sha1 do meet the "no gaps" requirement, they do not meet the "use the
strongest you know" requirement.

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Feb 2006 12:56:05 +0000

Hi Mark,

> strongest you know" requirement.

Just a few additional considerations:-

- SHA-1 is now considered to be 2^63 "strong" & that'll only get worse.
   The IESG will get more and more strict about allowing even SHA-1 to
   be used, esp. where they don't see a backwards compatibility problem.
   In those cases, I expect they'll want to see SHA-256 used. An issue
   for DKIM is whether to include SHA-1 for anything at all, or for
   more than compatibility with pre-standards versions.

- Algorithms don't necessarily have a fixed, known, order of "strength",
   but are perhaps better considered to be "strong", "dodgy" or "broken".
   at a given moment in time. There should be no reason to use a known
   broken algorithm. Dodgy ones (like SHA-1 is now) should only be used
   for backwards compatibility. There may be more than one "strong" at
   any given time, e.g. sha-256, sha-512 or perhaps whirlpool, and
   perhaps their use will break down not by strength, but say,
   geographically, or by industry or whatever.

- If an algorithm is dodgy, then an attacker may be able to generate
   collisions that remove or modify, any "U=" attribute, or equivalent,
   depending on the details of the attack. With "standard" (i.e. pkcs#1)
   signing, I don't think we can do much better really and I don't
   think we want to get into modifying pkcs#1 here. Even so, it may be
   worthwhile including a "U=" attribute, or something, to help
   verifiers handle good signatures.

- If you sign anything with a really weak algorithm, and the attacker
   can easily generate >1 collision, then the attacker can probably
   create many many different signed messages, perhaps giving rise to
   other threats.

- Lastly, DKIM needs to plan for sha-1 being retired (2010) and probably
   for sha-256 being superseded by some new NIST-competition-winning
   algorithm in the next 5+ years. So even if we start now with "only
   sha-256", all of the above is still an issue down the road.

Stephen.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Feb 2006 08:50:44 -0800

>   sha-256", all of the above is still an issue down the road.

DKIM already permits specifying different algorithms.

If you are suggesting that it needs to do more than that, to anticipate some 
requirement that might be imposed 5 years from now, please elaborate.

As for SHA-1 vs. SHA-256:  Dealing with both the current desire to use sha-256 
and maintain compatibility with pre-IETF, existing use of sha-1 is handled 
easily by having the specification state something like:

      A signer SHOULD use sha-256.

      A validator MUST support sha-256 and sha-1.

This permits pre-IETF signers to be validated by post-IETF implementations.

Whether to make the signing behavior a SHOULD or a MUST depends upon whether the 
IETF version is permitted to maintain downward compatibility with pre-IETF 
validators.

Given that the very limited purpose of DKIM, for assigning transit 
accountability, and given that SHA-1 is a "concern" rather than being outright 
"broken", the use of SHOULD seems reasonable.

A MUST probably also is inappropriate because it then makes it impossible for 
the signer to choose some other algorithm that the signer deems appropriate.

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to 
http://dkim.org/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Feb 2006 17:06:08 +0000

Dave Crocker wrote:
> If you are suggesting that it needs to do more than that, to anticipate 
> some requirement that might be imposed 5 years from now, please elaborate.

Its neither that vague, nor that frightening. NIST will end up
organising a competition for a new hash algorithm - they've nearly
said as much already. When that's done, the winner will be a FIPS and
will be the algorithm of choice. That's likely to take a few years,
but probably not 10, IMO.

The point is that when the DKIM RFC is about 2-3 years old, there'll
likely be a different preferred algorithm and we should (now) try to
make that transition as easy as we can, so long as it doesn't hold us
up too much. But, if we do a good job on the sha-1/sha-256 issue now,
I'd hope that should be enough.

> 
> As for SHA-1 vs. SHA-256:  Dealing with both the current desire to use 
> sha-256 and maintain compatibility with pre-IETF, existing use of sha-1 
> is handled easily by having the specification state something like:
> 
> Whether to make the signing behavior a SHOULD or a MUST depends upon 
> whether the IETF version is permitted to maintain downward compatibility 
> with pre-IETF validators.
> 
> accountability, and given that SHA-1 is a "concern" rather than being 
> outright "broken", the use of SHOULD seems reasonable.
> 
> A MUST probably also is inappropriate because it then makes it 
> impossible for the signer to choose some other algorithm that the signer 
> deems appropriate.

I'd be fine with that. Although it'd be a pity not to have a MUST
for the signer, but I guess some wording could handle that.

Equally, I'd also be fine with the MUST for sha-256, if that were
where the consensus lay. I guess the main argument for the MUST on
sha-256 would be to encourage moving away from sha-1 before there's
much wider DKIM deployment.

Stephen.

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 15 Feb 2006 11:05:21 -0600

> generate a sha256-based signature and an sha1-based signature.

It may not be obvious to all why this problem shouldn't be addressed 
simply by an operator of DKIM verification software making a local 
policy decision to ignore signatures which use insecure algorithms. 
Perhaps the danger here is wrapped up in some assumptions about that 
operator as follows:

a) it assumes that the operator of the verification software is 
attending all our conferences and reading our mailing lists so that they 
discover current and future vulnerabilities

b) it assumes they will recognize that the verification software they 
are using (which was procured from a vendor) is vulnerable (actually 
using the compromised algorithm)

c) it assumes they will be using verification software actually capable 
of the granularity necessary to select which algorithms to accept and 
which to ignore

d) it assumes they will obtain sufficient motivation to take any 
corrective action at all

Anyway, just some additional thoughts along these lines.

-- 
Arvel

---

From: Mark Delany <[email-masked]>
Date: Wed, 15 Feb 2006 17:35:07 +0000

On Wed, Feb 15, 2006 at 05:06:08PM +0000, Stephen Farrell allegedly wrote:

> make that transition as easy as we can

That sounds like you're in violent agreement with the idea then.

Mark.

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 15 Feb 2006 11:32:51 -0600

> I guess the main argument for the MUST on sha-256 would be to
 > encourage moving away from sha-1 before there's much wider DKIM
 > deployment.

A MUST would more than encourage, it would require :)

Isn't SHA-1 sufficient since it (a) isn't broken (b) is the least 
computationally taxing (I assume) and (c) provides sufficient protection 
for our use (we aren't protecting files full of credit card numbers with 
DKIM).

-- 
Arvel

---

From: Douglas Otis <[email-masked]>
Date: Wed, 15 Feb 2006 09:42:51 -0800

On Feb 15, 2006, at 9:06 AM, Stephen Farrell wrote:

>
>
> Dave Crocker wrote:
>>
>> DKIM already permits specifying different algorithms. If you are  
>> suggesting that it needs to do more than that, to anticipate some  
> said as much already. When that's done, the winner will be a FIPS  
> and will be the algorithm of choice. That's likely to take a few  
> years, but probably not 10, IMO.
>
> The point is that when the DKIM RFC is about 2-3 years old,  
> there'll likely be a different preferred algorithm and we should  
> (now) try to make that transition as easy as we can, so long as it  
> doesn't hold us up too much. But, if we do a good job on the sha-1/ 
> sha-256 issue now, I'd hope that should be enough.

Of equal concern with respect to crypto-security, support for 500-bit  
keys should be dropped.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Feb 2006 10:34:33 -0800

> for our use (we aren't protecting files full of credit card numbers with 

Just a few data points:

1) sha-256 is about 55% the speed of sha-1  [*]
2) for smallish pieces of email, it's almost certainly the RSA overhead
    that dominates.
3) I've heard tell that it's often the case the MTA's are IO bound. I
    don't know how much this holds true these days on inbound MTA's
    doing scanning/filtering.

Overall, my suspicion is that Moore's law will make this inconsequental
before there's even an RFC number for DKIM.

		Mike

[*] http://www.eskimo.com/~weidai/benchmarks.html
_______________________________________________
NOTE WELL: This list operates according to 
http://dkim.org/ietf-list-rules.html

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 15 Feb 2006 19:43:50 +0100

Mark Delany wrote:
 
> a signer MUST sign with the strongest algorithm and MAY

Add more crap to the mail header and I'll auto-report is as net
abuse with spamcop.

(Not really of course, but it illustrates a valid point)  Bye.

---

From: Eric Allman <[email-masked]>
Date: Wed, 15 Feb 2006 12:05:56 -0800

Stephen,

Although I have no objection to anything you say, I think you are 
missing the point.  sha1 vs sha256 was just a placeholder; Mark could 
have said "AlgorithmA" vs "AlgorithmB".  The point is how we can 
avoid downgrading attacks, not what we should do about the specific 
sha1 problem.

eric

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Feb 2006 20:08:37 +0000

Michael Thomas wrote:
>> computationally taxing (I assume) and (c) provides sufficient 
>> protection for our use (we aren't protecting files full of credit card 
>> numbers with DKIM).
> 
> Just a few data points:
> 

Yes. I don't believe there's an interesting performance issue here.

The point that DKIM signatures aren't meant to be high assurance is
also valid. However, sha-1 has been *seriously* weakened: 2^63 is a
lot less than 2^80, and such problems only ever get worse by
definition. So there is reason to think about whether it'd be ok
or not, were most instances of DKIM signatures to use sha-1.

And regardless of whether hash-collision based attacks are actually
a serious threat, (I reckon they're not really) if someone can
demonstrate colliding DKIM signatures, that does do damage to the
overall effort.

I'm not saying that the "MUST sha-256" argument is compelling, but
it does warrant consideration. (And the IESG will probably insist on
a good answer to the "why's sha-1 still allowed" question that they'll
inevitably ask.)

Regards,
Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Feb 2006 20:13:58 +0000

Hi Eric,

I agree that these are separable issues. Dave just followed up on
the sha1/sha256 point - other points I made were algorithm
independent, in particular I find it hard to see how to counter a
downgrade attack when we cannot negotiate and have to stick with
pkcs#1 signatures - but I would agree that the idea is worth
following up.

S.

Eric Allman wrote:
> have said "AlgorithmA" vs "AlgorithmB".  The point is how we can avoid 
> downgrading attacks, not what we should do about the specific sha1 problem.
> 
> eric
> 
>

---

From: Mark Delany <[email-masked]>
Date: Wed, 15 Feb 2006 20:27:16 +0000

> also valid. However, sha-1 has been *seriously* weakened: 2^63 is a
...
> And regardless of whether hash-collision based attacks are actually
...
> I'm not saying that the "MUST sha-256" argument is compelling, but

Can we seperate this discussion into another thread please?

I was wanting to solely discuss mechanisms in this thread.

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Feb 2006 13:58:07 -0800

>> If you are suggesting that it needs to do more than that, to 
>> anticipate some requirement that might be imposed 5 years from now, 
>> please elaborate.
> 

1. I can't guess what you interpreted as "frightening" in my characterization. 
All I did was note your own reference to a 5-year timeframe and the lack of our 
having any details about what would be chosen by then. As for vagueness, the 
lack of detail could hardly be characterized otherwise.

2. You did not answer my primary question:  What are you *specifically* are 
suggesting being done to the specification?

>> impossible for the signer to choose some other algorithm that the 
>> signer deems appropriate.
> 

A "pity"?

In other words, you think it appropriate to *require* that all signers *always* 
use SHA-256?

This would mean, for example, that support for the next, preferred algorithm, 
would require revising and re-issuing the specification.

> much wider DKIM deployment.

I think it is a bit unusual, if not unprecedented, to choose "MUST" as a means 
of encouraging folks, rather than because there is a technical *requirement* for 
only and exactly the behavior that is mandated.

d/
-- 

Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Feb 2006 00:35:27 +0000

> 1. I can't guess what you interpreted as "frightening" in my 

Nothing. I interpreted you as being frightened of something
that might be required in future. I was trying to reassure you.

 > All I did was note your own reference to a 5-year
> timeframe and the lack of our having any details about what would be 
> chosen by then. As for vagueness, the lack of detail could hardly be 
> characterized otherwise.

I disagree. Its very well known how to plug in a new hash function.
Nothing vague about it IMO.

> 2. You did not answer my primary question:  What are you *specifically* 
> are suggesting being done to the specification?

I am making no specific proposals, simply adding to the set of
things to be considered when/if some signature-algorithm flags are
being considered.

>> for the signer, but I guess some wording could handle that.

Yes. Its easier to just tell someone what they MUST do, rather than let
them figure it out from a SHOULD and a MAY. Not a big deal.

> In other words, you think it appropriate to *require* that all signers 
> *always* use SHA-256?

That could be appropriate. I haven't said that I think it is.

> This would mean, for example, that support for the next, preferred 
> algorithm, would require revising and re-issuing the specification.

That's inevitable so long as we prefer any set of algorithms. Same as
happens with every protocol using crypto when preferred algorithm
goodness changes.

> I think it is a bit unusual, if not unprecedented, to choose "MUST" as a 
> means of encouraging folks, rather than because there is a technical 
> *requirement* for only and exactly the behavior that is mandated.

I think you may be taking one word a tad too literally there. (Is
that unprecedented:-)

Discouraging use of suspect algorithms is a good. It may or may not
constitute a sufficient good to be worthwhile doing in this case.

Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Feb 2006 00:43:09 +0000

> I was wanting to solely discuss mechanisms in this thread.

Fair enough, but the problem is that the suggested scheme seems to
be vulnerable if the less desirable hash algs are broken for collisions.
That's exactly the problem seen with current hash functions.

The signer might mark the rsa-md5 signature with "U=crap-alg" but the
attacker can happily generate a colliding message with no "U=" at all.

Is the scheme still worthwhile if that's the case? Or, have I
misinterpreted your scheme?

S.

---

From: Mark Delany <[email-masked]>
Date: Thu, 16 Feb 2006 01:21:54 +0000

> misinterpreted your scheme?

I think you've mis-interpreted. The U= goes in the Selector of the
downgraded algorithm, not the signature.

Regardless of what the attacker does to the message, a verifier *has*
to fetch a Selector. If that Selector tells the verifier that they are
using a downgraded algorithm the verifier can act accordingly: ie
accept the risk if that's the best they can verify or fail the verify
if a higher grade sig isn't present.

Mark.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Feb 2006 12:02:18 +0000

> downgraded algorithm, not the signature.

Indeed I did. Sorry 'bout that.

Stephen.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 16 Feb 2006 05:45:37 -0800

> or not, were most instances of DKIM signatures to use sha-1.
According to a colleague attending RSA, someone has gotten SHA-1 down to
2^61.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Feb 2006 15:33:20 +0000

Mark,

Now that I've reset the brain a bit:-)

> be that a signer must sign from strongest to weakest, WITH NO GAPS.

The assumption that all signers and verifiers have the same idea of an
absolute strength-order for hash algorithms is a bit optimistic.

For example, some countries do insist on national algorithms being
supported - see rfc 4357 for example. I don't think I want to get into
a dispute about whether the Gost-hash is better or worse than sha-256
(or whatever) - do you?

Stephen.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 Feb 2006 08:14:52 -0800

> a dispute about whether the Gost-hash is better or worse than sha-256

If you can't rank algorithms, is there any meaningful concept of a
"downgrade attack"?

I'm sort of wondering though if Mark's problem here might be just as
easily solved by having a "current"/"next" kind of routine. That is,
only allow two in play at any one time, where < n-1 is deprecated.
Considering that 2822 is not nimble (ie, no ability to negotiate
e2e), is there any real likelihood that a reasonable receiver will
be two versions behind? It sort of strikes me like 40 bit only rc4
ssl: should we even care about such lame receivers?

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Feb 2006 08:20:57 -0800

Folks,

> only allow two in play at any one time, ...

I keep coming back to the very limited goal of DKIM and wondering whether the 
concern about a downgrade attack isn't just a little too esoteric for that goal.

Besides that presumably, having multiple signature versions, as discussed here, 
is only for transition times.

Do we really need to engineer such fine-grained mechanisms for protection 
against attacks during limited windows of mis-opportunity, for a mechanism that 
is only trying to aid in determining whether to deliver a message?

d/

-- 

Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Feb 2006 16:30:02 +0000

> If you can't rank algorithms, is there any meaningful concept of a

Yes. The "you" above is ambiguous though - every one can have their
own ranking, but we cannot all have the same ranking (it seems).

> ssl: should we even care about such lame receivers?

I think something along those lines might do it. Or else maybe have
the signer flag their "favorite" algorithm's public key, and let
verifiers who don't see one of those signatures be wary if they like.
(But before I'd want us to make such a decision I think we'd need to
spell out the entire signature algorithm agility story - perhaps a
good agenda item for Dallas?)

S.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 16 Feb 2006 08:33:02 -0800

On Feb 16, 2006, at 8:20 AM, Dave Crocker wrote:

> I keep coming back to the very limited goal of DKIM and wondering  
> whether the concern about a downgrade attack isn't just a little  
> too esoteric for that goal.
>
> Besides that presumably, having multiple signature versions, as  
> discussed here, is only for transition times.
>
> Do we really need to engineer such fine-grained mechanisms for  
> protection against attacks during limited windows of mis- 
> opportunity, for a mechanism that is only trying to aid in  
> determining whether to deliver a message?

That depends on how seriously recipients and their MUAs treat a DKIM
signature.

Is it a sign that the mail is very, very likely to come from who it  
claims to come
from, so domain-based whitelisting applies? In that case, the  
threshold of
"sufficiently expensive" to deter attacks is pretty low.

Or is it a sign that the mail definitely comes from the entity  
involved, for
instance your bank. Of course, DKIM doesn't really try to be that broad,
so there are a number of very cheap ways for a bad actor to do this
without compromising DKIM. Those approaches are extremely cheap,
and they set an upper bound on how much effort a bad actor will
bother applying to break DKIM. Again, the threshold is fairly low,
but a little higher than the previous one.

As I understand it, DKIM isn't really intended to be strong  
authentication
of message, rather it's intended to be cheap authentication of  
originating
entity.

"Simple and shipped" beats "over-engineered and irrelevant" in this  
case,
I think.

Cheers,
   Steve

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Feb 2006 08:52:55 -0800

> from, so domain-based whitelisting applies? In that case, the threshold of

DKIM does not necessarily claim to validate "who it came from".  It claims that 
the administrator of a particular domain name is willing to "take 
responsibility" for the message.

This is not a small difference in meaning.

> As I understand it, DKIM isn't really intended to be strong authentication
> of message, rather it's intended to be cheap authentication of originating
> entity.

cheap authentication, yes.  we can quibble about the "originating" reference, 
but the "cheap" is what i'm focused on.

Cheap means we should be very, very judicious about burdening the mechanism with 
clever, additional mechanisms designed to burden with with strength against 
occasional and esoteric attacks.

> "Simple and shipped" beats "over-engineered and irrelevant" in this case,
> I think.

definitely.

d/

-- 

Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Feb 2006 17:00:24 +0000

Dave Crocker wrote:
> whether the concern about a downgrade attack isn't just a little too 
> esoteric for that goal.
> 
> protection against attacks during limited windows of mis-opportunity, 
> for a mechanism that is only trying to aid in determining whether to 
> deliver a message?

I think that that's a fair question.

I believe we do need to have signature algorithm agility of some sort
for the reasons to do with hash weaknesses and also since there will
always be >1 favorite algorithm in a big world.

This scheme (or similar) may be a part of the way to provide that
agility. For now though, I don't understand well enough whether we
should worry about downgrade attacks when signing more than once.

Stephen.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Feb 2006 09:05:40 -0800

> should worry about downgrade attacks when signing more than once.

having agility is different from adding mechanisms to defend against attacks
against the use of that agility.

d/

-- 

Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Feb 2006 17:31:46 +0000

> against the use of that agility.

I agree.

S.

---

From: Mark Delany <[email-masked]>
Date: Thu, 16 Feb 2006 17:30:53 +0000

> Now that I've reset the brain a bit:-)

Thanks. My crude explanation probably compounded the problem a bit.

> a dispute about whether the Gost-hash is better or worse than sha-256

Right. I completely understand that there might be different views of
strong and weak and that we (for most of we and certainly me) aren't
experts in this area.

But I'm thinking that DKIM has a simpler task. It merely has to
observe the debate and decisions of the security world and when they
come to conclusions we piggy-back off of that:

 If 	a) The current algorithm is accepted as being at risk
 and If b) An agreed-upon stronger algorithm is available
 then 	c) Change the standard to reflect the stronger algorithm

While there remains uncertainly about a) or b) then do nothing.

Mark.

---

From: Mark Delany <[email-masked]>
Date: Thu, 16 Feb 2006 17:34:40 +0000

> If you can't rank algorithms, is there any meaningful concept of a

Furthermore, if you can't rank one as better, why would we consider
adding it to the repertoire in the first place?

> easily solved by having a "current"/"next" kind of routine. That is,

Right. That simplifies/eliminates the skipping issue.

> be two versions behind?

That's the question.

Mark.

---

From: Mark Delany <[email-masked]>
Date: Thu, 16 Feb 2006 17:36:45 +0000

> concern about a downgrade attack isn't just a little too esoteric for that goal.

It happens that it also solves the agility requirement too. So even if
you're skeptical of downgrade attacks being relevant, we are hoping -
I presume - that DKIM will live for longer than the current set of
anointed algorithms and that we do need a way to transition that
doesn't require a forklift.

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Feb 2006 09:55:17 -0800

Mark Delany wrote:
> It happens that it also solves the agility requirement too. 

I think the case for having agility has been well and strongly made, and I 
certainly was not challenging that.

Having an agility approach that we like more than any other approach, and that 
just happens to be robust against downgrade attack, is different than focusing 
on the concern for downgrade attack.

I was hearing the latter, not the former.

I am belaboring this issue because of the tendency that is true for all 
engineering, but particularly true for security engineering:  The tendency to 
worry more about every possible problem than any real need.

d/
-- 

Dave Crocker

---

From: Mark Delany <[email-masked]>
Date: Thu, 16 Feb 2006 18:14:49 +0000

> on the concern for downgrade attack.

Right. There are any number of reasons why we may have to change
algs. Security attacks, costs, IP claims...

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Feb 2006 10:26:51 -0800

> algs. Security attacks, costs, IP claims...

So forgive me for being so dense -- even though I assume folks are used to that 
by now -- but DKIM already supports multiple signatures (including permitting 
alternate algorithms).

So I am now entirely unclear what change is needed and what problem is being 
pursued, by the current thread.

d/
-- 

Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Thu, 16 Feb 2006 10:28:08 -0800

On Feb 16, 2006, at 9:36 AM, Mark Delany wrote:

> It happens that it also solves the agility requirement too. So even  
> if you're skeptical of downgrade attacks being relevant, we are  
> hoping - I presume - that DKIM will live for longer than the  
> current set of anointed algorithms and that we do need a way to  
> transition that doesn't require a forklift.

Preventing hash related exploits with the 'a=' parameter within the  
signature header remains doubtful.  The hash parameter should be  
indicated within the key information.  If I followed this correctly,  
you suggested the hash information could be moved to the currently  
undefined selector, which makes upward definitions difficult.  As the  
key must be located at the selector, there would be little advantage  
in using such an approach except to retain the limited (flawed) key  
definition even though DNS entries must change.  Introducing a new  
hash algorithm also means introducing new client software.  Perhaps  
modifying key content can also be resolved when transitioning to the  
use of the CERT RR.  This CERT RR would allow key information to be  
stored in a binary form, include references to other types of key  
services, and properly defined the complete algorithms as needed for  
a secure design. : )

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-09.txt

This CERT RR has the algorithms defined within a fields specified  
within a key parameter, the safe method for defining the hash used.

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Feb 2006 17:30:49 +0100

>> e2e), is there any real likelihood that a reasonable receiver will
And it's only slightly more easy to predict than tomorrow's stock
prices.  We know people are focusing on this space, but we don't know
what they'll find until they find it.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Feb 2006 17:53:49 +0100

> what they'll find until they find it.
Of course that's metaphorical.  Thank you to those who felt the need to
point out that tomorrow is Saturday.

Eliot