Re: [Ietf-dkim] Rechartering

[Michael Thomas]

On 1/12/23 10:52 AM, Murray S. Kucherawy wrote:

On Mon, Jan 9, 2023 at 12:57 AM Alessandro Vesely  wrote:

On Thu 05/Jan/2023 22:26:32 +0100 Dave Crocker wrote:
> On 1/5/2023 9:20 AM, Alessandro Vesely wrote:
>> How about "replay-resistant protocol"?
>
> btw, it isn't clear that 'protocol' is what a solution will be.
might be.
> might not.  might be purely operational conventions, for example.

That's right.  "Replay-resistant solution"?


The current charter text says "replay-resistant mechanisms", which 
avoids constraining us only to protocol solutions.


I'm not seeing any other proposed changes to the charter; the 
milestones are negotiable in flight so they don't need to be perfect 
out of the starting gate, but suggestions there are welcome.


Absent any other proposed changes to the charter's text, I'll release 
this for the next phase of review ("External Review", i.e., the whole 
IETF) in the next few days.


it would still be good to make explicit that the drafts mentioned are 
not the only ones on the table.


Mike
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Mon, Jan 9, 2023 at 12:57 AM Alessandro Vesely  wrote:

> On Thu 05/Jan/2023 22:26:32 +0100 Dave Crocker wrote:
> > On 1/5/2023 9:20 AM, Alessandro Vesely wrote:
> >> How about "replay-resistant protocol"?
> >
> > btw, it isn't clear that 'protocol' is what a solution will be. might
> be.
> > might not.  might be purely operational conventions, for example.
>
> That's right.  "Replay-resistant solution"?
>

The current charter text says "replay-resistant mechanisms", which avoids
constraining us only to protocol solutions.

I'm not seeing any other proposed changes to the charter; the milestones
are negotiable in flight so they don't need to be perfect out of the
starting gate, but suggestions there are welcome.

Absent any other proposed changes to the charter's text, I'll release this
for the next phase of review ("External Review", i.e., the whole IETF) in
the next few days.

-MSK, ART AD
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 1/9/2023 12:51 AM, Alessandro Vesely wrote:
2. We could focus only on the know replay efforts so far, independent 
of type or degree of threat.


3. We could focus only on known, significant replay efforts.

4. and so on...

Of these, only 4 ensures focused, pragmatic efforts,



Eh?  You mean the "and so on..."?


Sorry.  I meant 3.

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] Rechartering

[Alessandro Vesely]

On Thu 05/Jan/2023 22:26:32 +0100 Dave Crocker wrote:

On 1/5/2023 9:20 AM, Alessandro Vesely wrote:
How about "replay-resistant protocol"? 


btw, it isn't clear that 'protocol' is what a solution will be. might be.  
might not.  might be purely operational conventions, for example.



That's right.  "Replay-resistant solution"?


Best
Ale
--





___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Alessandro Vesely]

On Thu 05/Jan/2023 20:35:00 +0100 Dave Crocker wrote:

On 1/5/2023 11:03 AM, Wei Chuang wrote:



 2. Are there any other kinds of replay scenarios that are an issue now?
I suspect there aren't.


While not exactly ARC replay, we've seen recently that spammers are exploring 
munging the ARC headers.  One campaign had them swapping a complete ARC 
header set into another message.  In another they added an incomplete set.  
Consequently we're worried about the spammers exploiting ARC vulnerabilities.


There are some possibilities this suggests.

1. We could seek to explore and counter-act all (or a wide range) of replay 
scenarios, independent of their type or actual presence.  That is, both replays 
that are present in the wild and replays that are merely deemed possible, no 
matter how or why they do or might occur.



Well, that sounds like the best strategy in the long term, doesn't it?

For example, suppose we can sort out the few legitimate forwarding flows. 
Then, we could reject all mail where the envelope recipient doesn't match a To: 
or Cc: mailbox.  That would counter the vast majority of replay attacks.  And 
the techniques for doing so are much less tangled than signing the envelope.


Some times it is worth addressing the real weaknesses of a system, rather than 
some of the specific attack paths.



2. We could focus only on the know replay efforts so far, independent of type 
or degree of threat.


3. We could focus only on known, significant replay efforts.

4. and so on...

Of these, only 4 ensures focused, pragmatic efforts,



Eh?  You mean the "and so on..."?


Best
Ale
--






___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 1/5/2023 9:20 AM, Alessandro Vesely wrote:
How about "replay-resistant protocol"? 


btw, it isn't clear that 'protocol' is what a solution will be. might 
be.  might not.  might be purely operational conventions, for example.


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] Rechartering

[Michael Thomas]

On 1/5/23 10:17 AM, Wei Chuang wrote:



On Thu, Jan 5, 2023 at 10:06 AM Michael Thomas  wrote:


On 1/5/23 9:20 AM, Alessandro Vesely wrote:
> On Thu 05/Jan/2023 17:33:36 +0100 Murray S. Kucherawy wrote:
>> I've added a few proposed milestones with dates
>
> I wouldn't call "replay-resistant DKIM enhancement(s)" the
> deliverable.  I understand the WG name is DKIM, but two of the
> proposed drafts don't even mention it.  We may call ARC a "kind of
> DKIM", but a solution based on it would be better called an ARC
> enhancement, no?
>
> How about "replay-resistant protocol"?
>
Sorry, ARC is a failed experiment that doesn't deliver what it was
supposed to deliver.


I disagree that it's a failed experiment.  We're using ARC results for 
forwarders who choose to generate them.
Well, it doesn't do what it was purported to do. That and it doesn't do 
anything that DKIM couldn't do in the first place since nobody can say 
why the seal is actually needed.


The DKIM wg should have no part of it. It should be
completely out of scope.


I agree with Alessandro's proposed language change that allows for 
ARC.  Moreover ARC is subject to the same replay issue as DKIM and 
needs some sort of fix.


DKIM is a full internet standard and ARC is an experiment. This is the 
DKIM wg. ARC had no problem copying the DKIM output. Nothing that 
happens here will change that.


It's bad enough that this wg is considering doing unnatural acts with 
the envelope, it would be even worse to require it down a rat hole of a 
failed experiment.


Mike
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 1/5/2023 11:03 AM, Wei Chuang wrote:



1. The motivation for the current effort has been exploitation of
re-posting to exploit a DKIM reputation.

2. Are there any other kinds of replay scenarios that are an issue
now?
I suspect there aren't.


While not exactly ARC replay, we've seen recently that spammers are 
exploring munging the ARC headers.  One campaign had them swapping a 
complete ARC header set into another message.  In another they added 
an incomplete set.  Consequently we're worried about the spammers 
exploiting ARC vulnerabilities.


There are some possibilities this suggests.

1. We could seek to explore and counter-act all (or a wide range) of 
replay scenarios, independent of their type or actual presence.  That 
is, both replays that are present in the wild and replays that are 
merely deemed possible, no matter how or why they do or might occur.


2. We could focus only on the know replay efforts so far, independent of 
type or degree of threat.


3. We could focus only on known, significant replay efforts.

4. and so on...

Of these, only 4 ensures focused, pragmatic efforts, where there is 
actual pressure to find a remedy sooner rather than later.


The others seem more like research topics.

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] Rechartering

[Wei Chuang]

On Thu, Jan 5, 2023 at 10:43 AM Dave Crocker  wrote:

> On 1/5/2023 9:20 AM, Alessandro Vesely wrote:
> > I wouldn't call "replay-resistant DKIM enhancement(s)" the
> > deliverable.  I understand the WG name is DKIM, but two of the
> > proposed drafts don't even mention it.  We may call ARC a "kind of
> > DKIM", but a solution based on it would be better called an ARC
> > enhancement, no?
> >
> > How about "replay-resistant protocol"?
>
> Just to explore this a bit further:
>
> 1. The motivation for the current effort has been exploitation of
> re-posting to exploit a DKIM reputation.
>
> 2. Are there any other kinds of replay scenarios that are an issue now?
> I suspect there aren't.
>

While not exactly ARC replay, we've seen recently that spammers are
exploring munging the ARC headers.  One campaign had them swapping a
complete ARC header set into another message.  In another they added an
incomplete set.  Consequently we're worried about the spammers exploiting
ARC vulnerabilities.

-Wei


> 3. Whatever mechanisms are developed to prevent or mitigate replay,
> their current use will be to deal with a DKIM-related replay problem.
>
> It's likely to be useful for the working group name to relate to a
> specific, real and current problem, even if a technical solution doesn't
> explicitly deal with the technical details of that problem.
>
> 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
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 1/5/2023 9:20 AM, Alessandro Vesely wrote:
I wouldn't call "replay-resistant DKIM enhancement(s)" the 
deliverable.  I understand the WG name is DKIM, but two of the 
proposed drafts don't even mention it.  We may call ARC a "kind of 
DKIM", but a solution based on it would be better called an ARC 
enhancement, no?


How about "replay-resistant protocol"? 


Just to explore this a bit further:

1. The motivation for the current effort has been exploitation of 
re-posting to exploit a DKIM reputation.


2. Are there any other kinds of replay scenarios that are an issue now?  
I suspect there aren't.


3. Whatever mechanisms are developed to prevent or mitigate replay, 
their current use will be to deal with a DKIM-related replay problem.


It's likely to be useful for the working group name to relate to a 
specific, real and current problem, even if a technical solution doesn't 
explicitly deal with the technical details of that problem.


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] Rechartering

[Wei Chuang]

On Thu, Jan 5, 2023 at 10:06 AM Michael Thomas  wrote:

>
> On 1/5/23 9:20 AM, Alessandro Vesely wrote:
> > On Thu 05/Jan/2023 17:33:36 +0100 Murray S. Kucherawy wrote:
> >> I've added a few proposed milestones with dates
> >
> > I wouldn't call "replay-resistant DKIM enhancement(s)" the
> > deliverable.  I understand the WG name is DKIM, but two of the
> > proposed drafts don't even mention it.  We may call ARC a "kind of
> > DKIM", but a solution based on it would be better called an ARC
> > enhancement, no?
> >
> > How about "replay-resistant protocol"?
> >
> Sorry, ARC is a failed experiment that doesn't deliver what it was
> supposed to deliver.


I disagree that it's a failed experiment.  We're using ARC results for
forwarders who choose to generate them.


> The DKIM wg should have no part of it. It should be
> completely out of scope.
>

I agree with Alessandro's proposed language change that allows for ARC.
Moreover ARC is subject to the same replay issue as DKIM and needs some
sort of fix.

-Wei


>
> Mike
>
> ___
> 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

Re: [Ietf-dkim] Rechartering

[Michael Thomas]

On 1/5/23 9:20 AM, Alessandro Vesely wrote:

On Thu 05/Jan/2023 17:33:36 +0100 Murray S. Kucherawy wrote:

I've added a few proposed milestones with dates


I wouldn't call "replay-resistant DKIM enhancement(s)" the 
deliverable.  I understand the WG name is DKIM, but two of the 
proposed drafts don't even mention it.  We may call ARC a "kind of 
DKIM", but a solution based on it would be better called an ARC 
enhancement, no?


How about "replay-resistant protocol"?

Sorry, ARC is a failed experiment that doesn't deliver what it was 
supposed to deliver. The DKIM wg should have no part of it. It should be 
completely out of scope.


Mike

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Alessandro Vesely]

On Thu 05/Jan/2023 17:33:36 +0100 Murray S. Kucherawy wrote:

I've added a few proposed milestones with dates


I wouldn't call "replay-resistant DKIM enhancement(s)" the deliverable.  I 
understand the WG name is DKIM, but two of the proposed drafts don't even 
mention it.  We may call ARC a "kind of DKIM", but a solution based on it would 
be better called an ARC enhancement, no?


How about "replay-resistant protocol"?


Best
Ale
--





___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Sat, Dec 31, 2022 at 3:02 PM Murray S. Kucherawy 
wrote:

> On Sat, Dec 31, 2022 at 2:43 PM Dave Crocker  wrote:
>
>> The initial effort to form a working group in the IETF was pretty casual
>> and surfaced a lack of sufficient consensus among advocates.  The IETF
>> said go away until there's more agreement.
>>
>> We went away for a year, during which we developed the original version
>> of DKIM, which demonstrated the coherence.
>>
>> The current effort has none of that existing critical mass of work and
>> agreement.  This makes the effort quite a lot riskier.
>>
>> The fact that things are taking quite a few months doesn't help.
>>
>
> That's true.  I'd forgotten this bit of the history.
>
> If we think this constraint is appropriate, I'm fine to include it.  Does
> someone want to propose a sentence or two?  I need to avoid getting my
> wrist slapped for both championing the charter and writing it.
>

The IESG approved the proposed charter to go out for external review.  I've
added a few proposed milestones with dates (these can be edited later) and
taken a run at editing the text to add the constraints people were
proposing.  Please review and let me know if I got it wrong or missed any
feedback, or if the dates on the milestones are not realistic.  They were
selected on the assumption that we charter and have co-chairs in place by
the end of January.

https://datatracker.ietf.org/doc/charter-ietf-dkim/

Lastly, I have one co-chair volunteer, but I need a second, preferably
someone who has chaired something in the IETF before.  Please let me know
if you'd like to either volunteer or nominate someone.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Michael Thomas]

On 1/3/23 1:55 PM, Wei Chuang wrote:


So yes this was discussed and started at a M3AAWG BoF (at M3AAWG 56 in 
Oct 2022) that discussed DKIM replay.  As by that point there were 
several drafts with proposed solutions, the suggestion from feedback 
at the BoF was to send this work to IETF Dispatch.  This work was 
presented at IETF 115 (Nov 2022) and the Dispatch slides 
 
are largely derived from the BoF slides i.e. summarized to fit in 
Dispatch time limit.  The set of drafts mentioned at the BoF and 
Dispatch, are cited in the proposed DKIM WG charter 
.


Thanks for the slides. So it seems that two or three of the drafts are 
proposing to do something with the envelope, one is the signature 
stripping thing, one is counting which is in BCP territory and I didn't 
understand the last one. The envelope stuff seems pretty scary to me, 
and the stripping is easy to work around.


One thing that occurs to me is that the reputation of the 822.To domain 
could be interesting for his problem. That is, if they are sending it 
from somebody with good reputation to a mailbox on a domain with 
bad/little reputation, that might be a signal that it's suspicious. From 
what you're saying, mailing lists, etc, accrue reputation? So they would 
be less suspect after a while. Clearly in BCP land, but unless it's 
actually been tried there's no Best to write about. I haven't really 
thought this through, just wanted to throw this out there.


Mike
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Wei Chuang]

On Tue, Jan 3, 2023 at 1:38 PM Todd Herr  wrote:

> On Tue, Jan 3, 2023 at 4:04 PM Michael Thomas  wrote:
>
>> Yet another reason why I'm skeptical. If there were a viable protocol
>> solution to this, why hasn't M3AAWG found it? Why re-spin up a working
>> group with a what appears to be a greenfield solution space if an active
>> industry working group hasn't chimed in? If there were some viable protocol
>> solution, I would expect they would at least put it forward. Working groups
>> are infinitely more productive if there is some collective agreement about
>> the general parameters of a solution, even if the particulars need to be
>> vetted. The couple of solutions I've seen thus far are either trivially
>> breakable (= striping signatures at MDA's), or frightening to contemplate
>> what they'd break (= tying envelope to message). That doesn't give me the
>> warm fuzzies about any protocol level solution.
>>
>> Also: if they are indeed working on a BCP, it would be far better to use
>> that as input rather than reinventing wheels.
>>
> While I wouldn't presume to speak for M3AAWG, and although some M3AAWG
> work products have been used as inputs to the IETF process (such as RFC
> 6449, to cite but one example), and although there are many people that are
> active both in M3AAWG and the IETF, it's my sense that M3AAWG doesn't see
> itself as a body that proposes changes to existing protocols. Rather, I've
> always seen M3AAWG as an organization that primarily figures out the best
> way to make use of existing protocols and publishes documents describing
> those best uses in the fight against messaging and other abuse.
>
> I'm not at liberty to speak about the content of current M3AAWG work on
> the topic of DKIM replay attacks or what direction that work has taken, but
> everything I've seen so far has been recommendations to do things already
> permitted by the protocols in existence, recommendations that have almost
> certainly been implemented by a number of M3AAWG member companies. Those
> recommendations are not bulletproof, however, and so people have come here
> to see if there might be a forum for defining updates to the DKIM protocol
> that might make it more resistant to replay attacks.
>

+1

So yes this was discussed and started at a M3AAWG BoF (at M3AAWG 56 in Oct
2022) that discussed DKIM replay.  As by that point there were several
drafts with proposed solutions, the suggestion from feedback at the BoF was
to send this work to IETF Dispatch.  This work was presented at IETF 115
(Nov 2022) and the Dispatch slides

are largely derived from the BoF slides i.e. summarized to fit in Dispatch
time limit.  The set of drafts mentioned at the BoF and Dispatch, are cited
in the proposed DKIM WG charter
.

-Wei


smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Todd Herr]

On Tue, Jan 3, 2023 at 4:04 PM Michael Thomas  wrote:

> Yet another reason why I'm skeptical. If there were a viable protocol
> solution to this, why hasn't M3AAWG found it? Why re-spin up a working
> group with a what appears to be a greenfield solution space if an active
> industry working group hasn't chimed in? If there were some viable protocol
> solution, I would expect they would at least put it forward. Working groups
> are infinitely more productive if there is some collective agreement about
> the general parameters of a solution, even if the particulars need to be
> vetted. The couple of solutions I've seen thus far are either trivially
> breakable (= striping signatures at MDA's), or frightening to contemplate
> what they'd break (= tying envelope to message). That doesn't give me the
> warm fuzzies about any protocol level solution.
>
> Also: if they are indeed working on a BCP, it would be far better to use
> that as input rather than reinventing wheels.
>
While I wouldn't presume to speak for M3AAWG, and although some M3AAWG work
products have been used as inputs to the IETF process (such as RFC 6449, to
cite but one example), and although there are many people that are active
both in M3AAWG and the IETF, it's my sense that M3AAWG doesn't see itself
as a body that proposes changes to existing protocols. Rather, I've always
seen M3AAWG as an organization that primarily figures out the best way to
make use of existing protocols and publishes documents describing those
best uses in the fight against messaging and other abuse.

I'm not at liberty to speak about the content of current M3AAWG work on the
topic of DKIM replay attacks or what direction that work has taken, but
everything I've seen so far has been recommendations to do things already
permitted by the protocols in existence, recommendations that have almost
certainly been implemented by a number of M3AAWG member companies. Those
recommendations are not bulletproof, however, and so people have come here
to see if there might be a forum for defining updates to the DKIM protocol
that might make it more resistant to replay attacks.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Michael Thomas]

On 1/3/23 8:59 AM, Todd Herr wrote:

On Mon, Jan 2, 2023 at 3:04 PM Evan Burke  wrote:



On Sat, Dec 31, 2022 at 10:44 PM Wei Chuang
 wrote:
> I'm worried about duplicating work unnecessarily as the M3AAWG
has an email authentication BCP.  If the WG to-be indeed does want
to generate the BCP, perhaps the M3AAWG document can be the basis
for an IETF document assuming M3AAWG is okay with that, or the WG
can partner with M3AAWG to produce a common document.  I think
both are possible as there's a fair amount of people overlapping
between the IETF and M3AAWG, and I know that M3AAWG
organizationally wants to help here.

I believe there's a revision underway for the general M3AAWG auth
BCP doc, which will include a handful of sender-focused
recommendations for reducing the viability of replay attacks.
There is also a DKIM replay specific M3 BCP doc in progress with
more in-depth recommendations.


Evan is correct on this point; there is a revision underway for the 
general M3AAWG auth BCP doc, for some values of "underway", anyway.


I'm the person who's taken on the responsibility for authoring said 
revisions, but I've been waiting for the M3AAWG DKIM Replay work to 
produce something tangible to ensure that what I write doesn't 
conflict with that work.


Yet another reason why I'm skeptical. If there were a viable protocol 
solution to this, why hasn't M3AAWG found it? Why re-spin up a working 
group with a what appears to be a greenfield solution space if an active 
industry working group hasn't chimed in? If there were some viable 
protocol solution, I would expect they would at least put it forward. 
Working groups are infinitely more productive if there is some 
collective agreement about the general parameters of a solution, even if 
the particulars need to be vetted. The couple of solutions I've seen 
thus far are either trivially breakable (= striping signatures at 
MDA's), or frightening to contemplate what they'd break (= tying 
envelope to message). That doesn't give me the warm fuzzies about any 
protocol level solution.


Also: if they are indeed working on a BCP, it would be far better to use 
that as input rather than reinventing wheels.


Mike
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Todd Herr]

On Mon, Jan 2, 2023 at 3:04 PM Evan Burke  wrote:

>
>
> On Sat, Dec 31, 2022 at 10:44 PM Wei Chuang  40google@dmarc.ietf.org> wrote:
> >  I'm worried about duplicating work unnecessarily as the M3AAWG has an
> email authentication BCP.  If the WG to-be indeed does want to generate the
> BCP, perhaps the M3AAWG document can be the basis for an IETF document
> assuming M3AAWG is okay with that, or the WG can partner with M3AAWG to
> produce a common document.  I think both are possible as there's a fair
> amount of people overlapping between the IETF and M3AAWG, and I know that
> M3AAWG organizationally wants to help here.
>
> I believe there's a revision underway for the general M3AAWG auth BCP doc,
> which will include a handful of sender-focused recommendations for reducing
> the viability of replay attacks. There is also a DKIM replay specific M3
> BCP doc in progress with more in-depth recommendations.
>
>
Evan is correct on this point; there is a revision underway for the general
M3AAWG auth BCP doc, for some values of "underway", anyway.

I'm the person who's taken on the responsibility for authoring said
revisions, but I've been waiting for the M3AAWG DKIM Replay work to produce
something tangible to ensure that what I write doesn't conflict with that
work.
-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Evan Burke]

On Sat, Dec 31, 2022 at 10:44 PM Wei Chuang  wrote:
>  I'm worried about duplicating work unnecessarily as the M3AAWG has an
email authentication BCP.  If the WG to-be indeed does want to generate the
BCP, perhaps the M3AAWG document can be the basis for an IETF document
assuming M3AAWG is okay with that, or the WG can partner with M3AAWG to
produce a common document.  I think both are possible as there's a fair
amount of people overlapping between the IETF and M3AAWG, and I know that
M3AAWG organizationally wants to help here.

I believe there's a revision underway for the general M3AAWG auth BCP doc,
which will include a handful of sender-focused recommendations for reducing
the viability of replay attacks. There is also a DKIM replay specific M3
BCP doc in progress with more in-depth recommendations.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Wei Chuang]

On Sat, Dec 31, 2022 at 4:18 PM Michael Thomas  wrote:

>
> On 12/31/22 2:37 PM, Murray S. Kucherawy wrote:
>
> On Sat, Dec 31, 2022 at 1:09 PM Michael Thomas  wrote:
>
>>
>> On 12/29/22 7:20 PM, Murray S. Kucherawy wrote:
>>
>> On Sun, Dec 25, 2022 at 4:14 PM Michael Thomas  wrote:
>>
>>>
>>>
>>> Done, and thanks for that text.
>>>
>>> One nit, Barry's text should be above the proposals not below. It makes
>>> it look like those are the only proposals on the table which I'm nearly
>>> certain is not your intent.
>>>
>> One other thing though, should there be some bounds on what appears to be
>>> the possibility of writing a BCP like document? I mean, I can think of some
>>> things that could help mitigate this but they are pretty wonky and
>>> definitely untested. Do we actually have that operational experience to
>>> recommend anything?
>>>
>>
>> The charter as-is is now up for IESG Evaluation and one AD has already
>> commented on it, so I'm going to hold any edits until after the next
>> telechat (on January 5th) so as not to give them a moving target.  After
>> that I'll apply this and any other feedback.
>>
>> That's fine, but we can talk about it in the mean time, right? I'm not
>> suggesting a specific change on the BCP part because I'm not exactly sure
>> what we should do. I know that it seems "obvious" but it also seems to me
>> that we could get out in the weeds really easy and recommend stuff that we
>> probably shouldn't. That's what I'm struggling with respect to "bounds".
>> I'm not sure that we have the operational knowledge -- or more likely
>> operational knowledge that can be shared -- to recommend something?
>>
> I expect that one of two things will happen: (1) We will attract a
> sufficiently broad set of contributors that whatever consensus they come up
> with will be defensible because it collectively has the operational
> knowledge and expertise to make appropriate BCP-style recommendations to
> the industry, or (2) we will not, and we'll know it, and thus we'll know we
> can't produce defensible advice suitable for publication.
>
> Maybe we can put the same constraint on this as we do for protocol work
> going forward as in having a step which determines whether there is a 1)
> plausible route forward or not and 2) whether it's really within the scope
> of what IETF can recommend. Sort of the same A/B switch.
>
> Mike
>
I'm worried about duplicating work unnecessarily as the M3AAWG has an email
authentication BCP.  If the WG to-be indeed does want to generate the BCP,
perhaps the M3AAWG document can be the basis for an IETF document assuming
M3AAWG is okay with that, or the WG can partner with M3AAWG to produce a
common document.  I think both are possible as there's a fair amount of
people overlapping between the IETF and M3AAWG, and I know that M3AAWG
organizationally wants to help here.

That said, I think a BCP around the existing email authentication standards
can only provide workarounds that can be bypassed by spammers i.e. new
standards are needed to properly mitigate the current risk.
-Wei

>
> ___
> 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

Re: [Ietf-dkim] Rechartering

[Michael Thomas]

On 12/31/22 2:37 PM, Murray S. Kucherawy wrote:

On Sat, Dec 31, 2022 at 1:09 PM Michael Thomas  wrote:


On 12/29/22 7:20 PM, Murray S. Kucherawy wrote:

On Sun, Dec 25, 2022 at 4:14 PM Michael Thomas  wrote:




Done, and thanks for that text.


One nit, Barry's text should be above the proposals not
below. It makes it look like those are the only proposals on
the table which I'm nearly certain is not your intent.

One other thing though, should there be some bounds on what
appears to be the possibility of writing a BCP like document?
I mean, I can think of some things that could help mitigate
this but they are pretty wonky and definitely untested. Do we
actually have that operational experience to recommend anything?


The charter as-is is now up for IESG Evaluation and one AD has
already commented on it, so I'm going to hold any edits until
after the next telechat (on January 5th) so as not to give them a
moving target.  After that I'll apply this and any other feedback.


That's fine, but we can talk about it in the mean time, right? I'm
not suggesting a specific change on the BCP part because I'm not
exactly sure what we should do. I know that it seems "obvious" but
it also seems to me that we could get out in the weeds really easy
and recommend stuff that we probably shouldn't. That's what I'm
struggling with respect to "bounds". I'm not sure that we have the
operational knowledge -- or more likely operational knowledge that
can be shared -- to recommend something?

I expect that one of two things will happen: (1) We will attract a 
sufficiently broad set of contributors that whatever consensus they 
come up with will be defensible because it collectively has the 
operational knowledge and expertise to make appropriate BCP-style 
recommendations to the industry, or (2) we will not, and we'll know 
it, and thus we'll know we can't produce defensible advice suitable 
for publication.


Maybe we can put the same constraint on this as we do for protocol work 
going forward as in having a step which determines whether there is a 1) 
plausible route forward or not and 2) whether it's really within the 
scope of what IETF can recommend. Sort of the same A/B switch.


Mike

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 12/31/2022 3:02 PM, Murray S. Kucherawy wrote:
If we think this constraint is appropriate, I'm fine to include it. 
Does someone want to propose a sentence or two?  I need to avoid 
getting my wrist slapped for both championing the charter and writing it.


Murray,

Sorry but I don't know what constraint you mean.  I was describing some 
history.  (I think the Thaler report supports that model)  But it's not 
typically a requirement.


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] Rechartering

[Murray S. Kucherawy]

On Sat, Dec 31, 2022 at 2:43 PM Dave Crocker  wrote:

> The initial effort to form a working group in the IETF was pretty casual
> and surfaced a lack of sufficient consensus among advocates.  The IETF
> said go away until there's more agreement.
>
> We went away for a year, during which we developed the original version
> of DKIM, which demonstrated the coherence.
>
> The current effort has none of that existing critical mass of work and
> agreement.  This makes the effort quite a lot riskier.
>
> The fact that things are taking quite a few months doesn't help.
>

That's true.  I'd forgotten this bit of the history.

If we think this constraint is appropriate, I'm fine to include it.  Does
someone want to propose a sentence or two?  I need to avoid getting my
wrist slapped for both championing the charter and writing it.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 12/31/2022 2:37 PM, Murray S. Kucherawy wrote:
I take as evidence of this the fact that the first incarnation of the 
DKIM working group knew itself well enough to completely avoid the 
topic of user interfaces, for example.


The initial effort to form a working group in the IETF was pretty casual 
and surfaced a lack of sufficient consensus among advocates.  The IETF 
said go away until there's more agreement.


We went away for a year, during which we developed the original version 
of DKIM, which demonstrated the coherence.


The current effort has none of that existing critical mass of work and 
agreement.  This makes the effort quite a lot riskier.


The fact that things are taking quite a few months doesn't help.

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] Rechartering

[Murray S. Kucherawy]

On Sat, Dec 31, 2022 at 1:09 PM Michael Thomas  wrote:

>
> On 12/29/22 7:20 PM, Murray S. Kucherawy wrote:
>
> On Sun, Dec 25, 2022 at 4:14 PM Michael Thomas  wrote:
>
>>
>>
>> Done, and thanks for that text.
>>
>> One nit, Barry's text should be above the proposals not below. It makes
>> it look like those are the only proposals on the table which I'm nearly
>> certain is not your intent.
>>
> One other thing though, should there be some bounds on what appears to be
>> the possibility of writing a BCP like document? I mean, I can think of some
>> things that could help mitigate this but they are pretty wonky and
>> definitely untested. Do we actually have that operational experience to
>> recommend anything?
>>
>
> The charter as-is is now up for IESG Evaluation and one AD has already
> commented on it, so I'm going to hold any edits until after the next
> telechat (on January 5th) so as not to give them a moving target.  After
> that I'll apply this and any other feedback.
>
> That's fine, but we can talk about it in the mean time, right? I'm not
> suggesting a specific change on the BCP part because I'm not exactly sure
> what we should do. I know that it seems "obvious" but it also seems to me
> that we could get out in the weeds really easy and recommend stuff that we
> probably shouldn't. That's what I'm struggling with respect to "bounds".
> I'm not sure that we have the operational knowledge -- or more likely
> operational knowledge that can be shared -- to recommend something?
>
I expect that one of two things will happen: (1) We will attract a
sufficiently broad set of contributors that whatever consensus they come up
with will be defensible because it collectively has the operational
knowledge and expertise to make appropriate BCP-style recommendations to
the industry, or (2) we will not, and we'll know it, and thus we'll know we
can't produce defensible advice suitable for publication.

I don't know off the top of my head what charter text I need to add to
capture this.  This is how consensus works, in my mind.  I take as evidence
of this the fact that the first incarnation of the DKIM working group knew
itself well enough to completely avoid the topic of user interfaces, for
example.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Michael Thomas]

On 12/29/22 7:20 PM, Murray S. Kucherawy wrote:

On Sun, Dec 25, 2022 at 4:14 PM Michael Thomas  wrote:




Done, and thanks for that text.


One nit, Barry's text should be above the proposals not below. It
makes it look like those are the only proposals on the table which
I'm nearly certain is not your intent.

One other thing though, should there be some bounds on what
appears to be the possibility of writing a BCP like document? I
mean, I can think of some things that could help mitigate this but
they are pretty wonky and definitely untested. Do we actually have
that operational experience to recommend anything?


The charter as-is is now up for IESG Evaluation and one AD has already 
commented on it, so I'm going to hold any edits until after the next 
telechat (on January 5th) so as not to give them a moving target.  
After that I'll apply this and any other feedback.


That's fine, but we can talk about it in the mean time, right? I'm not 
suggesting a specific change on the BCP part because I'm not exactly 
sure what we should do. I know that it seems "obvious" but it also seems 
to me that we could get out in the weeds really easy and recommend stuff 
that we probably shouldn't. That's what I'm struggling with respect to 
"bounds". I'm not sure that we have the operational knowledge -- or more 
likely operational knowledge that can be shared -- to recommend something?


Mike
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Sun, Dec 25, 2022 at 4:14 PM Michael Thomas  wrote:

>
>
> Done, and thanks for that text.
>
> One nit, Barry's text should be above the proposals not below. It makes it
> look like those are the only proposals on the table which I'm nearly
> certain is not your intent.
>
One other thing though, should there be some bounds on what appears to be
> the possibility of writing a BCP like document? I mean, I can think of some
> things that could help mitigate this but they are pretty wonky and
> definitely untested. Do we actually have that operational experience to
> recommend anything?
>

The charter as-is is now up for IESG Evaluation and one AD has already
commented on it, so I'm going to hold any edits until after the next
telechat (on January 5th) so as not to give them a moving target.  After
that I'll apply this and any other feedback.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Michael Thomas]

On 12/25/22 7:55 AM, Murray S. Kucherawy wrote:
On Sun, Dec 25, 2022 at 6:31 AM Barry Leiba  
wrote:


I agree with Mike and Scott on the point that it’s worth
explicitly allowing the result to be a “can’t do it” publication. 
Implicit “couldn’t do it” is fine in most cases, but here we might
say something like, “If the working group decides that none of the
proposed approaches will work acceptably well and is unable to
find an acceptable alternative, it may instead publish a report
describing the problem and summarizing the reasons that proposed
approaches are not acceptable.”  Making that explicit will avoid
arguments about whether such a document is within the charter scope.


Done, and thanks for that text.

One nit, Barry's text should be above the proposals not below. It makes 
it look like those are the only proposals on the table which I'm nearly 
certain is not your intent.


One other thing though, should there be some bounds on what appears to 
be the possibility of writing a BCP like document? I mean, I can think 
of some things that could help mitigate this but they are pretty wonky 
and definitely untested. Do we actually have that operational experience 
to recommend anything?


Mike
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Sun, Dec 25, 2022 at 6:31 AM Barry Leiba  wrote:

> I agree with Mike and Scott on the point that it’s worth explicitly
> allowing the result to be a “can’t do it” publication.  Implicit “couldn’t
> do it” is fine in most cases, but here we might say something like, “If the
> working group decides that none of the proposed approaches will work
> acceptably well and is unable to find an acceptable alternative, it may
> instead publish a report describing the problem and summarizing the reasons
> that proposed approaches are not acceptable.”  Making that explicit will
> avoid arguments about whether such a document is within the charter scope.
>

Done, and thanks for that text.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Barry Leiba]

I agree with Mike and Scott on the point that it’s worth explicitly
allowing the result to be a “can’t do it” publication.  Implicit “couldn’t
do it” is fine in most cases, but here we might say something like, “If the
working group decides that none of the proposed approaches will work
acceptably well and is unable to find an acceptable alternative, it may
instead publish a report describing the problem and summarizing the reasons
that proposed approaches are not acceptable.”  Making that explicit will
avoid arguments about whether such a document is within the charter scope.

Barry

On Sat, Dec 24, 2022 at 4:17 PM Michael Thomas  wrote:

>
> On 12/24/22 1:08 PM, Scott Kitterman wrote:
> >
> > On December 24, 2022 8:22:45 PM UTC, Michael Thomas 
> wrote:
> >> On 12/23/22 10:25 PM, Murray S. Kucherawy wrote:
> >>> On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas  wrote:
> >>>
> >>>  Shouldn't the problem statement explore whether there is a
> >>>  plausible tractable solution before it moves on to protocol work?
> >>>  That is, if there isn't a tractable solution the wg should go into
> >>>  hibernation again. I'm pretty sure that I brought this quite a
> >>>  while ago. Of if not the problem statement, afterward just
> >>>  evaluating for a go-no go decision before starting any work.
> >>>
> >>>
> >>> A working group is implicitly allowed to admit defeat if it decides it
> can't solve the problem it thought it was supposed to solve.  DBOUND comes
> to mind; it deadlocked on whether the problem was tractable, or even well
> enough understood, to advance a consensus protocol solution, and closed
> without producing anything.
> >>>
> >>> I don't think the charter has to say that expressly. It's part of the
> process.  The charter stipulates an ordering, and I think that's sufficient.
> >>>
> >> I think it's worthwhile for the charter to have a step which is to
> determine whether the problem is 1) tractable and 2) requires IETF to do
> something. If either of those are false, the charter should say that it is
> completed. There has been quite a bit of skepticism expressed (and not just
> by me) about both of those points so it would be good to have a checkpoint
> before doing something to do something.
> >
> > +1.  I think it's a mistake to assume deciding not to make protocol
> changes by the group is a failure. A reasoned decision that additional
> protocol changes would not be helpful would be a success, if that's where
> the facts lead us (I have opinions on this, but have reached no definitive
> conclusions).
>
> and write an informational RFC explaining the outcome. heck, it would
> probably be worthwhile to keep an ID going during that period to
> document the various ideas/approaches.
>
> Mike
>
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Michael Thomas]

On 12/24/22 1:08 PM, Scott Kitterman wrote:


On December 24, 2022 8:22:45 PM UTC, Michael Thomas  wrote:

On 12/23/22 10:25 PM, Murray S. Kucherawy wrote:

On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas  wrote:

 Shouldn't the problem statement explore whether there is a
 plausible tractable solution before it moves on to protocol work?
 That is, if there isn't a tractable solution the wg should go into
 hibernation again. I'm pretty sure that I brought this quite a
 while ago. Of if not the problem statement, afterward just
 evaluating for a go-no go decision before starting any work.


A working group is implicitly allowed to admit defeat if it decides it can't 
solve the problem it thought it was supposed to solve.  DBOUND comes to mind; 
it deadlocked on whether the problem was tractable, or even well enough 
understood, to advance a consensus protocol solution, and closed without 
producing anything.

I don't think the charter has to say that expressly. It's part of the process.  
The charter stipulates an ordering, and I think that's sufficient.


I think it's worthwhile for the charter to have a step which is to determine 
whether the problem is 1) tractable and 2) requires IETF to do something. If 
either of those are false, the charter should say that it is completed. There 
has been quite a bit of skepticism expressed (and not just by me) about both of 
those points so it would be good to have a checkpoint before doing something to 
do something.


+1.  I think it's a mistake to assume deciding not to make protocol changes by 
the group is a failure. A reasoned decision that additional protocol changes 
would not be helpful would be a success, if that's where the facts lead us (I 
have opinions on this, but have reached no definitive conclusions).


and write an informational RFC explaining the outcome. heck, it would 
probably be worthwhile to keep an ID going during that period to 
document the various ideas/approaches.


Mike

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Scott Kitterman]

On December 24, 2022 8:22:45 PM UTC, Michael Thomas  wrote:
>
>On 12/23/22 10:25 PM, Murray S. Kucherawy wrote:
>> On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas  wrote:
>> 
>> Shouldn't the problem statement explore whether there is a
>> plausible tractable solution before it moves on to protocol work?
>> That is, if there isn't a tractable solution the wg should go into
>> hibernation again. I'm pretty sure that I brought this quite a
>> while ago. Of if not the problem statement, afterward just
>> evaluating for a go-no go decision before starting any work.
>> 
>> 
>> A working group is implicitly allowed to admit defeat if it decides it can't 
>> solve the problem it thought it was supposed to solve.  DBOUND comes to 
>> mind; it deadlocked on whether the problem was tractable, or even well 
>> enough understood, to advance a consensus protocol solution, and closed 
>> without producing anything.
>> 
>> I don't think the charter has to say that expressly. It's part of the 
>> process.  The charter stipulates an ordering, and I think that's sufficient.
>> 
>I think it's worthwhile for the charter to have a step which is to determine 
>whether the problem is 1) tractable and 2) requires IETF to do something. If 
>either of those are false, the charter should say that it is completed. There 
>has been quite a bit of skepticism expressed (and not just by me) about both 
>of those points so it would be good to have a checkpoint before doing 
>something to do something.


+1.  I think it's a mistake to assume deciding not to make protocol changes by 
the group is a failure. A reasoned decision that additional protocol changes 
would not be helpful would be a success, if that's where the facts lead us (I 
have opinions on this, but have reached no definitive conclusions).

Scott K

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Michael Thomas]

On 12/23/22 10:25 PM, Murray S. Kucherawy wrote:

On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas  wrote:

Shouldn't the problem statement explore whether there is a
plausible tractable solution before it moves on to protocol work?
That is, if there isn't a tractable solution the wg should go into
hibernation again. I'm pretty sure that I brought this quite a
while ago. Of if not the problem statement, afterward just
evaluating for a go-no go decision before starting any work.


A working group is implicitly allowed to admit defeat if it decides it 
can't solve the problem it thought it was supposed to solve.  DBOUND 
comes to mind; it deadlocked on whether the problem was tractable, or 
even well enough understood, to advance a consensus protocol solution, 
and closed without producing anything.


I don't think the charter has to say that expressly. It's part of the 
process.  The charter stipulates an ordering, and I think that's 
sufficient.


I think it's worthwhile for the charter to have a step which is to 
determine whether the problem is 1) tractable and 2) requires IETF to do 
something. If either of those are false, the charter should say that it 
is completed. There has been quite a bit of skepticism expressed (and 
not just by me) about both of those points so it would be good to have a 
checkpoint before doing something to do something.


Mike
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas  wrote:

> Shouldn't the problem statement explore whether there is a plausible
> tractable solution before it moves on to protocol work? That is, if there
> isn't a tractable solution the wg should go into hibernation again. I'm
> pretty sure that I brought this quite a while ago. Of if not the problem
> statement, afterward just evaluating for a go-no go decision before
> starting any work.
>

A working group is implicitly allowed to admit defeat if it decides it
can't solve the problem it thought it was supposed to solve.  DBOUND comes
to mind; it deadlocked on whether the problem was tractable, or even well
enough understood, to advance a consensus protocol solution, and closed
without producing anything.

I don't think the charter has to say that expressly.  It's part of the
process.  The charter stipulates an ordering, and I think that's sufficient.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 12/23/2022 11:38 AM, Murray S. Kucherawy wrote:
Having heard no further feedback, I've moved the draft charter to the 
next state, which will trigger the first of two IESG reviews early in 
the new year.  It will go out for full IETF review after it passes the 
first of those.


The draft looks good.

The specified work tasks are:


The DKIM working group will first develop a clear problem statement, which it 
may
choose to publish.  Then, it will produce one or more technical specifications 
that
propose replay-resistant mechanisms.


A problem statement needs to state the problem well enough for an 
average reader to understand not just its gist -- which arguably is 
already provided in the second paragraph of the charter -- but the 
details of scenarios that produce the problem.  A sufficiently detailed 
characterization might, indeed, warrant a separate document, though I 
hope that won't be needed.  On the other hand, a document with that 
detail that also explores 'solution' issues -- without diving too far in 
their details and definitely without choosing winners -- might be a very 
useful milestone for garnering wider community understanding (and even 
participation.)  It's worth being clear about problem vs. solution.  So 
a problem statement, per se, shouldn't cover solutions, since, well, 
it's a problem statement and not a solutions statement.


The "will produce one or more" is, of course, optimistic, since wg 
efforts can fail.  But noting that in a charter isn't all that useful, 
especially since it's never part of the plan.  More significantly, 
suggesting more than one nicely alerts to the possibilities that a) we 
might require more than one to get things under control enough, and/or 
2) there might be competing specifications worth pursuing.


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] Rechartering

[Michael Thomas]

On 12/23/22 11:38 AM, Murray S. Kucherawy wrote:
On Sun, Dec 11, 2022 at 7:25 PM Murray S. Kucherawy 
 wrote:



I've synthesized the feedback to date into a new update to the
charter text.  It calls out the order of operations the group
seems to prefer, and makes explicit the possible output of a "best
practices" update.  Let me know if this is a step in the right
direction or the wrong one.

https://datatracker.ietf.org/doc/charter-ietf-dkim/

Note that the next IESG telechat with room on it won't be until
the new year at this point, so this won't advance before then.


Having heard no further feedback, I've moved the draft charter to the 
next state, which will trigger the first of two IESG reviews early in 
the new year.  It will go out for full IETF review after it passes the 
first of those.


Shouldn't the problem statement explore whether there is a plausible 
tractable solution before it moves on to protocol work? That is, if 
there isn't a tractable solution the wg should go into hibernation 
again. I'm pretty sure that I brought this quite a while ago. Of if not 
the problem statement, afterward just evaluating for a go-no go decision 
before starting any work.


Mike
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Sun, Dec 11, 2022 at 7:25 PM Murray S. Kucherawy 
wrote:

>
> I've synthesized the feedback to date into a new update to the charter
> text.  It calls out the order of operations the group seems to prefer, and
> makes explicit the possible output of a "best practices" update.  Let me
> know if this is a step in the right direction or the wrong one.
>
> https://datatracker.ietf.org/doc/charter-ietf-dkim/
>
> Note that the next IESG telechat with room on it won't be until the new
> year at this point, so this won't advance before then.
>

Having heard no further feedback, I've moved the draft charter to the next
state, which will trigger the first of two IESG reviews early in the new
year.  It will go out for full IETF review after it passes the first of
those.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Thu, Dec 8, 2022 at 11:52 AM Jim Fenton  wrote:

>
> >> I think a checkpoint / review is a good goal for the group.
> >>
> >
> > This seems like something reasonable and easy to add.
> >
> > Any objections?
>
> I’m fine if the revision to best practices is scoped to the replay
> problem. This was presented to dispatch as a narrowly scoped problem
> statement, and the rechartering result was decided on that basis. If this
> were to evolve into a “let’s think about DKIM best practices” more
> generally, it will get bogged down.
>

I've synthesized the feedback to date into a new update to the charter
text.  It calls out the order of operations the group seems to prefer, and
makes explicit the possible output of a "best practices" update.  Let me
know if this is a step in the right direction or the wrong one.

https://datatracker.ietf.org/doc/charter-ietf-dkim/

Note that the next IESG telechat with room on it won't be until the new
year at this point, so this won't advance before then.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Jim Fenton]

On 8 Dec 2022, at 7:25, Murray S. Kucherawy wrote:

> On Thu, Dec 8, 2022 at 12:56 AM Laura Atkins 
> wrote:
>
>>
>> Fair enough.  Does the charter need to say that a revision to best
>> practices, relative to the replay problem, might be a possible output?
>> It's within the realm of possibility that no protocol work comes out of
>> this, but a "checkpoint" about current realities might be good to publish
>> in that case.
>>
>>
>> I think a checkpoint / review is a good goal for the group.
>>
>
> This seems like something reasonable and easy to add.
>
> Any objections?

I’m fine if the revision to best practices is scoped to the replay problem. 
This was presented to dispatch as a narrowly scoped problem statement, and the 
rechartering result was decided on that basis. If this were to evolve into a 
“let’s think about DKIM best practices” more generally, it will get bogged down.

-Jim

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Thu, Dec 8, 2022 at 12:56 AM Laura Atkins 
wrote:

>
> Fair enough.  Does the charter need to say that a revision to best
> practices, relative to the replay problem, might be a possible output?
> It's within the realm of possibility that no protocol work comes out of
> this, but a "checkpoint" about current realities might be good to publish
> in that case.
>
>
> I think a checkpoint / review is a good goal for the group.
>

This seems like something reasonable and easy to add.

Any objections?

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Laura Atkins]

> On 8 Dec 2022, at 00:26, Murray S. Kucherawy  wrote:
> 
> On Wed, Dec 7, 2022 at 2:06 PM Dave Crocker  > wrote:
> As appealing as the AS concept is, I've never been clear how operationally 
> useful they are.
> More to the current point, if the anti-replay work to be done benefits from a 
> position on transit vs. non-transit, then including it directly in an 
> anti-replay specification would be more helpful than in a separate AS.
> 
> Fair enough.  Does the charter need to say that a revision to best practices, 
> relative to the replay problem, might be a possible output?  It's within the 
> realm of possibility that no protocol work comes out of this, but a 
> "checkpoint" about current realities might be good to publish in that case.

I think a checkpoint / review is a good goal for the group.

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Michael Thomas]

On 12/7/22 4:26 PM, Murray S. Kucherawy wrote:


Fair enough.  Does the charter need to say that a revision to best 
practices, relative to the replay problem, might be a possible 
output?  It's within the realm of possibility that no protocol work 
comes out of this, but a "checkpoint" about current realities might be 
good to publish in that case.


This is why I'm extremely skeptical anything useful will come of this. 
We're putting the burden on the receiver to solve a sender's problem. 
That is the recipe for failure because what is the receiver's motivation 
to fund somebody else's problem? DKIM at least has the right incentives 
which is that senders have motivation for better delivery and receivers 
get utility in their fights against spam, etc. Regardless of solution, 
any solution to this has neither of those properties.


The actual solution is for the sender to not send spam.

Mike
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 12/7/2022 4:26 PM, Murray S. Kucherawy wrote:
Fair enough.  Does the charter need to say that a revision to best 
practices, relative to the replay problem, might be a possible 
output?  It's within the realm of possibility that no protocol work 
comes out of this, but a "checkpoint" about current realities might be 
good to publish in that case.


That's what is ironic about this thread:  I don't think there has been 
any suggestion to change the details of DKIM tech, just a refinement of 
DKIM intention.  And maybe rather slight modification to expected use.  
But given actual current use, I doubt even that.


Frankly, the word transit was included to get an essential point, 
without otherwise trying to tweak the wg work.


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] Rechartering

[Scott Kitterman]

On December 8, 2022 12:26:45 AM UTC, "Murray S. Kucherawy" 
 wrote:
>On Wed, Dec 7, 2022 at 2:06 PM Dave Crocker  wrote:
>
>> As appealing as the AS concept is, I've never been clear how operationally
>> useful they are.
>>
>> More to the current point, if the anti-replay work to be done benefits
>> from a position on transit vs. non-transit, then including it directly in
>> an anti-replay specification would be more helpful than in a separate AS.
>>
>Fair enough.  Does the charter need to say that a revision to best
>practices, relative to the replay problem, might be a possible output?
>It's within the realm of possibility that no protocol work comes out of
>this, but a "checkpoint" about current realities might be good to publish
>in that case.

Yes.  It's not a given that protocol changes are the only non-failure outcomes.

Scott K

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Wed, Dec 7, 2022 at 2:06 PM Dave Crocker  wrote:

> As appealing as the AS concept is, I've never been clear how operationally
> useful they are.
>
> More to the current point, if the anti-replay work to be done benefits
> from a position on transit vs. non-transit, then including it directly in
> an anti-replay specification would be more helpful than in a separate AS.
>
Fair enough.  Does the charter need to say that a revision to best
practices, relative to the replay problem, might be a possible output?
It's within the realm of possibility that no protocol work comes out of
this, but a "checkpoint" about current realities might be good to publish
in that case.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 12/7/2022 1:47 PM, Murray S. Kucherawy wrote:
Yes, it's definitely true that the standard was written from the 
perspective of delivery-time evaluation, and then sending that result 
to MUAs rather than having MUAs actually do the evaluation.  So 
although 4686 says that's a design goal, 6376 sure doesn't have that 
flavor.


I don't see either RFC clearly "disagreeing" with the view that
DKIM is for transit-related work.  That's contrary to Murray's
assessment.  But again, the RFC doesn't make that limitation clear
(enough, IMO), either.


Right, I think that's what I'm driving at.  And because of this, we 
can't take "transit-time" as a given.


Possibly beating this poor horse beyond equinimity...

It's not meant to be about 'given' but about current reality. Even with 
the reality that the signatures are used forensically, that was not a 
design goal and, based on thoughtful consideration as reflected in that 
article, it's not very good for it.  This of course doesn't prevent 
anyone from using it that way, but neither does it mean that a new 
specification has to accept that use as... acceptable.



It is absolutely within the purview of the reconstituted WG to "fix" 
this by clarifying using current operational realities and acquired 
experience.  An applicability statement, for instance, would not be 
out of the question.


As appealing as the AS concept is, I've never been clear how 
operationally useful they are.


More to the current point, if the anti-replay work to be done benefits 
from a position on transit vs. non-transit, then including it directly 
in an anti-replay specification would be more helpful than in a separate AS.


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] Rechartering

[Michael Thomas]

On 12/7/22 1:47 PM, Murray S. Kucherawy wrote:



Yes, it's definitely true that the standard was written from the 
perspective of delivery-time evaluation, and then sending that result 
to MUAs rather than having MUAs actually do the evaluation.  So 
although 4686 says that's a design goal, 6376 sure doesn't have that 
flavor.
That's certainly what we had in mind as to how to deploy it, there 
certainly was no reason to preclude MUA's or other validators to use the 
signature as well.


It is absolutely within the purview of the reconstituted WG to "fix" 
this by clarifying using current operational realities and acquired 
experience.  An applicability statement, for instance, would not be 
out of the question.



Part of the problem is that use for forensics is essentially opaque. We 
really can't know with any certainty how often it is used because 
companies aren't in the habit of letting the world know about phishing 
attacks against them, for example.


And therein lies the problem: the only difference between forensics of 
the phishing kind and the Her Emails kind is the intent of the 
investigation which is a very layer 8 difference. For all of the layers 
below, they are identical.


Mike
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Tue, Dec 6, 2022 at 4:20 PM Dave Crocker  wrote:

> DKIM was developed to facilitate delivery handling decisions.  The
> language in the RFC 4871 and RFC 6376 doesn't make this as explicit as I'd
> wish, given the perspective I'm advocating, but it's got some implicating
> language.  References to validation by MTAs or MDAs obviously has to do
> with transit or delivery, and not after.  Reference to MUAs might imply
> long-term term.  Or not.  Certainly there is no discussion about long-term
> use of the signature.
>

Yes, it's definitely true that the standard was written from the
perspective of delivery-time evaluation, and then sending that result to
MUAs rather than having MUAs actually do the evaluation.  So although 4686
says that's a design goal, 6376 sure doesn't have that flavor.

I don't see either RFC clearly "disagreeing" with the view that DKIM is for
> transit-related work.  That's contrary to Murray's assessment.  But again,
> the RFC doesn't make that limitation clear (enough, IMO), either.
>

Right, I think that's what I'm driving at.  And because of this, we can't
take "transit-time" as a given.

It is absolutely within the purview of the reconstituted WG to "fix" this
by clarifying using current operational realities and acquired experience.
An applicability statement, for instance, would not be out of the question.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 12/4/2022 7:52 PM, Murray S. Kucherawy wrote:

On Sat, Dec 3, 2022 at 12:20 PM Jon Callas  wrote:

> On Dec 3, 2022, at 11:42, Dave Crocker  wrote:
> On 12/3/2022 11:35 AM, Jon Callas wrote:
>> Agreed, and we need some other weasel word than "lightweight"
because there are lots of people working on "lightweight"
symmetric ciphers. Something like "appropriate"?
>>
>> Y'all know this is one of the many bees in my bonnet -- DKIM
doesn't need a signature that is secure for a year (or more), it
needs one that is secure for somewhere between a minute and a week.
>
> transit-time, cryptographic authentication ?

I like that.


I've edited in this change, minus "transit-time".  I acknowledge that 
this is what Jon and Dave are saying was the intent all along, and I'm 
not arguing the point, but RFC 4686 -- which presumably recorded what 
was our consensus at the time, and which RFC 6376 references as 
foundational material -- disagrees, holding out an additional 
possibility that no DKIM document since then has dispelled.  I don't 
think we should ignore this conflict; I think it's important to 
resolve and record that resolution, and this revised perspective can 
be part of the document(s) this working group produces.



I'll start by noting that, other than Jon Callas, I haven't seen other 
support for the view I'm espousing.  So my response here is more a 
matter of due diligence than in an expectation of swaying the group's 
decisions.


DKIM was developed to facilitate delivery handling decisions. The 
language in the RFC 4871 and RFC 6376 doesn't make this as explicit as 
I'd wish, given the perspective I'm advocating, but it's got some 
implicating language.  References to validation by MTAs or MDAs 
obviously has to do with transit or delivery, and not after.  Reference 
to MUAs might imply long-term term.  Or not. Certainly there is no 
discussion about long-term use of the signature.


It's probably worth noting that the RFC examples, in Sec tion A.3 says 
"The signature is normally verified by an inbound SMTP server or 
possibly the final delivery agent." And Section B.2 is similarly limited 
to delivery-related use of DKIM.


Further, the semantics about the signature are:  "permits a person, 
role, or organization to claim some responsibility for a message" which 
is quite far from claims of authorship, or the like.  Not to deny the 
fact of forensic use of DKIM, but a serious intention to have DKIM be 
used for longer-term validations would (or at least should) have 
attended to its requirements explicitly.


I don't see either RFC clearly "disagreeing" with the view that DKIM is 
for transit-related work.  That's contrary to Murray's assessment.  But 
again, the RFC doesn't make that limitation clear (enough, IMO), either.


So much for the specification's position on transit vs. later. Now we 
have some operational realities.


Retaining the signature facilitates replay.  Arguments about how easy it 
is to move reception to a friendlier site, closing off less friendly 
sites is like closing off open SMTP relays.  It can be circumvented, but 
is still worth doing.


There is a nice article detailing the problems of using DKIM for 
longer-term forensic purposes and even suggesting defeating that use by 
publishing the private keys:


   blog.cryptographyengineering.com

   Ok Google: please publish your DKIM secret keys <#>

   The Internet is a dangerous place in the best of times. Sometimes
   Internet engineers find ways to mitigate the worst of these threats,
   and sometimes they fail. Every now and then, however, a major …

   
   
https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/
   



Lastly, a current working group is working from current realities.  If 
specifications written some time ago are either not clear about and 
issue or have become problematic in the face of current use, it is not 
unreasonable for a current working group to fix things.  In fact, that's 
it's job.



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] Rechartering

[Murray S. Kucherawy]

On Sat, Dec 3, 2022 at 12:20 PM Jon Callas  wrote:

> > On Dec 3, 2022, at 11:42, Dave Crocker  wrote:
> >
> > On 12/3/2022 11:35 AM, Jon Callas wrote:
> >> Agreed, and we need some other weasel word than "lightweight" because
> there are lots of people working on "lightweight" symmetric ciphers.
> Something like "appropriate"?
> >>
> >> Y'all know this is one of the many bees in my bonnet -- DKIM doesn't
> need a signature that is secure for a year (or more), it needs one that is
> secure for somewhere between a minute and a week.
> >
> > transit-time, cryptographic authentication ?
>
> I like that.
>

I've edited in this change, minus "transit-time".  I acknowledge that this
is what Jon and Dave are saying was the intent all along, and I'm not
arguing the point, but RFC 4686 -- which presumably recorded what was our
consensus at the time, and which RFC 6376 references as foundational
material -- disagrees, holding out an additional possibility that no DKIM
document since then has dispelled.  I don't think we should ignore this
conflict; I think it's important to resolve and record that resolution, and
this revised perspective can be part of the document(s) this working group
produces.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Scott Kitterman]

On Saturday, December 3, 2022 2:35:55 PM EST Jon Callas wrote:
> > On Dec 3, 2022, at 11:01, Stephen Farrell 
> > wrote:
> > 
> > One nit though, that you should feel free to ignore if it
> > was discussed already - the phrase "in a secure way" doesn't
> > quite capture what the DKIM WG was trying to produce, e.g.
> > we consider unsigned DNS fine for DKIM public keys, even
> > though that'd not be described as "secure."
> > 
> > Maybe s/in a secure way/using a lightweight cryptographic
> > mechanism/ would be better? But again, it's a nit.
> 
> Agreed, and we need some other weasel word than "lightweight" because there
> are lots of people working on "lightweight" symmetric ciphers. Something
> like "appropriate"?
> 
> Y'all know this is one of the many bees in my bonnet -- DKIM doesn't need a
> signature that is secure for a year (or more), it needs one that is secure
> for somewhere between a minute and a week.
> 
> Moreover, one of the ways that we could deal with some of the knock-on
> issues of not wanting DKIM to be a non-repudiation system (the Podesta
> Problem) is to use signatures that could be  forged by someone who put a
> CPU(s)-week's effort into it after the fact.
> 
> Even if we never get around to the actual issues, we don't want to cut off
> someone in the future at the knees.

If you want to avoid such problems, you can do so already.  Script your mail 
server/DNS to publish a new key at a new selector weekly and then at the end 
of the second week, replace the public key with the private key.  That will 
guarantee that any signatures more than two weeks old can be repudiated, but 
still work for normal email transit times.

IETF doesn't need to do anything for domains which which to create DKIM 
signatures with a very limited temporal validity.

Scott K


___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Jon Callas]

> On Dec 3, 2022, at 11:42, Dave Crocker  wrote:
> 
> On 12/3/2022 11:35 AM, Jon Callas wrote:
>> Agreed, and we need some other weasel word than "lightweight" because there 
>> are lots of people working on "lightweight" symmetric ciphers. Something 
>> like "appropriate"?
>> 
>> Y'all know this is one of the many bees in my bonnet -- DKIM doesn't need a 
>> signature that is secure for a year (or more), it needs one that is secure 
>> for somewhere between a minute and a week.
> 
> transit-time, cryptographic authentication ?
> 

I like that.

Jon
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 12/3/2022 11:35 AM, Jon Callas wrote:

Agreed, and we need some other weasel word than "lightweight" because there are lots of people 
working on "lightweight" symmetric ciphers. Something like "appropriate"?

Y'all know this is one of the many bees in my bonnet -- DKIM doesn't need a 
signature that is secure for a year (or more), it needs one that is secure for 
somewhere between a minute and a week.


transit-time, cryptographic authentication ?

d/

ps. technical docs that are security related tend to do better when they 
don't use the word 'security' as a technical term meant as a specific 
reference...


--
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] Rechartering

[Jon Callas]

> On Dec 3, 2022, at 11:01, Stephen Farrell  wrote:
> 
> One nit though, that you should feel free to ignore if it
> was discussed already - the phrase "in a secure way" doesn't
> quite capture what the DKIM WG was trying to produce, e.g.
> we consider unsigned DNS fine for DKIM public keys, even
> though that'd not be described as "secure."
> 
> Maybe s/in a secure way/using a lightweight cryptographic
> mechanism/ would be better? But again, it's a nit.

Agreed, and we need some other weasel word than "lightweight" because there are 
lots of people working on "lightweight" symmetric ciphers. Something like 
"appropriate"?

Y'all know this is one of the many bees in my bonnet -- DKIM doesn't need a 
signature that is secure for a year (or more), it needs one that is secure for 
somewhere between a minute and a week. 

Moreover, one of the ways that we could deal with some of the knock-on issues 
of not wanting DKIM to be a non-repudiation system (the Podesta Problem) is to 
use signatures that could be  forged by someone who put a CPU(s)-week's effort 
into it after the fact.

Even if we never get around to the actual issues, we don't want to cut off 
someone in the future at the knees.

Jon

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Stephen Farrell]

Hiya,

On 03/12/2022 06:38, Murray S. Kucherawy wrote:

I've placed what I believe is the text that is closest to consensus in the
datatracker:

https://datatracker.ietf.org/doc/charter-ietf-dkim/

Please provide comments or criticism soon.  Once it appears to be stable
relative to this audience, I'll send it on its way for internal (IESG) and
then full IETF review.


That seems to fairly reflect the discussion on the list,
though I've only been skimming it.

One nit though, that you should feel free to ignore if it
was discussed already - the phrase "in a secure way" doesn't
quite capture what the DKIM WG was trying to produce, e.g.
we consider unsigned DNS fine for DKIM public keys, even
though that'd not be described as "secure."

Maybe s/in a secure way/using a lightweight cryptographic
mechanism/ would be better? But again, it's a nit.

Cheers,
S.

PS: I'm not convinced there's a useful solution to be found
for these replay problems, but the charter seems to me to
allow for that outcome, so is fine.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 12/2/2022 10:38 PM, Murray S. Kucherawy wrote:
I've placed what I believe is the text that is closest to consensus in 
the datatracker:


+1


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] Rechartering

[Laura Atkins]

> On 3 Dec 2022, at 06:38, Murray S. Kucherawy  wrote:
> 
> I've placed what I believe is the text that is closest to consensus in the 
> datatracker:
> 
> https://datatracker.ietf.org/doc/charter-ietf-dkim/ 
> 
> 
> Please provide comments or criticism soon.  Once it appears to be stable 
> relative to this audience, I'll send it on its way for internal (IESG) and 
> then full IETF review.
> 
> Should you wish to serve as a co-chair, or nominate someone for that 
> position, please contact me off-list.

+1

laura

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Scott Kitterman]

On Saturday, December 3, 2022 5:33:27 AM EST Alessandro Vesely wrote:
> On Sat 03/Dec/2022 07:38:24 +0100 Murray S. Kucherawy wrote:
> > I've placed what I believe is the text that is closest to consensus in the
> > datatracker:
> > 
> > https://datatracker.ietf.org/doc/charter-ietf-dkim/
> > 
> > Please provide comments or criticism soon.
> 
> Please add the other Wei's I-D:
> https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/

I agree.

I still think limiting the backward compatibility language to DKIM is too 
narrow.

Scott K 


___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Alessandro Vesely]

On Sat 03/Dec/2022 07:38:24 +0100 Murray S. Kucherawy wrote:
I've placed what I believe is the text that is closest to consensus in the 
datatracker:


https://datatracker.ietf.org/doc/charter-ietf-dkim/

Please provide comments or criticism soon.



Please add the other Wei's I-D:
https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/


Best
Ale
--





___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

I've placed what I believe is the text that is closest to consensus in the
datatracker:

https://datatracker.ietf.org/doc/charter-ietf-dkim/

Please provide comments or criticism soon.  Once it appears to be stable
relative to this audience, I'll send it on its way for internal (IESG) and
then full IETF review.

Should you wish to serve as a co-chair, or nominate someone for that
position, please contact me off-list.

-MSK, ART Area Director
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Laura Atkins]

I support this.

If the consensus is “that specific parts of the message have not been altered” 
should be added I’d support that, too. 

laura 



> On 28 Nov 2022, at 02:30, Murray S. Kucherawy  wrote:
> 
> Hi folks,
> 
> Area Director hat on here:
> 
> The discussion Barry kicked off has been interesting, but it has strayed (and 
> mea culpa, in part, because the material is interesting) from the work of 
> discussing a charter.
> 
> I've set the stage for re-chartering in the system, and now we need some 
> charter text.  Dave and Barry submitted text, which I've synthesized into 
> what's below.  Let's keep this thread just to discussion the charter text; if 
> you want to continue to debate the technical solutions or problem space, 
> please start other threads or reply to the other existing ones.
> 
> Here's my run at a charter; please provide suggestions or comments, or tell 
> us if you think it's ready to go.  It's a variant of Barry's version with 
> parts of Dave's merged in.  I've kept the list of candidate documents as a 
> starting point; the WG doesn't actually have to use any of them if that's 
> where consensus lands.
> 
> But let's figure out consensus on a charter before we try to hammer out 
> consensus on solutions.
> 
> -MSK
> 
> --
> 
> Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for
> using a digital signature to associate a domain identity with an email
> message in a secure way, and to assure receiving domains that the message has
> not been altered since the signature was created.  Receiving systems
> can use this information as part of their message-handling decision.
> This can help reduce spam, phishing, and other unwanted or malicious
> email.
> 
> A DKIM-signed message can be re-posted, to a different set of recipients, 
> without
> disturbing the signature's validity.  This can be used to confound the 
> engines that
> identify abusive content.  RFC 6376 identified a risk of these "replay" 
> attacks, but
> at the time did not consider this to be a problem in need of a solution.  
> Recently,
> the community has decided that it has become enough of a problem to warrant 
> being revisited.
> 
> The DKIM working group will produce one or more technical specifications that
> describe the abuse and propose replay-resistant mechanisms that are compatible
> with DKIM's broad deployment.  The working group may produce documents 
> describing
> relevant experimental trials first.
> 
> Current proposals include the following drafts:
> 
>  - draft-bradshaw-envelope-validation-extension-dkim
>  - draft-chuang-replay-resistant-arc
>  - draft-gondwana-email-mailpath
>  - draft-kucherawy-dkim-anti-replay
> 
> The working group may adopt or ignore these as it sees fit.
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 11/28/2022 12:14 AM, Murray S. Kucherawy wrote:

On Sun, Nov 27, 2022 at 6:50 PM Dave Crocker  wrote:

This does not provide any real understanding of how replay is
accomplished.  And since it's easy to explain and doesn't take much
text, I'll again encourage including that in the document that
defines
the nature of the problem we will be working on, namely the charter.


Doesn't the "A DKIM-signed message can be re-posted, ..." sentence do 
that?  I pulled it from your suggested text for that very reason.  
Maybe add something to the second sentence making clear the roles in 
the attack?


Your text:

   A DKIM-signed message can be re-posted, to a different set of
   recipients, without
   disturbing the signature's validity.  This can be used to confound
   the engines that
   identify abusive content.

If a reader is sufficiently knowledgeable and thoughtful, this text is 
probably sufficient.


However...

While a charter typically should not do deep tutorials, it does have a 
goal of being useful for a wide audience, such as helping to convince a 
manager that their company should participate.  To that end, a bit of 
hand-holding in the charter can be helpful.


 * What does it take to achieve malicious reposting? Collaborating
   recipient.
 * How does this differ from non-malicious re-posting?  Mostly it
   doesn't, except in scale of repostings.  (And if I have that wrong,
   we should make sure we have solid wg understanding of the
   differences.  And if there is not clear and immediate consensus
   about it, then developing it should be explicitly part of the
   charter, IMO.)
 * How does it 'confound' analysis engines? By using the reputation of
   a good source site and therefore by looking like it is legitimate. 
   (Same parenthetical comments as the previous bullet.)

Hence my text:

   A DKIM-signed message can be re-posted, to additional recipients, in a fashion that 
retains the original signature. With an author and a recipient collaborating, this can 
"replay" the message, using the original signer's reputation to propagate email 
with problematic content -- spam, phishing, and the like.

   Generally, the technical characteristics of this form of abuse match that of 
legitimate mail, making its detection or prevention challenging. Timestamps and 
carefully-tailored message signing conventions are appealing approaches to 
replay mitigation.  Each has significant limitations.




> The DKIM working group will produce one or more technical
> specifications that
> describe the abuse and propose replay-resistant mechanisms that are
> compatible
> with DKIM's broad deployment.  The working group may produce
documents
> describing
> relevant experimental trials first.

This draft doesn't include the 'preservation of installed base' cover
text that Barry's had and I forgot to include in mine.  I think it's
important.


I had intended "compatible with DKIM's broad deployment" to cover 
exactly this.  Should I word it differently?


Looking over it less quickly, your text looks reasonable.

However...

Since this type of text is often important for controlling wg activity, 
I'll raise the question about the possible problem of having the wg 
decide that a significant change (not just addition) is needed that is 
NOT 'compatible'.  Imagine something that is permitted now, but isn't 
used much, and creates problems.  Making it no longer permitted might be 
helpful for dealing with the current problem, but, obviously, is not 
compatible with what is deployed, although actually affecting few 
activities. The challenge, then, is to document the goal of 
compatibility, without absolutely requiring it.


Yours:

   The DKIM working group will produce one or more technical
   specifications that
   describe the abuse and propose replay-resistant mechanisms that are
   compatible
   with DKIM's broad deployment.

Perhaps:

   The DKIM working group will produce one or more technical
   specifications that
   describe the abuse and propose replay-resistant mechanisms. The
   working group will
   seek compatibility with DKIM's broad deployment.


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] Rechartering

[Scott Kitterman]

On November 28, 2022 8:17:21 AM UTC, "Murray S. Kucherawy" 
 wrote:
>On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman 
>wrote:
>
>> I would add mention of the problem statement draft.  I think it may turn
>> out
>> to be the most important of the ones we have now.
>>
>
>Do you mean: Mention it as a mandatory deliverable?
>
>Should we still produce that document even if we conclude replay can't be
>solved?

I had been thinking about it as an input, since that document more fully 
describes the problem.
>
>> I still think "compatible with DKIM's broad deployment" is too narrow.
>> Also,
>> I think it's one reasonable conclusion the group might reach is that the
>> cure
>> is worse than the disease and a resolution along the lines of "remove
>> signatures during delivery" and "be more careful about what you sign
>> because
>> signing bad things will hurt your domain's reputation" may be the most
>> appropriate approach.
>>
>
>Yes, I think it's always implied that a working group can throw in the
>towel if consensus is to do that.  I've never seen it spelled out in a
>charter that this is an available option, but we can make it explicit if
>people feel doing so would help set the scope.

As long as there's a consensus in the group for a solution, even if it's not 
new protocol, I don't think that's giving up.  If we quit because we can't 
reach rough consensus on a way forward, I think that could reasonably be 
characterized as throwing in the towel.
>
>> How about instead of "The DKIM working group will produce one or more
>> technical specifications that describe the abuse and propose
>> replay-resistant
>> mechanisms that are compatible with DKIM's broad deployment" we say "The
>> DKIM
>> working group will evaluate potential mechanisms to mitigate this attack
>> and
>> produce one or more technical specifications that describe the abuse and
>> propose improvements which, consistent with compatibility with DKIM's
>> broad
>> deployment and general email protocols, will reduce the impact of replay
>> attacks".
>>
>
>I think those say approximately the same thing, so I'm fine with either.
>
I agree it's not a large difference, but I'd prefer to be more explicit about 
general email compatibility.

Thanks,

Scott K

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman 
wrote:

> I would add mention of the problem statement draft.  I think it may turn
> out
> to be the most important of the ones we have now.
>

Do you mean: Mention it as a mandatory deliverable?

Should we still produce that document even if we conclude replay can't be
solved?


> I still think "compatible with DKIM's broad deployment" is too narrow.
> Also,
> I think it's one reasonable conclusion the group might reach is that the
> cure
> is worse than the disease and a resolution along the lines of "remove
> signatures during delivery" and "be more careful about what you sign
> because
> signing bad things will hurt your domain's reputation" may be the most
> appropriate approach.
>

Yes, I think it's always implied that a working group can throw in the
towel if consensus is to do that.  I've never seen it spelled out in a
charter that this is an available option, but we can make it explicit if
people feel doing so would help set the scope.


> How about instead of "The DKIM working group will produce one or more
> technical specifications that describe the abuse and propose
> replay-resistant
> mechanisms that are compatible with DKIM's broad deployment" we say "The
> DKIM
> working group will evaluate potential mechanisms to mitigate this attack
> and
> produce one or more technical specifications that describe the abuse and
> propose improvements which, consistent with compatibility with DKIM's
> broad
> deployment and general email protocols, will reduce the impact of replay
> attacks".
>

I think those say approximately the same thing, so I'm fine with either.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Murray S. Kucherawy]

On Sun, Nov 27, 2022 at 6:50 PM Dave Crocker  wrote:

> On 11/27/2022 6:30 PM, Murray S. Kucherawy wrote:
> > Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for
> > using a digital signature to associate a domain identity with an email
> > message in a secure way, and to assure receiving domains that the
> > message has
> > not been altered since the signature was created.  Receiving systems
>
> Again:  DKIM does not assure that the message has not been altered.  It
> assures only the covered portions of the message.
>
> That's not a small difference in data integrity protection.
>

OK, I'll add that in.


> > A DKIM-signed message can be re-posted, to a different set of
> > recipients, without
> > disturbing the signature's validity.  This can be used to confound the
> > engines that
> > identify abusive content.  RFC 6376 identified a risk of these
> > "replay" attacks, but
> > at the time did not consider this to be a problem in need of a
> > solution.  Recently,
> > the community has decided that it has become enough of a problem to
> > warrant being revisited.
>
> This does not provide any real understanding of how replay is
> accomplished.  And since it's easy to explain and doesn't take much
> text, I'll again encourage including that in the document that defines
> the nature of the problem we will be working on, namely the charter.
>

Doesn't the "A DKIM-signed message can be re-posted, ..." sentence do
that?  I pulled it from your suggested text for that very reason.  Maybe
add something to the second sentence making clear the roles in the attack?


> > The DKIM working group will produce one or more technical
> > specifications that
> > describe the abuse and propose replay-resistant mechanisms that are
> > compatible
> > with DKIM's broad deployment.  The working group may produce documents
> > describing
> > relevant experimental trials first.
>
> This draft doesn't include the 'preservation of installed base' cover
> text that Barry's had and I forgot to include in mine.  I think it's
> important.
>

I had intended "compatible with DKIM's broad deployment" to cover exactly
this.  Should I word it differently?

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Scott Kitterman]

On November 28, 2022 7:22:33 AM UTC, Wei Chuang 
 wrote:
>On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman 
>wrote:
>
>> On Sunday, November 27, 2022 9:30:49 PM EST Murray S. Kucherawy wrote:
>> > Hi folks,
>> >
>> > Area Director hat on here:
>> >
>> > The discussion Barry kicked off has been interesting, but it has strayed
>> > (and mea culpa, in part, because the material is interesting) from the
>> work
>> > of discussing a charter.
>> >
>> > I've set the stage for re-chartering in the system, and now we need some
>> > charter text.  Dave and Barry submitted text, which I've synthesized into
>> > what's below.  Let's keep this thread just to discussion the charter
>> text;
>> > if you want to continue to debate the technical solutions or problem
>> space,
>> > please start other threads or reply to the other existing ones.
>> >
>> > Here's my run at a charter; please provide suggestions or comments, or
>> tell
>> > us if you think it's ready to go.  It's a variant of Barry's version with
>> > parts of Dave's merged in.  I've kept the list of candidate documents as
>> a
>> > starting point; the WG doesn't actually have to use any of them if that's
>> > where consensus lands.
>> >
>> > But let's figure out consensus on a charter before we try to hammer out
>> > consensus on solutions.
>> >
>> > -MSK
>> >
>> > --
>> >
>> > Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for
>> > using a digital signature to associate a domain identity with an email
>> > message in a secure way, and to assure receiving domains that the message
>> > has
>> > not been altered since the signature was created.  Receiving systems
>> > can use this information as part of their message-handling decision.
>> > This can help reduce spam, phishing, and other unwanted or malicious
>> > email.
>> >
>> > A DKIM-signed message can be re-posted, to a different set of recipients,
>> > without
>> > disturbing the signature's validity.  This can be used to confound the
>> > engines that
>> > identify abusive content.  RFC 6376 identified a risk of these "replay"
>> > attacks, but
>> > at the time did not consider this to be a problem in need of a solution.
>> > Recently,
>> > the community has decided that it has become enough of a problem to
>> warrant
>> > being revisited.
>> >
>> > The DKIM working group will produce one or more technical specifications
>> > that
>> > describe the abuse and propose replay-resistant mechanisms that are
>> > compatible
>> > with DKIM's broad deployment.  The working group may produce documents
>> > describing
>> > relevant experimental trials first.
>> >
>> > Current proposals include the following drafts:
>> >
>> >  - draft-bradshaw-envelope-validation-extension-dkim
>> >  - draft-chuang-replay-resistant-arc
>> >  - draft-gondwana-email-mailpath
>> >  - draft-kucherawy-dkim-anti-replay
>> >
>> > The working group may adopt or ignore these as it sees fit.
>>
>> I would add mention of the problem statement draft.  I think it may turn
>> out
>> to be the most important of the ones we have now.
>
>
>+1 (granted my partiality).  Hopefully it can provide helpful context and
>framing device.
>
>
>> I still think "compatible with DKIM's broad deployment" is too narrow.
>> Also,
>> I think it's one reasonable conclusion the group might reach is that the
>> cure
>> is worse than the disease and a resolution along the lines of "remove
>> signatures during delivery" and "be more careful about what you sign
>> because
>> signing bad things will hurt your domain's reputation" may be the most
>> appropriate approach.
>
>
>> How about instead of "The DKIM working group will produce one or more
>> technical specifications that describe the abuse and propose
>> replay-resistant
>> mechanisms that are compatible with DKIM's broad deployment" we say "The
>> DKIM
>> working group will evaluate potential mechanisms to mitigate this attack
>> and
>> produce one or more technical specifications that describe the abuse and
>> propose improvements which, consistent with compatibility with DKIM's
>> broad
>> deployment and general email protocols, will reduce the impact of replay
>> attacks".
>>
>>
>On this I'm more with the MSK version, that we ought to create a
>specification.  To me at least, the problem with DKIM replay is that it is
>indistinguishable to a receiver from other benign forwarding flows.  I
>believe the proposed drafts help us do this though different approaches.

My proposal doesn't preclude that.  I'm not convinced that the problem is 
reasonably solvable and a new specification may not be appropriate.  Let's not 
assume we know more than we do at this point.

I am, however, more worried about the compatibility language, so I could live 
with that.

Scott K

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Wei Chuang]

On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman 
wrote:

> On Sunday, November 27, 2022 9:30:49 PM EST Murray S. Kucherawy wrote:
> > Hi folks,
> >
> > Area Director hat on here:
> >
> > The discussion Barry kicked off has been interesting, but it has strayed
> > (and mea culpa, in part, because the material is interesting) from the
> work
> > of discussing a charter.
> >
> > I've set the stage for re-chartering in the system, and now we need some
> > charter text.  Dave and Barry submitted text, which I've synthesized into
> > what's below.  Let's keep this thread just to discussion the charter
> text;
> > if you want to continue to debate the technical solutions or problem
> space,
> > please start other threads or reply to the other existing ones.
> >
> > Here's my run at a charter; please provide suggestions or comments, or
> tell
> > us if you think it's ready to go.  It's a variant of Barry's version with
> > parts of Dave's merged in.  I've kept the list of candidate documents as
> a
> > starting point; the WG doesn't actually have to use any of them if that's
> > where consensus lands.
> >
> > But let's figure out consensus on a charter before we try to hammer out
> > consensus on solutions.
> >
> > -MSK
> >
> > --
> >
> > Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for
> > using a digital signature to associate a domain identity with an email
> > message in a secure way, and to assure receiving domains that the message
> > has
> > not been altered since the signature was created.  Receiving systems
> > can use this information as part of their message-handling decision.
> > This can help reduce spam, phishing, and other unwanted or malicious
> > email.
> >
> > A DKIM-signed message can be re-posted, to a different set of recipients,
> > without
> > disturbing the signature's validity.  This can be used to confound the
> > engines that
> > identify abusive content.  RFC 6376 identified a risk of these "replay"
> > attacks, but
> > at the time did not consider this to be a problem in need of a solution.
> > Recently,
> > the community has decided that it has become enough of a problem to
> warrant
> > being revisited.
> >
> > The DKIM working group will produce one or more technical specifications
> > that
> > describe the abuse and propose replay-resistant mechanisms that are
> > compatible
> > with DKIM's broad deployment.  The working group may produce documents
> > describing
> > relevant experimental trials first.
> >
> > Current proposals include the following drafts:
> >
> >  - draft-bradshaw-envelope-validation-extension-dkim
> >  - draft-chuang-replay-resistant-arc
> >  - draft-gondwana-email-mailpath
> >  - draft-kucherawy-dkim-anti-replay
> >
> > The working group may adopt or ignore these as it sees fit.
>
> I would add mention of the problem statement draft.  I think it may turn
> out
> to be the most important of the ones we have now.


+1 (granted my partiality).  Hopefully it can provide helpful context and
framing device.


> I still think "compatible with DKIM's broad deployment" is too narrow.
> Also,
> I think it's one reasonable conclusion the group might reach is that the
> cure
> is worse than the disease and a resolution along the lines of "remove
> signatures during delivery" and "be more careful about what you sign
> because
> signing bad things will hurt your domain's reputation" may be the most
> appropriate approach.


> How about instead of "The DKIM working group will produce one or more
> technical specifications that describe the abuse and propose
> replay-resistant
> mechanisms that are compatible with DKIM's broad deployment" we say "The
> DKIM
> working group will evaluate potential mechanisms to mitigate this attack
> and
> produce one or more technical specifications that describe the abuse and
> propose improvements which, consistent with compatibility with DKIM's
> broad
> deployment and general email protocols, will reduce the impact of replay
> attacks".
>
>
On this I'm more with the MSK version, that we ought to create a
specification.  To me at least, the problem with DKIM replay is that it is
indistinguishable to a receiver from other benign forwarding flows.  I
believe the proposed drafts help us do this though different approaches.

-Wei


smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Scott Kitterman]

On Sunday, November 27, 2022 9:30:49 PM EST Murray S. Kucherawy wrote:
> Hi folks,
> 
> Area Director hat on here:
> 
> The discussion Barry kicked off has been interesting, but it has strayed
> (and mea culpa, in part, because the material is interesting) from the work
> of discussing a charter.
> 
> I've set the stage for re-chartering in the system, and now we need some
> charter text.  Dave and Barry submitted text, which I've synthesized into
> what's below.  Let's keep this thread just to discussion the charter text;
> if you want to continue to debate the technical solutions or problem space,
> please start other threads or reply to the other existing ones.
> 
> Here's my run at a charter; please provide suggestions or comments, or tell
> us if you think it's ready to go.  It's a variant of Barry's version with
> parts of Dave's merged in.  I've kept the list of candidate documents as a
> starting point; the WG doesn't actually have to use any of them if that's
> where consensus lands.
> 
> But let's figure out consensus on a charter before we try to hammer out
> consensus on solutions.
> 
> -MSK
> 
> --
> 
> Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for
> using a digital signature to associate a domain identity with an email
> message in a secure way, and to assure receiving domains that the message
> has
> not been altered since the signature was created.  Receiving systems
> can use this information as part of their message-handling decision.
> This can help reduce spam, phishing, and other unwanted or malicious
> email.
> 
> A DKIM-signed message can be re-posted, to a different set of recipients,
> without
> disturbing the signature's validity.  This can be used to confound the
> engines that
> identify abusive content.  RFC 6376 identified a risk of these "replay"
> attacks, but
> at the time did not consider this to be a problem in need of a solution.
> Recently,
> the community has decided that it has become enough of a problem to warrant
> being revisited.
> 
> The DKIM working group will produce one or more technical specifications
> that
> describe the abuse and propose replay-resistant mechanisms that are
> compatible
> with DKIM's broad deployment.  The working group may produce documents
> describing
> relevant experimental trials first.
> 
> Current proposals include the following drafts:
> 
>  - draft-bradshaw-envelope-validation-extension-dkim
>  - draft-chuang-replay-resistant-arc
>  - draft-gondwana-email-mailpath
>  - draft-kucherawy-dkim-anti-replay
> 
> The working group may adopt or ignore these as it sees fit.

I would add mention of the problem statement draft.  I think it may turn out 
to be the most important of the ones we have now.  

I still think "compatible with DKIM's broad deployment" is too narrow.  Also, 
I think it's one reasonable conclusion the group might reach is that the cure 
is worse than the disease and a resolution along the lines of "remove 
signatures during delivery" and "be more careful about what you sign because 
signing bad things will hurt your domain's reputation" may be the most 
appropriate approach.

How about instead of "The DKIM working group will produce one or more 
technical specifications that describe the abuse and propose replay-resistant 
mechanisms that are compatible with DKIM's broad deployment" we say "The DKIM 
working group will evaluate potential mechanisms to mitigate this attack and 
produce one or more technical specifications that describe the abuse and 
propose improvements which, consistent with compatibility with DKIM's broad 
deployment and general email protocols, will reduce the impact of replay 
attacks".

Scott K



___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 11/27/2022 6:30 PM, Murray S. Kucherawy wrote:

Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for
using a digital signature to associate a domain identity with an email
message in a secure way, and to assure receiving domains that the 
message has

not been altered since the signature was created.  Receiving systems


Again:  DKIM does not assure that the message has not been altered.  It 
assures only the covered portions of the message.


That's not a small difference in data integrity protection.



can use this information as part of their message-handling decision.
This can help reduce spam, phishing, and other unwanted or malicious
email.

A DKIM-signed message can be re-posted, to a different set of 
recipients, without
disturbing the signature's validity.  This can be used to confound the 
engines that
identify abusive content.  RFC 6376 identified a risk of these 
"replay" attacks, but
at the time did not consider this to be a problem in need of a 
solution.  Recently,
the community has decided that it has become enough of a problem to 
warrant being revisited.


This does not provide any real understanding of how replay is 
accomplished.  And since it's easy to explain and doesn't take much 
text, I'll again encourage including that in the document that defines 
the nature of the problem we will be working on, namely the charter.


Really, it's not asking a lot to identify the role of the collaborating 
recipient and possibly a bit more.  This makes the charter more directly 
useful to circulate widely and be understand in substance, without 
requiring the reader to either already know the topic or to forage for 
other documents.



The DKIM working group will produce one or more technical 
specifications that
describe the abuse and propose replay-resistant mechanisms that are 
compatible
with DKIM's broad deployment.  The working group may produce documents 
describing

relevant experimental trials first.


This draft doesn't include the 'preservation of installed base' cover 
text that Barry's had and I forgot to include in mine.  I think it's 
important.


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