Subject: Re: auth header in Montreal agenda, other than base - msg#00187

Previous Message by Date: click to view message preview

Re: Montreal agenda, other than base

Stephen Farrell wrote: > > Our main Montreal agenda is for a) finishing base and b) kicking > off SSP-related discussions. (a) seems nicely in-hand. I suggest that we explicitly solicit some discussion in the meeting with both Security and DNS experts. We have made some assumptions about what is likely to be acceptable to each of those communities, yet I suspect we do not have much feedback yet about their limits. (I suspect we are in quite good shape, with respect to the Security folks, but I find myself worried about the DNS constituency.) So, for example, the DNS purists could well take exception to the choice we have made for an initial TXT record, with a new RR outside the critical path of -base. Montreal could give us some valuable insight into the likely problems we will or will not have in getting -base approved. Alternatively, we could go through working group last call, IETF last call, and IESG push-back. For any interesting push-back, we are probably looking at delays in the range of 6 months. (That estimate is, of course, not merely theoretical.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net

Next Message by Date: click to view message preview

Re: Montreal agenda, other than base

On Jun 16, 2006, at 2:39 PM, Dave Crocker wrote: So, for example, the DNS purists could well take exception to the choice we have made for an initial TXT record, with a new RR outside the critical path of -base. It would be good to have a binary DNS RR defined within the base draft. Depending upon how this record is used and what it contains, base64 encoding might exceed the 512 byte message limit, as previously explained in detail. The savings from a binary encoded key should be compared against the space normally remaining. This remaining space is affected by the domain name of the signing domain, the size of the 'g=' parameter, and whether other parameters become commonly included. Such an effort could also benefit from expert DNS review and advise. -Doug

Previous Message by Thread: click to view message preview

Re: auth header in Montreal agenda, other than base

John R Levine wrote: >> Well, it's not in our charter, but assuming that the -base discussion >> doesn't take up the entire agenda it seems worthwhile socializing it >> in a pre-re-charter kind of way. I'll note that Auth-res is pretty >> intertwinned with SSP as well. > > I hope we can get it un-twined. The most likely use of the auth > header is so that an MTA can pass along the DKIM info to a MUA that is > one or two hops downstream for sorting. That shouldn't need to have > anything to do with SSP. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net

Next Message by Thread: click to view message preview

base-02 // worst-case scenario/duration of exploit/use of deprecated

Definitions: Deprecated - Will be made invalid or obsolete in the future. Obsolete - Is currently invalid. ----- Although a worst-case scenario is highly unlikely, the objective is to review an exigent transitional change in either a DKIM signature service or algorithm. A highly targeted attack using substantial resources is a moderately plausible threat to the protections offered by DKIM, where such an attack may permit only an intermittent exploit. Much like a balking car, a repair is likely to be sought in conjunction with continued use. (A worst case situation from a protocol standpoint.) An intermittent exploit may cause the available DKIM services or algorithms to be considered deprecated by an affected target with respect to their outbound messages. After upgrading to support a better alternative, the affected domains still needs to offer the deprecated signature by adding two signatures. Two signatures are required when a significant number of verifiers have yet to upgrade. Abruptly dropping a supported signature in favor of a better but poorly supported alternative will cause recipients to see their messages as unsigned. This strategy will cause most of their recipients to once again experience a flood of fraud by more bad actors. These bad actors now only needed to include a spoofed signature, and may have otherwise lacked the resources to achieve the intermittent exploit. With this outcome, an abrupt transition from a faltering signature version is an irresponsible strategy. Instead, providing two signatures is the responsible action during an exigent transitional two signature phase seeking to thwart the intermittent exploit. As the targeted entity would be the first to upgrade, knowledge of what represents a deprecated signature is initially understood by only those few domains. Even after a verifier has upgraded, during the two signature transitional phase, the verifier is still unable to discern which MTA has upgraded. Without the signing domain able to communicate what they consider to be deprecated within prior signature constructs, intermittent exploits will continue. This exploit remains viable during the transition even when both the signing and verifying domain have upgraded. A diminished benefit for early upgrading may also slow adoption of the improvement. There must be a parameter within the existing signature header and key that conveys which signing domain has upgraded. Logically, as any element of the DKIM signature might be affected, the signature version should offer a value that declares that the signing domain now considers this version of the DKIM signature to be deprecated. In essence, this signature is offered only for compatibility during a two signature transitional phase. The current base draft expects verifiers, irrespective as to whether the signing domain upgraded, to abruptly ignore a deprecated (rather than obsolete) signature. This behavior is highly disruptive when only a small number of domains have adopted the alternative. The verifier ignoring deprecated signatures early within a transitional phase exposes most of their recipients to a flood of fraud instead of a few intermittent instances. This outcome, caused by a not having a ready means to communicate the version level of the signing domain, implies an intermittent exploit will likely continue over the entire transitional phase, perhaps measured in years. In contrast, with a means for the signing domain to communicate the status of a signature's version, adoption by the affected domains and by a number of major ESPs can then restore protection for most most recipients within weeks without the need for any out-of-band communication. This rapid recovery of DKIM protections should help promote the upgrade. --------------------- ,---- | 4. Semantics of Multiple Signatures | ... | When evaluating a message with multiple signatures, | a receiver should evaluate signatures independently | and on their own merits. For example, a receiver | that by policy chooses not to accept signatures | with deprecated crypto algorithms should consider | such signatures invalid. As with messages with a | single signature, receievers are at liberty to use | the presence of valid signatures as an input to | local policy; likewise, the interpretation of | multiple valid signatures in combination is a local | policy decision of the receiver. '____ Change to: : When evaluating a message with multiple signatures, : a receiver should evaluate signatures by different : signing domains independently. A receiver, : that by policy considers a crypto algorithm or : service to be obsolete, should ignore the signature : and consider it invalid. Multiple signatures by the : same domain must include at least one signature : version that has not been marked as deprecated. : When an alternative version of a signature is : from the same domain is supported, this signature : should be used in preference to a signature marked : as deprecated. As with messages with a single : signature, receivers are at liberty to use the : presence of valid signatures as an input to local : policy; likewise, the interpretation of multiple : valid signatures in combination is a local policy : decision of the receiver. ,--- |3.5 The DKIM-Signature header field | ... | v= | Version (MUST be included). This tag defines | the version of this specification that applies | to the signature record. It MUST have the | value 0.2. | | ABNF: | | sig-v-tag = %x76 [FWS] "=" [FWS] "0.2" '___ : v= : Version (MUST be included). This tag defines : the version of this specification that applies : to the signature record. It MUST have the : numeric value 0.2. The signing domain may : mark the signature as deprecated by appending : a "d" character to the version value. : : ABNF: : : dkim-sv = "0.2" : sig-v-tag = %x76 [FWS] "=" [FWS] dkim-v ["d"] : ,--- | 3.6.1 Textual Representation |... | v= | Version of the DKIM key record (plain-text; | RECOMMENDED, default is "DKIM1"). If specified, | this tag MUST be set to "DKIM1" (without the quotes). | This tag MUST be the first tag in the response. | Responses beginning with a "v=" tag with any other | value MUST be discarded. | | ABNF: | | key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1" '___ : v= : Version of the DKIM key record (plain-text; : RECOMMENDED, default is "DKIM1"). If specified, : this tag MUST be set to "DKIM1" (without the quotes). : This tag MUST be the first tag in the response. : Responses beginning with a "v=" tag with any other : numeric value MUST be discarded. The signing domain : may mark the key as deprecated by appending : a "d" character to the version value. When the : DKIM-Signature version is marked as deprecated, : the DKIM-Key version MUST BE included and marked as : deprecated. : : ABNF: : : dkim-kv = "1" : key-v-tag = %x76 [FWS] "=" [FWS] "DKIM" dkim-kv ["d"] : : INFORMATIVE IMPLEMENTATION NOTE: The DKIM Signature and : Key versions will both have the numeric value "1" in the : final draft. -Doug