-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 26, 2007, at 3:30 AM, Stephen Farrell wrote:
It seems to me that the exchange between John and Charles
below captures the crux of the issue.
Option 1: If we agree with Charles (& Phill I guess) that
looking up SSP and then passing on the only-signed-with-B
message will be common practice then there seems to be a
sufficient reason to include the "I sign all with A"
statement or equivalent in SSP.
Option 2: If OTOH, we agree with John, that further processing
(after sig check & SSP lookup) SHOULD or MUST treat the
only-signed-with-B message as unsigned, with no code branching
on the presence of the putative B-sig, then the additional SSP
expressiveness is useless.
I don't understand the choices. I *think* I prefer 2.
I think the example is interesting in theory, but I really think we
don't have an agreement on some SSP basics. Here's some handwaving at
some formalism in some principles:
(1) The receiver is always in control. The receiver can do anything
they want to a message for whatever reason they want to. (I treat
this as an axiom, and one that is independent of DKIM. If the is
false, then a receiver can't delete spam.)
(Corollary) Checking a DKIM signature is optional. The fact that you
signed a message does not obligate me to verify your signature. I can
look at a properly-constructed DKIM message from the domain "419-
guild.ng" and decide to trash it out of hand.
(2) If a DKIM signature is valid, the receiver isn't going to check
SSP. The receiver will make whatever action they will take based upon
knowing the responsible domain combined with content analysis, the
direction of the wind, and so on.
(3) If a DKIM signature is missing, a receiver might check SSP, but
don't count on it.
(4) If a DKIM signature is present but broken, a receiver *might*
check SSP, but is under no obligation to. (This is derivable from
(1), but I think it needs to be stated.)
(5) A receiver might consider a signature made with parameters that
they don't speak to be either a broken signature or a non-existent
signature.
I think that these principles get us out of the apparent "downgrade
attack." Let's suppose that SHA-1 was broken yesterday. I can deploy
DKIM software that just considers all SHA-1 signatures to be noise
and thus anything signed with SHA-1 is a non-DKIM message. End of
problem. Yeah, this is going to be an operational annoyance, but
there's no *problem*, where a problem is a forged signature or
something akin to one.
I think that we tend to forget (1). We also tend to forget (4) and (5).
None of the sender's actions with DKIM creates an obligation on the
receiver's part. To be blunt, DKIM is one big MAY. (It might be a big
SHOULD, but a SHOULD is just a MAY with an attitude.) On top of that,
SSP is a big MAY, as well. Now I hope and expect that many people
will decide to do these MAYs, but I don't expect DKIM to become
mandatory.
There is going to be a *receiver* policy system that we aren't going
to standardize, but the implementers will create. That receiver
system is going to include options like whether the receiver should
bother to check SSP. It will include options as to how to deal with
SHA-1, eventually.
Okay, now on to more of the poll question. I think Phill came up with
a fine example of why it's a good idea to have the SSP language
expressive enough to say, "I sign with both RSA-sha1 and ECDSA-
sha256." It removes ambiguity, and removing ambiguity is always good.
But if the receiver only implements RSA and thinks that SHA-1 is
crap, then we may not ever get to checking SSP. I may trash the
message, flag it as spam, content-scan it, or anything else I desire.
This is why I also agree with John. It is unambiguous that the
receiver is in control. If you publish a crap policy, it's not *my*
problem. I'm going to flag you messages or trash them, or whatever
else. If you write something in a policy that is useless or non-
actionable, I'm going to ignore it.
Furthermore, I may not even check your policy. *My* policy may
include a list of "phish-likely" domains, and I trash all messages
from them that aren't signed with a 4096-bit RSA key and SHA-512, and
if you don't like it (or don't implement SHA-512), tough. Open an
SMTP connection to the hand.
In general, I support expressiveness in SSP language. I also think
that SSP is a *hint*, not a mandate (and that that is a real-world
fact, not a protocol issue). If we remember that SSP provides
guidance to the receiver for the case of broken signatures and
nothing more, we can keep from getting around a large number of axles.
Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.5.3
Charset: US-ASCII
wj8DBQFF43vJsTedWZOD3gYRAlC4AKCWMFVmNXC5qCWhqtlJK5hRMp0KQwCbBQ8t
iCuz8ZjBWY08eAUW58O5gbI=
=c7a6
-----END PGP SIGNATURE-----
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html