Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts
Hi Murray. > RFC6376 and even RFC4871, but now it's apparently happening I'd be interested to hear about the actual scenarios. Are the targeted users somehow given an indication that the email verifies and it's from a credible domain and yet it contains a malevolent payload? This sounds like some sort of quarantine system which only looks at verification status. It's too bad formal communication to the MUA was eliminated in DKIM. The original hope was that after a decade or so, MUAs would have evolved to participate and make some rendering indication in such situations. After all, an unknown-to-the-MUA to:/cc: recipient or domain in a verified email is highly actionable. Anyway, based on your draft I presume the desire is still to retain the binary verification status as a strong dispositional attribute that is handled by anything *but* the MUA? In the section that discusses the impact on forwarded and list email you might want to highlight that the proposal could further reduce email to a point-to-point protocol. In which case an alternative long-term strategy might be simply to insist on strong SPF checks rather than signatures. Or do SPF checks not help the scenario you're addressing here? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts
On Sun, Nov 13, 2016 at 03:50:05PM +0900, Murray S. Kucherawy wrote: > https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/ > > Comments welcome. Thanks for this. It isn't very clear to me how this proposal deals with receipients at different domains, including but not limited to blind carbon copies. I may be showing my ignorance of how DKIM signing engines work under the hood, but unless the email is not signed until a copy has been created for each receiving domain, my understanding of the draft is that this would result in every receiving domain receiving an invalid copy of the email. I also think it wouldn't hurt to make point 2 of section 4.1 a bit more explicit: should the addresses be converted to lowercase? To ASCII? Finally, is there a reason the proposal doesn't sign the canonicalized list of recipients separately and add this signature as a separate DKIM tag? This could allow for a more smooth transition period. One could even sign each recipient individually and add a list of signatures to a separate DKIM header. This would allow the verifier to check each recipient individually, which should be doable if their number isn't too big and does not require knowledge of which signature links to which recipient. Martijn. signature.asc Description: Digital signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts
On November 13, 2016 1:50:05 AM EST, "Murray S. Kucherawy" wrote: >I've posted a draft that attempts to address an attack that's begun to >appear with DKIM. Interestingly, we called it out as a possible attack >in >RFC6376 and even RFC4871, but now it's apparently happening and being >annoying enough that people (I believe from the MAAWG community) are >asking >if there's a protocol solution that's possible. > >https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/ > >Comments welcome. Wouldn't a DMARC option to allow senders to specify only messages that pass verification and alignment for BOTH SPF and DMARC accomplish the same result with less complexity and without the layering violation inherent in this proposal? DMARC seems to be the policy engine of choice in the community (for better or for worse). I think addressing this at the policy level makes more sense than changing the semantics of DKIM signatures after almost a decade of deployment. Scott K P.S. With my Debian OpenDKIM maintainer hat on, I'm not immediately convinced I'd want to enable this feature. I don't know if other distro maintainers are on this list or not, but that's one opinion. It's not guaranteed to be widely deployed. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts
> 1. This standard is not backward compatible with existing DKIM > implementations. It makes it useless. In addition, in it's current form > it can not be implemented in most MTAs (see below) It wouldn't work at all in our MTA without modifications because our general filter interface currently receives recipient addresses after some processing has been performed. We could add an option to change that fairly easily, but as you note, that doesn't address all the issues. > 2. This standard mixes transport standards (SMTP) and message standard. > There are multiple issues as a result of this: > 2.1 Same message may have multiple recipients on different MTAs while > each MTA only sees it's own recipients. So, destination MTA can not > verify signature, because it doesn't know all recipients. This can be > fixed if message to every destination is signed independently, but it > breaks existing mail flows, because in most cases message is signed > before placing to MTA queue. We have sufficient flexibility in this regard to sign late (and as noted above, verify early), and we can split by destination before signing each variant separately. What would be much more difficult is detecting this usage and turning off splitting where feasible to avoid breaking the signature. That would be very difficult. The bottom line is that at best this will be very fragile, at worst it will fail a significant percentage of the time. > 2.2 Recieving MTA may e.g. limit the number of recipients and single > message may be sent to different final recipients on the same MTA in > multiple session as few different messages, each message with partial > list of recipients. Actually, this quickly turns into a hairball. The minute the receiving system starts 4yz'ing some recipients the precomputed signature is going to be rendered invalid and will have to be recomputed. And how does the receiving MTA know when do this? It gets no indication that it's dealing with this particular DKIM variant until after recipients are processed. So it's only choice would be to do it unconditionally, or to try and keep track of senders who use this feature. Yuck. > Actually same message to same destination may be > sent to different MTAs (e.g. different MXs with same weight). > 2.3 Canonization must be better defined. It's usual for MTA to e.g. > lowercase the domain of recipient. Our default is to leave the case of addresses alone by default, but sites often do configure things to "right case" their business name. That said, Early validation would avoid such issues for us. I think. > All problems except 2.1 may be fixed by adding additional header, like e.g. > DKIM-Transport-recipients > which contains salted hashes (with some random salt) of all recipient > addresses, and require this header to be added to DKIM signature and > existence for every recipient's address' hash to be checked in this > header. It is compatible with any current DKIM implementation. If you're talking about hashing all recipients together, then I don't see this solving all the problems except 2.1. And if you're talking about hashing them separately, then why would you insist that they all be present? > 2.1 can also be solved in this case, but it disclosures BCCs of the > message (even if this header is removed before delivery to mailbox) Prior to delivery the bcc's are disclosed by being present in the envelope. So as long as the sender adopts the approach of splitting by destination before signing, only including the recipients for a given copy in the signature, and the receiver removes the field prior to final delivery, I think it might work. But limiting the number of recipients to 1 when this extension is used would be a much simpler approach. Of course there's some overhead involved in doing this, but given the idiotically limited spam report mechanisms in place at some sites single copy may be a requirement already. > All problems may be solved by using asymmetric encryption instead of > hashing, e.g. require domains with support for this standard to publish > some public key (or to use special DKIM selector) via DNS record and > encrypt recipient's addresses in the additional header with public key > and only sign recipients for systems with this key published. Yes, and that's really cute. Considerable overhead though. > P.S. I just did a quick look into standard, sorry if I missed or > misunderstood something. So did I, and so do I. Finally, my biggest concern here is that this, like most proposals that involve complex linkages between the header and envelope, is complex and loaded with pitfalls. (Just look at these two messages...) And at least some of this spills over to both implementations and operational policy. Can we really expect people to get this right? Ned ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts
On Sun, Nov 13, 2016 at 9:39 PM, Mark Delany wrote: > Hi Murray. > Mark! > RFC6376 and even RFC4871, but now it's apparently happening > > I'd be interested to hear about the actual scenarios. Are the targeted > users somehow given an indication that the email verifies and it's > from a credible domain and yet it contains a malevolent payload? > As I understand the attack: Spammer tries to send spam to a victim. The MSA blocks this because it's spam. However, the spam filter is not applied to mail sent by the spammer to itself, because why would that be a problem? So the spammer sends itself a piece of spam, which the MSA dutifully signs. Then the spammer downloads that message and remails it using whatever envelope it likes. The signature will continue to validate, carrying the reputation of the signing domain through any whitelist or other system that says this signer tends to send good mail. > This sounds like some sort of quarantine system which only looks at > verification status. > Sort of, yeah. It's any receiver that gives preferential treatment to messages signed by particular domains. > It's too bad formal communication to the MUA was eliminated in > DKIM. The original hope was that after a decade or so, MUAs would have > evolved to participate and make some rendering indication in such > situations. After all, an unknown-to-the-MUA to:/cc: recipient or > domain in a verified email is highly actionable. > Which channel was eliminated? I think RFC7601 could help if that's what you're referring to. > Anyway, based on your draft I presume the desire is still to retain > the binary verification status as a strong dispositional attribute > that is handled by anything *but* the MUA? > Right, that seems to be the attack that needs addressing. > In the section that discusses the impact on forwarded and list email > you might want to highlight that the proposal could further reduce > email to a point-to-point protocol. In which case an alternative > long-term strategy might be simply to insist on strong SPF checks > rather than signatures. Or do SPF checks not help the scenario you're > addressing here? > SPF might indeed help for cases where there are no intermediate hops. Both good suggestions. Thanks! -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts
On Mon, Nov 14, 2016 at 5:30 AM, Martijn Grooten wrote: > It isn't very clear to me how this proposal deals with receipients at > different domains, including but not limited to blind carbon copies. I > may be showing my ignorance of how DKIM signing engines work under the > hood, but unless the email is not signed until a copy has been created > for each receiving domain, my understanding of the draft is that this > would result in every receiving domain receiving an invalid copy of the > email. > Yes, if you have three recipients going to distinct MXes, and you want this to work, you need to sign each copy individually. You need to anticipate how the message is likely to arrive, basically > I also think it wouldn't hurt to make point 2 of section 4.1 a bit more > explicit: should the addresses be converted to lowercase? To ASCII? > In fact that's woefully underspecified and I show some ignorance, but fortunately I have local help! We've been discussing it in the hallway track at IETF 97 in Seoul and some of the suggestions I've received are: - just do a bytewise lexical sort, and don't try to interpret the addresses at all - apply NFKC to all of them before comparing - other suggestions are imminent Finally, is there a reason the proposal doesn't sign the canonicalized > list of recipients separately and add this signature as a separate DKIM > tag? This could allow for a more smooth transition period. > Now that's an interesting idea. > One could even sign each recipient individually and add a list of > signatures to a separate DKIM header. This would allow the verifier to > check each recipient individually, which should be doable if their > number isn't too big and does not require knowledge of which signature > links to which recipient. > I think that adds additional complexity beyond your previous suggestion and I'm not sure what the incremental gain is. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts
On Mon, Nov 14, 2016 at 5:41 AM, Scott Kitterman wrote: > Wouldn't a DMARC option to allow senders to specify only messages that > pass verification and alignment for BOTH SPF and DMARC accomplish the same > result with less complexity and without the layering violation inherent in > this proposal? > Doesn't that presuppose point-to-point handling? The proposal here doesn't. > DMARC seems to be the policy engine of choice in the community (for better > or for worse). I think addressing this at the policy level makes more > sense than changing the semantics of DKIM signatures after almost a decade > of deployment. > As the problem was presented to me, I haven't heard that DMARC is specifically involved here. It might be (maybe even "probably" is apt), but I haven't heard that, so I limited this idea to just the DKIM signing and verifying components of the system. > P.S. With my Debian OpenDKIM maintainer hat on, I'm not immediately > convinced I'd want to enable this feature. I don't know if other distro > maintainers are on this list or not, but that's one opinion. It's not > guaranteed to be widely deployed. > Why is this a distribution issue? -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts
On Mon, Nov 14, 2016 at 6:01 AM, Vladimir Dubrovin wrote: > 1. This standard is not backward compatible with existing DKIM > implementations. It makes it useless. In addition, in it's current form it > can not be implemented in most MTAs (see below) > 2. This standard mixes transport standards (SMTP) and message standard. > There are multiple issues as a result of this: > 2.1 Same message may have multiple recipients on different MTAs while each > MTA only sees it's own recipients. So, destination MTA can not verify > signature, because it doesn't know all recipients. This can be fixed if > message to every destination is signed independently, but it breaks > existing mail flows, because in most cases message is signed before placing > to MTA queue. > 2.2 Recieving MTA may e.g. limit the number of recipients and single > message may be sent to different final recipients on the same MTA in > multiple session as few different messages, each message with partial list > of recipients. Actually same message to same destination may be sent to > different MTAs (e.g. different MXs with same weight). > Yes the current text in the document already calls all of those issues out. > 2.3 Canonization must be better defined. It's usual for MTA to e.g. > lowercase the domain of recipient. > That's a good point. > All problems except 2.1 may be fixed by adding additional header, like e.g. > DKIM-Transport-recipients > which contains salted hashes (with some random salt) of all recipient > addresses, and require this header to be added to DKIM signature and > existence for every recipient's address' hash to be checked in this header. > It is compatible with any current DKIM implementation. > 2.1 can also be solved in this case, but it disclosures BCCs of the message > (even if this header is removed before delivery to mailbox) > Also an interesting idea. > All problems may be solved by using asymmetric encryption instead of > hashing, e.g. require domains with support for this standard to publish > some public key (or to use special DKIM selector) via DNS record and > encrypt recipient's addresses in the additional header with public key and > only sign recipients for systems with this key published. > If you do asymmetric encryption, with or without a distinct selector, aren't you basically doing the same thing I'm proposing, other than where it gets recorded in the message? -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts
On Mon, Nov 14, 2016 at 8:40 AM, Ned Freed wrote: > > Actually same message to same destination may be > > sent to different MTAs (e.g. different MXs with same weight). > > 2.3 Canonization must be better defined. It's usual for MTA to e.g. > > lowercase the domain of recipient. > > Our default is to leave the case of addresses alone by default, but sites > often > do configure things to "right case" their business name. That said, Early > validation would avoid such issues for us. I think. > Long ago some MTAs use to mess with the case of the domain names in the envelope. Assuming some of them are still out there, wouldn't we want to fold everything to lowercase (or uppercase; pick one) before doing the sort? > All problems except 2.1 may be fixed by adding additional header, like > e.g. > > DKIM-Transport-recipients > > which contains salted hashes (with some random salt) of all recipient > > addresses, and require this header to be added to DKIM signature and > > existence for every recipient's address' hash to be checked in this > > header. It is compatible with any current DKIM implementation. > > If you're talking about hashing all recipients together, then I don't see > this > solving all the problems except 2.1. > > And if you're talking about hashing them separately, then why would you > insist that they all be present? > I think he's trying to avoid being clobbered by an envelope that gets split downstream. If you as a verifier have the full original recipient set, then all you care about is that your recipient set is a subset of the original set. > But limiting the number of recipients to 1 when this extension is used > would be > a much simpler approach. Of course there's some overhead involved in doing > this, but given the idiotically limited spam report mechanisms in place at > some > sites single copy may be a requirement already. > It's also the most common use case in threat space, as I understand it. > Finally, my biggest concern here is that this, like most proposals that > involve complex linkages between the header and envelope, is complex > and loaded with pitfalls. (Just look at these two messages...) And at least > some of this spills over to both implementations and operational policy. > Indeed; I don't think that's avoidable if we want to try to tackle this problem versus punting it back up to layers 8 and 9. But maybe that's the best thing one can do. Can we really expect people to get this right? > I wonder that every time I write a draft anymore. :-) -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts
On November 14, 2016 12:50:01 AM EST, "Murray S. Kucherawy" wrote: >On Mon, Nov 14, 2016 at 5:41 AM, Scott Kitterman > >wrote: > >> Wouldn't a DMARC option to allow senders to specify only messages >that >> pass verification and alignment for BOTH SPF and DMARC accomplish the >same >> result with less complexity and without the layering violation >inherent in >> this proposal? >> > >Doesn't that presuppose point-to-point handling? The proposal here >doesn't. Your proposal breaks all non-point-to-point handling, if I understand it correctly, so whether you make DKIM signatures non-forwardable or do it in DMARC policy, it's the same end result. > >> DMARC seems to be the policy engine of choice in the community (for >better >> or for worse). I think addressing this at the policy level makes >more >> sense than changing the semantics of DKIM signatures after almost a >decade >> of deployment. >> > >As the problem was presented to me, I haven't heard that DMARC is >specifically involved here. It might be (maybe even "probably" is >apt), >but I haven't heard that, so I limited this idea to just the DKIM >signing >and verifying components of the system. I think your pushing a substantial change to DKIM and to the extent this is a reasonable problem to solve, DKIM isn't the right layer in the email authentication stack to do it. > >> P.S. With my Debian OpenDKIM maintainer hat on, I'm not immediately >> convinced I'd want to enable this feature. I don't know if other >distro >> maintainers are on this list or not, but that's one opinion. It's >not >> guaranteed to be widely deployed. >> > >Why is this a distribution issue? Because so far this looks like a source of interoperability problems and bug report headaches I could do without. I think the solution to "I have a problem that results when I sign spam" is "don't do that", not the entire community turns on its head to work around someone's local configuration problems. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
