Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

On Jun 11, 2009, at 7:05 AM, Dave CROCKER wrote: > If out-of-band algorithm/key-type registration like this is not a > regular "protection" mechanism provided in existing, related crypto- > based schemes: > > 1) Why should it be only in DKIM? DKIM offers a domain's credentials to messages

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

Dave CROCKER wrote: > > > Stephen Farrell wrote: >> The putative attack would be to sign with foo-sha256 where foo is some >> algorithm that a verifier supports and such that the foo key encoding >> could >> accept an rsa p= value as input and such that that combination allows the >> attacker t

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

Stephen Farrell wrote: > The putative attack would be to sign with foo-sha256 where foo is some > algorithm that a verifier supports and such that the foo key encoding could > accept an rsa p= value as input and such that that combination allows the > attacker to forge signatures. > > That's fai

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

Murray S. Kucherawy wrote: >> Here's what I remember from the original discussion of h= and k= in >> the key record. >> >> First, part of the idea was to have them both there, to make things >> parallel: "This key is used for this crypto suite." >> [...] > > I'm neutral on either keeping or remo

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

Dave CROCKER wrote: > > Barry Leiba wrote: >> 1. Crypto suite X had been seriously cracked, such that an attacker >> could, at least in some cases, create a valid suite-X signature on his > > Is there any experiential basis to motivate our having to worry about this > attack vector? In other

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

Barry Leiba wrote: > 1. Crypto suite X had been seriously cracked, such that an attacker > could, at least in some cases, create a valid suite-X signature on his Is there any experiential basis to motivate our having to worry about this attack vector? In other words, do we have good reason to

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

> Here's what I remember from the original discussion of h= and k= in > the key record. > > First, part of the idea was to have them both there, to make things > parallel: "This key is used for this crypto suite." > [...] I'm neutral on either keeping or removing this one. It seems to me an RSA

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

On Tue, 9 Jun 2009 22:03:10 -0400 Barry Leiba wrote: >Does anyone else remember anything vaguely similar to what I've said? > Yes. That matches my recolloection. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-li

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

Barry, I don't recall the reason for them in the base spec, but as I recall there were exchanges to explore the compatibility idea via policy. The I-D policy proposal (DSAP)l I wrote was based on these discussions: http://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-15 The main

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

> Help me understand. Describe the use case where someone will use it. Here's what I remember from the original discussion of h= and k= in the key record. First, part of the idea was to have them both there, to make things parallel: "This key is used for this crypto suite." Now, as I remember --

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

> Another way to look at it is that k= is useless, but it's not harmful, > so it'd be more productive to argue about the warts that are both > useless and harmful. I don't know that it's completely useless, but I'll defer to Jon on this point: Is the actual cost of parsing "k=rsa" from the key an

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

John Levine wrote: > Another way to look at it is that k= is useless, but it's not harmful, > so it'd be more productive to argue about the warts that are both > useless and harmful. To be a bit pedantic: While components of the specification that are openly acknowledged to be actively proble

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

>* A lot of what we call trust is the users believing in the software. >Despite the fact that it is indeed essentially impossible for there to >be a cryptographic error, crypto is hard to understand. Look at how >ill-understood the SHA1 issues are. This is an easy way to give >explainable,

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 4, 2009, at 5:00 PM, Douglas Otis wrote: >> > > First assume there is a _real_ transition to different DKIM > algorithms sporadically occurring. Perhaps based upon being > targeted by bot-net resources. > > An attacker spoofs a K_2 signatu

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

On Jun 4, 2009, at 3:46 PM, Jon Callas wrote: > > On Jun 4, 2009, at 2:18 PM, Douglas Otis wrote: > >> >> On Jun 4, 2009, at 11:34 AM, Jon Callas wrote: >>> >>> On Jun 3, 2009, at 10:53 PM, Eliot Lear wrote: >>> The basic question is simply this: is it sufficient to list the key algor

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 4, 2009, at 2:18 PM, Douglas Otis wrote: > > On Jun 4, 2009, at 11:34 AM, Jon Callas wrote: >> >> On Jun 3, 2009, at 10:53 PM, Eliot Lear wrote: >> >>> The basic question is simply this: is it sufficient to list the >>> key algorithm in the

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

Wietse Venema wrote: > Siegel, Ellen: Eliot Lear wrote: > The basic question is simply this: is it sufficient to list the key > algorithm in the header? I don't see a plausible attack, so I'm okay +1 >>> +1 >>> > with that. But let's at least have the debate based on facts.

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

On Jun 4, 2009, at 11:34 AM, Jon Callas wrote: > > On Jun 3, 2009, at 10:53 PM, Eliot Lear wrote: > >> The basic question is simply this: is it sufficient to list the key >> algorithm in the header? I don't see a plausible attack, so I'm >> okay with that. But let's at least have the debate

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 3, 2009, at 10:53 PM, Eliot Lear wrote: > The basic question is simply this: is it sufficient to list the key > algorithm in the header? I don't see a plausible attack, so I'm okay > with that. But let's at least have the debate based on fac

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

Siegel, Ellen: > > > > Eliot Lear wrote: > > > > The basic question is simply this: is it sufficient to list the key > > > > algorithm in the header? I don't see a plausible attack, so I'm okay > > > > > > +1 > > > > +1 > > > > > > with that. But let's at least have the debate based on facts.

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

> > Eliot Lear wrote: > > > The basic question is simply this: is it sufficient to list the key > > > algorithm in the header? I don't see a plausible attack, so I'm okay > > > > +1 > > +1 > > > > with that. But let's at least have the debate based on facts. > > > > yup. > > +1 > +1 Ellen

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Dave CROCKER > Sent: Wednesday, June 03, 2009 11:13 PM > To: ietf-dkim@mipassoc.org >> DKIM IETF WG > Subject: Re: [ietf-dkim] RFC4871bis - whethe

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

Eliot Lear wrote: > It's not a list. Dave got it wrong. Please look at RFC 4871: I did, indeed. > The basic question is simply this: is it sufficient to list the key > algorithm in the header? I don't see a plausible attack, so I'm okay +1 > with that. But let's at least have the deba

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

On 6/3/09 12:16 AM, J.D. Falk wrote: > Jon Callas wrote: > > >> Okay. I misunderstood. If it's a DNS-level list of all possible >> algorithms, it has very limited use, and can go. >> > +1 > > It's not a list. Dave got it wrong. Please look at RFC 4871: k= Key type (plain-text

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

I also expected to offer added value to our customers who are more exclusive in their communications. A vendor when signing up a new user or customer, if have a DKIM mandate in their Vendor/User communications and may want to quickly verify what level of DKIM support the user's email domain

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

On Jun 2, 2009, at 3:36 PM, Murray S. Kucherawy wrote: >> Without this feature, people may soon find their inbox flooded by >> bogus messages indicating the use of new algorithm, that could have >> been mitigated extensively by having the key feature. > > As opposed to what? What would you e

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 2, 2009, at 3:17 PM, Douglas Otis wrote: > > On Jun 2, 2009, at 2:38 PM, Jon Callas wrote: >> >> The only use I can see of it is the case where you have many live >> messages out there, some of them with (e.g.) RSA and others with >> (e.g.

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

Jon Callas wrote: > Okay. I misunderstood. If it's a DNS-level list of all possible > algorithms, it has very limited use, and can go. +1 -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mi

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

> Without this feature, people may soon find their inbox flooded by > bogus messages indicating the use of new algorithm, that could have > been mitigated extensively by having the key feature. As opposed to what? What would you expect a verifier or assessor to do if the hash used to sign was no

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

On Jun 2, 2009, at 2:38 PM, Jon Callas wrote: > > The only use I can see of it is the case where you have many live > messages out there, some of them with (e.g.) RSA and others with > (e.g.) ECDSA and you want to make all RSA messages start failing > now, and yet for some reason want to kee

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 2, 2009, at 4:17 AM, Dave CROCKER wrote: > > > Eliot Lear wrote: >> ... you do not see a benefit in stating the algorithm in the key >> record when it has already been stated in the header, that perhaps >> there >> is some nebulous potenti

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

On Jun 2, 2009, at 11:29 AM, Dave Crocker wrote: > There are much easier ways to do a dos attack. IIRC, this feature was intended to reduce the number of unsupported algorithms that might be otherwise accepted because the algorithm was not yet adopted by the receiver. Unless the key indicat

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

On 6/2/09 7:41 PM, Murray Kucherawy wrote: > So if a=rsa-sha256, then the key I get from issuing a query based on s= and > d= will be an RSA key, or it will fail to verify. What k= offers is somewhat > redundant except for the fact that I can avoid the crypto overhead if I can > detect early on

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

; DKIM WG >> Subject: Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type >> >> Eliot Lear wrote: >>>... you do not see a benefit in stating the algorithm in the key >>> record when it has already been stated in the header, that perhaps there >>&g

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

There are much easier ways to do a dos attack. /d -- Dave Crocker bbiw.net > --- Original Message --- > From: Eliot Lear > To: Murray Kucherawy > Sent: 02-Jun-09, 10:59:30 AM > Subject: Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type > > On 6

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Dave CROCKER > Sent: Tuesday, June 02, 2009 4:18 AM > To: Eliot Lear > Cc: Russ Housley; dcroc...@bbiw.net; DKIM WG > Subject: Re: [ietf-dkim] RFC4871

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

On Jun 2, 2009, at 4:17 AM, Dave CROCKER wrote: > Eliot Lear wrote: >> ... you do not see a benefit in stating the algorithm in the key >> record when it has already been stated in the header, that perhaps >> there is some nebulous potential downgrade attack. Is that right? > > Yes. > > And

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

Eliot Lear wrote: >... you do not see a benefit in stating the algorithm in the key > record when it has already been stated in the header, that perhaps there > is some nebulous potential downgrade attack. Is that right? Yes. And it's not "the" algorithm in the DNS record; it's a list of

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

On 6/1/09 9:43 PM, Dave CROCKER wrote: > > Let's make sure everyone is in synch about what is being proposed: > > The suggestion is to drop a tag from the *DNS record*, /not/ > from the *DKIM-Signature* header field. > > What is the benefit of having the DNS record list possible algorithm

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 30, 2009, at 10:15 AM, Dave CROCKER wrote: >> k: Key type >> >> Much the same as h=, with the added issue that there's only one >> possible key type right now, and if there were a need for k= in the >> future it could be added in the same R

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

Dave CROCKER: > Let's make sure everyone is in synch about what is being proposed: > > The suggestion is to drop a tag from the *DNS record*, /not/ > from the *DKIM-Signature* header field. > > What is the benefit of having the DNS record list possible > algorithms? > > A protocol li

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

Eliot Lear wrote: > On 6/1/09 6:38 PM, Steve Atkins wrote: >> I would assume that if it were added back it would look exactly like it >> does now, but with some additional options other than "rsa". >> >> Adding k= back or extending it to support other options would >> both require RFC level effor

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

On 6/1/09 6:38 PM, Steve Atkins wrote: > I would assume that if it were added back it would look exactly like it > does now, but with some additional options other than "rsa". > > Adding k= back or extending it to support other options would > both require RFC level effort, so I'd expect anyone doi

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

Siegel, Ellen wrote: >>>TXT RR tags >>> >>> k: Key type >>> >>> Much the same as h=, with the added issue that there's only one >>> possible key type right now, and if there were a need for k= in the >>> future it could be added in the same RFC that adds support for >>> anything oth

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

On Jun 1, 2009, at 8:41 AM, Siegel, Ellen wrote: >> >>> TXT RR tags >> >>> k: Key type >>> >>> Much the same as h=, with the added issue that there's only one >>> possible key type right now, and if there were a need for k= in the >>> future it could be added in the same RFC that adds suppo

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

> > >TXT RR tags > > > k: Key type > > > > Much the same as h=, with the added issue that there's only one > > possible key type right now, and if there were a need for k= in the > > future it could be added in the same RFC that adds support for > > anything other than RSA. > Dropping t

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

To save bandwidth - I'm +1 on steve's list - in particular the ones you posted surveys for, so far. On Sat, May 30, 2009 at 10:45 PM, Dave CROCKER wrote: >>    TXT RR tags > >>      k: Key type >> >> Much the same as h=, with the added issue that there's only one >> possible key type right now, a

[ietf-dkim] RFC4871bis - whether to drop -- k: Key type

Folks, In: Steve Atkins posted a list of suggested DKIM features to drop. This note is intended to anchor a discussion thread for discusses one of those features, namely: >TXT RR tags > k: Key type > > Much the same a