Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On Fri 09/Feb/2018 23:31:41 +0100 John R. Levine wrote: > > The DKIM v=2 hack I proposed is a lot like SMTP extensions in that if > your signature doesn't need the new semantics, don't ask for them, so > you should sign with v=1, so the old and new will coexist forever. > Since they can easily be handled by the same signing and verifying > libraries, that's not a problem. Assuming that that hack would have been way more befitting than any other idea discussed on dmarc-ietf ever since, one may wonder how much of its fading away was due to its version bumping instead of, say, introducing a new header field. Ale ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [Editorial Errata Reported] RFC6376 (5260)
On Thu 08/Feb/2018 19:23:09 +0100 Dave Crocker wrote: > On 2/8/2018 10:05 AM, Pete Resnick wrote: >> >> RFC 7405 is also useful along these lines. > > If those modifications are used, sure. If not, not so much. > > >> So, no error in 5322. As for the erratum below, not having ABNF for the >> header field does seem like a miss, though I'm not sure it should be marked >> as more than "Hold for document update". > > Consider: > > 1. RFC 5322 specifies ABNF for field names that is in terms of 'allowed' > characters, but has no text constraining the method of defining the specific > characters for specific header-field names. > > 2. Section 1.2.2 notes that "..." is case insensitive, but that the %... is > inflexible (ie, sensitive.) > > 3. Nothing in the definition of optional-field requires using the "..." > construct to define the header field name. It merely defines what range of > characteris allowed in a field-name. > > fields = *(trace > ... > optional-field) > > optional-field = field-name ":" unstructured CRLF > > field-name = 1*ftext > > ftext = %d33-57 / ; Printable US-ASCII > %d59-126 ; characters not including > ; ":". The above section is referenced by RFC 3868, which in turn is referenced by the IANA registry. So, a case sensitive header field name is technically possible. > 4. If a spec defines a field-name using the %... construct, it has effectively > required case sensitivity in processing the field-name. > > 5. That was most certainly /not/ what was 'intended' for field-name parsing, > going at least back to RFC 733. Violation of 'intent' is the criterion for an > RFC erratum. Isn't that the difference between technical and editorial errors? Since the intent is clear, I reported the error as editorial. The question arose because someone had DKIM-Signature changed to Dkim-Signature by some (presumably DKIM-unaware) tool. The user thought the culprit was my signing filter, and reported a bug. I told him to look somewhere else. I wanted to add that that change can be acceptable if canonicalization is relaxed, but I was unable to point him to a line that explicitly stated or implied case insensitivity. I'd have to explain the intent maieutically, which, in a standard, seems to leave something to be desired... Ale ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Where is the formal definition of DKIM-Signature?
Hi, someone asked me about case sensitiveness of the header field name. I looked for an ABNF in RFC6376, but only found examples and informative notes. Is that an error worth being reported? Ale ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts
On Wed 16/Nov/2016 21:12:45 +0100 Murray S. Kucherawy wrote: On Thu, Nov 17, 2016 at 3:47 AM, Alessandro Vesely <ves...@tana.it> wrote: That way it will stay dormant until someone gets hurt and has to activate it, at which time it may cause more damage than improvement. A loose cannon. The document makes that risk clear, or so I thought. You mean Section 5? Yes. Well, if its title were *Incompatibility with Current Infrastructure*, I would agree there is a statement on the risk of disrupting how DKIM works. Finally, if you stick to one recipient per message, why do you rack your brains about encryption? I suggest adding a Disclosed-BCC: I don't follow. There's no additional encryption going on here. I mean the SHA transformation. Cleartext is obviously easier to understand and debug. I wouldn't say a salted hash qualifies as "racking my brains". The idea is to make it difficult to see who the envelope recipient is simply by looking. A one-way transformation forces an interloper to make guesses and try to confirm, and the salt guarantees that your email address does not always hash to the same thing. It's not perfect security by any means, but it's a cheap way to limit what gets leaked. This too is spelled out in Section 7. "To make guesses" is not the specified implementation. Section 4.2 says envelop recipient must match exactly. This requirement not only forces single-recipient mode, but also rules out verifiers which run after acceptance or after alias expansion. An incredibly narrow scope, overall. If instead you really allow some guessing, as mentioned in Section 7, you may rehabilitate a range of verifiers, but undoubtedly do so at the cost of full scale brains racking. Adding a "Disclosed-BCC" field guarantees disclosure, rather than only disclosing if the MDA adds a Delivered-To. I don't think we should make that worse. So long as you disclose it to the very recipient, there is no worry. NDNs customarily report SMTP chit-chat in cleartext, betraying users who attempt to hide their real address behind a dot-forward. Log files are plenty of envelope citations. Received: fields feature a FOR clause which is not deprecated for single recipient messages. We're not worsening anything. If you hand me a printed copy of a message without the envelope, and the Received didn't use the (non-standard) "for" clause, I cannot be certain it was delivered to whatever the To and Cc say, if they're even present. I don't think I'm with you. You seem to mean you don't know if, say, Terry actually received a copy of this. For example, one might arrange social engineering by adding CC:'s to your boss, the press, the police, et cetera, none of which corresponds to the envelope. Is that concern part of the problem at hand? It may have gone only to an envelope recipient that isn't visible. That is, if there was a Bcc, it's not revealed to me. If you insist on using "for" or "Disclosed-Bcc", that information is guaranteed to be exposed, and I can see who that secret recipient was. Invisible recipients may come from BCCs or other sources. When you get the message, you may want to know why it was delivered to you, and, yes, "for" or "Disclosed-Bcc" let you know that. Why should that info be kept secret? By contrast, including these tags at most reveals to me that there was a Bcc, but I have to do some complex (though these days, cheap) math to guess whether a specific address was in there. If I never make the correct guess, the secret is never revealed. I fail to see why that would be an advantage: The address is likely shorter than its hash. In general, it would be nice to have a standard means to tell recipients on what grounds a message was delivered to their mailboxes. For example, was it a role address or a personal one? If the message body is ambiguous (e.g. short messages) knowing the original recipient address may help. In the scenario you are proposing, only mailbox providers know the envelope, and can verify if that was what the sending domain signed. Final recipients --the actual subjects-- cannot access that info. That picture looks unfair. Indeed, in some countries providers may seem to be legally bound to reveal the envelope address upon subject request (IANAL). Ale ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts
On Wed 16/Nov/2016 14:00:26 +0100 Murray S. Kucherawy wrote: On Wed, Nov 16, 2016 at 7:57 PM, Alessandro Vesely <ves...@tana.it> wrote: That way it will stay dormant until someone gets hurt and has to activate it, at which time it may cause more damage than improvement. A loose cannon. The document makes that risk clear, or so I thought. You mean Section 5? Finally, if you stick to one recipient per message, why do you rack your brains about encryption? I suggest adding a Disclosed-BCC: header field with the recipient address in the same 5322.address-list cleartext format as the other address fields, and sign it FWIW. It won't break more privacy than Delivered-To: does. I don't follow. There's no additional encryption going on here. I mean the SHA transformation. Cleartext is obviously easier to understand and debug. Adding a "Disclosed-BCC" field guarantees disclosure, rather than only disclosing if the MDA adds a Delivered-To. I don't think we should make that worse. So long as you disclose it to the very recipient, there is no worry. NDNs customarily report SMTP chit-chat in cleartext, betraying users who attempt to hide their real address behind a dot-forward. Log files are plenty of envelope citations. Received: fields feature a FOR clause which is not deprecated for single recipient messages. We're not worsening anything. Ale ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts
On Wed 16/Nov/2016 03:28:08 +0100 Murray S. Kucherawy wrote: On Wed, Nov 16, 2016 at 10:59 AM, Terry Zink wrote: Large email receivers forward tons of email. This proposal causes email from DMARC-passing messages to be incapable of forwarding. As a large email receiver who gets tons of complaints about breakage of DKIM signatures on forwarded messages which causes DMARC failures [1], this proposal is not all that appealing. Version 01 is purely incremental, meaning you can just ignore the new tags if you're more worried about breakage of forwarding than the attack it's trying to address. That way it will stay dormant until someone gets hurt and has to activate it, at which time it may cause more damage than improvement. A loose cannon. I'd keep it in its own header field [Ned's (1)(a)], so as to avoid the risk Rolf points out. Besides forwarding, use of this method worsens mailing lists breakage further, which makes it totally out of scope for dmarc-ietf. At this point, I follow Dave's directive and remove that Cc:. Finally, if you stick to one recipient per message, why do you rack your brains about encryption? I suggest adding a Disclosed-BCC: header field with the recipient address in the same 5322.address-list cleartext format as the other address fields, and sign it FWIW. It won't break more privacy than Delivered-To: does. Ale ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
Apologies for jumping in late; just to note that 1024-bit keys seem to have been accepted until quite recently: https://www.sophos.com/en-us/support/knowledgebase/122327.aspx On Wed 13/May/2015 13:54:04 +0200 Martijn Grooten wrote: [...] I don't think such a BCP should be so broad as to cover other protocols, including TCP, which is orders of magnitude more complicated. BCP 86, which DKIM refers to, makes statements such as 1024-bit RSA moduli will not be factored until about 2037. Should it be updated? Ale -- Small keys are fine for test suites. And I wish 8-bit keys were functional, for illustrative and educational purposes. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] That weird i= is most probably EDSP
(subject adjusted) A sender using SRS would need to maintain a database of valid addresses. However, that task can become unduly complicated if the database has to be kept in sync across several distant hosts. A digital signature can substantially complement the security of the necessarily-too-short hash added to an SRS address, making it possible to avoid the database entirely, except for address length worries. That's where EDSP can save the day. On Mon 01/Jul/2013 21:24:25 +0200 Michael Deutschmann wrote: On Mon, 1 Jul 2013, Alessandro Vesely wrote: Well, not really. MAIL FROM: is only visible after delivery, so to avoid dangling signatures one should store its value in some other header field or... in the i= tag. ITYM only visible *before* delivery It has to be in the message content for DKIM to be applicable. There's long been a standard header for that purpose, Return-path:. The signature the OP posted had h=content-type:mime-version:subject: list-unsubscribe:reply-to:to:from:date:message-id, so the sender had to stuff it in i=. But EDSP checking in the MUA is not very useful -- if the Return-path is disavowed, then bouncing is an even worse idea than normal. The only place to act is in the SMTP transaction at the border. It is not very useful to the SMTP receiver either. The only value added is the d= domain supplied by EDSP. SPF leaves the receiver wondering about where the cut lies, but that's a non-actionable datum anyway, for the time being. It does mean that if the mail passes through an SPF Sender Rewriting Scheme forwarder, then it will end up with an unbroken but irrelevant signature. Even if that forwarder knows about EDSP, it can't strip the signature because it can't know that it isn't there to serve a different accessory protocol yet to be invented. After all, most of the time MAIL FROM: = From:, so the signature added for the sake of EDSP will simultaneously be serving ADSP or DMARC. But I don't think that's a problem. The message will get through, because the forwarder now owns the MAIL FROM and it's up to him whether an EDSP check is needed. Also, if any DKIM accessory protocol will false positive OR false negative due to the presence of irrelevant (ie: not the d= you're looking for) signatures, then that accessory protocol is really broken. Of course, it's always correct for an accessory protocol to dismiss a message as unsigned if the irrelevant signatures the only signatures present. Any other behavior would fall under false negative due to irrelevant signatures. Yes. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] That weird i= is most probably EDSP
On Tue 02/Jul/2013 17:37:20 +0200 Michael Deutschmann wrote: On Tue, 2 Jul 2013, Alessandro Vesely wrote: (subject adjusted) A sender using SRS would need to maintain a database of valid addresses. [...] That's where EDSP can save the day. That's off in the weeds. EDSP would not take any notice of i=, and is not there to enhance SRS -- rather it's something of a competitor. (Both try to make return path validation work in spite of forwarding.) The point is what any of them might be useful for. It has to be in the message content for DKIM to be applicable. Core DKIM is only tasked with determining if a signature is genuine, not if the signature is relevant. Therefore it doesn't matter if part of the information EDSP uses to determine relevancy is out of band. Yes, one just needs to maintain his own software to run it :-/ BTW, there is already a hack in how that's implemented, because they used no l=0 tag. So, if the bounce they get has text/rfc822-headers only, they have to assume that the body hash matches. Perhaps, they reasoned that they can still verify the SRS hash, and that an assumed but variable bh= is still better than the constant body hash specified for l=0. Depending on what library they use, implementing that could be as simple as checking the return code. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The problem with the DKIM design community
On Sun 30/Jun/2013 15:21:29 +0200 Michael Deutschmann wrote: EDSP would only pay attention to signatures where the d= matches the right hand side of the RFC821 MAIL FROM:. This means that someone can publish the strictest possible EDSP without causing mailing list false positives. Mailing lists take ownership of the MAIL FROM:, hence only an EDSP set by the list itself will apply, and the original poster's EDSP will be correctly ignored. Just like in SPF. Of course, since the MAIL FROM: is usually not visible without pressing a show all headers button, this would be more about leaving a clearer audit trail than actually foiling phishes. Well, not really. MAIL FROM: is only visible after delivery, so to avoid dangling signatures one should store its value in some other header field or... in the i= tag. Heck, is that the semantics that the OP was talking about? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On 07/Jul/11 16:13, Dave CROCKER wrote: On 7/7/2011 6:57 AM, Murray S. Kucherawy wrote: I'd s/to be liberal/to be exceedingly liberal/ (we don't want to revise Postel's statement, do we?) You're either liberal in your application of the RFCs, or you're not. I don't see how adding that word improves things here. well, it keeps the thread going... You /have/ to be liberal, but that can be limited in degree and in time. An app must be liberal in what it accepts, not only because a specification is subject to some variance in interpretation, but also because of unavoidable time differences in its adoption. Since no RFC can be transmitted faster than the speed of light, a host which adopted an RFC at time t0 (see graph) has to wait at least until time t2 before a compliant signal from a distant source may reach it. ^ | time | Xt2 (RFC-compliant signals | |\ may reach the host | | \ from the distant source) | | \ | | \ | |\ . | | \. | | \ . | . | \t1 (RFC reaches signal source) | . | / | . | / |\| / | \ |/ | \ | / | \ | / |\| / | \/___t0 (RFC reaches the host) | /\ |/| \ | / | \ |\ / | \ | \ / |\ | \ /| \ | \ / | \ |\ / | \space +-X---XX RFC- host signal Editorsource ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On 06/Jul/11 20:34, Murray S. Kucherawy wrote: Anyway, with a few nitty edits from me as well, here's the current 8.15 for -15 for everyone's consideration. A few comments: 8.15. Attacks Involving Extra Header Fields [...] Many email components, including MTAs, MSAs, MUAs and filtering modules, implement message format checks only loosely. This is done out of years of industry pressure to be liberal in what is accepted into the mail stream for the sake of reducing support costs; improperly formed messages are often silently fixed in transit, delivered unrepaired, or displayed inappropriately (e.g., by showing only one of multiple From: fields). I'd s/to be liberal/to be exceedingly liberal/ (we don't want to revise Postel's statement, do we?) A genuine signature from a domain under attack can be obtained by legitimate means, but extra header fields can then be added, either by interception or by replay. In this scenario, DKIM can aid in detecting addition of specific fields in transit. This is done by having the signer list the field name(s) in the h= tag an extra time (e.g., h=from:from:... for a message with one From field), so that addition of an instance of that field downstream will render the signature unable to be verified. (See Section 3.5 for details.) This in essence is an explicit indication that the signer repudiates responsibility for such a malformed message. +1 for exemplifying h=from:from:..., even if it's not a cure-all. DKIM signs and validates the data it is told to and works correctly. So in this case, DKIM has done its job of delivering a validated domain (the d= value) and, given the semantics of a DKIM signature, essentially the signer has taken some responsibility for a problematic message. It is up to the identity assessor or some other subsequent agent to act on such messages as needed, such as degrading the trust of the message (or, indeed, of the signer), or by warning the recipient, or even refusing delivery. I'd omit any allegation on what an assessor's needed actions might be. (Actually, we'd need yet another policy or authentication method in order to allow the outcome of an identity assessor to be formally expressed. Without it, the quick-n-dirty approach of degrading the trust of a message by tampering with its DKIM verification's results may seem the easiest remedy --much like what Doug et al. proposed.) An agent consuming DKIM results needs to be aware that the validity of any header field, signed or otherwise, is not guaranteed by DKIM. Please, s/validity/reliability/: someone might believe a field is valid if it retains the value that was given to it originally. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] spam filtering 101
On 27/Jun/11 23:38, Michael Deutschmann wrote: * Put it in its own RFC * I think there's room for a Minimum Quality of Forgery Supression BCP. Such an RFC would outline a number of faults a message can have, and declare that any of those faults mean the message MUST NOT be delivered to the nominal recipient. +1, revising RFC 2505, whose date is in last century, should be due. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Certified DKIM verification
On 17/Jun/11 20:01, Murray S. Kucherawy wrote: From: [...] On Behalf Of Alessandro Vesely does anybody know about commercial/free DKIM verifiers that produce a certificate of valid email message, or similar, for archival usage by the requesting party? What, other than an Authentication-Results field, did you have in mind? Dunno. Perhaps a web form where you upload a .eml signed message and get back a duly signed printable thing certifying that the message verified. Its semantic content is the same as an A-R field, except that it cannot be forged. If you exhibit it sometime in 2021, say, it will still prove that you received the given message from the given domain on the given date. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Certified DKIM verification
Hi all, does anybody know about commercial/free DKIM verifiers that produce a certificate of valid email message, or similar, for archival usage by the requesting party? TIA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 31/May/11 17:28, John R. Levine wrote: Chain of trust is always an appealing model. Unfortunately, it hasn't been used successfully over the open Internet. I agree with your doubts about the utility of chain of trust, but I would have to say that SSL signed web sites are used successfully over the open Internet. The power grid probably raises such issues as well. I just stumbled on this http://tcipg.org/publications?tag=291 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 31/May/11 00:23, Murray S. Kucherawy wrote: -Original Message- From: On Behalf Of Steve Atkins The most obvious thing that MLMs do that invalidate signatures are 1. append content to the body and 2. prepend content to the subject line. Any approach that allows me to replay messages while making those changes seems to open the door to abuse. While that's true for MLM, I'm not sure it correctly reflects MTAs' behaviors. In particular, the X-MIME-AUTOCONVERT feature and whatever may cause MIME rewriting. This is MTA-specific, and affects MLMs as well as dot-forwards. Pareto has been discussed enough, so I don't comment on the fact that such minor part of the traffic would demand complicated and expensive implementations to go through correctly. Agree on all counts. And I talked to the Mailman people, for example, about a modified header canonicalization that deals with Subject: tagging, and they also agreed it wouldn't help that much since that's not the most common change made that would invalidate the signatures. Yeah, reply messages have subject-tags already in place. If MLM subscriptions were known at submission time, tag addition before signing could be easily done by MSAs, MUAs, or manually by users. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 27/May/11 19:16, Murray S. Kucherawy wrote: I'm all for including experimental code in future releases of our stuff, especially if it's an experiment other implementations are trying. But I need to see a spec first, or enough detail that I could write one. For the body, I brought some ideas[1]. For MIME header fields, punctuation and boundaries need to be omitted as well. For other header fields, including the DKIM-Signature, it is probably enough to remove just any white space. [1] http://mipassoc.org/pipermail/ietf-dkim/2011q2/016692.html IMHO, the hard parts of the code are (i) selecting a MIME parser, and (ii) finding a good way to structure experimental C14Ns and handle double (triple?) signatures in the existing code. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and signatures again
On 26/May/11 23:52, Murray S. Kucherawy wrote: From: On Behalf Of Franck Martin 2) do we need a mechanism to alert the receiving MTA that you have subscribed to a mailing list, and all messages should pass through? Yes, desperately. Certainly a possible feature, but it seems like it won't scale very well. Why not? Of course, having a copy of each subscription record would roughly double the database, globally. Twice is scalable, though. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 25/May/11 20:23, Dave CROCKER wrote: On 5/25/2011 9:59 AM, John Levine wrote: The idea is to anticipate any unknown signature breaker. I'm pretty sure that's specifically out of scope. And I promise that whatever you do, short of wrapping the whole message in opaque armor, I can come up with something that will break it. One might have a goal of attempting to be robust against all forms of potential breakage. That's not likely to be the goal of this sort of exercise. Rather, it will be to choose a set of particular types of breakage, ignoring others. For an effort like that, it is not meaningful to come up with additional types of breakage, since there is no attempt to cover such additional examples. Of course, a signature cannot survive a deliberate attempt at breaking it. However, earlier analysis considered man-in-the-middle attacks like changing, e.g., Amoeba yeast into Amo ebay east [Bryan Costales, Thu, 04 Aug 2005]. We don't know how likely such kind of attacks may be, since only tight canonicalizations were standardized. By introducing a loose canonicalization we may learn whether signature survivability affects DKIM adoption. If wider usage introduces attacks, we can switch back to current canonicalizations --in case downgrades will have gone away-- or design yet another one, approaching just the tightness we need. My appeal is for not imposing monotonicity to successive approximations, and allow erring on the too-lose side as well. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 25/May/11 18:42, Hector Santos wrote: Alessandro Vesely wrote: Yes, dot is one of the punctuation characters that should be removed. This turned out to be a bug in our beta code, revamped to support I/O completion ports and the code for undotting of the leading dot (per RFC5321 4.5.2) fell thru the crack. So we can nix this one. :) Yet, it wouldn't have hurt if those signatures had passed. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Triple opt-in, was MLMs and signatures again
On 27/May/11 18:29, John R. Levine wrote: 2) do we need a mechanism to alert the receiving MTA that you have subscribed to a mailing list, and all messages should pass through? Yes, desperately. Certainly a possible feature, but it seems like it won't scale very well. Why not? If I were a spammer, I would tell the victim's MTA that the victim subscribed, then send the spam. Yes, but then the MTA would then know how to treat the corresponding victim's complaint. These days most subscriptions are entered on a web page, and if you're lucky the mailer will send a confirmation message with a URL that sends the subscriber back to the web page. Where's the MTA going to get the subscriber info? An http url could be advertised on the MX's EHLO reply. That's a page on the users' server, where they can confirm subscriptions along with their credentials. MLMs get digitally signed confirmations of COI. Ways to accept non-interactive subscription notifications are also necessary. I agree they are somewhat more challenging. For MLMs that present DKIM-signed List-* header fields, subscriptions might be assumed, and tracked unilaterally that way. But unsubscribe attempts seem to be more difficult to do, in this case. The challenges in designing a protocol that neither makes unreasonable demands on users and MUAs nor is easily spoofed by hostile mailers seem insurmountable to me. MUAs wouldn't be much affected, except for allowing TiS buttons. Users would gain uniform subscribe/unsubscribe pages. If you're planning to keep a reputation database of mailers who send credible subscription announcements, why not just whitelist their mail? The ability to maintain such database would be improved. Since as far as I know nobody does this, it's a resarch topic, so I've directed replies to the ASRG. See you there. Here I am. I've kept a CC to DKIM list, to be removed in followups. It is not the first time I bring up this idea on the ASRG. It addresses newsletters more than discussion lists, because of the way subscriptions work. In Europe, the resulting protocol could help providing proofs of consent, which many European newsletters handle as a checkbox on _manually_ signed forms. Indeed, I'd consider it an implementation of the Data Protection Directive. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 25/May/11 10:03, Hector Santos wrote: How would 7/8 bit be considered? Personally, the STRIP C14N idea would work just fine by removing all trailing WSP (CR, LF, SP) and for QP text, decode it first. I'm considering updating my 2006 I-D to include the QP decoding logic. I propose a much more radical approach, something that will likely land on the too-loose side. Such kind of approach is justified by the most breakage is innocent theory, and by already having two canonicalizations on the too-tight side. For example, consider these criteria for feeding the body hash: 1) For multipart MIME messages, completely remove the preamble, the epilogue, and all boundaries and entity headers. 2) For MIME encoded parts, get back to the binary content. 3) For text parts, completely remove /any/ whitespace. Additionally, remove most punctuation, especially from begin and end of lines. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 25/May/11 14:27, Hector Santos wrote:
Alessandro Vesely wrote:
On 25/May/11 10:03, Hector Santos wrote:
How would 7/8 bit be considered?
Personally, the STRIP C14N idea would work just fine by removing all
trailing WSP (CR, LF, SP) and for QP text, decode it first. I'm
considering updating my 2006 I-D to include the QP decoding logic.
I propose a much more radical approach, something that will likely
land on the too-loose side. Such kind of approach is justified by the
most breakage is innocent theory, and by already having two
canonicalizations on the too-tight side.
For example, consider these criteria for feeding the body hash:
1) For multipart MIME messages, completely remove the preamble, the
epilogue, and all boundaries and entity headers.
2) For MIME encoded parts, get back to the binary content.
3) For text parts, completely remove /any/ whitespace. Additionally,
remove most punctuation, especially from begin and end of lines.
Do we really need this? Do you know of cases related to this?
The idea is to anticipate any unknown signature breaker. My three
points above are rather generic. They are meant to be expanded so as
to include your five points below, and more.
I think it is quite obvious that MIME rewriting generates new
boundaries, and may alter an entity's header.
Non-text binary content that arrives corrupted deserves breaking a
signature. However, a rewriter may decode a base64 entity for local
storage, and then re-encode it with a different line length.
Text undergoes any kind of massage, trailing = may be leftover,
CRLFs may be doubled, From turned into From , besides the
leading dots you mention in point five.
We should identify and list the sort of transformation issues we are
seeing.
Erring on the too-lose side implies some generalization.
I have identified four so far:
1 - We forgot a possible top CRLF. We dealt with the bottom CRLF
but not the top,
2 - Top level QP decoding,
3 - Top Level reformatting to C-T-E: base64 (not MIME multi-part)
4 - Lines over 998 (1000 with CRLF), this is an invalid RFC5322, but
its possible some verifiers are designed to do a buffered C14N
and don't check for RFC5322 line lengths between two memory points
in the buffer as oppose as a line by line feed into the C14N
function. Why buffer vs line? speed.
I imagined the C14N function reads characters one by one. On finding
CRLF it can go back a few bytes to remove end-of-line punctuation.
However you code c14n(), it will be sparklingly faster than sha256().
However, distinguishing begin middle of line versus begin/end is
possibly inconsistent, since line breaks may be altered because of
invalidly long lines or RFC3676 rewrapping.
I found 98 such buffer hash errors from various domains due to
having at least 1 super long line.
Some MUAs consistently keeps paragraphs on a single line.
and I just found a yet another problem which I was currently
investigating to see where it this mite is occurring:
5 - Incorrect handling of lines beginning with dots, for example
I sent a message containing a line beginning with:
... blah blah blah. blah.
and it was received by my SMTP server as:
blah blah blah. blah.
and its sent to this list, it comes back as:
. blah blah blah. blah.
I checked my SMTP server and its correct. I just now pretty much
confirmed ThunderBird is causing this initial dot escaping error by
sending mail to my gmail host and hotmail host accounts. The
showed up in my new mail bin. But it also appears there could be an
intermediary with a bug as well adding yet another dot.
While we like to shift blame to the buggy software, IMV, since
transport DOT escaping is a SMTP requirement and there could be these
small issues, I'm thinking maybe we should consider a similar
relaxed logic now done for reducing multiple WSP to reduce
multiple DOT as well but only when its begins on a new line (or for
block transfers, preceded by CRLF). So a line like
DOTDOTDOTSPblahSPblahDOTSPSPblahDOT
it becomes:
DOTSPblahSPblahSPblahDOT
Yes, dot is one of the punctuation characters that should be removed.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
On 23/May/11 22:04, Hector Santos wrote: Alessandro Vesely wrote: On 23/May/11 06:35, Hector Santos wrote: Alessandro Vesely wrote: For example, MTAs that autoconvert from quoted-printable to 8bit, a rather common circumstance. I did the following Content-Transfer-Encoding failure analysis: Failure rates for message top level encoding type ++ | enctype total bodyfail pct | || | 8bit 31 25 80.6| It is not clear what part of these 8bit failures is due to messages that had been downgraded before signing, and then upgraded before verifying. None. Sorry, by upgraded I mean the same as X-MIME-Autoconverted: from /any encoding/ to 8bit. Thus I take your answer as 20/31. Of the 31, 20 were from Keith Moore signed messages into the IETF-SMTP list with a 3rd party signature and Hoffman's list server (non-dkim aware) doing this: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p4BLC7Hl032165 Thanks! It was recently mentioned that Hoffman's MLM inserts a white line on top of the body. Unfortunately, relaxed body canonicalization regards this line as significant. This autoconversion is another, unrelated change that breaks signatures. Now, let me say that my MTA contravenes the SHOULD downgrade precept. I hypothesize that if it wasn't for the extra white line, that is, taking into account only normalization issues, then my signatures would survive while Keith's would not. IOW: the 1st paragraph of Section 5.3 can be *misleading*, as in some cases a signature's survivability gets worsened. What encoding minimizes the chances of conversion is a moving target whose current state we should not purport to know. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] dot-forward, was 8bit downgrades
On 24/May/11 15:22, John Levine wrote: Of the 31, 20 were from Keith Moore signed messages into the IETF-SMTP list with a 3rd party signature and Hoffman's list server (non-dkim aware) doing this: Oh, it's a mailing list. Why are we even having this discussion? We all know there's a million ways that lists break incoming signatures, which is why they should sign on the way out. IMHO, that MLM is only responsible for the inserted whiteline; MIME rewriting is done by MTA/MDA. This rewriting is typical of a class of messages that arrive at an MTA and then undergo a dot-forward or similar mechanism. Although it is a minor number of messages, I don't think that ignore-by-design could play a winning role here, because --unlike mailing lists-- there is no way to eventually fix this at the forwarding MTA. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] dot-forward, was 8bit downgrades
On 24/May/11 16:14, John R. Levine wrote: Although it is a minor number of messages, I don't think that ignore-by-design could play a winning role here, because --unlike mailing lists-- there is no way to eventually fix this at the forwarding MTA. If the EAI work is any guide, in the long run everything will be 8 bit, and downgrades will eventually go away. Well, this consideration suggests it would be smoother to remove the recommendation to use transfer encoding now, rather than suddenly turn it into the opposite recommendation in a post-EAI DKIM spec. Anyway, if that is going to take decades, a more robust canonicalization could be worth its while. In the shorter term, if the forwarding MTA is inclined to be helpful, it can re-sign on the way out. SPF experience says MTAs often don't help. Even if they did, the resulting SDID would be neither the author's domain nor the MLM. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
On 23/May/11 06:35, Hector Santos wrote: Alessandro Vesely wrote: For example, MTAs that autoconvert from quoted-printable to 8bit, a rather common circumstance. I did the following Content-Transfer-Encoding failure analysis: Failure rates for message top level encoding type ++ | enctype total bodyfail pct | || | 8bit 31 25 80.6| It is not clear what part of these 8bit failures is due to messages that had been downgraded before signing, and then upgraded before verifying. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 19/May/11 05:17, John Levine wrote: The point I was making was that ever more complex ways to decide that two mutated versions of a message are the same aren't likely to help much, certainly not compared to the large cost of implementing code even more complex than what relaxed does now. Just to mention two of those ways, MIME rewriting is a capability mayor MTAs introduced when MIME took root, HTML styles mangling is an ongoing MUA exercise. And anyway, if your goal is for your message to survive, you should armor it better, not come up with more arcane ways to declare that it may be bleeding heavily but it's not dead yet. Interesting, but not less intricate. The semantics of authenticating only the armored part of a message is not obvious. Resorting to base64 encoding is subject to varying interpretations, including spammers attempts to avoid naive content filtering. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
On 20/May/11 15:33, John Levine wrote: of what paths are likely to downcode a message and what paths aren't, so I would prefer not to purport to offer advice about it. Actually, I kinda prefer to leave it in. It seems to me assume a downgrade will happen unless you're certain it won't, and plan accordingly is good advice without having to know the details of a transport path. And the paragraph gives discussion of the how and why. So long as it's clear that the advice is illustrative rather than definitive, I'm not extremely opposed. What I want to avoid is the impression that we think we've anticipated all possible message mutations, so if there's one we didn't mention, that means we need to add another hack to DKIM to work around it. For example, MTAs that autoconvert from quoted-printable to 8bit, a rather common circumstance. Wietse reminded us that MTAs with native MIME rewriting capabilities can run filters (including DKIM filtering) either before or after MIME conversion. The former is good for signing while the latter is good for verifying, but what about subsequent dot-forwards? We can hope MTAs will stop autoconverting. Until then, it is useless to say /when/ to invoke a DKIM filter, let alone whether to use MUST, SHOULD, or MAY. Up/down grading depends on conversion, so I concur with John's original statement: I would prefer not to purport to offer advice about it --which is not the same as not mentioning the problem. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Section 3.7 s/content-hash/body-hash/?
On 17/May/11 20:17, Dave CROCKER wrote: On 5/17/2011 1:54 PM, Murray S. Kucherawy wrote: The remaining changes are inconsistent with the rest of the section or don't clarify anything. For example, the hash-alg function on the body-hash line takes the canonicalized body and the l-param as inputs, and produce the body-hash. Thus, that expression is correct as-is. Not merely inconsistent. The existing text specifies parameters to routines that do internal processes. This is a standard form for specifying interfaces. The proposed change tries to move some of the processing into the parameter, and hence is not an interface specification (unless, for example, the goal is to tell the caller to truncate the body, rather than have the subroutine do the truncating. Yes, I put the remaining changes quickly and badly just to suggest that, IMHO, there is room for improvement. In particular, hash-alg looks like an overloaded function that can take two or three parameters, but its definitions are hard to spot. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 17/May/11 16:45, Ian Eiloart wrote: However if some of the messages were never properly signed (whether failed attempts to spoof, or administrative or technical failure), then that 20% must be higher. It could even represent 100% reduction in false negatives due to (otherwise benign) in-flight modifications. Actually, those figures don't even distinguish between failures due signature comparison and earlier errors, such as body-hash mismatch or invalid key. To run the test properly we'd need to put two DKIM-Signatures with different canonicalizations, on each message. I don't know what is going to happen with EAI and YAM, but one day we'll have utf-8 in the header as well as in the body. As it would be very clumsy to insist for 7-bit normalizations at that point, I think there will be a new revision; presumably, the next one after 4871bis. If we'll have some test results of a new canonicalization at that time, showing, say, 95%~98% pass, the new canonicalization can be included in such future DKIM revision. That would be a significant improvement, won't it? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Section 3.7 s/content-hash/body-hash/?
Version -10 says More formally, pseudo-code for the signature algorithm is: body-hash = hash-alg (canon-body, l-param) data-hash= hash-alg (h-headers, D-SIG, content-hash) signature= sig-alg (d-domain, selector, data-hash) where: body-hash: is the output from hashing the body, using hash-alg. Shouldn't it say More formally, pseudo-code for the signature algorithm is: body-hash = hash-alg (canon-body limited by l-param) data-hash= hash-alg (h-headers, D-SIG with body-hash) signature= sig-alg (d-domain, selector, data-hash) where: body-hash: is the output from hashing the body, using hash-alg. It is set as the value of the bh= tag in D-SIG for computing the data-hash. ? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On 15/May/11 21:04, Hector Santos wrote: The author can be a human using an MUA (Mail User Agent) or an automated mail robot with an MTA. Both the human and the robot use an MTA (or an MSA.) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] New canonicalizations
On 16/May/11 06:15, Murray S. Kucherawy wrote: From: On Behalf Of Barry Leiba 2. We wanted to cover the vast majority of the cases, though we knew there'd always be outlying situations where some mail would get broken because what we had didn't *quite* cover some other case. We decided to accept that. However, relaxed header canonicalization is not MIME compatible. In particular, RFC 2045 says Note that the value of a quoted string parameter does not include the quotes. That is, the quotation marks in a quoted-string are not a part of the value of the parameter, but are merely used to delimit that parameter value. In addition, comments are allowed in accordance with RFC 822 rules for structured header fields. Thus the following two forms Content-type: text/plain; charset=us-ascii (Plain text) Content-type: text/plain; charset=us-ascii are completely equivalent but they are not DKIM-wise equivalent. Fixing this and a couple more nits, we could claim to cover text/plain, which is still not quite the vast majority of the cases. I would add that adding a new canonicalization now has an extremely high cost to the people that want to use it, because signatures using it will go unverified for a very long time until software supporting the new canonicalization is widely deployed. Many MTAs still add a Domainkey-Signature. They could stop that, and add a legacy DKIM-Signature along with a one that features the newer canonicalization instead. Setting the pace in this manner can keep DKIM development alive indefinitely. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 16/May/11 15:00, John R. Levine wrote: In retrospect, it probably would have been better only to provide simple and tell people more firmly to do the signing after and the checking before any local modification. That implies hop to hop rather than end to end. What would the advantage over SPF be then? Perhaps Murray has data that says whether relaxed verifies much more often than simple does. Yes, http://www.opendkim.org/stats/report.html#hdr_canon says Header canonicalization use: canonicalizationcount domains passed simple 653688 6786591938 relaxed 3940377 56621 3640854 Although they only differ by 2% (90% simple vs 92% relaxed), such percentages would be superb for tools like Spamassassin. I'd expect at least 99% from a cryptographic tool. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 16/May/11 15:41, John R. Levine wrote: http://www.opendkim.org/stats/report.html#hdr_canon says Header canonicalization use: canonicalization count domains passed simple 653688 6786591938 relaxed 3940377 56621 3640854 Although they only differ by 2% (90% simple vs 92% relaxed), such percentages would be superb for tools like Spamassassin. I'd expect at least 99% from a cryptographic tool. This tells me that the benefit from relaxed is at most pretty small. OTOH, comparing the count fields of those two lines, 86% relaxed vs 14% simple, says that such kind of benefit is really really wanted. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 16/May/11 19:00, Michael Thomas wrote: On 05/16/2011 09:39 AM, Dave CROCKER wrote: The problem with the above is the biasing factor of signers' choosing to use one or the other, based on criteria we can't know about. Their criteria might have greatly affected actual survival rates. Or might not have... My guess is that admins just don't understand any of the subtleties, have heard lore that relaxed is better and just click relaxed wherever they find it. It may also be the case that some implementations don't even have separate nerd knobs for headers and body canonicalization. However, Murray's stats show some difference in the choice of relaxed: Header canonicalization use: canonicalizationcount domains passed simple 653688 6786591938 relaxed 3940377 56621 3640854 Body canonicalization use: canonicalizationcount domains passed simple 1187858 11526 1096204 relaxed 3406207 51818 3136588 For the body count, we have 74% relaxed vs 26% simple, while it is 86% relaxed vs 14% simple for the header. There is a 12% difference toward relaxing the header, which implies some thought or testing. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] SMTP DATA EOD Reject Code for MLMs
On 14/May/11 22:16, Hector Santos wrote: SM wrote: From http://www.rfc-editor.org/rfc/rfc5321.txt DATA I: 354 - data - S: 250 E: 552, 554, 451, 452 E: 450, 550 (rejections for policy reasons) Ok. I recommend (prefer) text that reflects receiver w/o RFC3463 support. +1, and we have to mandate a precise format for the text, I mean a production rule including %x41.44.53.50, or forget this whole idea that a receiver could make a better job by signaling ADSP violations. Practically coding, a DKIM aware MLM adding this conditional check might look for three or five triggers: 554 5.7.0 5.8.0 or 5.8.1 ADSP or POLICY or some other recommended work that could be used. Indeed, a gateway on a Mac that forwards by means of the AppleTalk Data Stream Protocol, may signal a failure of the latter stack by 554 ADSP failure. -- http://www.all-acronyms.com/ADSP ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On 13/May/11 20:17, Murray S. Kucherawy wrote: From: On Behalf Of SM By my read, the bulk of your comments fall into these categories: (1) Remove the normative language, publish as Informational My reading of SM's comments is for replacing Best Current Practices, not normative language in general (but in particular, where it is redundant.) I consider his thoughts in accord with what another John noted: When we make that sort of recommendation in a BCP, we expose ourselves to the criticism that the recommendation is neither best (as distinct from a bad compromise), nor current (as distinct from a recommendation about future behavior), nor actively practiced. As I said to John, I'd be fine with this. The document started out as Informational but there was working group momentum in the direction of a BCP instead, hence the conversion to use of RFC2119 language. I personally don't have strong feelings about that so if the preferred course of action is to go back to that, I'd be fine. -1, I'd favor AS/PS or even experimental over BCP, but still prefer BCP over informational. As for the idea of using PS instead, that doesn't seem appropriate to me given we're not standardizing a protocol here, and at best we don't have enough implementation experience to back up the claims. How about running a test? I guess many of us can configure their MTAs for signing/verifying as it requires... (3) RFC5451 discussion This falls under policy decision. The usage of a 554 code is inappropriate. From Section 3.6.2 of RFC 5321: If it [SMTP server] declines to relay mail to a particular address for policy reasons, a 550 response SHOULD be returned. 3.6.2 applies to relays, not recipients. A relay might try DKIM validation and ADSP evaluation, but that's not the model this document discusses. Yes, my understanding of that SMTP snippet is that it concerns responses to RCPT TO:particular address, while DKIM and ADSP can only be evaluated after CRLF.CRLF. (In this respect, mentioning user unknown in the MLM spec may cause some confusion in readers not familiar with SMTP.) However, if that doesn't matter, unfortunately this makes the distinction we're trying to make impossible without using enhanced status codes, which aren't universally used. +1 for keeping 554 as is. But to be conformant, I suppose 550 5.7.0 would be appropriate. Conformant to what? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On 13/May/11 09:15, SM wrote: In Section 4.1: In an idealized world, if an author knows that the MLM to which a message is being sent is a non-participating resending MLM, the author SHOULD be cautious when deciding whether or not to send a signed message to the list. The author generally does not have any control over that decision as DKIM signing is not done at the MUA level. The usage of a key word is somewhat excessive here as the ideal world is out of scope for RFC 2119. +1, should be lowercase. This problem can be compounded if there are receivers that apply signing policies (e.g., [ADSP]) and the author publishes any kind of strict policy, i.e., a policy that requests that receivers reject or otherwise deal severely with non-compliant messages. The definition of insanity is doing the same thing over and over and expecting different results. There are parallels between ADSP and SPF. As a corollary, it is sane to do slightly different things over and over until one catches the one that works. SPF is slightly better than ADSP, though. In Section 5.1: It is RECOMMENDED that periodic, automatic mailings to the list are sent to remind subscribers of list policy. This is currently being done by the IETF under the guise of mailman day. Yes, the time-distributed database... In Section 5.8: DKIM-aware authoring MLMs MUST sign the mail they send according to the regular signing guidelines given in [DKIM]. Removing the MUST [...] +1, the MUST is in DKIM's specs and thus is redundant here. In Section 5.10: An FBL operator might wish to act on a complaint from a user about a message sent to a list. Shouldn't that be FBI? :-) +1 (smiley not taken), FBL is a specific mechanism. As much of the advice is also valid for other mechanisms, I suggest to change the title to Abuse Reporting Issues or similar. From Section 5.11: Upon DKIM and ADSP evaluation during an SMTP session (a common implementation), an agent MAY decide to reject a message during an SMTP session. If this is done, use of an [SMTP] failure code not normally used for user unknown (550) is preferred; therefore, 554 SHOULD be used. This falls under policy decision. The usage of a 554 code is inappropriate. From Section 3.6.2 of RFC 5321: If it [SMTP server] declines to relay mail to a particular address for policy reasons, a 550 response SHOULD be returned. -1, although it is a policy question, it has nothing to do with relaying. In such cases where the submission fails that test, the receiver or verifier SHOULD discard the message but return an SMTP success code, i.e. accept the message but drop it without delivery. An SMTP rejection of such mail instead of the requested discard action causes more harm than good. I would remove the SHOULD as the argument (second sentence) is clear. The usage of the SHOULD raises the question about whether this is a SMTP receiver action and whether it is appropriate to create a black hole (silent drop of message). This should have been explained more clearly in RFC 5617. Perhaps, we should say that discardable means droppable in general? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
On 08/May/11 19:13, Dave CROCKER wrote: In practical terms for the current world, what is the likelihood that a signer has any information about the 'type' of an email address? How can a signer possibly know that an addressee is a mailing list??? Currently, it has to query the /time-distributed database/ brought about by the spotty subscription reminders that MLMs send on April fools' day and similar occasions. Seriously, since it is a civic and sometimes legal duty to confirm subscriptions, one may wonder why that database is not maintained by means of present-day technologies. Every MTA would then have a list of mass mailers, cross-linked to its users, to be looked up when whitelisting, signing, resolving complaints, and, occasionally, attesting (un)subscriptions. Forgive the OT. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
On 07/May/11 15:39, Hector Santos wrote: I would like to know why 6% of the mail use [l=] but don't need it. One possible answer is that the signing agents have no clue about that mail's destination. The easiest way to configure DKIM in order to use l= on some messages, is to enable it on _all_ messages. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output requirements
On 06/May/11 20:37, Murray S. Kucherawy wrote: Verifiers SHOULD ignore those signatures that produce a PERMFAIL result (see Section 7.1), acting as though they were not present in the message. ... s/Verifiers SHOULD ignore/Identity assessors SHOULD ignore/ (and probably in other places too). Verifiers are explicitly instructed to return PERMFAIL/TEMPFAIL), and returning something is evidently inconsistent with ignoring it. +1 Since this is already somewhat mushy, might I suggest: Verifiers MAY decline to report, and identity assessors SHOULD ignore, ... I wouldn't delve into what identity assessors should do, since that is outside the scope of the DKIM Signing specification. The wording in section 3.9 already conveys that ignoring is being used as a synonym for returning PERMFAIL. I'd make such meaning more explicit rather than introducing yet a new phrase to allude to the same behavior. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
On 06/May/11 21:09, John R. Levine wrote: this, but I need to get a clear view of consensus. Doug agrees with Hector's note, below, and Dave and Murray do not. I'd like to hear from others within the next few days, about whether you think we should make the change Hector requests or not. Dave and Murray are right, Hector is not. +1, since we don't know precisely what output is actually used. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] 23 again (sorry John) was Output summary - proposing ODID Originating Domain Identity
On 04.05.2011 21:13, MH Michael Hammer (5304) wrote: boun...@mipassoc.org] On Behalf Of Dave CROCKER On 5/4/2011 11:34 AM, Murray S. Kucherawy wrote: So the issue is that someone might read it as leave l=value out of what you feed to the hash versus hash it, but ignore what it's telling you? If so, I agree, we should fix that. Seems like the replacement text should be something along the lines of: Considerations Section 8. To avoid this attack, signers should be extremely wary of using this tag, and verifiers might wish to ignore the tag. To avoid this attack, signers need to be extremely wary of using this tag, and verifiers might choose to ignore signatures containing it. I thought we meant ignore the value that this tag provides; that is, fail signatures only if the body length actually changed. W.r.t. RFC 4871, we only removed the text suggesting to remove text that appears after the specified content length (assuming it grew). So we have a very poor wording in both documents, pining for arguments among opposite-minded implementers, one claiming that another is non-compliant. If this is the sort of advice we are going to give then we should just deprecate l=. +1: it was an error in the PS and the DS fixes it. Alternatively we can allow it, warn, and expect implementers to code heuristics that can discern attacks from regular footers. We can't have both. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Question: ADSP DKIM=UNKNOWN and A-R reporting
On 03.05.2011 15:28, Hector Santos wrote: Authentication-Results: dkim.winserver.com; dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k1; adsp=fail policy=unknown author.d=tana.it signer.d=mipassoc.org (unauthorized signer); The (unauthorized signer) was added because it was an explicit DKIM=UKKNOWN DNS record declaration. If there was no ADSP record, the adsp= info would look like this: adsp=none author.d=tana.it signer.d=mipassoc.org; Would that be a reasonable valid A-R reporting for ADSP based on my interpretation of explicit vs implicit DKIM=UNKNOWN setting? I don't think so. The only difference between setting unsigned and letting it be derived by default should be the ability to control the expiration of such value. As for ATPS, I will happily mention mipassoc.org as authorized signer, and I'll possibly authorize more domains, but then I'll also forget some. That's what happened when I enabled ADSP promising to myself to whitelist each and every MLM, and failing to keep it. IMHO, MLMs should tell authors' servers about subscriptions, as that would solve a number of problems. Until they continue not doing that, this particular problem remains among the unsolved ones. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Question: ADSP DKIM=UNKNOWN and A-R reporting
On 04.05.2011 14:56, Hector Santos wrote: Alessandro Vesely wrote: The only difference between setting unsigned and letting it be derived by default should be the ability to control the expiration of such value. Can you rephrase this so I can better understand your thinking? ATPS wasn't visible when I set that record. The only reason I put it there was to state a decent TTL, which makes sense since the design of the DNS is such that replying not found never costs less than directly stating that it will stay unknown at least for the whole day. I am merely thinking of terms of intent. [...] So only as an rhetorical example, what was tana.it intent by declaring DKIM=UNKNOWN? Hm... I'm not sure how layer logic applies to that reasoning. A default is a value; discriminating whether it was explicitly given or assumed resembles Terrell's ternary logic, holding that a bit has three values http://tools.ietf.org/html/draft-terrell-math-quant-ternary-logic-of-binary-sys ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket 23 -- l= and Content-type
On 01.05.2011 14:13, John R. Levine wrote: I don't think we actually understand all the ways that l= allows you to shoot yourself in the foot, so I would prefer not to give the impression that if people avoid a few cases we describe, they're safe. -1, I agree we don't know all the ways DKIM can be fooled. Neither we actually saw real attacks in the wild. We don't even state how to react to multiple Froms. Presumably, the wider the DKIM deployment, the more we'll learn on handling attacks. However, hiding the few things we know doesn't seem to be a good start toward such watchful cooperative deployment. The message should be don't use l= if you care about your signature. I mostly agree on that. However, the way it is stated in version -09, it may be overlooked. IME, your message [1] prompted me to conceive an actual example, which in turn makes me want to amend my signer's configuration. Thus, I believe the current text requires some extra diligence to have the desired effect. [1] http://mipassoc.org/pipermail/ietf-dkim/2011q2/016002.html I don't think we yet have consensus to take out l= but it is quite clear that the problems it causes are far greater than whatever problems it might solve. As Hector notes, it is required by non-DKIM aware MLMs. The point is that relaying MTAs seldom know whether the target is a MLM, let alone whether DKIM-aware. Perhaps reasoning should go like this: Let's assume we can sign according to the target, then what would we do with a non-aware MLM? If the answer is to avoid signing in such cases, then omitting l= and letting the signature break is just equivalent --except for aesthetic considerations... Please consider the environment before printing the header of this e-mail ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity
On 01.05.2011 10:38, Hector Santos wrote: Again, its about protocol consistency. So maybe I should ask the chairs for: Consensus needs to be reevaluated IMHO, it needs not: It is premature to define an ODID now. ADSP is considered somewhat broken, and for this message, for example, it seems that the relevant id should be mipassoc.org rather than tana.it. ODID would risk to be a candidate for removal like AUID. From an engineering POV, policy developments are closely related to the verification software, as a matter of facts, so that cleaning up the definition of the interface between them doesn't seem to be urgent. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket 23 -- l= and Content-type
On 01/May/11 06:18, John R. Levine wrote: What's your counter-proposal to Alessandro's proposal to modify 9.1.1? Oh, that. Replace all of sec 9.1 with: As noted in Section 4.4.5, use of the l= tag enables a variety of attacks in which added content can partially or completely changes the recipient's view of the message. I don't think we actually understand all the ways that l= allows you to shoot yourself in the foot, so I would prefer not to give the impression that if people avoid a few cases we describe, they're safe. -1, I agree we don't know all the ways DKIM can be fooled. Neither we actually saw real attacks in the wild. We don't even state how to react to multiple Froms. Presumably, the wider the DKIM deployment, the more we'll learn on handling attacks. However, hiding the few things we know doesn't seem to be a good start toward such watchful cooperative deployment. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket 23 -- l= and Content-type
On 29/Apr/11 19:56, Dave CROCKER wrote: As for the second part, with or without Content-Type, messing with the message in any interesting way will break the signature. I'm not sure what you mean by second part and interesting way. The change to that security consideration section was meant to warn against the attack that John mentioned, that is: original: DKIM-Signature: d=example.com; h=From:From:Subject; l=17; ... From: u...@example.com Subject: unsigned Content-Type follows Content-Type: text/plain This is signed! changed by attacker: DKIM-Signature: d=example.com; h=From:From:Subject; l=17; ... From: u...@example.com Subject: unsigned Content-Type follows Content-Type: multipart/mixed; boundary=boundary This is signed! --boundary Content-Type: text/plain Now this is the only visible part of the message, the (invisible) MIME preamble is still signed, the original signature is not broken. --boundary-- -- ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output requirements
On 29/Apr/11 19:39, Murray S. Kucherawy wrote: Here’s a more comprehensive proposal for an output summary (excuse the “diff” output): +4.9. Output Requirements + + For each signature that verifies successfully or produces a TEMPFAIL + result, the output of a DKIM verifier module MUST include the set of: + + o The domain name, taken from the d= signature tag; and + + o The result of the verification attempt for that signature. + + The output MAY include other signature properties or result meta-data + for use by modules that consume those results. How about mentioning ignored signatures, e.g., The output MAY include further data, such as properties or result meta-data of any signatures, including ignored ones, for use by modules that consume those results at any stage of the verification process. (Just to make clear that all the SHOULD ignore are not conflicting with this.) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Two issues derived from Ticket #20: signature practices
On 27/Apr/11 21:29, Dave CROCKER wrote: On 4/27/2011 12:17 PM, Murray S. Kucherawy wrote: Actually if we're talking about A-R fields, RFC5451 talks plenty about this. Rather than duplicating advice, we should just refer to it. as long as it's informative rather than normative, that seems entirely constructive. Yeah, the whole INFORMATIVE ADVICE to MUA can be safely replaced by just mentioning RFC 5451. That note has been there since 2006, when draft-kucherawy-sender-auth-header was about version -03. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
On 27/Apr/11 22:18, John R. Levine wrote: We check ADSP every time we run DKIM and see the following policy distribution: 97.98% unknown (including domains not explicitly publishing policy) 2% discardable 0.02% all In my much smaller sample, I see discardable on mail from Paypal, and I could believe that Paypal is 2% of the signed mail they check. But they don't check Paypal messages that pass SPF, which IME is all of them for mailfrom, none for helo. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket #10: public key example -- no change needed
On 27/Apr/11 01:25, John Levine wrote: Whether the name in the DNS record should be brisbane or brisbane._domainkey or brisbane._domainkey.example.org depends entirely on the most recent $ORIGIN line in the master file. If the $ORIGIN is _domainkey.example.org, an entirely plausible scenario, the current text is correct. Thus, the example can be enhanced by adding it: This public-key data (without the BEGIN and END tags) is placed in the DNS, for example using [RFC1035] syntax like this: $ORIGIN _domainkey.example.org. brisbane IN TXT (v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v /RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket #11
On 26/Apr/11 23:50, MH Michael Hammer (5304) wrote: However I suggest adding the usual waffling qualifier: claiming (some) responsibility I think we should drop signed from it, since that's what the entire specification is about in the first place. I think it is better to leave signed in. It is explicit and correct. Could be more explicit: A single domain name that is the mandatory payload output of DKIM and that refers to the identity claiming some responsibility for the message by signing it. (I've left off introduced into the mail stream.) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket #19
On 26/Apr/11 23:13, Dave CROCKER wrote: I think I understand the intent, here, and I'm supportive of the goal. However the text is technically invalid. A DKIM signature has only one meaning, relative to existing, formal specification. Inferring meanings beyond what is defined is very, very far outside of the scope of DKIM and it isn't documented anywhere, including the MLM document. Yes, any possible owner-specific semantics are outside the scope of DKIM. However, the MLM does explore circumstances outside such scope. Perhaps, this can be said explicitly: A signing MLM can make its role apparent by properly choosing the signing domain, SDID, the one used in the d= tag of the DKIM signatures added by the MLM. Recognizing the role of a signer allows to infer implied semantics that are outside the scope of DKIM. Two criteria are as follows: * A signature can be identified as pertaining to an aliasing or resending MLM if the domain-part of the List-Post field matches the signing domain. * When no List-Post field is present, a signature can be identified as pertaining to an authoring or digesting MLM if the list-id-namespace (see [LIST-ID]) matches the signing domain. These spontaneous bindings are assessment-level heuristics whose use is hereby suggested. They are not specified by any currently existing standard, and not required. (I left off that the reputation of the signer will be a more critical data point.) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] FYI: Curious IPR from Yahoo! to DKIM
I'm puzzled by this message http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00447.html Its date is Tue, 26 Apr 2011 09:01:41 -0700 (PDT), and it talks about a submission on 2011-04-10. However, the given datatracker URL (1530) results in a 404 Not Found error, and the mentioned draft- ietf-dkim-base-11 doesn't seem to exist (RFC 4871 appears right after version -10). What the heck do they do? The most recent IPR seems thus to be `920' of January 2008, whose text leaves so much to be desired when compared to, say, the reasonable non-discriminatory terms made explicit by Cisco's or Huawei's IPRs. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Two issues derived from Ticket #20: signature practices
On 27/Apr/11 01:42, John R. Levine wrote: I agree with Dave's changes, +1, and also for Murray's advice of signing A-R fields. However, in such case, the last phrase in Sec 7.2 (INFORMATIVE ADVICE to MUA filter writers) should be changed from To circumvent this attack, verifiers may wish to delete existing results header fields after verification and before adding a new header field. to, e.g., To circumvent this attack, verifiers may wish to delete counterfeit results header fields after verification and before adding a new header field. except that you need to sign Content-Type: if you use l=. However, signing Content-Type affects a signature's robustness, due to the possibility to add/remove quotes from MIME attributes during those rewrites that l= is meant to pass through. Otherwise it's trivial to replace the entire visible contents of the message by changing the MIME section separator, and adding new stuff at the end. Content-Type is not currently mentioned in Section 9.1.1. Addition of new MIME parts to multipart/*. It should. Because it is now the 27th, I dare propose a replacement for that section: If the body length limit does not cover a closing MIME multipart section (including the trailing --CRLF portion), then it is possible to add a new body part without breaking the signature. This possibility can be abused. Depending on the details of the MIME type and the implementation of the verifying MTA and the receiving MUA, this could allow an attacker to change the information displayed to an end user from an apparently trusted source. For example, if a message has a multipart/alternative body part, an attacker might be able to add a new body part that is preferred by the displaying MUA. Appending content to an existing body part can also have surprising effects, as exemplified in the next section 9.1.2. Furthermore, if the top Content-Type does not appear (possibly twice) in the h= tag, then it is possible to replace the entire visible contents of the message by defining a suitable MIME multipart/* and its boundary, so that the signed content appears to only cover a MIME preamble and/or invisible MIME entities. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Section 4.3 Hash method Note
On 26/Apr/11 06:19, Hector Santos wrote: While I agree with your version, if there is anything else to reconsider it would be the last sentence: However, compliant verifiers might not implement rsa-sha1; they will treat such messages as unsigned. That seems to say rsa-sha1 signatures will be ignored independently of a verifier's capabilities. Taking into account Mike's note, I'd limit such behavior to verifiers that (for some reason) cannot do otherwise. However, compliant verifiers who have not enabled rsa-sha1 will treat such messages as unsigned. may better reflect all paths an implementator may take with this note. +1, or even better with Murray's original wording However, compliant verifiers who do not implement rsa-sha1 will treat such messages as unsigned. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Taking responsibility for a message
On 26/Apr/11 07:09, Murray S. Kucherawy wrote:
-Original Message-
From: Dave CROCKER [mailto:d...@dcrocker.net]
So with all that in mind, here's my suggestion for replacing the first part
of
this section:
[...]
o Subject
o Date,
I guess Message-ID is among those structural, not semantic fields.
I concur. However, we miss a field that says an MTA is _knowingly_
breaking whatever signatures may be present.
o To, Cc
o Resent-Date, Resent-From, Resent-To, Resent-Cc
o In-Reply-To, References
o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post,
List-Owner, List-Archive
Does List-Id deserve its own bullet?
I'd actually like to add Authentication-Results because an agent
that wishes to claim that observed authentication meta-data should
become part of the message core certainly should sign such a field,
but that's not worth recycling at Proposed and basically RFC5451
already says that anyway.
It is clear that when DKIM talks about taking some responsibility,
it means it is the MTA as a whole who takes any responsibility, not
the signing agent. Any field semantics might be documented in some
MLM-policy documentation, if there is a need to make it clear /what/
responsibility is being taken.
A-R is peculiar because it is often added by the very DKIM agent.
However, strictly speaking, the field is not added by the signer, but
by the verifier.
More confusion originates from the fact that MLMs keep lots of
original fields, including From. I'd propose to replace the last
phrase in the last paragraph of Section 2.1 Background, so that it
reads something like so, for example:
The DKIM signing specification deliberately rejects the notion of
tying the signing {DKIM 12} domain (the d= tag in a DKIM signature)
to any other identifier {DKIM 12} within a message; any ADMD that
handles a message could sign it, regardless of its origin or author
domain. In particular, DKIM does not define any meaning to the
occurrence of a match between the content of a d= tag and the value
of, for example, a domain name in the RFC5322.From field, nor is
there any obvious degraded value to a signature where they do not
match. An ADMD can thus let an MLM add DKIM signatures to posts
that originated from other domains, thereby asserting some
responsibility for handling them. The exact semantics of the signed
contents is usually documented elsewhere.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Last minute MLM addition (6.8)
Section 6.8 proposes a binding between List-Post and the signing domain:
A signing MLM could add a List-Post: {DKIM 12} header field (see
[LIST-URLS]) using that DNS domain matching the one used in the d=
tag of the DKIM signature that is added by the MLM. This can be used
by {DKIM 12} verifiers or receivers to identify the DKIM signature
that was added by the MLM. This is not required, however; it is
believed the reputation of the signer will be a more critical data
point rather than this suggested binding. Furthermore, this is not a
binding recognized by any current specification document.
Proposed replacement (rewording + List-Id addition):
A signing MLM can make its role apparent by properly choosing the
signing domain, the one used in the d= tag of the DKIM signatures
added by the MLM. Recognizing the role of a signer can be important
for inferring the semantics of any signed content. Two criteria are
as follows:
* A signature can be identified as pertaining to an aliasing or
resending MLM if the domain-part of the List-Post field matches
the signing domain.
* When no List-Post field is present, a signature can be identified
as pertaining to an authoring or digesting MLM if the right part
of the List-Id matches the signing domain.
These criteria are not required, however; it is believed the
reputation of the signer will be a more critical data point rather
than these suggested bindings. Furthermore, these bindings are not
recognized by any current specification document.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: non-ascii header text
On 21/Apr/11 14:25, John R. Levine wrote: Use of A-labels within header fields supporting UTF-8 is a bad idea. Since DKIM is defined on RFC 5322 messages, and 5322 is ASCII-only, no header fields in a compliant message can contain UTF-8. It would be surprising if DKIM supported UTF-8 in the header, since it recommends 7bit encodings for the body :-/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dkim] #4: non-ascii header text
On 16/Apr/11 18:45, Dave CROCKER wrote: The problem with ignoring UTF-8 issues is, of course, that that's no longer acceptable. Would it be acceptable to put some text like the following? Internationalized domain names MUST be represented as A-labels as described in [RFC5890]. NOTE: For experimental use only, domain names MAY be represented in UTF-8 as described in [RFC5335]. or INFORMATIVE NOTE: For experimental use of [RFC5335], domain names are to be represented in UTF-8. jm2c ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ISSUE: Verifiers MUST implement rsa-sha256
Section 3.3 has the phrase Verifiers MUST implement rsa-sha256 Implementers will understand that they can go away with a verifier that does not implement rsa-sha1. Their verifier would then return PERMFAIL for the sha1-signed newsletter in the following informative note. I suggest to clarify this as follows: INFORMATIVE NOTE: Although sha256 is strongly encouraged, some senders of low-security messages (such as routine newsletters) may prefer to use sha1 because of reduced CPU requirements to compute a sha1 hash. MTAs whose verifiers don't implement rsa-sha1 will treat these messages as if they were not signed. In general, sha256 should always be used whenever possible. See also http://mipassoc.org/pipermail/ietf-dkim/2011q1/015464.html (which was written at a time when verifiers were mandated to implement both sha digests.) This change is meant to prevent that kind of misunderstandings. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Work group future
On 03/Apr/11 18:45, Murray S. Kucherawy wrote: I think when it's clear there's no more progress that can be made, you close down and move on. You can always start up a WG later when there's a chance for better progress or new work to be done. Is there a difference between the WG and the mailing list, in this respect? Shutting down the mailing list implies possibly different members whenever a new DKIM WG will be started up. Our outstanding chartered items have been getting nowhere for years. It seems nonsensical to keep it open. I see some agree on this point. And yet, rechartering was discussed withing this WG just one year ago, and the text adjusted so as to meet consensus. Was the charter perceived as a compromise? I, for one, was not 100% satisfied with it, but still preferred to remain in the WG to discuss the parts that I was interested in. Possibly my decision was wrong, because a smaller and more agile WG may have worked better. RFC 2418 considers closed membership for design teams within a WG, but I never actually saw that here. My guess is that the paramount impact that spam has rouses too many people, so that WGs become overpopulated, discussions difficult, and people nervous. Is it so? It's certainly true, but I don't think keeping this WG open in spite of this solves anything. Yes, the horses are out already. However, in general, I'm very interested in learning why spam hasn't been stopped by the IETF, and this sort of WG dynamics seems to be part of the response. (I wasn't in the MARID, I only read about it after the fact.) Thanks for all responses, and my apologies for this OT. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Interpretation, was Open issues in RFC4871bis
On 01/Apr/11 23:08, Murray S. Kucherawy wrote: *2.3**. Identity* A person, role, or organization. In the context of DKIM, examples include the author, the author's organization, an ISP along the handling path, an independent trust assessment service, and a mailing list operator. Besides assessment services, there have been several discussions about operators along the handling path, who sometimes break signatures. I propose to clarify the text that discusses the interpretation, in Section 4.2, by adding a sentence to the fourth paragraph, something like so: Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified. Instead, when a relay alters a message such that any valid signature gets broken, it SHOULD re-identify the message by synthesizing a new Message-ID for it, according to Section 3.6.4 of RFC 5322. Would that help deterring on-the-fly auto-conversions? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
On 04/Apr/11 06:09, John Levine wrote: Another way is to have a dkim tag that specify the header that indicates the stream classification Many ways to kill the same bird. If there is a reason why people aren't able to use a d= domain per stream, I wish someone would explain in simple terms that even a dimwit like me can understand. Attaching multiple meanings to the same datum produces non-orthogonal structures that may result in idiosyncrasies. (If Joe Marketeer's address is jo...@example.com rather than j...@marketing.example.com, he may want to sign with d=example.com irrespectively of the message stream.) As vague as the concept of /message stream/ is, I don't think it is necessary to invent a new header field for it, since the List-Id exists already, and SHOULD be included in the signature according to the current spec. Likewise, there is an auth tag in A-R for the authenticated id. (The only use of such token for unknown domains seems to be in connection with _submission._tcp SRV RRs to devise dictionary attacks.) +1 for softly deprecating the AUID. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Interpretation, was Open issues in RFC4871bis
On 04/Apr/11 18:03, John Levine wrote: Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified. Instead, when a relay alters a message such that any valid signature gets broken, it SHOULD re-identify the message by synthesizing a new Message-ID for it, according to Section 3.6.4 of RFC 5322. Would that help deterring on-the-fly auto-conversions? No, and it would be a bad idea, anyway. I often get two copies of a message, one sent directly to me, one relayed through a mailing list that changed it enough to break the signature. By any normal standard, they're the same message, and it's useful to be able to tell that from the common Message-ID. You often said you don't sort list messages by author... I heard the opposite complaint, about gmail automatically keeping a single copy of list messages based on Message-ID. That poster said: So, the user doesn't know whether moderator disapproved or edited the message. Some moderators put replies to members' questions in edits, so Gmail users don't see such replies to their questions. Apparently, not all lists were made equal. [I]f people were sufficiently aware of DKIM to do what you suggest, they're aware enough to add a new signature which is the right thing to do. Agreed, and I also agree that mailing lists are a minor concern in the current landscape. The MLM document could explicitly dispense mailing lists from obeying the SHOULD quoted above, under suitable conditions --they already remove signatures. It is hard to accept that signatures may break even when the message is not actually changed. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Work group future
On 02/Apr/11 09:08, Hector Santos wrote: I would suggest an aura is present that the job is not done especially when there are still active discussions about removing, deprecating, changing this and that, and there is still a chartered POLICY standard development work item yet not complete. ...and EAI coming up. I agree that the presence of such aura is not a sufficient reason for keeping the WG, and more so if we keep in mind other considerations. At any rate, do we agree that such aura is present or is it just a minority of us who feel it? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-03
On 05/Mar/11 02:02, Jim Fenton wrote: 1. Introduction: The opening paragraph has lost the sense that the signer has to be authorized by the domain owner to apply a signature on behalf of that domain. While the previous draft was a bit too restrictive (implied that the signer had to actually be the domain owner) this version is too loose. For the opening sentence I suggest something like, DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name [RFC1034] for which they are authorized with the message [RFC5322]. +1, although it may be more readable swapping the nouns around with, that is DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating the message [RFC5322] with a domain name [RFC1034] for which they are authorized to do so. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
On 13/Jan/11 18:10, Dave CROCKER wrote: 3. For authentication uses, it's unlikely that the DKIM-Signature header field should be shared, because it is an explicit flag for specific DKIM semantics, including the meaning of a signature. Any other signature scheme is going to have different semantics and will need a different flag for indicating it. Perhaps a few more words on the /spirit/ of the split are in order. I have serious difficulties at grasping it. On the one hand, as a glance to the DOSETA draft confirms, the generalization being sketched seems to be by far more complex than those that a simple porting to HTTP (or similar header/content protocol) requires. The template model introduces an extra degree of freedom whose justification is not obvious. For example, the IANA registry already defines a DKIM-Signature Query Method for the single dns/txt entry. A client service may define additional entries. Yet, the Key Retrieval template offers a different way to achieve a similar effect. Why would we need that? On the other hand, after the endless discussions about the meaning of DKIM signatures, I had started to appreciate the current 1st paragraph of rfc4871bis. Claiming some responsibility obviously alludes to the ability of imposing any policies on the contents originating from controlled servers. Thus, DKIM characterizes _messages_ as-if their contents originated from a direct connection to an ADMD server. Why would client services have to redefine that? I think that if it were possible to design a much much simpler generalization, opinions about the resulting split might be different. To wit, if the only details pertaining to our client service consisted of bindings to RFC 5322, e.g. mandatory fields, then the split could be seen as a simplification. In particular, it would happen to nicely insulate a controversial compliance issue that we discussed recently. jm2c ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DOSETA and re-thinking the organization of the DKIM spec
On 11/Jan/11 20:15, John R. Levine wrote: The new docs willuse the CORRECTED rfc4871bis text. Considering how far along we are with rfc4871bis, and keeping mind mind the objections from Jim and others, my inclination would be to finish and publish rfc4871bis as a standalone document, and after that do the DOSETA document that, as I understand it, pulls out components of DKIM and defines interfaces to them as a toolkit. +1, considering that the current rfc4871bis is the result of a merge, publishing the intermediate step before a further split will ease future comparisons (as they won't have to go down to draft records.) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposed documentation split between DKIM and DOSETA
On 07/Jan/11 21:58, Dave CROCKER wrote: Here's the proposal that Barry just announced, for splitting the DKIM specification into a DKIM-specific portion and an underlying, more generic portion that could be re-purposed for other services. It's current working acronym is DOSETA. I'm embarrassed to raise such a trivial issue, but couldn't it be done the other way around? That is, keep the name DKIM for the core spec and invent some other name for its application to RFC 5322. This way * the DKIM-Signature name remains fully justified, * it will be more meaningful for iSchedule to say they use DKIM than to mention DOSETA, and * DOSETA would not have to define a _domainkey keyword that is not part of its title. DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. I'd also s/Mail/Message/ (Messages, Messaging, or similar) in the acronym expansion. Such change may be used to convey the extent of the split. JM2C ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
Like RFC 4871, draft-ietf-dkim-rfc4871bis-02 says 3.3.1. The rsa-sha1 Signing Algorithm The rsa-sha1 Signing Algorithm computes a message hash as described in Section 3.7 below using SHA-1 [FIPS-180-2-2002] as the hash-alg. That hash is then signed by the signer using the RSA algorithm (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. Given that RFC 3447 does not delve in PKCS#1 versions history more than needed, would it be clearer to mention RSASSA-PKCS1-v1_5? JM2P ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ADSP and SPF
On 24/Nov/10 16:46, Ian Eiloart wrote: DKIM and SPF both permit the use of domain based reputation databases. Unfortunately, both have problems with various paths that emails may take. Fortunately, the problematic paths are different - mailing lists are problematic for one, and forwarding is problematic for the other. My point that DKIM and SPF can complement one another therefore relies on an understanding that mailing lists are not forwarders. +1. For different reasons, both ADSP and SPF seem to need a revision. Is there an opportunity to be taken here? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Japan has been set up
Hi Tsuneki, first of all, since I write, let me make my welcome-on-list explicit! On 22/Nov/10 03:43, Tsuneki Ohnishi wrote: Senders in dkim.jp are committed to attach DKIM signature withing 6 months, and possibly ready to write their ADSP discardable. Since we have major ISPs on our member list and they are very willing to discard unveryfied emails, no surprise about it :-), we are trying to inch up to the level where all domestic emails are signed and verified. I hope you'll get replies more qualified than mine... FWIW, I suggest you do not use ADSP that way. But there is a small problem. It is rather political. We have a telecommunication law that allows ISPs to discard forged email, but our Ministry so far does not acknowledge that failure of DKIM verification immediately equals to forgery, because there could be other reasons to fail. IMHO, your Ministry is correct. We can fight about it taking time to get through to dull Japanese bureaucracy, but I think there is a faster way. It is to let senders to have an option to declare that if there is no DKIM signature at all, verifiers can discard those messages. Then we can shut their mouths insisting there could be other reasons. As an alternative, it is the recipients who may eventually decide they are not interested in receiving unsigned contributions to their inboxes, unless they have other means to identify those messages. IMHO, such decision should be made by each recipient individually. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the double header issue
On 09/Nov/10 03:05, John R. Levine wrote: Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. This is OK, but it misses the scenario where a bad guy takes an existing signed message and prepends another Subject: or From: header. It's more effective to address this in the verifier. I'd agree on the effectiveness of that approach from a software design POV only. Designing specifications may involve different considerations... 3. It'd be reasonable for the DKIM spec to remind verifiers that signers aren't supposed to sign stuff like this, so they might consider that when deciding what to do with it after verification. It'd be reasonable to remind them of this particular case. But I think that all ought to be informative text. I don't feel strongly about how normative we make the language, but I do think it would be a good idea to encourage verifiers not to say the signature is valid on a message with extra headers, even if it mechanically verifies. This catches both the sloppy signer and the hostile intermediary. FWIW, my DKIM verifier has for several weeks rejected anything which has an extra of any of these [omitted] headers: Thanks for putting it that way, John. It makes it easier to clear the issue: I think everybody agrees that DKIM specifications say nothing about rejecting. Therefore, John's software is called a DKIM verifier somewhat improperly. It /includes/ a DKIM verifier, but also acts as a band-pass message filter. IMHO, strong feelings about this issue come up from misunderstandings about these roles. On the one hand we have a normative definition of the mechanical properties of signatures. On the other hand we want to deal with MTA behavior, since that is the mechanism's semantics. One problem of tackling both topics within the same document is that making normative statements about MTA behavior may result in confusion between semantic validation and mechanical verification. At this point I would rephrase the third paragraph of Murray's Take two for 8.14 Malformed Inputs, as follows: Because of this, DKIM implementations for MTAs are strongly advised to couple with message filters who can complement their MTA's native checks and reject or treat as suspicious any message that has multiple copies of header fields that are disallowed by section 3.6 of [MAIL], particularly those that are typically displayed to end users (From, To, Cc, Subject). A signing module could return an error rather than generate a signature; a verifying module might return a syntax error code or arrange not to return a positive result even if the signature validates according to normative DKIM specification. However, referring to another document --either ADSPbis or draft-kucherawy-mta-malformed-- may allow for stronger and clearer language. For example, setting dkim=fraud in an A-R field would not be confused with broken signatures like dkim=fail (technically pass). ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] FW: New Version Notification for draft-kucherawy-authres-vbr-00
On 08/Nov/10 06:25, Murray S. Kucherawy wrote: Filename: draft-kucherawy-authres-vbr Revision: 00 Title: Authentication-Results Registration For Vouch By Reference Results Creation_date: 2010-11-07 WG ID: Independent Submission Number_of_pages: 7 Abstract: This memo updates the registry of properties in Authentication- Results: message header fields to allow relaying of the results of a Vouch By Reference query. Nice one, Murray! Section 4 (Definition) is ambiguous, though. It says the DNS domain name used to perform the VBR query, but a VBR query takes two domain names. I think mentioning the tag (md, according to the example) would make it clearer. However, why not structure all the available domains? E.g. delivering something like (modified from section A.1) Authentication-Results: mail-router.example.net; dkim=pass (good signature) header.d=newyork.example.com header.b=oINEO8hg; vbr=pass (all) header.mv=voucher.example.net header.md=newyork.example.com where the comment contains the actual content of the TXT record. A machine readable voucher name could be used by clients to learn what vouchers a server trusts. Another item that may need clarification is the positive response given in the definitions of pass and fail. It could be expanded as, say, pass: A VBR query was completed and the vouching service queried gave a positive response. That is to say, it returned a record consisting of strings of lowercase letters separated by spaces, as per section 5 of [VBR]. The added sentence is meant to dispel any question on whether the verifier should attempt to match the text in the RR with the content of the mc= tag in the VBR-Info header field, if any. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the double header issue
On 08/Nov/10 10:20, Barry Leiba wrote: As participant: [...] Proposal: 1. The DKIM spec is responsible for describing the problem in terms of how it relates to signed and unsigned versions of the fields. That's the stuff in 8.14. +1. IMHO, 8.14 may avoid giving any advice, if we are unable to agree on any. However, in such case, I'd recommend to take Julian's suggestion[1] of replacing Comments with From in the note that exemplifies the ugly hack. [1] http://mipassoc.org/pipermail/ietf-dkim/2010q4/014683.html 2. The DKIM spec should probably say that signers need to sign valid messages, and, therefore, SHOULD NOT sign things like this. Text along the line of this might work well: Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. +1. Enforcing some RFC conformance is a task that many MTAs can (optionally) do natively. Perhaps this is an issue about MTA configuration, rather than specifically for the signing module. For example, I'm quite happy that such tweaking occurs before signing, so that the signer signs the revised version. However, since also the verifying filter is invoked after any optional modifications, I've had to enable them for MSA only. 3. It'd be reasonable for the DKIM spec to remind verifiers that signers aren't supposed to sign stuff like this, so they might consider that when deciding what to do with it after verification. It'd be reasonable to remind them of this particular case. But I think that all ought to be informative text. This is again a question of roles. John has (correctly) recommended that verifiers don't tamper with the message content, except for possibly adding an A-R field. However, a DKIM verifier does not /have/ to act as a verifier only. An additional role is the umbrella under which a filter module may discard suspicious messages, suppress unsigned singleton fields that occur more than once, or anything it deems cool. I agree it should be informative, w.r.t. DKIM. 4. We should agree to this or some variant of it, and then move on. This is not meant to satisfy everyone. In fact, it isn't what I'd prefer, if I had my full choice. But it takes care of the problem in a way that I think is sufficient, and allows us to resolve the issue. +1. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the double header issue
On 08/Nov/10 15:52, Hector Santos wrote: Alessandro Vesely wrote: 2. The DKIM spec should probably say that signers need to sign valid messages, and, therefore, SHOULD NOT sign things like this. Text along the line of this might work well: Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. +1. Enforcing some RFC conformance is a task that many MTAs can (optionally) do natively. But DKIM can not make that presumption that is the prevailing nature of many MTAs. At best, it can RECOMMEND that integration DKIM into a mail system that for BEST results, a general filter would address this issue. Yes. If there will ever be an MTA considerations appendix, it may prompt MTA developers to provide for filtering callbacks at the right points. But it can't assume that will be possible as it might mean a software change. Hence the better DKIM software will offer a direct solution that COULD be turned off when the MTA is capable of doing the filter itself. Anything we change in the protocol may imply software changes. For example, OpenDKIM is a package mainly for the Sendmail MTA. It may have or will have a MTA milter to check for RFC 5322 compliance. However, the I believe the software also allows has a DKIM only component that can be used in other MTAs. You don't know if these other MTAs will have the same kind of filter DKIM is expecting in order to have clean results. Yes, the library component of OpenDKIM provides for just DKIM (well, it also has some generic utilities, e.g. for parsing mailboxes.) It works equally well with different MTAs as offline. Now take Alt-N pure C/C++ DKIM API with no tie-ins to any MTA. It has an non-overhead DKIM verifier option that deals this multiple 5322.From issue directly and independently from any other layered requirement. However, that feature makes for more difficult usage. It tells the caller that a given signature failed to verify by delivering a status of DKIM_UNSIGNED_FROM. Now, suppose the caller is a forensic tool, rather than an MTA filter. The tool is interested in knowing whether the signature validates, but it cannot be sure that the reported status was the /only/ problem with that signature. In facts, it'd be better off disabling such verifier option. (And it can be disabled because it is not mandated.) Now for MTA message filters. Why should a DKIM library hide the simple facts and opt for telling them what to do instead? It is quite trivial to count the From fields in the header. A library can provide a function that tells whether a given field was signed by a given signature. Based on such simple facts, a filter may make various decisions. It may turn out that an unsigned From deserves the same treatment as a failed signature, but are we sure that that is the only one option whatever the circumstances? Actually, we haven't observed many occurrences of that attack in the wild. To me, the latter is the best approach for the specification to take. Allow Readers of this document to decide how they will implement DKIM based on the MTA they are using or MTAs they are targeting. However, if that behavior were mandated, it would affect all compliant libraries, forensic tools notwithstanding. I prefer to see a blackbox model for DKIM where its interface points are well defined. Its input was well described with stated boundary conditions and its output is well defined and described with a view on being a feed for possible message filters/handlers. +1. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues (why multiple h= singleton listing is an ineffective hack.)
On 02/Nov/10 22:58, Douglas Otis wrote: On 11/2/10 11:47 AM, Alessandro Vesely wrote: On 01/Nov/10 22:56, Douglas Otis wrote: If big-bank.com asserts a restrictive policy, the relevant author address should make that message fail ADSP verification, since no author domain signature can be found. Apparently, RFC 5617 already provides for multiple author addresses. Section 3 reads If a message has multiple Author Addresses, the ADSP lookups SHOULD be performed independently on each address. Per RFC5322 Section 3.6.2, the From header field may contain a comma separated list of mailbox specifications. Section 3 of RFC5617 does not indicate how multiple From header fields are to be handled. This refers to multiple Author Addresses which may exist within a single From header field. Presumption of RFC5322 compliance is the mistake made in DKIM and ADSP. 50% agreed. This mistake is only in DKIM, IMHO. There remains uncertainty as to which From header field might be selected whenever multiple singleton header fields exist. The uncertainty is not resolved by Section 3 of RFC5617, which again presumes RFC5322 compliance. When there is a conflict in DKIM's bottom-up selection process and a typical display or sorting process using top-down, the presumption of RFC5322 compliance creates an easily exploited DKIM security gap! RFC 5616 actually just says multiple Author Addresses. It does not say that having examined a single From field is sufficient. Although, that is an apparently legitimate inference --if one assumes RFC 5322 compliance-- software that acts that way can still be considered buggy. Multiple listings of singleton header fields in the h= parameter This hack does not address the security concern! It incorrectly presumes the valid signature being exploited is that of a high value domain attempting to protect their recipients from a spoofing attack. It does not presume that. The hack just allows signers to protect from this exploit /if they care/. In order to protect against illicit usage of a domain name by third parties one could use ADSP. The valid signature could easily be that of a large domain that is unlikely blocked. Only proactive policies are able to preclude highly polymorphic botnet attacks. Blocking based upon reputation will not be effective in the case of large domains, or in the case of new domains. You mean the receiving host has a whitelist_from_dkim clause? Yes, in that case the message probably passes even if it fails ADSP. How is this a DKIM error? It has been repeatedly noted that DKIM allows producing poor signatures, and whitelisting signers with such practices is a questionable setting. Nevertheless, it works. If ADSP verification is thorough, the exploit can only succeed when big-bank.com asserts no restrictive ADSP. In such case, yes, the exemplified message may verify. Blame poor signing practices at big-isp.com. Disagree. DKIM verification failed to ensure the presumption of RFC5322 singleton header field compliance. As such, ADSP compliance could be based upon an unseen DKIM signature and an unseen From header field. Here you hypothesize that the ADSP verifier is unable to see all the From fields in the message. That makes this an implementation issue. Tough verifiers see all author addresses. It would not matter whether high-value domains always include multiple singleton header fields in their h= parameter! Since other domains are unlikely affected by From header field spoofing, why require a practice for every other large domain to use this ugly, wasteful, and ineffective hack? Because it protects from this specific attack. A domain does not set h=from:from to protect against abuse of its domain name: It sets it in order to protect its signatures from being spoofed. Admitting a mistake and including explicit checks for multiple singleton header fields in the DKIM verification process properly handles the greater concern. This proper repair will reduce multiple listings of singleton header fields to being an interim solution for an unlikely exploit. IMHO, it is not the proper solution. It changes the design of DKIM so as to include heuristic considerations about RFC 5322 compliance that are not pristine to digital signatures. That would result in fuzzy results and more false positives. I note that the 95% pass shown in http://www.opendkim.org/stats/report.html#mlm_comparison is so low that nobody would discard a message because of an invalid signature. For DKIM to be usable, we should reduce that 5% failure rate, rather than increase it. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 01/Nov/10 22:56, Douglas Otis wrote: On 10/30/10 3:05 AM, Alessandro Vesely wrote: On 28/Oct/10 03:36, Douglas Otis wrote: I'll repeat the example given previously. The multiple listing of a header in the h= parameter can not mitigate exploitation of DKIM PASS results where a valuable domain is prefixed to that of large domain. The large domain is unlikely concerned by possible presence of a pre-pended header field, where their decision not to include multiple listing for a message clearly not compliant with RFC5322. In other words, this leaves DKIM results open to exploitation. From: accou...@big-bank.com From: some...@big-isp.com DKIM-Signature: h=from, d=big-isp.com, ... Besides RFC 5322 compliance, how is this different from a traditional unsigned spoofed From: accou...@big-bank.com? Having just a signature doesn't mean much, and spelling how to match signature and From field is ADSP's job, even in corner cases. [...] ADSP compliance only requires a valid DKIM signature by the Author Domain, as currently defined by DKIM. This does not protect against pre-pended singleton header fields containing a domain that may have a restricted ADSP assertion, even one that always signs with multiple singleton header fields listed in the h= parameter. If big-bank.com asserts a restrictive policy, the relevant author address should make that message fail ADSP verification, since no author domain signature can be found. Apparently, RFC 5617 already provides for multiple author addresses. Section 3 reads If a message has multiple Author Addresses, the ADSP lookups SHOULD be performed independently on each address. Multiple listings of singleton header fields in the h= parameter is an ugly and wasteful hack that offers an incomplete remedy for these selection conflicts. Why ugly hack? You mean from an aesthetic POV? Yes, some bytes are wasted, as usual. Whenever we'll recycle we should fix that. (MIME compliance and UTF-8 header would be valid reasons for v=2, IMHO.) Since it addresses precisely this issue, it is not incomplete in that respect. Note: RFC5322 defines the following singleton header fields: orig-date, from, sender, reply-to, to, cc, message-id, in-reply-to, references, and subject. In the example, a domain being targeted by attacks may assert ADSP discardable and sign with the h= parameter listing multiple singleton header fields. A victim might accept information based upon a valid DKIM signature, only to then be misled by different selections used by the display or sort process. DKIM fails to mitigate the exploitation of a DKIM signature inappropriately considered valid when multiple singleton header fields exist. If ADSP verification is thorough, the exploit can only succeed when big-bank.com asserts no restrictive ADSP. In such case, yes, the exemplified message may verify. Blame poor signing practices at big-isp.com. Only by ensuring DKIM never asserts a valid signature for messages having multiple singleton header fields, can exploitation of a valid DKIM signature status be avoided. Not quite. Big-isp.com may delegate responsibility for the From field to the relevant author, as it seems common practice. Then, one doesn't even need to infringe RFC 5322 to produce a DKIM-valid bait. For the only by part, unaesthetic signing practices _can_ avoid the singleton exploit. If big-isp.com carefully validates the From field, it should also include it twice in the h= tag. Possibly, one might even derive from there a criterion for guessing what kind of signing practices have been applied. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Some responsibility
Rolf E. Sonneveld wrote: I'm not very happy with the introduction of the word 'some' in front of 'responsibility'. The way it is mentioned now is like one can say 'somewhat dead' or 'a bit pregnant'. It involves domains. For comparison with the web, how would we describe the varying degree of responsibility that domains implicitly claim for hosting content on their web sites? A user's bank account page is obviously very different from a blog post... ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 28/Oct/10 03:36, Douglas Otis wrote: I'll repeat the example given previously. The multiple listing of a header in the h= parameter can not mitigate exploitation of DKIM PASS results where a valuable domain is prefixed to that of large domain. The large domain is unlikely concerned by possible presence of a pre-pended header field, where their decision not to include multiple listing for a message clearly not compliant with RFC5322. In other words, this leaves DKIM results open to exploitation. From: accou...@big-bank.com From: some...@big-isp.com DKIM-Signature: h=from, d=big-isp.com, ... Besides RFC 5322 compliance, how is this different from a traditional unsigned spoofed From: accou...@big-bank.com? Having just a signature doesn't mean much, and spelling how to match signature and From field is ADSP's job, even in corner cases. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 25/Oct/10 06:54, Steve Atkins wrote: On Oct 24, 2010, at 9:05 PM, Murray S. Kucherawy wrote: 3) For any header field listed in Section 3.6 of [MAIL] as having an upper bound on the number of times it can appear, include the name of that field one extra time in the “h=” portion of the signature to prevent addition of fraudulent instances. Any attachment of such fields after signing would thus invalidate the signature (see Section 3.5 and 5.4 for further discussion). This works, and is definitely on the right track as it's looking at the specific problem rather than broad 5322 compliance, but feels like a hack workaround by the signer for a problem that's simpler for the receiver to deal with directly. Implementations, e.g. OpenDKIM, may be configured with a list of fields-to-sign, rather than the exact content of the h= tag. Thus, such a signer can double the occurrence of singleton fields as part of DKIM-Signature creation. Or it can slightly improve its configuration grammar in order to let the user specify when fields are to be bounded by adding an extra instance of their name in the h= tag. We can sprinkle any amount of syntactic sugar on that... I think that, although it may seem simpler to deal with the problem at the receiver's, we've seen it actually is not simpler at all. It is something we can encourage that's strictly within the bounds of a DKIM spec, but that doesn't make it the ideal solution to the problem. Why it's not ideal? Even having to specify From may be felt as a nuisance, since it's mandatory already. Kay Engert's serendipitous reinvention of DKIM, http://kuix.de/spamsalt/, provides for a fixed set of signed header fields: does that make spamsalt less hacky than DKIM? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
On 26/Oct/10 19:08, Murray S. Kucherawy wrote: On Behalf Of Alessandro Vesely On 26/Oct/10 06:58, Murray S. Kucherawy wrote: a verifying module might return a syntax error code or arrange not to return a positive result even if the signature technically validates. -1. How does might differ from MAY? In a bunch of ways. In particular, though, it is deliberately not RFC2119 language, partly because that's not generally done in Security Considerations since that section is discussion (informative) rather than protocol (normative). But it affects the result! That way a verifier is encouraged to determine the validity of a signature based on heuristic criteria. This kind of checking belongs to scam filters a la SpamAssassin. Now, SA doesn't do it. Possibly, that's because it's statistically irrelevant. AFAIK, SA does not even analyze Authentication-Results, but re-checks signatures anew. Why? Suppose one day the double-From attack becomes trendy and SA developers will want to write code that checks for the valid-signature + added-From pattern. They would never be able to use A-R, because those results might be flawed by such non-normative arrangements: This is where that layer violation hurts. According to that text, it is strongly advised to have a scam filter /integrated/ within a DKIM verifier. Doesn't this slash the value of stand alone verifiers and A-R fields? JM2C ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
On 26/Oct/10 06:58, Murray S. Kucherawy wrote: a verifying module might return a syntax error code or arrange not to return a positive result even if the signature technically validates. -1. How does might differ from MAY? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the usual misunderstanding about what DKIM promises
On 23/Oct/10 21:25, Barry Leiba wrote: DKIM makes no statement about the validity of a sender address. DKIM makes no statement about the validity of an Author address. No matter how many times it is stated and repeated, it will never be true. If one wants this to be true, then remove the required binding the Author Address, A.K.A 5322.From. No, not at all. While I think it was probably a mistake to make the signing of ANY header fields MUST (we should have just put From in with the other SHOULD fields), the fact that From MUST be signed says, in itself, nothing about the *validity* of the address (nor the display name) in that field. That's up to the signer. A way to clarify this point is to say /why/ From MUST be signed. For simplicity, I restrict my guessing to two possible reasons: A) From MUST be signed because assuming that h= is not empty may simplify something. The From header was chosen somewhat randomly among fields that would have deserved a SHOULD anyway. B) DKIM mandates signing From in order to pave the way for ADSP. Indeed, ADSP semantics is largely anticipated in DKIM, although not specified in the details. The latter reason would require normative text to guard against double fields in 4871bis, for consistency with RFC 4871's implicit assumptions. IMHO, the new text in Murray's proposal would be easier to understand if reason A, Barry's quoted paragraph above, or any similar informal explanation were also added to the draft. Gmail will sign mail that I send with my old IBM addresses in the From, though I have not worked for IBM for over a year and a half, and no longer have any authorization from IBM to use those addresses. Is that valid? Yes, in the sense that it is what the Author choose. More precisely: The originator fields indicate the mailbox(es) of the source of the message. The From: field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. It doesn't have to be a working mailbox, e.g. nore...@example.com. The responsibility that a signer claims may be delegated, e.g. I make no attempt at all to control my users' From: lines, since I know them all and don't expect them to misbehave. Even syntactical validity checks may be delegated to the Author's client, according to message submission policies. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On 22/Oct/10 18:06, Charles Lindsey wrote: On Thu, 21 Oct 2010 16:17:18 +0100, Alessandro Veselyves...@tana.it wrote: DKIM-Signature: d=Big-IPS.com; h=from; (supposedly)... From accou...@big-bank.com From some...@big-ips.com Subject: Audit notification body of text saying anything In my hypothesis, a verifier would discard the 2nd From accou...@big-bank.com, at least for hashing purposes. If they were both signed, PERMFAIL would result from a mismatch in the header-hash. If Big-Bank had been added after signing, verifiers are already authorized to delete that field from the message, according to the current PS. Isn't that enough? I am am not clear what you are suggesting here. Please clarify. Do you actually want to pass on to the recipient a message that was different (i.e. lacked a header) from what came in. If so -1. That's one possibility. What I have in mind is an MTA filter, not a MUA extension. The same program may be authorized to silently drop whole messages to honor discardable policies, so I don't think it is a desecration to drop a spoofed header field when it finds one. I'd never mandate such behavior, though. It may be made available as an option when users will solicit it, if ever. Or if you are saying that the verifier should hash the first From: (contrary to 4871 with requires it to hash the second), thus triggering a PERMFAIL, then you are indeed getting the right answer, but by some very weird means. I mean first, second in a bottom-up sense. Since the verifier knows there can only be a single From, it hashes empty strings for any further one. Of course, if the verification fails, there is no way to try and discern signed fields... DKIM-Signature: d=Big-IPS.com; h=from; ... From: some...@big-ips.com, accou...@big-bank.com Subject: Audit notification ... (missing Sender) Isn't that already required to have signatures from each, according to 4871? No, the signature isn't tied to the domain in the From field(s). ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On 20/Oct/10 19:48, Douglas Otis wrote: On 10/20/10 7:27 AM, Alessandro Vesely wrote: For example, the initial paragraph of section 5.4 could be modified so as to read: The From header field MUST be signed; that is, it MUST be included at least once in the h= tag of the resulting DKIM-Signature header field, and SHOULD be included twice (see Section 8.14). In addition, the signer MUST ensure that at most one instance of the From field actually exists in the header. [...] Verifiers would then discard any From field after the first one, whether signed or not. While this represents a defensive posture that might be used prior to DKIM reliably returning PERMFAIL when multiple From header fields are contained within the message, it only thwarts half of the threat created by multiple From header fields. As both Charles and I have illustrated: DKIM-Signature: d=Big-IPS.com; h=from; (supposedly)... From accou...@big-bank.com From some...@big-ips.com Subject: Audit notification body of text saying anything This message could be sent directly, or distributed by replaying it to millions of recipients. In my hypothesis, a verifier would discard the 2nd From accou...@big-bank.com, at least for hashing purposes. If they were both signed, PERMFAIL would result from a mismatch in the header-hash. If Big-Bank had been added after signing, verifiers are already authorized to delete that field from the message, according to the current PS. Isn't that enough? Further thwarts can be specified in some ADSPbis, eventually. In particular: DKIM-Signature: d=Big-IPS.com; h=from; ... From: some...@big-ips.com, accou...@big-bank.com Subject: Audit notification ... (missing Sender) Nothing Big-Bank.com might do with their signing mitigates this variant of the double From header field attack. The ONLY sure method is to ensure DKIM always returns PERMFAIL when multiple From header fields are detected, whether both or one of them are signed. I don't think the spec should impose surplus security. The minimal layer violation quoted above might be forgiven after considering the importance of the From field for DKIM. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On 21/Oct/10 17:47, John R. Levine wrote: If Big-Bank had been added after signing, verifiers are already authorized to delete that field from the message, according to the current PS. Isn't that enough? I don't know any DKIM verifier that modifies the message, and I doubt that many people would want to use one. Adding and removing Authentication-Results is probably the most common modification. Removing header garbage may also be fairly popular, dunno. Why do you think it's bad? At any rate, the paragraph I was referring to is The verifier MAY treat unsigned header fields with extreme skepticism, including marking them as untrusted or even deleting them before display to the end user. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] How MUAs render mail
On 18/Oct/10 20:50, Dave CROCKER wrote: There is a premise that is motivating the proponents of giving instructions to MUA designers about DKIM outcomes. The premise is that providing DKIM information will be useful, and possibly that providing /more/ DKIM information will be more useful. (There is also some unfortunate vagueness about the actual meaning of some of this information.) Providing DKIM information /will/ be useful. Only the second part is probably wrong, because a signature cannot do more than validate. As a small example of how peculiar the current line of advocacy is, I'll suggest a simple example: Alice sends Bob a message. Alice diligently signs all the right header fields and all of the body. I think Dave gave a deceptive description on purpose, to check whether we still confuse DKIM and S/MIME. If we're talking DKIM, the subtle difference between author and author domain characterizes the signing. Bob's MUA is sophisticated and up to date, so it displays the message with this extra information about the validity of the message. What is the actual value of this marking, given that Alice is really a spammer? IMHO the goal is distinguishing between two categories of spam, tractable and intractable. More precisely, two categories of /messages/ --DKIM knows nothing about spam. Bob knows that in case he complains he will probably be listened with the diligence that Alice's domain is reputed for: That's the actual value of the marking. Please reply to [domainrep]. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 19/Oct/10 04:55, John Levine wrote: There's a strong correlation between badly structured emails (SMTP, MIME, HTML) and email that the recipient doesn't want to see. You're right, but I think that's largely orthogonal to DKIM. If a message has a good signature from a credible signer, I expect I'd want to show it to the user even if it had structure problems. I'd like to make the trust model as simple as possible, preferably good signature - good message rather than good signature + tidy SMTP + correct headers + unobjectionable HTML + favorable phase of moon - good message +1. That's why I don't think much of Jim's SHOULD language, recommending stiff syntax validation in response to a threat whose only known trait is technical feasibility. Verifiers are already authorized to react with extreme skepticism. We can better their diagnostic capabilities, but cannot recommend a therapy that we never tried. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] yet more sophistry, was Data integrity claims
On 16/Oct/10 21:24, John R. Levine wrote: Which header fields are essential to protect? How much of the message body is essential to protect? Your questions are noted. Other than the MUST to sign the From: header, the DKIM spec offers the technical latitide to create a totally worthless signature. I don't know anyone who disagrees with that. The spec preludes to a policy in various parts. Another one is in section 6.3 (page 51) where it says If the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader. IMHO, this sentence can be safely dropped. A couple of paragraphs below that, one reads The verifier MAY treat unsigned header fields with extreme skepticism, including marking them as untrusted or even deleting them before display to the end user. This does not specify whether such fields break RFC 5322 compliance. Mark's suggestion to suitably prefix them can be added here, as an explicit indication of /how/ to mark them. IMHO, rising that MAY to a SHOULD or MUST would not be very effective in practice, though. In section 2.6, in item 2 on page 8 [...] I couldn't locate this. For a trivial note, tools.ietf.org doesn't seem to respond properly. It does: # curl -vO http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis * About to connect() to tools.ietf.org port 80 (#0) * Trying 194.146.105.14... connected * Connected to tools.ietf.org (194.146.105.14) port 80 (#0) GET /html/draft-ietf-dkim-rfc4871bis HTTP/1.1 User-Agent: curl/7.17.1 (i586-pc-mingw32msvc) libcurl/7.17.1 OpenSSL/0.9.8b zlib/1.2.3 Host: tools.ietf.org Accept: */* HTTP/1.1 302 Found Date: Mon, 18 Oct 2010 08:43:09 GMT Server: Apache/2.2.16 (Debian) Location: http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-02 But then it delivers an empty document for that location: # curl -vO http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-02 * About to connect() to tools.ietf.org port 80 (#0) * Trying 194.146.105.14... connected * Connected to tools.ietf.org (194.146.105.14) port 80 (#0) GET /html/draft-ietf-dkim-rfc4871bis-02 HTTP/1.1 User-Agent: curl/7.17.1 (i586-pc-mingw32msvc) libcurl/7.17.1 OpenSSL/0.9.8b zlib/1.2.3 Host: tools.ietf.org Accept: */* HTTP/1.1 200 OK Date: Mon, 18 Oct 2010 08:43:25 GMT Server: Apache/2.2.16 (Debian) Content-Location: draft-ietf-dkim-rfc4871bis-02.html Vary: negotiate TCN: choice Last-Modified: Mon, 11 Oct 2010 22:32:20 GMT ETag: 15d10aa-0-4925e0500;492e02b528300 Accept-Ranges: bytes Content-Length: 0 Content-Type: text/html; charset=UTF-8 And in http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-01 there is no mention at all of -02. Why? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 14/Oct/10 20:09, Mark Delany wrote: On Thu, Oct 14, 2010 at 08:01:17PM +0200, Alessandro Vesely allegedly wrote: On 13/Oct/10 20:45, Scott Kitterman wrote: On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote: If we can extract DKIM from the equation entirely and the problem remains, how is it a DKIM problem? If the DKIM signature doesn't verify after signed headers have been altered, then it's not. Correct. And the way that it fails to verify is h=from:from. Which strikes me as an ugly hack. Given that most headers should only occur once and given that a lot of signers sign most headers doesn't this suggestion degenerate to h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id? Yes, it does. The only question is to devise normative statements correctly, e.g. MUST duplicate From, SHOULD duplicate the rest. This is _not_ a kludge. It is how DKIM signing works (Section 5.4). Are we worried about wasting 100~200 bytes per signature? (I get ~4Kb headers nowadays, so that is about 3% of it.) Introducing an abbreviation --e.g. an h2 tag-- is considerably clearer from an algorithm developer's POV. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 15/Oct/10 17:13, John Levine wrote: In article201010151013.26823.ietf-d...@kitterman.com you write: On Friday, October 15, 2010 10:04:40 am MH Michael Hammer (5304) wrote: why don't we just deprecate l=? Yes. Please. Agreed. Has anyone ever found it useful for its nominal purpose of messages transiting MLMs? For me, it works as advertised: I can verify my own messages when they come back from a list that just adds footers. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 15/Oct/10 18:59, Jim Fenton wrote: On 10/15/10 2:12 AM, Alessandro Vesely wrote: Fuzziness stems from the fact that a signature on a given message may either verify or not depending on how meticulously the verifier interprets that SHOULD. The MUST immediately following it is deceptive because it conveys the false impression that a signature is REQUIRED to fail in case a particular header field is added after signing. Because of the SHOULD, existing verifiers can still be considered compliant. Thus, it may still make sense for a signer to still put h=from:from. Why did Jim remove that advice? I wanted it to be clear that it's the verifier's job to detect the duplication, not the signer's job to work around the problem. Recall that SHOULD means, roughly Do it unless you have a valid reason not to, and have considered the implications. The implications are that instead of having a signature that is either valid or not we'll have signatures that verify according to a variable percentage of existing verifiers, as it is for virus detection. Why not mandate to fail verification if the signed body contains a virus? To clarify, I'm not against changing DKIM. However, if we do, we better integrate the change in the original design. First of all, it should be in section 5.4. Second, it has to be an explicit list of header fields, rather than generic references to RFC 5322, RFC 2919, etcetera. Third, the spec should state that any repetition of such fields in the h tag, e.g. h=from:to:from:to, has to be regarded as a backward compatible guard, and new implementations must discard duplicated names retaining their first occurrence only. Then, it can derive the implication that signers cannot produce a valid signature of a message whose header actually contains multiple instances of any listed field... Lots of work and some semantic change... Besides, as Mark Delany said yesterday, having to do h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id strikes me as an ugly hack. But then the whole DKIM-Signature is an ugly hack :-) MUAs often disallow writing a From with multiple mailboxes, thus a sender may happen to end up with two From fields after hacking in an attempt to recognize authorship to a second mailbox. Are you saying that there are MUAs that disallow a From: with multiple addresses, but support the addition of multiple From: header fields? If so, I hope it's not a popular MUA that's doing this. One can always find ways or extensions to add /any/ header field more easily than for modifying existing ones. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 14/Oct/10 00:22, Jim Fenton wrote: Insert prior to current section 6.1.2 (which becomes 6.1.3, etc.): 6.1.1 Validate the Message Syntax The verifier SHOULD meticulously validate the format of the message being verified against the requirements specified in [RFC5322], [RFC2045], and [RFC2047]. In particular, limitations on the number of occurrences of particular header fields specified in [RFC5322] section 3.6 SHOULD be verified. Messages found to be in violation of these checks MUST return a PERMFAIL (message syntax error) verification result. -1 If we go for changing the protocol in order to avoid the exploit, we should explicitly enumerate the header fields whose duplication verifiers MUST check. SHOULD meticulously validate + MUST return PERMFAIL make for a fuzzy protocol. The spec should also state whether duplicated fields invalidate a signature even when they are duly signed. Finally, it does make sense to duplicate fields in h= as stated in -02's 8.14, because that's the only way to guard against the exploit in case the destination's verifier is coded according to the previous protocol version. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
