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
Re: [Ietf-dkim] Lars Eggert's Block on charter-ietf-dkim-04-05: (with BLOCK and COMMENT)
On Tue, Jan 31, 2023 at 7:23 PM Murray S. Kucherawy wrote: > On Tue, Jan 31, 2023 at 2:12 PM Michael Thomas wrote: > >> Also: the date on the problem statement seems awfully aggressive. My >> thinking is that the problem statement should at least discuss (as is >> mentioned in the charter) how "replays" are completely legitimate uses >> of DKIM, and thus limit the solution space to not break those uses. >> > > Milestones are negotiable, and the one(s) I used for this are largely dart > throws. We can change them to be something more practical once chairs have > been secured. > We can move up discussing the problem statement document if it hinders chartering. I've been working on that document and can push out a new draft soon. -Wei > > -MSK > > ___ > 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
