Re: [ietf-dkim] Re: 1368 straw-poll :

In my view, it doesn't matter if its A, B, AB, XYZ or weaker or 
stronger.   It is about expectations.
if S says I only sign with A, then R should not see signatures with B, X 
or Y.
Expected behavior is what I consider a strong part of the negotiation if 
we want to call it that. Anything short of that produces uncertainty and 
hence risk.
Just consider that bad guys may find using the weakest covers 80% of
all systems, and when it needs to, it uses the stronger method for the 
remaining.
But guess what?

He might not use it at all or create a conditions that produces a FAULT 
simply because systems still need to deal with LEGACY operations
So in other words, until we have a SPECIFICATION, BCP or what have you 
on how to deal with failure, it really doesn't matter what strength you
have.

Seeing failure as unsigned just doesn't cut it for me simply because 
there will be MORE failures then success and we will need a way to deal 
with that.
My hope is that DOMAIN POLICY helps in every way it can, including 
having a bit saying "I SIGN WITH THIS OR THAT ALGORITHM."
Just look at it this way:

I can see companies doing a preliminary "check" on receivers to see what 
"DKIM" support it has before it accepts email addresses from users.  A 
high value company policy account may mandate this before begins to do 
high value transactions with the user.  If the user's email domain is 
not "secured" enough in the eyes of the company, it might even provide 
the user its own email or some other more secured domain ISP address.

---
HLS



EKR wrote:
> Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> writes:
> > On Feb 26, 2007, at 7:32 AM, John Levine wrote:
> > >   Why shouldn't receivers use their own best judgement about what
> > > hashes are adequately strong, and why should they believe
> > > statements from random spammers about relative strengths of crypto
> > > algorithms?
> > Without a means for the signer to assert which algorithms are
> > deprecated, until the problematic algorithm can be obsoleted, a
> > downgrade vulnerability will exist.  This period of this
> > vulnerability will likely be measured in years.  Defining a way
> > forward does not need to alter existing structures, but instead
> > simply define how the signer can make the assertions when they are
> > needed.
> I'm sure I'm going to regret wading in here, but...
>
> We have two algorithms, A and B. Let's stipulate that B is stronger
> than A. Now, the sender can have three policies: send A (SA) Send B
> (SB) and send A+B (SAB). The receiver can similarly have three
> policies, accept A (RA), accept B (RB) and accept A or B (RAB).
>
> If you cross these you get the following matrix:
>
>                  Sender
>              SA    SB    SAB
>          RA   A     X      A
> Receiver RB   X     B      B
>          RAB  A     B     AB
>
> Because implementations are supposed to ignore signatures they
> can't verify, the only context in which downgrade attacks matter
> is if the sender is implementing SAB and the receiver is implementing
> RAB. In this case, assuming there's no policy information, the 
> attacker can strip a signature and convince the receiver that the
> sender implemented SA or SB. Since we've stipulated that B>A, 
> only the former makes sense.
> Now, again there are two cases:
>
> 1. A is so weak that an attacker can readily mount attacks on it
>    at a practical level.
> 2. It's not.
>
> Only in the first case does a downgrade attack buy you anything.
>
> So, as I understand Doug's argument, A is strong enough that the
> receiver thinks it conveys *some* informational value (otherwise
> he would simply implement RB) but strong enough that it's
> being regularly broken. So, the sender wants to implement SAB
> and securely tell the receiver that so that receivers which
> do implement RAB will get the benefit of B. Do I have this
> right?
>
> If so, I find this scenario fairly implausible. If algorithms
> are being routinely broken, I would expect people to turn them
> off entirely or *at least* for receivers to quickly roll out
> the new algorithms allowing senders to safely send the newer
> ones without the older ones. And if algorithms are being broken
> enough to mandate this kind of policy indicator, I find it
> hard to believe they carry much informational value.
>
> As a thought experiment: SHA-256 has a nominal security value
> of 256-bits against preimage attacks (the kind that's most
> likely relevant here). At what bit strength do you believe
> receivers would still trust it but downgrade attacks would be
> practical enough to mandate this kind of indicator?
>
> -Ekr
>
>
>
>
>
>
>
>
>
>  
>
>
>
>
>
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html

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