Re: [Ietf-dkim] DKIM update - header tag
Dne 13. 3. 2023 v 16:08 Murray S. Kucherawy napsal(a): On Fri, Mar 10, 2023 at 10:48 AM Jan Dušátko wrote: I got recommendation to propose changes in that mailing group. My work depend on appropriate protection of our brand, however this tasks require also management of records required for that protection. We have huge problem with identification of selector records required by DKIM and also this make for us problem with compatibility. We would like to strongly follow RFCs, but sometimes v=DKIM1 tag are resolved like issue as well as sometime missing of that tag do the same. This is a reason, why I would like to propose mitigation of problem, caused by word RECOMMENDED in standard RFC 6376: [...] Just to clarify: Are you saying the identification of a DKIM record in the DNS is uncertain unless "v=DKIM1" is present? -MSK Yes, exactly, you are right. Although DKIM FQDN records must be in the format [selector]._domainkey.domain.tld, this not impact any records prepared to create CNAME for other domains. As for the internal format, if the record contains only a key (p="base64encodedkey"), it is difficult to verify whether it is really a DKIM record. Especially in the case of a corrupted encoded record. Jan -- -- --- - - Jan Dušátko Tracker number: +420 602 427 840 e-mail: j...@dusatko.org GPG Signature: https://keys.dusatko.org/E535B585.asc GPG Encrypt:https://keys.dusatko.org/B76A1587.asc ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Process Questions
On 3/13/23 8:14 AM, Murray S. Kucherawy wrote: Our current milestones are: Apr 2023 - Post a consensus problem statement draft to the datatracker (may not go to the IESG) Jun 2023 - Proposal regarding plans for remaining document(s) presented to the AD Dec 2023 - Submit technical specifications for replay-resistant DKIM enhancement(s) to the IESG at Proposed Standard Per the charter, Or Not. That is what I'm asking about. Between the milestones and the charter text, the charter text is typically the more important of the two. Milestones can be edited without full IESG review, while the charter can't. So if the working group needs more time than April or June, that can be negotiated. Plus, frankly, I made up those dates during chartering. The chairs and I haven't discussed whether they're reasonable or whether something else should be there. If people want to propose adjustments, I'm all ears. Considering that the activity is far from jumping here, those dates look like so much wishful thinking. The current state of the problem draft is still extremely vague and seems to be suffering from political issues that people who know what's going on can't or won't elaborate. If the only thing that can be produced is so vague then I really don't see what the point is in going forward. So maybe the April milestone needs to include whether there is anything actionable and especially testable. That is, if there is a problem how can we know whether a solution works? The second issue is the set of solution approaches. At some point they need to be considered. If there are more forthcoming, there needs to be some sort of deadline so that they can be read and considered. Maybe that aligns with the June milestone, but I'm not sure. Which remaining documents are we talking about here? The charter also mentions operational recommendations, iirc. I'm not sure where that fits in. Again, if the problem statement remains as vague as it is right now, then that should be completely off the table as a wg item since it's then so much navel gazing. If people who are more in the know want to create an informational document, that's fine but if there's no way for the wg to vet it, then there's no point in the wg submitting it. It should just be an individual submission and ask the IESG to publish it ala DMARC. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Process Questions
On Fri, Mar 10, 2023 at 11:19 AM Michael Thomas wrote: > On 3/10/23 7:46 AM, Laura Atkins wrote: > > > On 10 Mar 2023, at 00:30, Michael Thomas > wrote: > > Now that we have a chair, I have a question about process wrt to the > charter. The charter states that either the working group will produce > documents addressing the problem, or it will produce a document saying why > it can't do anything about it within the IETF confines. I strongly suspect > that that the latter will be the conclusion but I don't know what the > process would look like to come to that conclusion. It seems like it > entails a long list of "can't do this"'s etc followed by "we give up". But > that list could be nearly endless if it is allowed to get out of hand. So > what does it take to come to that conclusion from a process standpoint? > > > Our current milestones are: > > Apr 2023 - Post a consensus problem statement draft to the datatracker (may > > not go to the IESG) > > Jun 2023 - Proposal regarding plans for remaining document(s) presented to > > the AD > > Dec 2023 - Submit technical specifications for replay-resistant DKIM > > enhancement(s) to the IESG at Proposed Standard > > > Per the charter, Or Not. That is what I'm asking about. > Between the milestones and the charter text, the charter text is typically the more important of the two. Milestones can be edited without full IESG review, while the charter can't. So if the working group needs more time than April or June, that can be negotiated. Plus, frankly, I made up those dates during chartering. The chairs and I haven't discussed whether they're reasonable or whether something else should be there. If people want to propose adjustments, I'm all ears. -MSK, this time with the AD hat on ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM update - header tag
On Fri, Mar 10, 2023 at 10:48 AM Jan Dušátko wrote: > I got recommendation to propose changes in that mailing group. > My work depend on appropriate protection of our brand, however this > tasks require also management of records required for that protection. > We have huge problem with identification of selector records required by > DKIM and also this make for us problem with compatibility. We would like > to strongly follow RFCs, but sometimes v=DKIM1 tag are resolved like > issue as well as sometime missing of that tag do the same. This is a > reason, why I would like to propose mitigation of problem, caused by > word RECOMMENDED in standard RFC 6376: > [...] > Just to clarify: Are you saying the identification of a DKIM record in the DNS is uncertain unless "v=DKIM1" is present? -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Fwd: New Version Notification for draft-crocker-dkim-replay-00.txt
Sorry for the delay. Top level, I agree that this draft tightens up the details in a beneficial way, and the working group ought to work off the crocker version. I'm happy to also merge this version in my problem-statement draft also. My interpretation of the changes, is that the crocker draft removes one of the redundant DKIM replay definitions found in the introduction. It also tightens up the language with respect to RFC5598 and reorders the glossary section. There's a new section "Replay technical characteristics" which is gives our current understanding of what a replayed message would look like. On Thu, Mar 9, 2023 at 7:20 AM Dave Crocker wrote: > On 3/9/2023 7:04 AM, Tim Wicinski wrote: > > it would be useful to the working group if the authors > could perhaps summarize the differences between them. > > As I noted, mine is a revision of Wei's. (And I have been among the > contributors to his, for some months.) If adopted, the author list needs to > reflect that, really, it's the work of that set of authors. > > My goal was to tighten the focus, as well as to reduce the tutorial > content. It still has a fair amount of foundational introduction, since > many people don't know all the terms or use them differentially. > > For a long time, I'd thought that references to SPF should be removed, > since this is about DKIM. As the text on detection of replay developed, > I've been swayed that limited reference to SPF can be helpful. But I > removed reference to DMARC, since I think it adds nothing to detection. > I'm good removing DMARC . Glad you kept the SPF description, and put in clarifications on why SPF is important in the context of DKIM replay. > The discussion of possible prevention/mitigation is isolated to the last, > brief section. Given that the document is likely to get wide distribution, > I think it might be helpful to have a small amount of discussion that > emphasizes that this topic will not be amenable to trivial solution. > Also glad that it was kept, as I agree, I think it's important for readers to understand broad outlines of some of the existing ideas and their issues. -Wei > d/ > > -- > Dave Crocker > Brandenburg InternetWorkingbbiw.netmast:@dcrocker@mastodon.social > > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim > smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
