ietf-dkim
[Top] [All Lists]

Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues

2007-06-06 15:07:31

On Jun 6, 2007, at 2:41 PM, Jon Callas wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have a huge fear that I am beating a dead horse down a rathole. I
also fear that I no longer understand what's being discussed.
However, I want to make a cryptographic observation.

If you create a suitably-sized RSA key, throw away the private key,
and put the public key in a DKIM selector, you have made a selector
that can't have mail signed from it (or if you want to be really
anal, forging a signature for that selector is equivalent to breaking
that key).

If you then say, "I sign all mail" for any domain pointing to that
selector, you've effectively made a cryptographically enforced no-
mail, no-use, etc. domain using the existing Tinkertoys.

In short -- saying "I sign everything" with a non-existent or bogus
key is the same thing as saying, "You'll never see a valid one of
these."

Yup. I think everyone (mostly) understands this. The entertainment
arrives when you want to be able to have a single policy record
refer to a large number of subdomains via wildcard.

The line of reasoning goes something like this:

1. We can already say "NO MAIL" any time we can say
   "NO UNENCRYPTED MAIL".

2. We kinda know how to say "NO UNENCRYPTED MAIL"
  for a single domain.

3. There are a few tricky issues with being able to say
   "NO UNENCRYPTED MAIL" across large numbers
  of domains via wildcard.

4. But the vast majority of cases where we'd want to say
  "NO UNENCRYPTED MAIL" for a wildcard all we really
  want to say is "NO MAIL".

5. So if we can say "NO MAIL" for a wildcard via some other
  protocol we don't need to be able to say "NO
  UNENCRYPTED MAIL" via wildcard, and can avoid the
  tedium referred to in point 3.

I don't believe point 4 is entirely valid, myself, but that's
the line of reasoning, and why people are bringing up
wildcards and "NO MAIL" in the same discussion.

Cheers,
  Steve

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

<Prev in Thread] Current Thread [Next in Thread>