Re: [ietf-dkim] l= summary, as I see it
Tony Hansen wrote: But if *anyone* is signing with it, then it cannot be safely removed as part of moving to Draft Standard. Then such a change would require recycling back at Proposed Standard. Tony, This is a much more stringent rule for Draft than I recall hearing before. I've done a quick review of some IETF docs and can't find such a rule. Can you point to anything about criteria for dropping features when going to Draft. (In general, this appears to need MUCH better documentation than now exists, but perhaps I have forgotten some guidance that is already available. While operational use is, of course, an issue, the premise behind dropping a feature is that there is not enough use to warrant retention. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] RFC4871bis - whether to drop -- x: Signature expiration
Folks, In: http://mipassoc.org/pipermail/ietf-dkim/2009q2/011959.html 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: DKIM-Signature Header tags x: Signature expiration Expiration is a fairly common feature in signing specifications. But DK and DKIM are different in that the public key is not distributed to others, it's always under the control of the signer. Does this add anything that removing the DNS TXT record doesn't do? Is it used? Is it necessary? Please discuss arguments for and against dropping this. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] RFC4871bis - whether to drop -- z: Copied header fields
Folks, In: http://mipassoc.org/pipermail/ietf-dkim/2009q2/011959.html 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: DKIM-Signature Header tags z: Copied header fields Has this been useful? Is it likely to remain useful beyond a testing phase? Please discuss arguments for and against dropping this. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms
Folks, In: http://mipassoc.org/pipermail/ietf-dkim/2009q2/011959.html 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 h: Acceptable hash algorithms The spec needs to define the supported set of hash algorithms. There may be some value in a signer being able to state that they're using an algorithm that isn't supported, perhaps. But unless there is a viable attack such that an attacker can craft a message that validates correctly against the domain owner public key using a hash supported by the spec (sha1 or sha256), without access to the domain owners private key, then there's no need for this to be in the TXT record. Please discuss arguments for and against dropping this. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] RFC4871bis - whether to drop -- k: Key type
Folks, In: http://mipassoc.org/pipermail/ietf-dkim/2009q2/011959.html 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 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. Please discuss arguments for and against dropping this. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] RFC4871bis - whether to drop -- t=y: Domain is testing DKIM
Folks, In: http://mipassoc.org/pipermail/ietf-dkim/2009q2/011959.html 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 t=y: Domain is testing DKIM A test flag is a little like the version field, except there's much less history of it's use in Internet standards. It isn't that useful, and may cause problems. It seems a questionable choice to define something into a protocol that's almost immediately useless. Testing takes place only during startup, then everyone has to support it forever, even though it's never used again. In the case of DKIM it's also unclear how this would be useful, as there's no obvious way for a receiver to communicate to a sender the result of a DKIM validation in testing mode other than an arrangement outside of the protocol - in which case the testing flag wouldn't need to be part of the protocol. Is anyone supporting t=y in a DKIM validator? What does it do in terms of delivery and communication with the sender that's different to normal non-test usage? And is it useful? g: Granularity of the key s: Service type t=s: Require that domain in i= and d= are the same All three of these exist to ask the DKIM validator to compensate for the domain owners lack of control over usage inside the domain owners area of control. They don't belong in the basic DKIM signing mechanism. If they're thought to be useful to identify and control different aspects of use, what are they, or what are they thought likely to be? Please discuss arguments for and against dropping this. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] RFC4871bis - whether to drop -- SHA1 support
Folks, In: http://mipassoc.org/pipermail/ietf-dkim/2009q2/011959.html 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: Drop support for SHA1 entirely. It's beginning to look cryptographically very dubious, and is being dropped by pretty much everyone else. Even if the attacks against it don't affect the way it's used in DKIM it seems unwise to suggest it be used at all. At the very least it seems a poor marketing move to include an algorithm that's been dropped by most everyone else as insecure before this spec is finalized. Verifiers MUST support rsa-sha256 and MAY support rsa-sha1. Signers SHOULD sign using rsa-sha256 and SHOULD NOT sign using rsa- sha1. might provide enough wiggle room to allow existing code time to migrate away from SHA1. Please discuss arguments for and against dropping this. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] RFC4871bis - whether to drop -- other features
Folks, In: http://mipassoc.org/pipermail/ietf-dkim/2009q2/011959.html Steve Atkins posted a list of suggested DKIM features to drop. This note is intended to anchor a discussion thread about dropping any other features, which Steve did NOT suggest dropping. This note is for completeness, to make sure that other suggestions are not missed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] I-D Action:draft-ietf-dkim-overview-12.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : DomainKeys Identified Mail (DKIM) Service Overview Author(s) : T. Hansen, et al. Filename: draft-ietf-dkim-overview-12.txt Pages : 25 Date: 2009-05-30 This document provides an overview of the DomainKeys Identified Mail (DKIM) service and describes how it can fit into a messaging service. It also describes how DKIM relates to other IETF message signature technologies. It is intended for those who are adopting, developing, or deploying DKIM. DKIM allows an organization to take responsibility for transmitting a message, in a way that can be verified by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public- key cryptography, with the domain name service as its key server technology [RFC4871]. This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM also enables a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of spam and phishing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-overview-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-dkim-overview-12.txt ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis - whether to drop -- SHA1 support
Drop support for SHA1 entirely. It's beginning to look cryptographically very dubious, and is being dropped by pretty much everyone else. Even if the attacks against it don't affect the way it's used in DKIM it seems unwise to suggest it be used at all. At the very least it seems a poor marketing move to include an algorithm that's been dropped by most everyone else as insecure before this spec is finalized. Verifiers MUST support rsa-sha256 and MAY support rsa-sha1. Signers SHOULD sign using rsa-sha256 and SHOULD NOT sign using rsa- sha1. might provide enough wiggle room to allow existing code time to migrate away from SHA1. Seeing that the message I received this suggestion in, is signed by the mipassoc.org server with an rsa-sha1 key, I find this suggestion curious. Dropping support altogether for SHA1 might indeed alienate many currently installed systems. I'd opt for Verifiers MUST support rsa-sha256 and MUST support rsa-sha1, whilst keeping the SHOULD/SHOULD NOT emphasis as described above, in order to eventually have every signer use rsa-sha256. To optimise is okay, but to start dropping/alienating currently installed base is something I'd consider unwise at this point in time. Kind regards, -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] who's using l=
However, if no one has deployed with l= signatures, then it can be safely removed *because* no one is using it. Looking through my log which now has over 13,000 DKIM signatures from incoming mail, there's about 300 with l= and nearly all of those are from Cisco. Anyone from Cisco know whether you're doing anything with l= as opposed to just putting it in the signature? Related question: whether or not you sign with l=, does anyone have any software that does anything with l= other than use it to decide how much of the body to check? Anyone seen an MUA that uses it to manage message display? A spam filter that uses l= in its secret sauce? Any use of l= at all? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
