I know that we've gotten a barrage in the last few days but is there
support for
having policy for what algorithms a domain uses? I assume this is to
deal with
bid-down attacks. I know where we stand wrt this with -base, but don't
remember
whether we were given any guidence wrt -ssp, or whether there was general
support for this in -ssp.
Mike
Hallam-Baker, Phillip wrote:
I sign nothing has to be there in the matrix even if it is implict by the lack
of a DKIM policy record. I dislike this form of signaling, it leads to
unpleasant edge cases, better to do it explicitly.
I don't see the need to specify anything about third parties though. That is a
key record attribute, not a top level policy. If someone only signs third party
records then they should only have records for third parties.
The case where I do see a need that is not yet addressed is the ability to say
'I sign everything with this particular algorithm'.
The reason it is needed is to manage the transition from a weak signature
scheme to a strong one. The existence of a key record means only that it is an
acceptable signature key. If I am in a transition situation I am going to be
double signing with the legacy algorithm and the new one simultaneously:
Signature: 1.A, RSA-1024
Signature: 1.B, DSA-2048
Assume for a moment that the policy record only says 'I always sign' and that
RSA1024 has been compromized. The attacker can then perform a downgrade attack
by only provising the first signature:
Signature: 1.A, RSA-1024
There is no way for the recipient to know that the signature is compromized,
there is no way to know that there should be a strong signature in addition.
Alternatively the attacker might make use of the fact that there are many
verifiers that only support the RSA1024 algorithm and perform an 'unsupported
upgrade' attack:
Signature: 1.B, DSA-2048
If the policy record says 'I always sign with DSA2048 AND I always sign with
RSA1024) this issue is avoided and the transition can be managed effectively
and securely.
There are two ways that this could be implemented, one is by direct reference
to the algorithm, the other is by subselector. In this case I deliberately used
key selectors in different subdomains.
So the statement then becomes something of the form 'I always sign with a key
in *.a._domain.example.com' AND 'I always sign with a key in
*.a._domain.example.com'.
I prefer this particular approach as it allows us to establish arbitrary
constraints using appropriate key selector management tools. It also allows for
the keys to be referenced to an entirely different domain. So for example
example.com outsourced their mail provision to pobox.com which signs with a key
managed exclusively by PO.Box. This mechanism allows for a redirection to the
signature provider key set. I think we can meet a lot of the use case
requirements that way.
I also prefer the selector approach because it neatly partitions all the crypto
in the key records. The policy record remains 'crypto blind'. Same goes for
c18n algorithms and such.
Selectors are good stuff.
Note that in this approach it is necessary to always retreive the policy record
in the case that the verifier is uncertain of the security of a particular
signature algorithm. I don't think that this is a major concern since it is
very rarely the case that there is widespread use of a seriously broken crypto
algorithm, we tend to be very very conservative and plan transitions long
before they are forced.
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Paul Hoffman
Sent: Thursday, July 27, 2006 2:26 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: [ietf-dkim] I sign nothing / only only 3rd party / some mail
At 2:00 PM -0400 7/27/06, <Bill(_dot_)Oxley(_at_)cox(_dot_)com> wrote:
My requirements
I sign all
I sign nothing
I sign only 3rd party
I sign all and 3rd party
I sign some mail
My Policy/Practice
I sign all - every piece of mail purported to be from me
must be signed
I sign nothing - If mail arrives with a DKIM sig I didn't send it
I sign only 3rd party - I only act as a signing domain for other
domains, I don't sign any of my own mail
I sign all and 3rd party- I sign all my mail and for other
parties as
well
I sign some mail - I sign only mail that I am willing to
swear that I
am responsible for
I am completely confused by "I sign nothing" and "I sign only
3rd party" and "I sign some mail". I don't see the value of
those to the recipient.
"I sign nothing" seems weird. If I have something signed by
your domain, and I cannot get the signing key from your
domain, "I sign nothing" adds no value. The signature is
invalid. If an attacker can inject a DKIM header and a key,
he can also suppress the SSP response.
"I sign only 3rd party" has the same attack problem as "I
sign nothing".
"I sign some mail" doesn't tell the recipient anything useful.
What am I missing?
--Paul Hoffman
_______________________________________________
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html