[ietf-dkim] Are verifiers expected to query SSP on a successful verify?

Tue Aug 1 15:54:20 PDT 2006

Doug,

Maybe its just late in the evening here, but a mail that starts with
a list of 16 new, old, borrowed, and blue, acronyms is not IMO a way
to make what you want to say easier to understand.

I'll read it again in the morning though, maybe it'll seem worth it
then;-)
S.

Douglas Otis wrote:
> This explores a range of possible policy and auxiliary records and label 
> scenarios as a general exercise.  Rather than repeating the same phase 
> fairly often, acronyms are still used, but now are defined up front.  
> The expected drawbacks are retained to help with their eventual 
> disposition.
> 
> 
> Definitions of Terms
> --------------------
> 
> Resource Record (RR): The storage element selected by type used by DNS 
> containing structured content.
> 
> Resource Record Set (RRset): One or more Resource Records at a specific 
> domain name.
> 
> Originator Address (OA): An email address found within the 2822.From 
> header field.
> 
> Originator Address Domain (OAD): The domain of an OA.
> 
> Current Address (CA): The latest dominant email-address introduced per 
> RFC2822. (The latest 2822.Resent-Sender, Resent-From, Sender, or From.)
> 
> Current Address Domain (CAD): The domain of an CA.
> 
> Mail From Domain (MFD): This represents the domain within the 
> 2821.Mail_From parameter.
> 
> Signing Domain (SD): The domain verified by a valid signature located by 
> DKIM-Signature header field 'd=' parameter.
> 
> Policy Publishing Domain (PPD): The domain from where policy is 
> published, excluding any special prefix for referencing the policy RR.
> 
> Designated Signing Domain (DSD): A domain contained within policy 
> providing authoritative signatures for the PPD.
> 
> Non-Designated Domain (NDD): A domain not contained within policy and 
> not considered authoritative for the PPD.
> 
> Designated Host-Name (DHN):  A host-name designated as being 
> authoritative for the PPD.
> 
> Direct Message (DMSG): A message issued and signed by the OAD.
> 
> Indirect Message (IMSG):  A message issued on behalf of the OA and 
> signed by a NDD.
> 
> Signature/Address Tuple (SAT):  The OA combined with either a valid 
> signature by a DSD or a DMSG.
> 
> --------------------
> 
> =========
> 
> Problem 1:  Spoofs of the OA in phishing attempts.
> 
> Solution A:
> In the case of IMSGs, OAD policy might provide a means to block spoofs 
> of DMSGs.  Acceptance could be denied when OAD policy indicates 
> exclusive use of DSDs, and the SD is not in conformance.
> 
> Drawback of solution A:
> a) A recipient can not differentiate DMSGs from IMSGs.  Exclusive use of 
> DSDs will not conform to common IMSG related services, such as 
> mailing-lists or e-invites.  Policy may be ignored (see Solution B), the 
> message may be annotated to indicate a level of policy assertion 
> conformance, or the message may be refused when not conforming with 
> policy assertions.
> 
> b) The OA may not be visually apparent or may be visually misleading.  
> When just display-names are visible, or look-alike or international 
> domains are used, the recipient may be unable to discern the exact OA 
> being displayed.
> 
> -----
> 
> Solution B:
> Track SATs at the MUA with an address book or correspondence log, and 
> then annotate messages matching an SAT.  This does not require policy be 
> obtained to prevent spoofing and this also resolves look-alike issues.
> 
> Drawback of solution B:
> This introduces a new requirement for MUAs to annotate messages based 
> upon SATs, where this information should also be exchanged between 
> disparate MUAs for the same user.
> 
> =========
> 
> Problem 2: Spoofs of visual content where the OA may also be contrived 
> to be visually misleading in phishing attempts.
> 
> Solution C:
> When a domain can be ascertained from the visual content of a message, 
> this domain can be checked for DSD conformance with OAD policy at this 
> domain.  Acceptance could be denied when OAD policy indicates exclusive 
> use of DSDs, and the SD is not in conformance with this policy.
> 
> Drawback of solution C:
> There is no reliable proactive means to identify cognitively similar 
> message content when ascertaining the domain.  Being a niche problem, 
> this would not likely have a specific policy expressed, and the lack of 
> conformance with OAD policy may be prone to false positives.
> 
> -----
> 
> See Solution B.
> 
> =========
> 
> Problem 3: SMTP host-name are utilized within administrative domains by 
> compromised systems for sending abusive messages, both signed and unsigned.
> 
> Solution D:
> Authenticate the reverse DNS host-name or EHLO and then reference a 
> host-name policy providing DSDs where the left-most host-name label is 
> not used for the reference.  A valid DKIM signature by a DSD then 
> validates the administrative' control of the message's introduction and 
> demonstrates conformance with the policy.
> 
> Drawback of Solution D:
> There can be an immense number of DSDs associated with an SMTP client 
> host-name.  While there are techniques to efficiently resolve a large 
> name:name relationship using DNS (query of 
> <signing-domain>._policy-label.<publish-domain>), the maintenance of 
> these relationships by an administrative domain may be daunting.
> 
> -----
> 
> Solution E:
> Require that a DKIM sanctioned method be used to authenticate SMTP 
> client host-names.  For example an Address RR must found at 
> _dkim.<host-name> that validates the client. The EHLO could also 
> encompass the _dkim.<hostname> to avoid replicate A records, and to 
> signal use of dkim at the EHLO.
> 
> Drawback of Solution E:
> This would only protect systems that never send email and thus would not 
> have an assigned _dkim specific IP address.  However, a compromised 
> system implementing DKIM signing seems unlikely protected by 
> supplemental policies or records.  This protection would require some 
> means to assert that host-names must provide SDs within the same domain, 
> and hope that the private key was not also obtained.
> 
> =========
> 
> Problem 4: Replayed messages and bogus signatures are difficult to 
> detect and effectively triage.
> 
> Solution F:
> Publish a policy that returns DHNs at SDs.  After verifying the 
> host-name, and finding a DHN association at the SD, invalid signature at 
> a DHN can be considered bogus, and valid signatures at a DHN should not 
> be considered the product of replay.
> 
> Drawback of solution F:
> These relationships of possibly disparate administrative domains may be 
> daunting.  These policies would not offer a basis to refuse a message 
> when a DHN is not established.
> 
> =========
> 
> Problem 5: Spoofing of the CA, when the CA is not also the OA.
> 
> Solution G:
> When the CAD is not within the SD, reference a specific CAD policy for 
> DSDs and check for conformance.
> 
> Drawback of Solution G:
> This may lead to additional loading of the DNS server when some 
> verifiers attempt to validate additional header fields within the 
> message.  As this field is not likely to be the target of a spoof, the 
> added overhead may be considered unwarranted.
> 
> =========
> 
> Problem 6: Spoofing of the MFD.
> 
> See Solution F, except replace SD with MFD.
> 
> -----
> 
> Solution H:
> Attempt to impose the OAD policy upon the MFD, in lieu of a policy 
> specifically for the MFD.  This may short-cut some checks and prevent 
> some possible handling delays.
> 
> Drawback of solution H:
> Can only be used to bypass some checks.  Lack of an DSD association 
> corresponding to the MFD can not be acted upon for refusing messages.
> 
> -----
> 
> -Doug
> 
> _______________________________________________
> NOTE WELL: This list operates according 
> tohttp://mipassoc.org/dkim/ietf-list-rules.html
> 