Subject: what DKIM is --- a personal perspective - msg#00370

Previous Message by Date: click to view message preview

Re: DKIM SSP: Security vulnerability when SSP record does not exist?

On August 19, 2005 at 01:03, Douglas Otis wrote: > > Is your view in a nutshell (of what DKIM should be): When a domain > > signs a message, it is saying, "Here is what I got and transmitted." > > DKIM only provides a verifiable trace of a message. > > The signature indicates a specific message has been transmitted by a > specific administrative domain, to be held accountable for the access > thereby granted. Additional properties must be premised upon the > governance demonstrated by the accountable domain. Okay, but I am having some trouble in how accountable a domain will be. Mail transmission is not necessarily point-to-point, with a message potentially going through multiple domains before reaching its final destination. When a domain signs a message, what level of accountability is the domain stating? Can there be different levels depending on the role the domain plays in the transmission of the message? > > And/or, DKIM should provide verifiability of a message's originating > > domain: the initial domain that receives a sender's message for > > transmission. > > I do not understand what significance you're placing upon "originating > domain." Is this implying a relationship with a mailbox address? Yes. The "originating domain" is the first domain to handle the message. The sender of the message obtained authorization from the originating domain to transmit the message. Since you mention accountability, I believe there should be a different level of accountability from the originating domain from subsequent domains that may handle a message during transit. > > When the initial domain signs a message, it is saying, "Here is what > > the domain-authorized sender submitted to me for > > transmission." > > Again, I don't understand what is implied by "domain-authorized sender." > Is this suggesting a provider must query the domain in a mailbox-address > for a specific "sender" authorization prior to transmitting the message? I am talking about the relationship between the domain and the mailbox users it services. For a mailbox user to send out a message (through the given domain), the domain must grant permission for the mailbox user to do this. Therefore, the sender is "domain-authorized" to send messages originating from the given domain. --ewh _______________________________________________ ietf-dkim mailing list http://dkim.org

Next Message by Date: click to view message preview

Re: DKIM Threat Analysis v0.06

Arvel Hathcock wrote: Here's what I think. 1. Who are the bad actors that DKIM is trying to thwart? Put another way, if DKIM is deployed, what bad actors will have to find a different way to perform their bad acts. The bad actors are anyone who would use a domain name in an identity header of an email message without authorization from the domain owner. The same will have to discover a new means of doing so. There are different classes of bad actors: some only want to cover their tracks and will send mail using arbitrary addresses, others want to use specific domains (either spoofing established domains or using lookalikes), and yet others will want to exploit existing social relationships (gleaned from address books) in order to try to get through whitelists. Also, what resources do these bad actors have at their disposal? I assume "resources" refers to the set of conditions the bad actor finds which enables him to achieve his goal. These are primarily (a) the wide-open unauthenticated nature of SMTP which lets anybody claim they are anybody else (b) the wide-open unauthenticated nature of RFC-2822 which has no inherent mechanism for restricting the use of identity headers to the domain owner (c) the relative lack of use (for whatever reason) of stronger security measures such as S/MIME and PGP and (d) the ubiquitous habit of and conditioning imposed through the display of the RFC-2822.From identity header to email consumers in preference to any other identity. I think by "resources" what he means is what capabilities does the attacker have. Can the attacker mount a man-in-the-middle attack? Can the attacker corrupt the key storage? Can the attacker pretend to be coming from a different IP address (if that's even relevant)? Does the attacker have access to signed messages which might be modified ? Can the attacker cause some arbitrary message to be signed which they might be able to exploit? There is probably not a single answer to many of these questions, because there is more than one class of attacker here. So we need to describe which of these we intend to address and which we don't. An attacker that can trick a registrar into changing the DNS entries for a domain to their rogue DNS servers is one we don't intend to address, for example. 2. Where are these bad actors in the protocol environment? Where in the email system do they pop up to perform the acts that DKIM is trying to prevent. Again, different bad actors may appear at different places. Some of the "places" that he refers to might be whether the bad actors are within the originating domain, the recipient's domain, whether they might pose as (or attack) mailing lists, or whether they're out in interdomain space. 3. What are the bad acts that DKIM is trying to thwart? The first two questions are really background for this question. These are so related it's hard for me to separate. Unauthorized domain use is a means to several ends. The 'end' will determine where, in the email delivery chain, the bad actor "pops up". When the goal is to trash the reputation of a domain owner in the eyes of an email user or ply some scam part of which requires the unauthorized use of a domain to lend it credibility, the "pop up" is the MUA of an email user and the effect takes place in the mind of that user. When the goal is to thwart filtering agents or attempt to manipulate a receiving domain's incoming email policy in some way the "pop up" is at the point wherein those processes are invoked and the effect is in reducing or rendering useless the effectiveness of those processes. Sure; we need to distill down the list of bad acts as much as possible in order to make the discussion as clear and unambiguous as possible. The trashing of domain reputations and such is a second-order effect. -Jim _______________________________________________ ietf-dkim mailing list http://dkim.org

Previous Message by Thread: click to view message preview

Focus on: Threat Analysis and Chartering

Folks, The note that I posted to a number of threads on this list attempts to highlight how far afield most of our discussion has gotten. A number of threads were started with the purpose of resolving issues that very much have to do with producing a threat analysis and/or getting the group chartered. Then they have wandered off into the bushes of engineering protocol details or debating larger email philosophy. We need to get considerably more focus on the only requirement currently facing us: getting chartered. To get chartered, our immediate requirement is a threat analysis. The threat analysis has been characterized by our cognizant AD as attending to the threats that DKIM is intended to respond to. The threat analysis, therefore, is another perspective on intended working group scope, DKIM value proposition, and similar organizing frameworks for the standardization effort. Can we please apply the obvious enthusiasm present on the list to solving our immediate requirement? d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ ietf-dkim mailing list http://dkim.org

Next Message by Thread: click to view message preview

Re: what DKIM is --- a personal perspective

On August 19, 2005 at 13:18, Eric Allman wrote: > First, by itself, DKIM is not an anti-phishing tool and is definitely > not an anti-spam tool. Then the DKIM specification should be careful when refering to such things. Since the current draft states that DKIM could assist in dealing with phishing and spam, it either needs to remove the statement(s) or mention how it can actually assist. Since it appears people will infer that DKIM is designed to deal with forgery (e.g. phishing), the specification must be clear about the problem it is attempting to solve and its scope. > It is not intended for direct end-user use. > It is not intended to stand by itself. It is designed to > authenticate at the domain administration level rather than the user > level, although there are some hooks designed to prevent misuse of > the user (local) part for a limited number of common situations. Authentication has many levels and cannot be independent of the roles various entities play. This is why is my other posts I have tried to define the role domains will play in message tranmission, separating the orginating domain from subsequent domains. > DKIM is designed to be used between the boundary of the sender > and the boundary of the receiver with possible intermediate MTAs (and > yes, I do realize that S/MIME and PGP can be used in this mode, and > that DKIM can be used end-to-end, but that's not the primary design > goals of any of these examples). Unfortunately, the DKIM draft is not specific about this. The DKIM draft mentions MUAs, and directly implies that MUAs can play an active role in signing and verifying. I am not sure if restricting DKIM to border MTAs (and systems in between) is the way to go, but the DKIM specification should explicitly state where DKIM applies and where it does not. > DKIM is a protocol enabling some entity to assert accountability for > the message. "Accountability" doesn't necessarily have to be > attached to authorship of the message, the content of the message, or > any header fields of the message, because the primary point is simply > to create an authenticated identity of an accountable entity to which > a reputation can be attached. I think here is where you get into some trouble. Accountability has been mentioned numerous times, but it has not been defined very well. There are different levels of accountability, and the level of accountability is tied into the role a domain plays in the transmission of a message. In order for a reputation system to be built on top of DKIM, it appears there is very useful value in knowing the role the signer plays in the transmission of a message. For example, the originating domain should have the greatest amount of accountability while intermediate domains (forwarders, secondary exchangers, mail lists) level of accountability is less, and may only serve for traceability versus accountability. It is counter-productive to hold a forwarding service to the same level of accountability as the originating domain. This can be cost prohibitive for a forwarding service, discouraging a forwarding service from ever signing messages (assuming that such signing is something DKIM should support). > The entity is a domain, not an > individual address. Reputation is a critical part of an overall > anti-spam, anti-phishing system but is intentionally outside the > purview of the DKIM base specification because how you do reputation > is fundamentally orthogonal to how you do authentication. A reliable reputation service depends on accurate authentication and the form of authentication being provided. > DKIM is a > pragmatic approach intended to be a "good enough" contribution to > solving a critical problem that is plaguing email today. And what exactly is the "critical problem"? This ties into the threat analysis work. It appears the underlying problem is reliable authentication of email. Without reliable authentication, it is hard to create reliable reputation, accreditation, and other trust-type systems. For example, without reliable authentication, and entity can be assigned a negative reputation due to mis-identification. Without reliable authentication, a malicious party can try to take advantage of someone elses positive reputation (and/or accreditation) by exploiting inefficiencies in the authentication system being utilized. Due to scalability (and some other) factors, DKIM attempts to address this problem at the domain level, leaving authentication at the mailbox level to be a domain-specific problem or covered by other protocols (e.g. S/MIME). > Conceptually, once you have established an identity of an accountable > entity associated with a message you can start to apply a new class > of identity-based algorithms, notably reputation. Again, accountability is not absolute. With what is being said about accountability on this (and previously ietf-mailsig) list, it appears that only the originating domain should sign messages. Entities that blindly sign all messages could be causing themselves unneeded headaches for asserting accountability they do not want to take. > If a signing entity has no > reputation (i.e., is new) then it will be treated with suspicion, > since that's highly likely to be a new spammer domain. This is a dangerous assumption since any new legitimate business or organization is assumed to be suspicious just because they are new. Since there can be problems with reputation systems, along with a multitude of ways that reputation can be established, it is probably better to not go into details about reputation systems when discussing DKIM (which you mention in your post). I think it is sufficient to state that DKIM can help facilitate reputation and accreditation since it provides a reliable authentication system. > None of these > require direct association between the identity of the signing entity > and any header or envelope information. I think the role of signers are important. IMHO, assigning the same level of accountability on any signer ignores how email systems operate. IMHO, even mentioning accountability wrt DKIM could kill it. Why? Because you then have to discuss the level of accountability the signer takes, and if it is a fixed level of accountability, this can discourage many to adopt it. How accountability is enforced is not a trivial manner and should not be part of DKIM. It is clear that something like DKIM can help facilitate accountability via reputation, accreditation, and/or whatever. All this can be done since DKIM will hopefully provide an acceptable, good-enough authentication framework for email. > It would be inappropriate to force the DKIM specification to also > include how reputation, scanning, challenges, or quarantining would > be performed because they are fundamentally different tasks. Agreed. Accountability should be in this list also. It would be impractical to try to define accountability in the DKIM specification since accountability implies reprecussions and all the actions who have mentioned. Everything you have said can be achieved if DKIM not only provides a cryptographic signing mechanism for email, but allows the role of the signer to be clearly defined. If DKIM is to be restricted in only supporting the role of originating domain, then discussion about signing by intermediary entities should be dropped and explicitly excluded as outside of DKIM's scope. --ewh _______________________________________________ ietf-dkim mailing list http://dkim.org