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

[Damon]

> 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."
>
>        Jon
>

Jon,

 Horse of a different color that has already been hammered down another hole.
 A message with a broken sig - while less tasty - is still valid message.

In general, verifiers SHOULD NOT reject messages solely on the basis
   of a lack of signature or an unverifiable signature; such rejection
   would cause severe interoperability problems.  However, if the
   verifier does opt to reject such messages (for example, when
   communicating with a peer who, by prior agreement, agrees to only
   send signed messages), and the verifier runs synchronously with the
   SMTP session and a signature is missing or does not verify, the MTA
   SHOULD use a 550/5.7.x reply code.

   If it is not possible to fetch the public key, perhaps because the
   key server is not available, a temporary failure message MAY be
   generated using a 451/4.7.5 reply code, such as:

      451 4.7.5 Unable to verify signature - key server unavailable

   Temporary failures such as inability to access the key server or
   other external service are the only conditions that SHOULD use a 4xx
   SMTP reply code.  In particular, cryptographic signature verification
   failures MUST NOT return 4xx SMTP replies.

   Once the signature has been verified, that information MUST be
   conveyed to higher-level systems (such as explicit allow/whitelists
   and reputation systems) and/or to the end user.  If the message is
   signed on behalf of any address other than that in the From: header
   field, the mail system SHOULD take pains to ensure that the actual
   signing identity is clear to the reader.

   The verifier MAY treat unsigned header fields with extreme
   skepticism, including marking them as untrusted or even deleting them
   before display to the end user.




-Also-

8.7.  Intentionally Malformed Key Records

   It is possible for an attacker to publish key records in DNS that are
   intentionally malformed, with the intent of causing a denial-of-
   service attack on a non-robust verifier implementation.  The attacker
   could then cause a verifier to read the malformed key record by
   sending a message to one of its users referencing the malformed
   record in a (not necessarily valid) signature.  Verifiers MUST
   thoroughly verify all key records retrieved from the DNS and be
   robust against intentionally as well as unintentionally malformed key
   records.

8.8.  Intentionally Malformed DKIM-Signature Header Fields

   Verifiers MUST be prepared to receive messages with malformed DKIM-
   Signature header fields, and thoroughly verify the header field
   before depending on any of its contents.