Re: [Ietf-dkim] Chartering update
On Fri 03/Feb/2023 01:06:27 +0100 Scott Kitterman wrote: There is an existing draft of a problem statement, so there's at least a starting point to consider. I think discussion about what's needed is probably more useful relative to a specific draft than in the abstract: https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/ It may be interesting to compare that document's Section 2, Mail Flow Scenarios, with pre-DKIM analysis depicted here: https://commons.wikimedia.org/wiki/File:Mailflows-reloaded.png Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On 2/6/23 10:53 AM, Alessandro Vesely wrote: On Sat 04/Feb/2023 00:44:35 +0100 Michael Thomas wrote: Other than removing the ARC references, this seems like a good start. ARC is very similar to DKIM. Saying that it can have the same problem doesn't seem out of place to me. ARC is experimental and this is the DKIM wg. It's out of scope, imo and will only distract from the issue at hand. In particular, the editorializing about what it's useful for is not helpful at all. I'd drop Section 4. We have discussed those topics, but enumerating them in the problem statement sounds like establishing explicit limits to the solution space. Rather, I'd include a report of actual incidents, possibly showing full message contents and estimated fallout dimensions. Part of the "problem" is that potential avenues of "solution" can be extremely problematic, if not flat out wrong. I don't think that it hurts to have some discussion about the bounds of the solution space. That is, here's the problem but if you think you can solve it in this manner you need to show how it doesn't affect X, Y and Z. And can certainly make plain that this discussion section is open ended and that other avenues are encouraged. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
I'd drop Section 4. We have discussed those topics, but enumerating them in the problem statement sounds like establishing explicit limits to the solution space. Rather, I'd include a report of actual incidents, possibly showing full message contents and estimated fallout dimensions. It might help to be clear about the goal of the paper. I see it as helping to provide focus for the effort, as well as aid in educating the larger technical and operations community. Some discussion of incidents can make the fact that this is a real and present danger more... real and immediate to the reader. But it doesn't need to be a statistical analysis demonstrating solid academic research. Just examples, properly washed to protect the... well... Some discussion of the apparent solution space can help the reader with what to expect. In some cases it might even prompt someone to look for something useful outside that space. but again, the goal should be basic description, rather than attempt anything definitive. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On Sat 04/Feb/2023 00:44:35 +0100 Michael Thomas wrote: On 2/2/23 4:06 PM, Scott Kitterman wrote: There is an existing draft of a problem statement, so there's at least a starting point to consider. I think discussion about what's needed is probably more useful relative to a specific draft than in the abstract: https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/ Other than removing the ARC references, this seems like a good start. ARC is very similar to DKIM. Saying that it can have the same problem doesn't seem out of place to me. I sort of like the proposed solution space, but several of them could be tried today or have huge downsides. Bcc, for example, would be a security fail if it were in the message headers. Caching signatures could be tried today but I don't see how that can be distinguished from, say, a mailing list. But it could be rewritten in terms of not solutions but possible angles to attack the problem with pros and cons. It may well be that a preponderance of evidence could be useful. We could list off a bunch of other possible clues too. For one, what is the reputation of the To: address's domain? There are surely more. I'd drop Section 4. We have discussed those topics, but enumerating them in the problem statement sounds like establishing explicit limits to the solution space. Rather, I'd include a report of actual incidents, possibly showing full message contents and estimated fallout dimensions. Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On Sat, Feb 4, 2023 at 11:07 AM Michael Thomas wrote: > On 2/4/23 11:02 AM, Evan Burke wrote: > > On Sat, Feb 4, 2023 at 10:15 AM Michael Thomas wrote: > >> Marketing email probably does. Whether it's spam or not is often in the >> eye of the beholder. >> > > Having spent some time in the industry, I can tell you that a significant > majority of marketing email service providers will deliver a unique > message, with a unique signature, for each individual recipient. DKIM > replay, in its most problematic current form, repeats one signature, often > millions of times or more. Even a very approximate count of h= or bh= > hashes can be a useful signal to distinguish direct vs. replayed > signatures. > > As I'm sure there are occasional cases where non-replay mail may re-use > the same signature a substantial number of times, I suspect any potential > mechanism based on this would need to be optional on both the signer and > validator side, requiring no changes to existing infrastructure unless a > signer or validator is interested in addressing this type of DKIM replay. > Seems like that could satisfy the people seeking a solution, and those > interested in avoiding any breaking changes. > > > I get tons of mail that's just the same blast to everybody. The larger > point is that we can't preclude that use case especially from a standards > standpoint. > I agree with that larger point, and I noted that in my second sentence above. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On 2/4/23 11:40 AM, Murray S. Kucherawy wrote: On Sat, Feb 4, 2023 at 11:11 AM Michael Thomas wrote: There are architectural ramifications regardless of whether it's mandatory or not. It would be a lot more reassuring if this were a common and accepted practice. I don't know the answer to that. If it's uncommon, there needs to be wider discussion imo. What sort of ramifications? There have been multiple cases presented in the past of good reasons to double-sign something, if that's what you're referring to. Key rotation comes to mind. Algorithm deprecation. With and without "i=" or "l=" for people experimenting with them. No I'm talking about the layering violation of bindings between message and envelope. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On Sat, Feb 4, 2023 at 11:11 AM Michael Thomas wrote: > There are architectural ramifications regardless of whether it's mandatory > or not. It would be a lot more reassuring if this were a common and > accepted practice. I don't know the answer to that. If it's uncommon, there > needs to be wider discussion imo. > What sort of ramifications? There have been multiple cases presented in the past of good reasons to double-sign something, if that's what you're referring to. Key rotation comes to mind. Algorithm deprecation. With and without "i=" or "l=" for people experimenting with them. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On 2/4/23 12:38 AM, Murray S. Kucherawy wrote: On Thu, Feb 2, 2023 at 3:26 PM Michael Thomas wrote: I guess my concern is more along the lines of what solutions *aren't*. There are a bunch of drafts trying to tie the envelope to the email and I think there needs to be a meta discussion of whether that is a good idea or not in general. Frankly that seems like an email architecture question not just a DKIM question. It would be nice to know if there is precedent for that in the larger community and what the implications are. Fwiw, I don't really consider the DMARC "alignment" as tickling the larger question because all it is doing is reporting on it, but a case could certainly be made that it is. For what it's worth, the proposals that seek to offer a binding between the envelope and the message aren't making any sort of mandatory change to DKIM. It's entirely optional to the signer whether to make that connection using one of those proposals; conventional DKIM isn't being taken off the table. For instance, the idea I put forward suggests using two signatures, one that makes the binding and a typical one that does not. Such a tactic would leave the original signal about a message intact while possibly providing more, which seems to me to be strictly an improvement. There are architectural ramifications regardless of whether it's mandatory or not. It would be a lot more reassuring if this were a common and accepted practice. I don't know the answer to that. If it's uncommon, there needs to be wider discussion imo. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On 2/4/23 11:02 AM, Evan Burke wrote: On Sat, Feb 4, 2023 at 10:15 AM Michael Thomas wrote: Marketing email probably does. Whether it's spam or not is often in the eye of the beholder. Having spent some time in the industry, I can tell you that a significant majority of marketing email service providers will deliver a unique message, with a unique signature, for each individual recipient. DKIM replay, in its most problematic current form, repeats one signature, often millions of times or more. Even a very approximate count of h= or bh= hashes can be a useful signal to distinguish direct vs. replayed signatures. As I'm sure there are occasional cases where non-replay mail may re-use the same signature a substantial number of times, I suspect any potential mechanism based on this would need to be optional on both the signer and validator side, requiring no changes to existing infrastructure unless a signer or validator is interested in addressing this type of DKIM replay. Seems like that could satisfy the people seeking a solution, and those interested in avoiding any breaking changes. I get tons of mail that's just the same blast to everybody. The larger point is that we can't preclude that use case especially from a standards standpoint. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On Sat, Feb 4, 2023 at 10:15 AM Michael Thomas wrote: > Marketing email probably does. Whether it's spam or not is often in the > eye of the beholder. > Having spent some time in the industry, I can tell you that a significant majority of marketing email service providers will deliver a unique message, with a unique signature, for each individual recipient. DKIM replay, in its most problematic current form, repeats one signature, often millions of times or more. Even a very approximate count of h= or bh= hashes can be a useful signal to distinguish direct vs. replayed signatures. As I'm sure there are occasional cases where non-replay mail may re-use the same signature a substantial number of times, I suspect any potential mechanism based on this would need to be optional on both the signer and validator side, requiring no changes to existing infrastructure unless a signer or validator is interested in addressing this type of DKIM replay. Seems like that could satisfy the people seeking a solution, and those interested in avoiding any breaking changes. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On 2/4/23 9:20 AM, Evan Burke wrote: On Sat, Feb 4, 2023 at 8:47 AM Dave Crocker wrote: On 2/4/2023 8:41 AM, Scott Kitterman wrote: > I've yet to see a description of the problem that's distinguishable from a mailing list that preserves DKIM signatures. That seems like an especially healthy discussion to have. Focusing on, and seeking convergence about, the nature of the differences, could help consideration of the ways to counteract replay. In a word? Scale. Are there any mailing lists in existence that send tens of millions of messages a day, or more, in a way that preserves the original DKIM sig? Marketing email probably does. Whether it's spam or not is often in the eye of the beholder. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On February 4, 2023 5:20:27 PM UTC, Evan Burke wrote: >On Sat, Feb 4, 2023 at 8:47 AM Dave Crocker wrote: > >> On 2/4/2023 8:41 AM, Scott Kitterman wrote: >> > I've yet to see a description of the problem that's distinguishable from >> a mailing list that preserves DKIM signatures. >> >> That seems like an especially healthy discussion to have. Focusing on, >> and seeking convergence about, the nature of the differences, could help >> consideration of the ways to counteract replay. >> > >In a word? Scale. Are there any mailing lists in existence that send tens >of millions of messages a day, or more, in a way that preserves the >original DKIM sig? How does that attribute relate to DKIM protocol changes? Scott K ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On Sat, Feb 4, 2023 at 8:47 AM Dave Crocker wrote: > On 2/4/2023 8:41 AM, Scott Kitterman wrote: > > I've yet to see a description of the problem that's distinguishable from > a mailing list that preserves DKIM signatures. > > That seems like an especially healthy discussion to have. Focusing on, > and seeking convergence about, the nature of the differences, could help > consideration of the ways to counteract replay. > In a word? Scale. Are there any mailing lists in existence that send tens of millions of messages a day, or more, in a way that preserves the original DKIM sig? ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On 2/4/2023 8:41 AM, Scott Kitterman wrote: I've yet to see a description of the problem that's distinguishable from a mailing list that preserves DKIM signatures. That seems like an especially healthy discussion to have. Focusing on, and seeking convergence about, the nature of the differences, could help consideration of the ways to counteract replay. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On February 4, 2023 8:38:46 AM UTC, "Murray S. Kucherawy" wrote: >On Thu, Feb 2, 2023 at 3:26 PM Michael Thomas wrote: > >> I guess my concern is more along the lines of what solutions *aren't*. >> There are a bunch of drafts trying to tie the envelope to the email and I >> think there needs to be a meta discussion of whether that is a good idea or >> not in general. Frankly that seems like an email architecture question not >> just a DKIM question. It would be nice to know if there is precedent for >> that in the larger community and what the implications are. Fwiw, I don't >> really consider the DMARC "alignment" as tickling the larger question >> because all it is doing is reporting on it, but a case could certainly be >> made that it is. >> > >For what it's worth, the proposals that seek to offer a binding between the >envelope and the message aren't making any sort of mandatory change to >DKIM. It's entirely optional to the signer whether to make that connection >using one of those proposals; conventional DKIM isn't being taken off the >table. For instance, the idea I put forward suggests using two signatures, >one that makes the binding and a typical one that does not. Such a tactic >would leave the original signal about a message intact while possibly >providing more, which seems to me to be strictly an improvement. While literally true, I don't think it's accurate (if you assume the proposal gets significant uptake). If such a proposal gets a lot of traction, then the lack of such an additional signature becomes a negative sign about the message, which damages a lot of indirect mail flows. If this isn't the case, then there's no value in the additional signature. Without some way to distinguish 'good' replay, from 'bad', there will inevitably by negative side effects. I've yet to see a description of the problem that's distinguishable from a mailing list that preserves DKIM signatures. Scott K ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On Thu, Feb 2, 2023 at 3:26 PM Michael Thomas wrote: > I guess my concern is more along the lines of what solutions *aren't*. > There are a bunch of drafts trying to tie the envelope to the email and I > think there needs to be a meta discussion of whether that is a good idea or > not in general. Frankly that seems like an email architecture question not > just a DKIM question. It would be nice to know if there is precedent for > that in the larger community and what the implications are. Fwiw, I don't > really consider the DMARC "alignment" as tickling the larger question > because all it is doing is reporting on it, but a case could certainly be > made that it is. > For what it's worth, the proposals that seek to offer a binding between the envelope and the message aren't making any sort of mandatory change to DKIM. It's entirely optional to the signer whether to make that connection using one of those proposals; conventional DKIM isn't being taken off the table. For instance, the idea I put forward suggests using two signatures, one that makes the binding and a typical one that does not. Such a tactic would leave the original signal about a message intact while possibly providing more, which seems to me to be strictly an improvement. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On 2/2/23 4:06 PM, Scott Kitterman wrote: There is an existing draft of a problem statement, so there's at least a starting point to consider. I think discussion about what's needed is probably more useful relative to a specific draft than in the abstract: https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/ Other than removing the ARC references, this seems like a good start. I sort of like the proposed solution space, but several of them could be tried today or have huge downsides. Bcc, for example, would be a security fail if it were in the message headers. Caching signatures could be tried today but I don't see how that can be distinguished from, say, a mailing list. But it could be rewritten in terms of not solutions but possible angles to attack the problem with pros and cons. It may well be that a preponderance of evidence could be useful. We could list off a bunch of other possible clues too. For one, what is the reputation of the To: address's domain? There are surely more. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
There is an existing draft of a problem statement, so there's at least a starting point to consider. I think discussion about what's needed is probably more useful relative to a specific draft than in the abstract: https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/ Scott K On February 2, 2023 11:26:36 PM UTC, Michael Thomas wrote: > >On 2/2/23 3:18 PM, Tim Wicinski wrote: >> the problem statement should just bang out the problems in all their ugly >> glory. >> it should not attempt to suggest solutions, as that would be up to the >> working group >> to hammer out. >> >> (this is my opinion and of course am probably totally off base) > >I guess my concern is more along the lines of what solutions *aren't*. There >are a bunch of drafts trying to tie the envelope to the email and I think >there needs to be a meta discussion of whether that is a good idea or not in >general. Frankly that seems like an email architecture question not just a >DKIM question. It would be nice to know if there is precedent for that in the >larger community and what the implications are. Fwiw, I don't really consider >the DMARC "alignment" as tickling the larger question because all it is doing >is reporting on it, but a case could certainly be made that it is. > >Mike > >> >> >> On Thu, Feb 2, 2023 at 5:32 PM Michael Thomas wrote: >> >> >> On 2/2/23 2:16 PM, Tim Wicinski wrote: >>> >>> >>> On Thu, Feb 2, 2023 at 5:07 PM Michael Thomas wrote: >>> >>> >>> So here is what sticks in my craw. I think I brought up the >>> problem >>> statement, but maybe somebody else did before me. It's easy >>> to say "here >>> is the problem, fix it!" without any context to what any >>> proposed fixes >>> might break. It would be really bad imo to slap out a minimal >>> problem >>> statement and then proceed to solutions without any analysis >>> of what any >>> solution space should and should not do at a protocol level. >>> I guess >>> that's a little bit more requirement-y, but I'm not exactly >>> sure what >>> process-wise I'm asking for. DKIM is extremely widely >>> deployed so we >>> need to be really careful about not breaking existing >>> practices or doing >>> unnatural acts that have implications to the wider email >>> community. >>> >>> >>> My feeling part of the problem statement will be to document >>> various solutions >>> and how testing should be done and what to look for (breaking >>> existing practice would >>> be key). >>> >>> It may be that one solution is protocol rev which works outside >>> of current dkim. >>> We wrestled with this in the early days of DPRIVE - adding >>> additional encryption onto >>> DNS was viewed in a similar manner. >>> >>> >> I don't know if there is a formal IETF definitely of what >> constitutes a problem statement but it's easy to imagine a problem >> statement that... just states the problem. I don't think we have >> discussed what should actually be in scope for this problem >> statement. I guess we could suss that out before there are chairs, >> but obviously we'd need them to make consensus calls. >> >> Mike >> ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On 2/2/23 3:18 PM, Tim Wicinski wrote: the problem statement should just bang out the problems in all their ugly glory. it should not attempt to suggest solutions, as that would be up to the working group to hammer out. (this is my opinion and of course am probably totally off base) I guess my concern is more along the lines of what solutions *aren't*. There are a bunch of drafts trying to tie the envelope to the email and I think there needs to be a meta discussion of whether that is a good idea or not in general. Frankly that seems like an email architecture question not just a DKIM question. It would be nice to know if there is precedent for that in the larger community and what the implications are. Fwiw, I don't really consider the DMARC "alignment" as tickling the larger question because all it is doing is reporting on it, but a case could certainly be made that it is. Mike On Thu, Feb 2, 2023 at 5:32 PM Michael Thomas wrote: On 2/2/23 2:16 PM, Tim Wicinski wrote: On Thu, Feb 2, 2023 at 5:07 PM Michael Thomas wrote: So here is what sticks in my craw. I think I brought up the problem statement, but maybe somebody else did before me. It's easy to say "here is the problem, fix it!" without any context to what any proposed fixes might break. It would be really bad imo to slap out a minimal problem statement and then proceed to solutions without any analysis of what any solution space should and should not do at a protocol level. I guess that's a little bit more requirement-y, but I'm not exactly sure what process-wise I'm asking for. DKIM is extremely widely deployed so we need to be really careful about not breaking existing practices or doing unnatural acts that have implications to the wider email community. My feeling part of the problem statement will be to document various solutions and how testing should be done and what to look for (breaking existing practice would be key). It may be that one solution is protocol rev which works outside of current dkim. We wrestled with this in the early days of DPRIVE - adding additional encryption onto DNS was viewed in a similar manner. I don't know if there is a formal IETF definitely of what constitutes a problem statement but it's easy to imagine a problem statement that... just states the problem. I don't think we have discussed what should actually be in scope for this problem statement. I guess we could suss that out before there are chairs, but obviously we'd need them to make consensus calls. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
the problem statement should just bang out the problems in all their ugly glory. it should not attempt to suggest solutions, as that would be up to the working group to hammer out. (this is my opinion and of course am probably totally off base) On Thu, Feb 2, 2023 at 5:32 PM Michael Thomas wrote: > > On 2/2/23 2:16 PM, Tim Wicinski wrote: > > > > On Thu, Feb 2, 2023 at 5:07 PM Michael Thomas wrote: > >> >> So here is what sticks in my craw. I think I brought up the problem >> statement, but maybe somebody else did before me. It's easy to say "here >> is the problem, fix it!" without any context to what any proposed fixes >> might break. It would be really bad imo to slap out a minimal problem >> statement and then proceed to solutions without any analysis of what any >> solution space should and should not do at a protocol level. I guess >> that's a little bit more requirement-y, but I'm not exactly sure what >> process-wise I'm asking for. DKIM is extremely widely deployed so we >> need to be really careful about not breaking existing practices or doing >> unnatural acts that have implications to the wider email community. >> >> > My feeling part of the problem statement will be to document various > solutions > and how testing should be done and what to look for (breaking existing > practice would > be key). > > It may be that one solution is protocol rev which works outside of current > dkim. > We wrestled with this in the early days of DPRIVE - adding additional > encryption onto > DNS was viewed in a similar manner. > > > I don't know if there is a formal IETF definitely of what constitutes a > problem statement but it's easy to imagine a problem statement that... just > states the problem. I don't think we have discussed what should actually be > in scope for this problem statement. I guess we could suss that out before > there are chairs, but obviously we'd need them to make consensus calls. > > Mike > ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On 2/2/23 2:16 PM, Tim Wicinski wrote: On Thu, Feb 2, 2023 at 5:07 PM Michael Thomas wrote: So here is what sticks in my craw. I think I brought up the problem statement, but maybe somebody else did before me. It's easy to say "here is the problem, fix it!" without any context to what any proposed fixes might break. It would be really bad imo to slap out a minimal problem statement and then proceed to solutions without any analysis of what any solution space should and should not do at a protocol level. I guess that's a little bit more requirement-y, but I'm not exactly sure what process-wise I'm asking for. DKIM is extremely widely deployed so we need to be really careful about not breaking existing practices or doing unnatural acts that have implications to the wider email community. My feeling part of the problem statement will be to document various solutions and how testing should be done and what to look for (breaking existing practice would be key). It may be that one solution is protocol rev which works outside of current dkim. We wrestled with this in the early days of DPRIVE - adding additional encryption onto DNS was viewed in a similar manner. I don't know if there is a formal IETF definitely of what constitutes a problem statement but it's easy to imagine a problem statement that... just states the problem. I don't think we have discussed what should actually be in scope for this problem statement. I guess we could suss that out before there are chairs, but obviously we'd need them to make consensus calls. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On Thu, Feb 2, 2023 at 5:07 PM Michael Thomas wrote: > > On 2/2/23 8:22 AM, Murray S. Kucherawy wrote: > > Colleagues, > > > > The IESG is prepared to approve the charter overall. There was one > > blocking point about publishing the problem statement, which is that > > the IESG would like that not to be a "maybe". I think that's a > > reasonable change to make. > > > > There is also the fact that I have not secured co-chairs. I only have > > one volunteer, and I'd like to pair up that person with someone that's > > been an IETF working group chair before. I've approached a few people, > > all of whom have declined. We're stuck here until I can resolve that > > blank spot in the plan. > > > > If you have any suggestions, or have chaired before and are willing to > > volunteer, please feel free to reach out to me. > > > So here is what sticks in my craw. I think I brought up the problem > statement, but maybe somebody else did before me. It's easy to say "here > is the problem, fix it!" without any context to what any proposed fixes > might break. It would be really bad imo to slap out a minimal problem > statement and then proceed to solutions without any analysis of what any > solution space should and should not do at a protocol level. I guess > that's a little bit more requirement-y, but I'm not exactly sure what > process-wise I'm asking for. DKIM is extremely widely deployed so we > need to be really careful about not breaking existing practices or doing > unnatural acts that have implications to the wider email community. > > My feeling part of the problem statement will be to document various solutions and how testing should be done and what to look for (breaking existing practice would be key). It may be that one solution is protocol rev which works outside of current dkim. We wrestled with this in the early days of DPRIVE - adding additional encryption onto DNS was viewed in a similar manner. tim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On 2/2/23 8:22 AM, Murray S. Kucherawy wrote: Colleagues, The IESG is prepared to approve the charter overall. There was one blocking point about publishing the problem statement, which is that the IESG would like that not to be a "maybe". I think that's a reasonable change to make. There is also the fact that I have not secured co-chairs. I only have one volunteer, and I'd like to pair up that person with someone that's been an IETF working group chair before. I've approached a few people, all of whom have declined. We're stuck here until I can resolve that blank spot in the plan. If you have any suggestions, or have chaired before and are willing to volunteer, please feel free to reach out to me. So here is what sticks in my craw. I think I brought up the problem statement, but maybe somebody else did before me. It's easy to say "here is the problem, fix it!" without any context to what any proposed fixes might break. It would be really bad imo to slap out a minimal problem statement and then proceed to solutions without any analysis of what any solution space should and should not do at a protocol level. I guess that's a little bit more requirement-y, but I'm not exactly sure what process-wise I'm asking for. DKIM is extremely widely deployed so we need to be really careful about not breaking existing practices or doing unnatural acts that have implications to the wider email community. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] Chartering update
Colleagues, The IESG is prepared to approve the charter overall. There was one blocking point about publishing the problem statement, which is that the IESG would like that not to be a "maybe". I think that's a reasonable change to make. There is also the fact that I have not secured co-chairs. I only have one volunteer, and I'd like to pair up that person with someone that's been an IETF working group chair before. I've approached a few people, all of whom have declined. We're stuck here until I can resolve that blank spot in the plan. If you have any suggestions, or have chaired before and are willing to volunteer, please feel free to reach out to me. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
