Re: [ietf-dkim] double header reality check
On Wed, Oct 20, 2010 at 09:38:04PM -0700, Murray S. Kucherawy allegedly wrote: -Original Message- From: John R. Levine [mailto:jo...@iecc.com] Sent: Wednesday, October 20, 2010 5:08 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] double header reality check Here's maybe a better way to frame the question: Should we empower ourselves to label a DKIM implementation that doesn't do format enforcement as (a) non-compliant, or (b) low-security/low-quality? The latter. Hey, we agree. I think I always said SHOULD rather than MUST. Damn, lost it. I think we should talk about it, and even in detail, but without using those words. And I'd be fine converting the MUA advice to which you refer into something more general, like hammering home the point about what exactly a validated signature is telling you, and leave it to the implementers of those modules to figure out what to do with that information. It's stating the obvious by now, but I'm with (a). While it might be technically elegant to delegate (a) to another layer or some magic sauce, or some informative text, it misses the bigger picture. That bigger picture is that DKIM has no certainty of success simply by being a technically neat and layer-compliant protocol. DKIM will succeed only if it is picked up and used by a vibrant and wide-spread community of DKIM consumers - MUAs, list servers, reputation systems, email appliances, whatever. Given the well-recognized inertia in the email biz, to maximize our chance of success, we need to make it as easy as possible for this new community of DKIM consumers to succeed. To my mind that means that those consumers can write no-brainer code and reap the benefits of DKIM. So, every time we relegate or delegate parts of DKIM compliance to those consumers - perhaps by way of informative text about 2822 compliance - we are simply creating barriers for the very consumers that we need to make DKIM a success. Are we so confident about DKIM adoption that we feel we can effectively order this future community to do this sort of work? I for one am not. I for one think that if we make DKIM as easy as possible to consume and we market the heck out of it, we may, we just may succeed in wide-spread adoption, maybe. So, forget technical elegance. Forget layering violations. What are we doing that makes DKIM compelling and easy to consume? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
--On 20 October 2010 15:42:32 -0700 Douglas Otis do...@mail-abuse.org wrote: But, hey, I'm on your side here. I think we should put a warning in the RFC so that vendors are informed that they need to be sure they're highlighting the correct header. Why? There would not be a problem when DKIM verification results return PERMFAIL when there is any doubt which From header field might be selected when more than one exists. Well, that would be even better. But that's a change to the spec. If the spec were changed, I'd be happy about that. In the mean time, we need to warn implementers about the security risks that we've identified. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ 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 Wed, 20 Oct 2010 15:27:16 +0100, Alessandro Vesely ves...@tana.it wrote: On 20/Oct/10 13:23, Charles Lindsey wrote: The scam I have described involves the use, by the phisher, of a DKIM-signed (by himself) email with two From: headers, which is intended to fool verifiers into not spotting that the first signature should have triggered an ADSP lookup which would have revealed that the first From: was 'discardable'. Naturally, the phisher signs with a throaway domain that has not yet acquired any reputation, good or bad. Since the scam involves the use of DKIM, and since the only fix I am aware of requires a change to the DKIM standard, then it is highly relevant to the current discussion. IMHO, this issue has to be addressed refining the signing spec. For example, the initial paragraph of section 5.4 could be modified so as to read: But that does not address this particular scam (though it does address some other scams involving duplicated headers). Notice that in my scam it is the Bad Guy that generates the signature, and you cannot assume that a Bad Guy will obey ANY requirement imposes by 4871-bis if he believes that generating a message thsat violates that requirement will enable him to fool somebody of some sysyem somewhere. Verifiers would then discard any From field after the first one, whether signed or not. Of course, a combo-verifier is always free to return some error due to bad message syntax, even if all signatures verify (although I'd consider it cleaner to return non-DKIM errors for non-DKIM failures.) Yes, verifiers are the only place where this scam can be caught, and they must be mandated to catch it. The precise means of catching it can be discussed, and whether they catch it on the grounds that 5322 has been violated or on the grounds that some other provision of 4871-bis has been violated is just a matter of semantics. If it makes people happier to word it so that it is not perceived as a layering violation then I suppose making it appear as a 4871-bis violation would be better; but I do not really like technical solutions being dictated by purely political arguments. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Wed, 20 Oct 2010 18:32:44 +0100, John R. Levine jo...@iecc.com wrote: A reputation service can only say that a domain is BAD GOOD or NO EVIDENCE AVAILABLE EITHER WAY. I think the last case has to be treated pretty much like GOOD, otherwise newcomers to the internet will never even get their messages accepted. Heck, no. Treat it like there's no signature at all, and filter it like one does now. So if I (being a perfectly honest citizen) create some brand new internet service, which needs to be secure; and if I secure it by signing all emails sent to my clients plus declaring an ADSP policy of 'discardable', then you want all messages sent to my clients on day 1 of the service to be discarded at my clients' boundaries because, not yet having established any reputation, my messages are to be treated as unsigned, and hence discarded in accordance with my ADSP setting And it the reputation services discover that all mails sent from my domain are being discarded, they will start to create a Bad reputation for me, instead of the Good one that I hoped to acquire as my new service became known. No, lack of reputation has to be treated as entirely neutral. Bad reputations have to be earned by performing Bad deeds. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ 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] I-D Action:draft-ietf-dkim-mailinglists-04.txt
On Oct 16, 2010, at 9:36 AM, Alessandro Vesely wrote: *scope* Apparently, there is consensus that Discussion lists and broadcast lists are not the same thing [WV]. Section 3.2 exemplifies newsletters and bulk marketing mail as authoring MLM modes. In facts, most of the advice covers mailing lists proper. Should ESP-lists be removed from the I-D entirely, e.g. by saying they are not covered right after their definition? I think it's important to point out the differences. ___ 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
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. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly smime.p7s Description: S/MIME Cryptographic Signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] More on layer violations
Having pondered the layer thing some more, it occurs to me that we have several decades of practice with software that validates the format of mail messages to a greater or lesser extent, with the emphasis on lesser. Different software depends on different bits of the message to be correct, which means that some leakage of the message validation into different applications is unavoidable unless you're willing to lose mail that has flaws that don't matter to the applications that it passes through. In procmail, for example, doubled subjects only matter if you have a rule that does something depending on the subject line. In MUAs, based on the random way existing MUAs handle them, they don't matter at all. So that's where my SHOULD NOT comes from. It leaks the bit that matters to DKIM. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ 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] More on layer violations
-Original Message- From: John R. Levine [mailto:jo...@iecc.com] Sent: Thursday, October 21, 2010 9:07 AM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: More on layer violations Having pondered the layer thing some more, it occurs to me that we have several decades of practice with software that validates the format of mail messages to a greater or lesser extent, with the emphasis on lesser. Different software depends on different bits of the message to be correct, which means that some leakage of the message validation into different applications is unavoidable unless you're willing to lose mail that has flaws that don't matter to the applications that it passes through. In procmail, for example, doubled subjects only matter if you have a rule that does something depending on the subject line. In MUAs, based on the random way existing MUAs handle them, they don't matter at all. All true. But those are implementations, not specifications. You can add OpenDKIM to that list. Like I said, it already does do the validation, but that's because RFC5322 says so, not because RFC4871 says so. And I think that's the way it should stay. Take a tour through the eleven parts of Section 7 of RFC5451, and then Appendices A and C. They provide all kinds of warnings about misinterpreting the data provided, which amounts to pretty firm implementation advice, and identifies ways you can shoot yourself in the foot. But none of those sections are normative. (Actually there are two SHOULDs in 7.4, but in retrospect they shouldn't really be there.) That's what I'm advocating here: The normative stuff defines the core mechanics of the protocol itself, and the informative stuff explains why it's done that way, detailed implementation advice including stuff about other layers, and how one should (and shouldn't) interpret the output. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] More on layer violations
On Oct 21, 2010, at 9:53 AM, Murray S. Kucherawy wrote: Take a tour through the eleven parts of Section 7 of RFC5451, and then Appendices A and C. They provide all kinds of warnings about misinterpreting the data provided, which amounts to pretty firm implementation advice, and identifies ways you can shoot yourself in the foot. But none of those sections are normative. (Actually there are two SHOULDs in 7.4, but in retrospect they shouldn't really be there.) That's what I'm advocating here: The normative stuff defines the core mechanics of the protocol itself, and the informative stuff explains why it's done that way, detailed implementation advice including stuff about other layers, and how one should (and shouldn't) interpret the output. +1 Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] More on layer violations
-1. This is not a LAYER violation. DKIM is a protocol for RFC 822/2822/5322 data to: a) verify a message signature, and/or b) create a message signature. In order to do either requires INPUT that MUST be valid for the protocol to be fundamentally correct with its OUTPUT. Therefore it MUST make sure its input is 100% valid. This is not different than any function generator that checks its boundary conditions. A robust function generator MUST check its input otherwise you have faults, chaos, aborts, GIGO - Garbage In, Garbage Out. DKIM is fundamentally a security protocol and it will be insane to believe that it should allow GIGO to occur due to not checking it input validity. A Layer Violation is when you are asking for data bits that in 821/2821/5321 (or another our feed) and/or also producing BITS that other layers like a MUA might use. We are not doing the former but would be if we bind bits like a Return-Path. We are differently doing the latter with the creating of more bits for other LAYERS to use. DKIM validating its INPUT is not a layer violation and in practice, it will be extremely bad product engineering. In fact, I would go as far to make it an ethical engineering responsibility for ALL DKIM components to make sure its not a GIGO engine. Now, if that doesn't jive with the IETF DOCS well, thats an entirely different issue. Most implementators are not going to GAS (Give a S$$$) what that docs says or doesn't say if it not providing what is fundamentally necessary. The DKIM component MUST check its input and at least one independent API has done so (on the verify side for 5322.From only). It could not pass the buck to 822/2822/5322 message generators or verifiers. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Murray S. Kucherawy wrote: You can add OpenDKIM to that list. Like I said, it already does do the validation, but that's because RFC5322 says so, not because RFC4871 says so. And I think that's the way it should stay. Take a tour through the eleven parts of Section 7 of RFC5451, and then Appendices A and C. They provide all kinds of warnings about misinterpreting the data provided, which amounts to pretty firm implementation advice, and identifies ways you can shoot yourself in the foot. But none of those sections are normative. (Actually there are two SHOULDs in 7.4, but in retrospect they shouldn't really be there.) That's what I'm advocating here: The normative stuff defines the core mechanics of the protocol itself, and the informative stuff explains why it's done that way, detailed implementation advice including stuff about other layers, and how one should (and shouldn't) interpret the output. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] More on layer violations
On Oct 21, 2010, at 11:01 AM, Steve Atkins wrote: On Oct 21, 2010, at 9:53 AM, Murray S. Kucherawy wrote: Take a tour through the eleven parts of Section 7 of RFC5451, and then Appendices A and C. They provide all kinds of warnings about misinterpreting the data provided, which amounts to pretty firm implementation advice, and identifies ways you can shoot yourself in the foot. But none of those sections are normative. (Actually there are two SHOULDs in 7.4, but in retrospect they shouldn't really be there.) That's what I'm advocating here: The normative stuff defines the core mechanics of the protocol itself, and the informative stuff explains why it's done that way, detailed implementation advice including stuff about other layers, and how one should (and shouldn't) interpret the output. +1 +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] How MUAs render mail
On 10/19/2010 3:11 AM, Ian Eiloart wrote: It's that, in order to get the marking, she can't spoof a trusted person's sender address. DKIM makes no statement about the validity of a sender address. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] FIX THE (DOC) PROBLEM!
That is a different issue all together. We are talking about a security threat that fell through the cracks during the RFC 5016 production in this group. It MUST be corrected - pronto, not later, not in another I-D, not in another WG. No - in 4871bis. It is rather tiring to seeing the rationalization on how to try to avoid not directly talking about the security loophole and resolution. Whether its MUST, SHOULD or it should not do anything and pass the buck to a lower layer. That is all nonsense. While in an integrated environment, you have all sorts of ways to resolve this, a DKIM is an independent RFC 5322 Protocol Technology - therefore it inherent all the design requirements to make sure that GIGO (Garbage In, Garbage Out) does not occur. Lets fix the DOC BUG and be done with it - thats forward progress. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com J.D. Falk wrote: On Oct 21, 2010, at 11:13 AM, John R. Levine wrote: 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. That's an example of the bad advice that I think we should drop from 4871bis. It does nothing to improve robustness or interoperability, just offers unsolicited advice to MUA developers. As this conversation has continued, I'm increasingly convinced that the only sane path forwards is to have a separate Informational or BCP document containing MUA considerations. The only question is whether that'd be restricted to considerations we've discovered while discussing DKIM (in which case it might fit in this WG), or open to all the stupid MUA tricks this community has seen since rfc733 (which should probably be a new WG.) Either way, I'd be interested in participating in the effort. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ 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
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of SM Sent: Tuesday, October 19, 2010 2:19 PM To: ietf-dkim@mipassoc.org Subject: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02 Hello, I commented on draft-ietf-dkim-rfc4871bis-01 previously ( http://mipassoc.org/pipermail/ietf-dkim/2010q4/014696.html ). draft-ietf-dkim-rfc4871bis-02 obsoletes RFC 4871. RFC 5672 updates RFC 4871. Why is the RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update document not being obsoleted by this document? That sounds right to me. In the Introduction Section: 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. Dave proposed a change to add a RFC 1034 reference in that sentence. DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message [RFC5322] by associating the domain name [RFC1034] with the message. I suggest adding a reference to RFC 5322 in there to make it clear what message is. I forget; does the email architecture document talk about the difference between a DNS domain and an ADMD? This was an issue during the IESG evaluation of Authentication-Results and I seem to recall it being a place to which readers could be referred to learn the difference. Maybe changing domain to DNS domain would be appropriate, and also changing the RFC1034 reference to point at RFC5598? As I mentioned previously, in Section 3.3: In general, sha256 should always be used whenever possible. That text was in RFC 4871 too as part of the informative note. Could it be removed to avoid any dilution of the SHOULD in the Signers MUST implement and SHOULD sign using rsa-sha256 sentence? The OpenDKIM stats shows that SHA1 is still in very widespread use, both by domain counts and by aggregate message counts. Trying to force DS to talk only about SHA256 would mean alienating half or more of the current install base, and we felt that was probably a bad idea. In Section 3.3.3: The practical constraint that large (e.g., 4096 bit) keys may not fit within a 512-byte DNS UDP response packet Could a normative reference to RFC 1035 be added in that sentence? The practical constraint that large (e.g., 4096 bit) keys may not fit within a 512-byte DNS UDP response packet [RFC1035] Seems reasonable to me, though I don't think it needs to be normative since that text is discussion rather than protocol specification. I'll mention it again; in Section 3.5 for the d= tag: Internationalized domain names MUST be encoded as described in [RFC3490]. And i= tag: Internationalized domain names MUST be converted using the steps listed in Section 4 of [RFC3490] using the ToASCII function. Is there a reason why this working group requires that a document with an intended status of Draft Standard should have a normative reference to a RFC that has been obsoleted? I can't remember the disposition of this, but I think the problem is that we want to use ToASCII while no current (i.e. not obsolete) document contains a definition of it. I seem to recall one of the other co-authors looking into it and finding this was acceptable, but I don't recall. Dave, can you comment? In Section 5.3: Similarly, a message that is not compliant with RFC5322, RFC2045 correct or interpret such content. I do not understand that sentence. XML error. Dave already posted what that was supposed to be. Therefore, a verifier SHOULD NOT validate a message that is not conformant. That sounds like good advice. According to draft-ietf-dkim-implementation-report-03, the interoperability and testing event was held in 2007. Was the above requirement tested during that event? If this working group wants to add such a requirement, I suggest setting the intended status of draft-ietf-dkim-rfc4871bis to Proposed Standard. I don't recall it being tested specifically. And I don't have a good sense about whether the addition of this normative requirement would require a recycle or not. I defer to those more experienced than me. In Section 5.5: Verifiers MUST be capable of verifying signatures even if one or more of the recommended header fields is not signed (with the exception of From, which must always be signed) Is the last must a requirement? No, I think it's simply an informative back-reference to another specified requirement. Maybe changing must always to always has to would clear that up. draft-ietf-dkim-rfc4871bis has an informative reference to RFC 5451. I note that the draft uses the X-Authentication-Results header field line. Yes, that should be
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
Is there a reason why this working group requires that a document with an intended status of Draft Standard should have a normative reference to a RFC that has been obsoleted? I can't remember the disposition of this, but I think the problem is that we want to use ToASCII while no current (i.e. not obsolete) document contains a definition of it. I seem to recall one of the other co-authors looking into it and finding this was acceptable, but I don't recall. Dave, can you comment? I suggest the two places that refer to IDNS say Internationalized domain names MUST berepresented as A-labels as described in [RFC5891]. That's a current standard, and A-labels are what ToASCII was supposed to produce. R's, John ___ 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
I suggest the two places that refer to IDNS say Internationalized domain names MUST berepresented as A-labels as described in [RFC5891]. That's a current standard, and A-labels are what ToASCII was supposed to produce. That's a technical change to the DKIM Signing specification. Plus, it 'fixes' a problem that has not yet been reported for DKIM. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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
RFC 3490 is obsolete, replaced by 5890 and 5891. When they rewrote it they made the language descriptive rather than prescriptive, and an A-label is the new name for what was the output of ToASCII. My understanding is that they actually changed the behavior of the 'subroutine'. Nothing in the switch to 5322 from 2822 changes any behaviors for DKIM. Of course it does. The message syntax in 5322 is ever so slightly different from 2822, so the set of valid messages over which DKIM is defined is slightly different, too. It didn't change very much, but 5890 didn't change very much either. It mostly tightened up rules for rejecting invalid input, got rid of dependencies on a particular version of Unicode, and fixed a few arcane bugs. The toAscii routine still works for us. Sort of. IDN2008 handles more recent versions of Unicode than IDN2003 does and allows some joiner characters that IDN2003 ignored, so ToAscii willl fail on some valid current IDNs. I see that on the IDNA list they're arguing about this exact issue for a revision of http cookies, so I guess that whatever they do, we can do. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly smime.p7s Description: S/MIME Cryptographic Signature ___ 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
Hi Murray, At 13:48 21-10-10, Murray S. Kucherawy wrote: That sounds right to me. It does not sound right to me. I forget; does the email architecture document talk about the difference between a DNS domain and an ADMD? This was an issue during the IESG evaluation of Authentication-Results and I seem to recall it being a place to which readers could be referred to learn the difference. Maybe changing domain to DNS domain would be appropriate, and also changing the RFC1034 reference to point at RFC5598? A proper comparison of the two requirea more than one sentence. I'll keep it short; ADMD is about administrative authority whereas a DNS domain is of a list of labels. The reference to RFC 1034 is a pointer for the reader to find out what is meant by domain name. When we talk about domain names, as in DNS, we refer to specifications about DNS. If the question comes up in an discussion about email (within the IETF), consideration is given to whether it is about email delivery or about the domain name space and resource records; and the discussion is punted to the appropriate group. Changing the reference to RFC 5598 may cause problems in other parts of the draft. The OpenDKIM stats shows that SHA1 is still in very widespread use, both by domain counts and by aggregate message counts. Trying to force DS to talk only about SHA256 would mean alienating half or more of the current install base, and we felt that was probably a bad idea. Maybe I did not explain what I meant correctly. I am not arguing for the document to talk only about SHA256. I'll quote the text from Section 3.3: DKIM supports multiple digital signature algorithms. Two algorithms are defined by this specification at this time: rsa-sha1 and rsa- sha256. Signers MUST implement and SHOULD sign using rsa-sha256. As you can see, there is a SHOULD for signing using rsa-sha256. Signing with rsa-sha1 is not forbidden. I am not in favor of alienating half or more of the current install base. Seems reasonable to me, though I don't think it needs to be normative since that text is discussion rather than protocol specification. That text is not normative. Having the reference as normative means please read the following document to understand what is written in this document. I can't remember the disposition of this, but I think the problem is that we want to use ToASCII while no current (i.e. not obsolete) document contains a definition of it. I seem to recall one of the other co-authors looking into it and finding this was acceptable, but I don't recall. Dave, can you comment? It would be highly unusual to use such a reference. I will most likely nit about that. I don't recall it being tested specifically. And I don't have a good sense about whether the addition of this normative requirement would require a recycle or not. I defer to those more experienced than me. The addition of the normative requirement would complicate matters. I mentioned the recycle as it would keep matters simple. It would be premature to determine which status is the most appropriate. No, I think it's simply an informative back-reference to another specified requirement. Maybe changing must always to always has to would clear that up. That's fine. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Commments and clarifications to 4871bis-02
I've gone through 4871bis-02 again to look for sections that don't deal with correctness, robustness, or interoperability and have some suggested changes. I also noticed a few editing nits on the way. None of this is intended to be contentious, or to change any of the bits on the wire. Overall: in several places such as the informative note at the top of page 18, the language says that the verifer produces an edited version of the message. We either should say that the edited message is part of the verifier's output, probably in section 2.2, or delete the editing language. I'd suggest the latter. Page 11, informative operations note at the end of section 3.1: Either change to Signers SHOULD NOT reuse a selector with a new key or delete it. Page 11, informative implementation note at the bottom of the page: Delete it. If we want to support EAI, we should support EAI, but this language just encourages code that won't interoperate. Page 13: section 3.3: should it also say Verifiers MUST implement both sha1 and sha256? It says so on page 20 in a= and page 30 in h=, but I think this is a better place to put it. Page 13, informative note at the bottom of the page: Delete. I realize that people still use sha1, so we should document it, but is there any reason to encourage it. Page 14, sec 3.3.3, first paragraph. I don't understand what this pp is telling me to do. In the second sentence, what does for long-lived keys mean? A week? A decade? And what's the life of the key? The time from when it's published in the DNS until it's deleted? The time that signers use it, regardless of time in the DNS? Suggest trimming this down to say signers MUST use at least 1024 bits, verifiers MUST handle 512 to 2048 bits, and leave it at that. If we think a 512 bit signature is no good, we should say so. Page 17, informative implementation note at the top: Delete message editing language or remove text that appears after the specified content length, perhaps based on other criteria Page 17, second informative informative implementation note in the middle: suggest deleting the whole thing. It's a recipe for disaster which has not (I hope) ever been implemented. At least not on purpose. Page 20, informative note under v=: Delete. Has a version number ever increased other than arithmetically? Page 22, discussion of d=: Internationalized domain names MUST be represented as A-labels as described in [RFC5891] Page 23, discussion of i=: Internationalized domain names MUST be represented as A-labels as described in [RFC5891] Page 24. first pp: delete or MAY choose other means of representing its users. An AUID need have no relationship to any user. Some of my AUIDs refer to web scripts and mailing lists. Page 24, informative note: suggest deleting, again because AUID need have no relation to any user. Or perhaps rewrite as: INFORMATIVE NOTE: The Local-part of the i= tag is optional. It can include the domain part without the Local-part of the identity. Page 24, informative discussion: delete everything after the second sentence, since it doesn't help robustness or interoperability Page 25, informative implementation warning: remove language at the end of the paragraph suggesting that the verifier can remove text from the body. Page 27, x= first informative note: delete, doesn't help robustness or interoperability. (Neither does x= but that's a lost battle.) Page 28, z= last pp: it says that header fields SHOULD be converted as described in MIME Part Three [RFC2047]. That document describes encoding of specific character sets such as ISO-8859-1. What character set is it supposed to use? Page 28, sec 3.6, second pp: delete, since in fact the only key server we describe is the DNS. If some future document adds other key servers, that would be an appropriate time to add language about them. Page 29, sec 3.6.1, first pp: delete, since it doesn't help robustness or interoperability. Page 29, description of v=, last sentence: compare that to the note on page 20 that I suggested deleting. Page 29, description of g=: address - AUID, in four places. The i= value is an AUID, not an address. Page 30, h=: suggest moving the language about which algorithms a verifier supports to page 13 as suggested above. Page 33, informative operational note: delete it, since the first sentence is wrong, and the second sentence is out of scope. Wildcards work just fine as key records if that's what you want to do. For example, you could publish a wildcard with an empty p= to make all unknown selectors be revoked. Page 35, first pp, last sentence: delete it, or else get rid of l= Page 35, sec 3.8: language about on behalf of its subdomains is confusing since we now say the d= domain is the primary identity. Suggest renaming this section to Subdomains in AUIDs and flip the language around,
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
On 10/21/2010 9:31 PM, SM wrote: I forget; does the email architecture document talk about the difference between a DNS domain and an ADMD? ... A proper comparison of the two requirea more than one sentence. I'll keep it short; ADMD is about administrative authority whereas a DNS domain is of a list of labels. The reference to RFC 1034 is a pointer for the reader to find out what is meant by domain right. I think that clear references and careful use of terminology should suffice. The specification need not be a tutorial on the differences between two technologies or RFCs that it cites. Correct? Seems reasonable to me, though I don't think it needs to be normative since that text is discussion rather than protocol specification. That text is not normative. Having the reference as normative means please read the following document to understand what is written in this document. I am confused. In a technical specification a normative reference provides material that is part of the technical detail. It's not for background or explanation. It is for /use/. I can't remember the disposition of this, but I think the problem is that we want to use ToASCII while no current (i.e. not obsolete) document contains a definition of it. I seem to recall one of the other co-authors looking into it and finding this was acceptable, but I don't recall. Dave, can you comment? It would be highly unusual to use such a reference. I will most likely nit about that. Interestingly, the document that made it historical refers to it for more than a reference saying it has been replaced. That is, it makes a substantive comment on it. We need to be careful not to let odd formalities get in the way of basic pragmatics. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] IDNA
that we want to use ToASCII while no current (i.e. not obsolete) document contains a definition of it. I seem to recall one of the other co-authors looking into it and finding this was acceptable, but I don't recall. Dave, can you comment? It would be highly unusual to use such a reference. I will most likely nit about that. Interestingly, the document that made it historical refers to it for more than a reference saying it has been replaced. That is, it makes a substantive comment on it. I caught up on the back and forth on IDNA. The incompatibilities between IDN2003 and IDN2008 are limited to the encoding of two uncommon characters, which the IDNA group think is not a big deal, hence their decision not to change the xn-- prefix. Really, we should change the references to the current standard. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
