Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
Branching off from the interminable justifiable changes thread --On onsdag, desember 21, 2005 23:54:56 -0800 Cullen Jennings [EMAIL PROTECTED] wrote: Related to how much the charter pre-supposes the solution, the sentence that Public keys needed to validate the signatures will be stored in the responsible identity's DNS hierarchy. seems like a pretty heavy constraint on the possible solutions and one that some proposals disagreed with. I think this is part of divide and conquer that is generally argued to be an useful strategy in the IETF: once we buckle down and start writing specs, we're documenting one approach, with one set of advantages and disadvantages, and are trying to prove that *this approach* is feasible. We did that to (I believe) OSPF, IPNG after the pick one round, PKIX (vs SPKI), IM when it was split into SIMPLE and the 2 alternatives (with XMPP being a late 4th) and so on. Each of these groups could regard the what are the alternatives question as out of scope. I think that's a good way to get things out the door in a reasonable timeframe; I also think that the IETF at the moment lacks venues for the (probably interminable) discussions about what approaches to a problem exists and whether there are non-chartered alternatives that are worth following up - but I think the approach of chartering a WG to look at one and only one approach is a reasonable one. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
Related to how much the charter pre-supposes the solution, the sentence that Public keys needed to validate the signatures will be stored in the responsible identity's DNS hierarchy. seems like a pretty heavy constraint on the possible solutions and one that some proposals disagreed with. I think this is part of divide and conquer that is generally argued to be an useful strategy in the IETF: once we buckle down and start writing specs, we're documenting one approach, with one set of advantages and disadvantages, and are trying to prove that *this approach* is feasible. Sometimes feed-forward _is_ useful, and I would agree that the use of DNS to store public key information is one of the fundamental assumptions behind DKIM. Change that assumption and you will probably produce a system with very different characteristics than DKIM is currently assumed to have. OTOH, the assumption that _all_ public keys used to validate DKIM signatures will be stored in DNS is a very limiting one, because it appears to lead to either a) a constraint that policy be specified only on a per-domain basis (which is far too coarse for many domains) or b) a situation that large numbers of DNS queries may be required to validate a single signature I'm comfortable with having a domain's root public keys stored in DNS but allowing the corresponding root private keys to sign key certificates for individual public keys that can be included in DKIM-signed messages. The policies for use of those public keys can then be encoded in the certificates, allowing those policies to be specified on a per-user basis. This gets out of the trap of having to specify policy on a per-domain basis, and doesn't require any more DNS queries than current DKIM. IMHO it would make DKIM much more flexible and adaptable to diverse domain situations (and thereby much more acceptable as a standard) than the current proposal. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
Keith, Keith Moore wrote: I'm comfortable with having a domain's root public keys stored in DNS but allowing the corresponding root private keys to sign key certificates for individual public keys that can be included in DKIM-signed messages. The policies for use of those public keys can then be encoded in the certificates, allowing those policies to be specified on a per-user basis. This gets out of the trap of having to specify policy on a per-domain basis, and doesn't require any more DNS queries than current DKIM. IMHO it would make DKIM much more flexible and adaptable to diverse domain situations (and thereby much more acceptable as a standard) than the current proposal. If there were an I-D describing such a protocol, I'd be interested in reading it - is there one? Stephen. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
If there were an I-D describing such a protocol, I'd be interested in reading it - is there one? Not yet. But it hardly seems like the time to write an I-D when there is at present considerable effort being invested to preclude such an I-D being considered by the group. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
Branching off from the interminable justifiable changes thread Dropping DKIM, because those people suffer enough without being subjected to more general discussion about the nature of the universe at IETF :-) I applaud Cullen for his note. I agree with the parts that Harald snipped out, too (I'm just trying to post below the thread branch, so followups stay together). I think that's a good way to get things out the door in a reasonable timeframe; I also think that the IETF at the moment lacks venues for the (probably interminable) discussions about what approaches to a problem exists and whether there are non-chartered alternatives that are worth following up - but I think the approach of chartering a WG to look at one and only one approach is a reasonable one. The analogy I've been using in private e-mail discussion on how new work comes into the IETF is that the IETF is a bakery that's become pretty difficult to enter with only a bag full of raw ingredients, but if people bring in a finished cake with frosting and just ask for a boz to put the cake in, we're not a bakery any more. It really is a problem that (as Harald says) we don't have a good place to discuss alternative solutions, given that we are trying to be an engineering task force that may also standardize protocols, not a protocol standardization task force that occasionally tries to engineer something. People who need to solve a problem have every incentive to deploy what they believe is a solution to their problems as soon as they can specify it. The more specification work that happens on the way to the IETF, the more likely that work is to be deployed while we are discussing charters, the more pushback we see on charter discussion, and the less likely a second-round version of the protocol is to be widely deployed. I'd also like to point to Thomas Narten's draft on how to run a successful BOF (currently http://www.ietf.org/internet-drafts/draft-narten-successful-bof-00.txt). I would like to see some changes considered for the way we bring new work into the IETF, but getting a baseline on how it works today is a critical first step. I have provided a page or two of comments to Thomas, CC: Brian as General AD, and hope that others also look it over and provide feedback (soon) Thanks for reading, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
On Thu, 22 Dec 2005, Keith Moore wrote: Sometimes feed-forward _is_ useful, and I would agree that the use of DNS to store public key information is one of the fundamental assumptions behind DKIM. Change that assumption and you will probably produce a system with very different characteristics than DKIM is currently assumed to have. Not necessarily. One of the proposals that went into DKIM had characteristic of storing public key fingerprints in dns. This seems quite close to DK but has a number of advantages and unlike DKIM or DK does not put serious extra pressure on DNS infrastructure - which while very capable of serving data like ip addresses (i.e. fixed size small data) would not work so well for when data served answer would either come close to or exceed 512bytes UDP limit. But fingerprints (hash of public key) are finite and small pieces of data that are the same size no matter of public key size has to be larger or smaller and with this size being close to that of ipv6 address. Additionally having public key available with a message brings some additional advantages and allows for optimized algorithms during verification. As I noted the group forcefully removed considerations of such alternatives based on the charter and I consider this to be a disadvantage to community. OTOH, the assumption that _all_ public keys used to validate DKIM signatures will be stored in DNS is a very limiting one, because it appears to lead to either a) a constraint that policy be specified only on a per-domain basis (which is far too coarse for many domains) or b) a situation that large numbers of DNS queries may be required to validate a single signature Its rather likely that it would lead to both. I'm comfortable with having a domain's root public keys stored in DNS but allowing the corresponding root private keys to sign key certificates for individual public keys that can be included in DKIM-signed messages. The policies for use of those public keys can then be encoded in the certificates, allowing those policies to be specified on a per-user basis. You can just use X.509 certificates and retrieve them from HTTP with SRV records being used to confirm location of domain's root certificate. That walso one of the other alternatives (and the one I used for my proposal) and yes, it does make it much easier to do per-user policies signatures. This gets out of the trap of having to specify policy on a per-domain basis, and doesn't require any more DNS queries than current DKIM. IMHO it would make DKIM much more flexible and adaptable to diverse domain situations (and thereby much more acceptable as a standard) than the current proposal. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
On Thu, 22 Dec 2005, Barry Leiba wrote: Actually, the DKIM base spec does provide a mechanism for replacing the DNS keystore with something else. Look at 1.4 for a general statement, and the description of the q= tag in 3.5. DKIM's intended to be able to support user-level keys in a future version (there's some discussion of that in appendix A), and its design is set up specifically not to prevent that. The spec basicly says that you must support DNS public key distribution and authorization; that something else may also be added later will not change requirement for pki in dns and will only be usefull for those who can support it as alternative way to retrieve the key (which means the key would still need to be made available through dns for those who do not). It is really no brainer to see that if we have several authorization meachanisms a set of them would have to be done as a required for those creating implementation in order for them to be used and that means working on all that as part of the main work on the system and releasing together with other documents on the signature system. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
Keith Moore wrote: OTOH, the assumption that _all_ public keys used to validate DKIM signatures will be stored in DNS is a very limiting one, because it appears to lead to either a) a constraint that policy be specified only on a per-domain basis (which is far too coarse for many domains) or Actually, the DKIM base spec does provide a mechanism for replacing the DNS keystore with something else. Look at 1.4 for a general statement, and the description of the q= tag in 3.5. DKIM's intended to be able to support user-level keys in a future version (there's some discussion of that in appendix A), and its design is set up specifically not to prevent that. The proposed charter puts the details of other key management systems and user-level keys out of scope so that we can contain the work at this stage, and make quick progress on the first version. It'd be entirely reasonable to recharter and attack these issues immediately after completing the first round of chartered work, if there are enough people who want to work on that. Or we can see how a while of deployment goes, and form another WG in a year or so to do it. I disagree. The first standard version of DKIM needs to be something that is broadly applicable, not something that just handles a few corner cases. The amount of stress associated with getting closure and consensus on a document is sufficiently large (independent of the document scope) that it doesn't seem like a good idea to waste all of that effort producing a first document that is of limited applicability, and that will need to be updated soon - particularly when a lot of the division within the group stems from the current DKIM spec's overconstraining the problem. If your goal is gaining consensus on a useful specification in the shortest amount of time, it makes far more sense to work on the different aspects of the problem in parallel rather than serially. Let one subgroup work on per-domain keying, key management, and policies; another subgroup work on per-user keying, key management, and policies; another subgroup work on message canonicalization; another subgroup work on specifying signature and hash algorithms (and managing the transition from weaker to stronger algorithms as these are discovered); and finally, have a coordination team responsible for making everything fit together and managing the framework (definitions, header field names, parameter names, keywords) that all of these pieces fit into. Give each subgroup a year, with deliverables at 4 month intervals. After a year, expect to do working group last call on all pieces and start polishing the drafts for final publication. If any piece proves to be unworkable, it can be thrown out after a year. But even if that piece needs to be replaced from scratch and this causes a delay that's better than imposing a serial dependency a priori. The unworkable piece could as easily be per-domain keying as per-user keying. I believe this approach will produce a consensus far more quickly than the serial approach, and that the resulting standard will be more broadly applicable and more robust. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
On Dec 22, 2005, at 8:38 AM, Keith Moore wrote: If your goal is gaining consensus on a useful specification in the shortest amount of time, it makes far more sense to work on the different aspects of the problem in parallel rather than serially. My concern regarding the charter is related to inclusion of the SSP draft, which can impose significant disruption. In my view, DKIM should be seen as aspect of the SMTP transport. Having a signature at the transport qualifies sources of email, but should not constrain use email-addresses. Schemes related to the email-address such as S/ MIME or OpenPGP are designed to support email-address limitations. On the other hand, DKIM purports to offer S/MIME or OpenPGP like features for a sub-set of domains willing to disrupt normal email practices. The premise for DKIM protection assurances is based upon visual examination of the email-address. This seriously flawed concept already demands most MUAs change. Even the body-length option pre- supposes there is some type of MUA modification. With DKIM sans SSP, the MUA would be able to recognize prior correspondents without any other exchange of information. In some cases, an MTA could use this recognition to exclude some abusive traffic based upon prior recognitions. The MUA should be able to safely signal source recognition, but signaling adherence to some authorization would only place recipients in peril. SSP, just as with Sender-ID, requires email-address domain owners authorize the source of their email, where signatures are transposed for address lists. To allow existing practices, open-ended authorizations are required. The danger from this approach has been made apparent by those willing to hold any sort of authorization accountable for abuse seen. There can be no promise that authorizations can be open-ended to support existing practices. Reputation schemes bolstered by having authenticated the identifier when finding an authorization record will quickly preclude use of open-ended authorizations. When only a few domains publish the closed-ended authorization records for SSP, looking for policy for the majority of email will then require that label trees be climbed, where none of this effort can be effectively cached. The solution for this rather broken strategy is to create records that indicate open-ended authorizations to mitigate the search. These nonsense open-ended records however expose the email-address domain owner to unfair reputation schemes already in place. Details have been published for compatible extensions to DKIM that improve upon source recognition, abating abusive message replay, locating compromised systems, limiting the number of signatures per message, establishing expectations for specific email-addresses being signed, without requiring any additional lookups in most cases. http://www.sonic.net/~dougotis/id/draft-otis-dkim-options-00.txt The WG should be limited to establishing the base DKIM signature. This signature should be viewed as an aspect of the SMTP transport to differentiate it from S/MIME and OpenPGP. Another WG should make efforts related to the MUA incorporating the protections offered by DKIM in an opportunistic fashion. In essence, everyone becomes their own certificate authority based upon individual email source identifiers offered by DKIM. Recipients would be able to confirm the validity of the correspondent through out-of-band identifications of the source. This could be simply an expected confirmation when initially establishing a relationship. Once the initial identifier has been accepted by the recipient, messages could be safely highlighted as coming from a recognized source. There can never be a safe indication based upon a domain used in the email address as having authorized the message. There must be more consideration given for the use of unicode. One only needs to investigate the number of look-alike characters in Chinese to understand the fallacy of that assurance. Even the individual that does not understand the difference between online.bigbank.com and online-bigbank.com could be protected by a recognition scheme. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
On Thu, Dec 22, 2005 at 06:35:47AM -0800, william(at)elan.net allegedly wrote: Not necessarily. One of the proposals that went into DKIM had characteristic of storing public key fingerprints in dns. This seems quite close to DK but has a number of advantages and unlike DKIM or DK does not put serious extra pressure on DNS infrastructure Unproved speculation. As you know, email, compared to HTTP and P2P (neither of which sought approval from the IETF) constitutes an increasingly tiny part of the Internet load these days. The serious pressure comes from applications that never came near the IETF. like ip addresses (i.e. fixed size small data) would not work so well for when data served answer would either come close to or exceed 512bytes UDP limit. Unproved speculation. As you know, 512 is not a UDP limit it's a DNS implementation limit which was long ago removed by EDNS0 - an IETF standard. The other minor matter is that the Internet is already participating in a billion+ DK signed and verified emails per day - I've been watching, but as yet, no news at 11. At what point do you expect the pressure to be noticed? William. I admire your interest in optimizing DNS load, but, as Knuth might ask, is it premature? If you think not, convince us otherwise. Mark. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
On Fri, 23 Dec 2005, Mark Delany wrote: On Thu, Dec 22, 2005 at 06:35:47AM -0800, william(at)elan.net allegedly wrote: Not necessarily. One of the proposals that went into DKIM had characteristic of storing public key fingerprints in dns. This seems quite close to DK but has a number of advantages and unlike DKIM or DK does not put serious extra pressure on DNS infrastructure Unproved speculation. As you know, email, compared to HTTP and P2P (neither of which sought approval from the IETF) constitutes an increasingly tiny part of the Internet load these days. The serious pressure comes from applications that never came near the IETF. That is not a proper comparison. DNS is a key protocol (not to be confused with protocol for keys :) for almost all other L7 protocols on the net. HTTP was just another protocol and its use would not have had much effect on say telnet or ftp (ok, for ftp it might as it began to be used as replacement, but that is different matter). We have to be a lot more careful what we choose to do with dns and I think it should stay primarily as a protocol for linking domain names. to specific data locations rather then becoming all-purpose database. Another issue is that dns is not just client-server protocol where impact of using it would only be limited to server that chose to deploy dkim records and client that chose to check it. My view is that there is enough uncertainty and that if load on [core] protocol like dns can be minimized and moved into specific L7 protocol like SMTP, that it should be done. And we do have easy enough way to do it with DK-like system by using fingerprints. like ip addresses (i.e. fixed size small data) would not work so well for when data served answer would either come close to or exceed 512bytes UDP limit. Unproved speculation. As you know, 512 is not a UDP limit it's a DNS implementation limit which was long ago removed by EDNS0 - an IETF standard. Nevertheless for immediate future [at least 5 more years, probably 10] 512bytes is basically limit that dns records should fit in. BTW - that case of adding EDNS extension to widely deployed system and how slow long it takes to do is an example why adding additional key authorization methods to DKIM would not be easy and why we should worry about this issue right now. The other minor matter is that the Internet is already participating in a billion+ DK signed and verified emails per day - I've been watching, but as yet, no news at 11. At what point do you expect the pressure to be noticed? The number of emails being signed and checked is actually the main factor - especially for sites that constantly communicate with each other. What would make a difference is large number of small domains that only occasionally send emails but would have a signature on them requiring checking dns and caching the public key (I predict that specialized optimized caching servers would be needed - in fact its somewhat in my area so I may even make good money if we all have this requirement ...) Also small mail servers that have to check all signed emails would see these issues in even greater degree. What would also make a difference is when users at the largest domains begin to demand to be able to use their own unique keys. William. I admire your interest in optimizing DNS load, but, as Knuth might ask, is it premature? If you think not, convince us otherwise. Nothing is premature when it comes to dns. Once you make mistake its difficult to fix (without impacting ongoing deployment) even if other services are known to be impacted. As I said, it comes down to that we do have other choices to putting large records in dns and they are basically close to being equivalent to public keys in dns, so we should choose those. At the very least make them available as core supported authorization methods so in the future if problems are found, there would be a backup plan that does not require upgrade of every site software. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
