Re: [dmarc-ietf] Milestones changed for dmarc WG
On 8/29/14 12:35 PM, Tim Draegen wrote: > On Aug 29, 2014, at 12:50 PM, Pete Resnick wrote: > >> Tim/Ned [Ccing WG]: >> >> While I think the milestones that appear in the wiki are great for internal WG management (and in fact I think you could even add more of them), I think for the external-facing milestones on the charter page, you should have the more common externally visible milestones like "initial draft of X" or "submission of completed document Y to the IESG", etc. >> >> That work for you? >> > Yes it does. I'll rework the external-facing milestones to perhaps remove some confusion. > Are you OK with the following edits? Dec 2014Complete draft on DMARC interop issues + possible methods to address Mar 2015Complete draft on DMARC improvements to better support indirect email flows May 2015Complete draft on DMARC Usage Guide May 2015Complete draft on changes to DMARC base spec (That is, separating out the two documents from the May date, and rewording them a bit.) If so, I can make the changes as I approve them. Is "complete draft" the usual way these things are done now? It used to be that you list WGLC, LC, RFC published for each. I have to say I like this approach a lot better. Less bureaucracy. As for the substance, it looks fine to me. Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [apps-discuss] Start of DMARC WG + proposed milestones
> The list of milestones and deliverables looks good to me. Having not > participated in an IETF working group before, I have process oriented > questions. > Am I a part of the working group by being a member of the dmarc@ietf.org > list? Yes. The IETF doesn't have a concept of membership; you either participate or you don't. > How do I contribute to the working group, will the chairs ask for input at > specific times or for volunteers to write specific pieces of documents? Both of those things will probably happen, but that's in addition to general list discussions on current topics relevant to the goals of the group. > How does the working group decide that any given suggestion warrants > inclusion in a deliverable or a base spec change or some other action? When there's a rough consensus among the participants to do so. Usually it's pretty obvious whether something is supported or not, but it's up to the WG chairs to make the close calls. Ned P.S. You might want to take a look at "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", available here: http://www.ietf.org/tao.html ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Richard Barnes' Block on charter-ietf-dmarc-00-00: (with BLOCK)
> > This seems like a reasonable compromise with the overall DMARC effort. > > However, this charter seems to provide pretty huge scope. Can it be cut > > up into a few chunks? It already specifies phases; perhaps we could > > charter only the first phase now? What's the compelling reason to > > charter all this work in one fell swoop? > We have energy to do it, and we know what we want to get done. > What's the value in breaking it up? +1 I see no value in breaking it up. I also see substantional harm; like it or not, this work has to be conducted while being mindful of a very big "big picture", and further divisions may make that difficult. In fact if anything I think the scope is going to prove to be too limited, although in exactly what ways is hard to say right now. It's best to start with a charter that covers the necessary and little more and expand as needed. I think this charter achieves this goal. Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] The theory of DKIM versions
> Ned Freed writes: > > > Why is it a good idea to do an extensible protocol that we don't have > > > any proposed extensions for? > > > > First, the protocol is already extensible, just not in the right way for > this > > case. > By which you mean? I mean that any implementor can add whatever previously undefined tags they want to a signature and still be fully compliant. The meaning of those tags could then be taken to be whatever anyone eants by bilateral agreement. Semantics and requirements can also be attached to signatures through external means like publishing DNS records, as DMARC did. In other words, the issues you seem to be worried about criticality indicators introducing already exist. > It doesn't have a "criticality" indicator for tags? All criticality indicators would do, essentially is tell people when a signature has to be *ignored*. > > Second, what do you think the "non-V1 signatures in new fields" are if > > they aren't extensions? > Of course they're extensions, but not of an existing field. The > process required to get them standardized is different. Really? How does it differ? In either case you have to write a specification and get it through the IETF process. > > This is all old and well-tread ground in many protocols, and > > there's large amounts of "running code" saying that the issues you > > imagine this will create don't actually occur in practice. > I hope you're right. What worries me that I suspect that there really > aren't all that many protocols whose purpose is to DoS illegitimate > use, whose design is to DoS unauthenticated use, and where the set of > legitimate uses is so much larger than the authenticatible set, as in > the case of domain-based authentication. OK, let's say for the sake of argument that this is true - the question then is why would that mean that adding criticality indicators is a bad idea? > > (I have described the issues that have occurred, as well as why > > that won't happen here.) > Actually, no, you haven't. I accept your expertise, but I've seen > insufficient evidence to lead me to the same conclusion in your > absence. Then you need to reread my original message on this topic, where I covered the one previous adverse/perverse outcome I'm aware of in this space. And if you don't understand the difference between semantics requiring something be ignored and semantics requiring something be rejected, there's really nothing more I can say. And anything beyond examination of previous failures amounts to trying to prove a negative. > > Given that that this need has arisen, it seems to me that solving > > the general problem in a clean way makes a lot more sense than a > > one time hack, especially since the implementation costs are, > > AFAICT, nearly identical. > Why do you think the general problem can be solved "cleanly"? I agree > that a clean syntax can be constructed, and that it could be reused > for a lot of different individual problems that seem to be amenable to > DKIM-signature-based solutions. That's the general problem I'm talking about. So it seems we agree it can be solved cleanly. > But the domain of the "general problem" seems to be unknown, and the > specific example we have (third party authorization via in-band > protocol) is fraught with external semantic issues (criteria for > authorization, how to populate those lists, etc). I see no reason to > suppose that other problems won't have critical external semantics as > well, and those leading to conflicting requirements. In which case you define new critical tags to specify those semantics. > As soon as you > have multiple signatures for various purposes, you have potential for > unwanted interactions where one signature may validate even though > it's the wrong purpose, as we've seen with "token signatures" in this > discussion. I don't really see good reason to expect a semantically > clean solution. Of course it's necessary to properly design and specify future extensions. Any concievable mechanism carries with it the potential for misuse. > While semantic confusion is no excuse for ugly syntax, I remain > worried that use of one syntax for multiple semantics will lead to > more confusion than cleanliness. I'd be a lot happier if we had > another example of the "general problem" to help justify claims that > these tags really are a "polymorphic" solution for a class of similar > problems rather than C++ style arbitrary "overloading" of syntax. Yes, it's always nice to have more data to base decisions on. A
Re: [dmarc-ietf] The theory of DKIM versions
> Not specifying the full scenario was my bad. We can stop there, at > "my bad", if you like, but it would be more productive if we could > meet halfway, on some bridge between "your good" and "my bad". > > > > You're missing the point. We're *changing* the design here so > > > > things no longer work this way by associating this with a > > > > version bump. And we've already confirmed that a significant > > > > number of implementations ignore v=2 signatures. > > > > > Changing the design of what? > > > > DKIM and subsequently DMARC. > That's not *the* design, that's *two* designs you're changing. DKIM > is "owned" by the IETF, and "we" can change it. > DMARC is not; DMARC is a successful private protocol, and "we" can't > change it. We can make suggestions that provide sufficient benefits > to the current DMARC participants so that they prefer our proposal to > the one that works for them already. In other words, if may be difficult but we can change it. > That's a tall order though. "Don't fix what ain't broke." > > Then this entire effort is pointless > I'm afraid it's going to be unsuccessful, indeed. That doesn't make > it pointless. OTOH I'd rather not waste your effort and mine if it is > pointlees. > > and we might as well leave it all to the MLMs to deal with as best > > they can. > Well, we MLM devs will deal. But it's not just us. There are a bunch > of third parties for whom the workarounds so far are suboptimal. > > None of the present proposals make any sense if DMARC agents continue > > to only see only V1 signatures. > True. But some of the non-V1 signatures proposed are in new fields. > Why is it a good idea to do an extensible protocol that we don't have > any proposed extensions for? First, the protocol is already extensible, just not in the right way for this case. Second, what do you think the "non-V1 signatures in new fields" are if they aren't extensions? > I grant that if we're going to do that, > a version bump to DKIM-Signature (rather than a new field) is very > plausible. > > > it's possible, maybe even quite probable, that the big players > > > will use the possibility of registering values and imposing > > > criticality to serve their own purposes. > > > > Why would they bother? If they want to do things along those lines, > > they can already do them by generating and then requiring a > > different header field and there's nothing we can do about > > it. > Because if the IETF publishes it, it's a "standard", and the onus is > on them to conform. If they can conform without conforming, they can > blame everyone else (as Yahoo! and AOL are already doing, albeit > implicitly). And they can do it explicitly, because they "conform." You're confusing the definition of an extensibility mechanism with its use. We specify extensibility mechanisms all the time without there being any implication that someone using them is creating any sort of standard. Indeed, we could, as part of this mechanism, include additional tagging to make it clear whether or not a given set of tags are standardized or not. This is all old and well-tread ground in many protocols, and there's large amounts of "running code" saying that the issues you imagine this will create don't actually occur in practice. (I have described the issues that have occurred, as well as why that won't happen here.) > > This [X.400] mechanism caused problems because some vendors added > > critical extensions which would then cause other implementations to > > bounce those messages. > Sounds like "p=reject" to me. More precisely, in the "p=reject" > environment, ignoring things is no longer "fail-safe", it's > "fail-mail-lost". A critical extension must be handled properly, or > the signature doesn't validate ... and the message bounces. I have previously explained why the contexts aren't remotely comparable, but let's suppose for a moment that they are. "p=reject" was in no way dependent on any kind of extension to DKIM. Indeed, the main motivation behind extending DKIM is that DKIM gives us no way to specify what a signature is for, which makes it impossible to sign something twice with different grades of signature while making sure the weaker one isn't used for the wrong purpose. Although I don't agree with it and think it's gone one layer of abstraction too far, I accept the design decision that having a means to specify the intended purpose of a given signature in the signature itself is the wrong approach. Which means the only alternative is to extend the signature semantics one way or the other. Given that that this need has arisen, it seems to me that solving the general problem in a clean way makes a lot more sense than a one time hack, especially since the implementation costs are, AFAICT, nearly identical. Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/list
Re: [dmarc-ietf] The theory of DKIM versions
> Ned Freed writes: > > The scenario you propose makes no sense: > True. > > If Yahoo! or whoever does what you describe, their messages would > > in effect have no attached signatures until the receiving systems > > out there upgrade their software to handle the new critical tags. > No, they'll have effective signatures. They'll use "v=1" signatures > as well during a transition period (they work well enough to be used > for a while ), and then do what they're doing now: tell their users to > yell at recipients who don't handle vendor-specific "V=2" signatures > to get their act together and "be part of the solution". You've now changed the scenario. Previously you seemed to be talking about switching to the new scheme, not running both in parallel. Since the V2 signatures will be ignored, running them in parallel is effectively the same as just having V1 signatures to old agents. > > You can't count on much from large players, but I think you can > > count on them not intentionally screwing themselves over. > I don't see the strategy above as screwing a large player more than > publishing p=reject already does. They did that. Again, you're talking about a different strategy now. > > > By design, DMARC renders that requirement inoperative, and a > > > "p=reject" policy is intended to render messages unprocessable exactly > > > when a particular DKIM-signature is invalid. DKIM may not need to > > > worry about it, but we do. > > > > You're missing the point. We're *changing* the design here so things no > > longer work this way by associating this with a version bump. And we've > > already confirmed that a significant number of implementations ignore > > v=2 signatures. > Changing the design of what? DKIM and subsequently DMARC. > I wish we could change the design of > DMARC[1], but I don't think that is going to happen. Then this entire effort is pointless and we might as well leave it all to the MLMs to deal with as best they can. > DMARC is a > private agreement so far completely out of IETF control, it is known > to suck in some ways for third parties, and the big players are doing > those sucky things anyway because it accomplishes their goals without > hurting them very much. Changing DKIM is not going to change DMARC as > far as I can see. DMARC may adopt new features of DKIM, but only as > it serves the consortium's purposes, and they will surely continue to > apply the "p=reject" override to any "v=2" DKIM signature that fails > (generalized) identity alignment or is invalid. No? Absolutely not. I would have thought this was obvious, but I guess it isn't, so let me state it plainly: The goal here is to propose changes to DMARC that improve its interoperability with lists while maintaining the security it provides. None of the present proposals make any sense if DMARC agents continue to only see only V1 signatures. > All the evidence I see says that even if the exact scenario I propose > is unlikely to occur, How can there possibly be evidence of anything? We have yet to reach any sort of consensus on a proposal here. So unless you can cite a case where a proposal was made to the folks using DMARC along these lines which was subsequently turned down, I fail to see the point you're trying to make here. > it's possible, maybe even quite probable, that > the big players will use the possibility of registering values and > imposing criticality to serve their own purposes. Why would they bother? If they want to do things along those lines, they can already do them by generating and then requiring a different header field and there's nothing we can do about it. Indeed, we know for a fact that Google already does this sort of thing for their own purposes. For that matter, if someone wants to they can presently require a DKIM-Signature field be present with various optional fields. And once again there's nothing we can do about it. Just because DKIM declares some field to be optional doesn't mean that son-of-DMARC has to. Or that all field values are acceptable. And so on. > You describe the > same kind of thing happening in the past -- I understand that "that > was then, this is now (and different)", but this "difference" is all > hypothetical. The fact is that fragmentation does occur under some > circumstances. No, the differences are very real. I really don't want to get deep into the nitty-gritty of X.400, but suffice it to say that there are various extensbility areas built in to the protocol. The ones defined at the P2 "message" level don't have criticality bits; but
Re: [dmarc-ietf] The theory of DKIM versions
> Ned Freed writes:
> > The obvious issue is that it makes it possible to create myriad
> > incompatible but nevertheless legitimate variants of DKIM. Since an
> > important aspect of DKIM is use by bilateral agreement, and since
> > nothing prevents you from attaching multiple DKIM-Signature header
> > fields, even if this happens I don't see it as a problem.
> Multiple signatures with the same basic semantics ("the domain in 'd='
> vouches for the mailbox in From:", to paraphrase Dave Crocker) from
> the same signatory clearly increases complexity, of handling for third
> parties as well as of interpretation by recipients.
> The scenario that worries me is not that Yahoo! will choose to apply
> GMail-style conditions in a separate DKIM-Signature field from their
> "native" DKIM-Signature field. It's the scenario where they *don't*,
> and Mediators (and Recipients) have to adjust to new "critical" tags
> every time a large mailbox provider has a protocol brainstorm or
> suffers a security breach.
The scenario you propose makes no sense: If Yahoo! or whoever does what
you describe, their messages would in effect have no attached signatures
until the receiving systems out there upgrade their software to handle
the new critical tags.
You can't count on much from large players, but I think you can count on them
not intentionally screwing themselves over.
> > I don't see [ignoring criticality] as likely to happen with DKIM
> > for several reasons. For one thing, the failure to interpret a
> > paritcular DKIM-Signature field isn't supposed to render the
> > message unprocessable - in fact it's required that it not have that
> > effect.
> By design, DMARC renders that requirement inoperative, and a
> "p=reject" policy is intended to render messages unprocessable exactly
> when a particular DKIM-signature is invalid. DKIM may not need to
> worry about it, but we do.
You're missing the point. We're *changing* the design here so things no
longer work this way by associating this with a version bump. And we've
already confirmed that a significant number of implementations ignore
v=2 signatures.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] The theory of DKIM versions
> >The problem may be that we don't agree about what DKIM versions mean. > >Here's what I would like them to mean: ... > >c) Whenever we add new tags that require that the verifier understand them > >to get the right answer, we increment the version number. > Ned pointed out that we could add an indicator on a tag that means > that interpreting the tag is mandatory, so if the verifier doesn't > understand the tag, the verification fails. This would decrease the > need for future version bumps. > So for example: > DKIM-Signature: v=2; a=rsa-sha1; c=relaxed/relaxed; s=s1024; d=sender.example; >h=From:To:Date; l=0; !cs=fs; fs=t; >bh=... >b= > The ! in !cs= means that the verifier MUST handle the cs= tag or fail the > message. First, credit where credit is due: This is basically the criticality indicator found in X.400, X.500, and various other protocols. The idea dates back to at least the mid-1980s, if not earlier. Second, I didn't originally mention this because I intended to propose adding it, but having thought about it, I find myself liking the idea, especially since it gives you a more general capability-based mechanism for future extensions. In fact I could see this effectively obsoleting the version field in DKIM. Since there's substantial operational experience with this sort of mechanism - not all of it good - it's important to access it in light of that previous experience. The obvious issue is that it makes it possible to create myriad incompatible but nevertheless legitimate variants of DKIM. Since an important aspect of DKIM is use by bilateral agreement, and since nothing prevents you from attaching multiple DKIM-Signature header fields, even if this happens I don't see it as a problem. A second, more subtle, issue, and one that definitely happened in the X.400 space, is that the way this stuff ended up getting deployed created incentives for implementations to simply ignore the criticality bit. This happened because in an effort to create vendor lock-in several implementations decided to decorate all their messages with critical extensions containing who knows what. None of this stuff seemed to matter; messsages could be read and processed in spite of it. So the result was a lot of processors simply ignored the criticality, or at least could be set to do so. I don't see this as likely to happen with DKIM for several reasons. For one thing, the failure to interpret a paritcular DKIM-Signature field isn't supposed to render the message unprocessable - in fact it's required that it not have that effect. And there's so much flexibility along so many other axes - multiple DKIM-Signature fields, fields with different names, etc., that I don't see a serious concern here. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-levine-dkim-conditional-00
> On Mon, Jun 16, 2014 at 1:17 PM, John Levine wrote: > > Here's a draft that puts the forwarding thing into DKIM, with the > > dread version bump. It defines a general syntax for conditional > > signatures, with the forwarding signature the only condition defined > > so far. (Since you asked, new conditions don't need another version > > bump.) > > > I'm uneasy with an increase in version that isn't done in a complete > replacement for RFC6376. We're not just registering a couple of new > extension tags here. I would prefer that, if we do go decide to go down > this route, we crack it open and do a proper revision document rather than > just describing v2 in terms of "changes since v1". Behold the main problem with version numbers in protocols - people invariably attach more significance to such values that they really deserve. This is especially true when the number is "2" - they call it *second* system syndrome for a reason. Nathaniel and I have long since agreed that the MIME-Version field is one of the biggest, if not the biggest, fuckups in MIME. And yet it's a mistake we keep on making in protocol design. Sigh. There's a problem in front of us that needs solving. Part of that seems to call for a limited semantic extension to DKIM. Let's by all means make that one extension in way that generalizes as much as possible. But using this as justification to crack open the entire specification? That is not a good idea. Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] So if you don't want a DKIM version bump ...
So, are we going to create a new header field every time we come up with some new required semantic we want to attach to a DKIM signature? Admittedly this hasn't happened previously, but predicting the future has never been our strong suit. Why don't we fix the extensibility problem instead? Ned > Here's the exact same proposal, except done with a new header > CDKIM-Signature rather than a DKIM version bump. > A new version of I-D, draft-levine-cdkim-00.txt > has been successfully submitted by John Levine and posted to the > IETF repository. > Name: draft-levine-cdkim > Revision: 00 > Title:CDKIM Signatures > Document date:2014-06-19 > Group:Individual Submission > Pages:5 > URL:http://www.ietf.org/internet-drafts/draft-levine-cdkim-00.txt > Status: https://datatracker.ietf.org/doc/draft-levine-cdkim/ > Htmlized: http://tools.ietf.org/html/draft-levine-cdkim-00 > Abstract: >The DKIM protocol applies a cryptographic signature to an e-mail >message. This specification defines a DKIM-like signature that >includes the specification of external conditions that must be >satisfied for a signature to be valid. > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
