Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 8/5/23 9:05 AM, Murray S. Kucherawy wrote: On Fri, Aug 4, 2023 at 2:46 PM Michael Thomas wrote: Well, for starters ARC doesn't have broad deployment. But the author doesn't say why ARC is needed or relevant. That is the point here. *All* changes need to be justified including

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 8/4/23 2:29 PM, Murray S. Kucherawy wrote: Colleagues, On Fri, Aug 4, 2023 at 12:08 PM Michael Thomas wrote: Exactly. Any proposed modifications to DKIM should be based on DKIM itself. Anything else is off-topic. It's not like you can't propose the ARC modifications

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 8/4/23 12:03 PM, Jim Fenton wrote: The charter calls for a standards-track specification by December. It would seem problematic if it has a normative reference to an experimental specification. But a call for adoption has not been issued yet, so perhaps this is jumping the gun.

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

That is, to the extent that you disagree about its relevance, it will help to hear specifics, rather than your asking a generic question that throws a burden of proof back on the document author, without providing them any indication what criteria you are applying here or any detail about

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

. Mike tim On Fri, Aug 4, 2023 at 2:27 PM Michael Thomas wrote: On 8/4/23 11:12 AM, Wei Chuang wrote: > Hi all, > I just wanted to mention two proposals for tolerating mailing list > modifications as suggested in person IETF-117. They both use ARC > headers as in

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

On 8/4/23 11:12 AM, Wei Chuang wrote: Hi all, I just wanted to mention two proposals for tolerating mailing list modifications as suggested in person IETF-117. They both use ARC headers as infrastructure, but go about tolerating mailing list modifications in different ways. 1) Disclose and

Re: [Ietf-dkim] Tolerating Mailing-List Modifications I-D

Dude. This is so 20 years ago. It only gets you so far. I should know. There is nothing for IETF to do here. The basic tools are already available in DKIM to do this. It's up to individual sites to determine their own tolerance to changes and that's nothing the IETF has any say over. And it

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/28/23 7:16 PM, Suresh Ramasubramanian wrote: Let me clarify that 1. I think Mike’s tone to have been aggressive in this, and not constructive.  I would support an official warning being issued. 2. I also think that, as Scott pointed out, when Laura as a wg member has disagreed

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

in sending the email yesterday and left your address off the cc list. laura On 28 Mar 2023, at 19:34, Michael Thomas wrote: On 3/28/23 2:31 AM, Laura Atkins wrote: Dear Michael, Your message of 27 March quoted in its entirety below, included _ad hominem_ attacks against another partic

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/28/23 2:31 AM, Laura Atkins wrote: Dear Michael, Your message of 27 March quoted in its entirety below, included _ad hominem_ attacks against another participant.  _Ad hominem_ is a fallacious form of argument wherein the person arguing attacks the person holding an opposing position,

Re: [Ietf-dkim] On the current state of DKIM and the replay problem

On 3/28/23 11:07 AM, Hector Santos wrote: On Mar 28, 2023, at 1:36 PM, Michael Thomas wrote: Since the chair is threatening to ban me, I decided to write up my view of things in a longer form. https://rip-van-webble.blogspot.com/2023/03/on-dmarc-arc-and-dkim-replays.html This has some

[Ietf-dkim] On the current state of DKIM and the replay problem

Since the chair is threatening to ban me, I decided to write up my view of things in a longer form. https://rip-van-webble.blogspot.com/2023/03/on-dmarc-arc-and-dkim-replays.html This has some technical aspects and meta aspects. The meta aspects can be addressed in the blog comments itself

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/27/23 5:34 PM, Murray S. Kucherawy wrote: On Tue, Mar 28, 2023 at 1:05 AM Michael Thomas wrote: Lastly: cutting off debate because of time is bogus. Murray already said that the milestone dates were fairly arbitrary. Using them as a tool to get the chair's preferred

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/27/23 8:46 AM, Scott Kitterman wrote: On March 27, 2023 3:10:40 PM UTC, Laura Atkins wrote: It seems to me a history of what did work / didn’t will go into document 4 or the reasoning for document 3. My current preference is for the discussion to not be in the problem statement. My

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/26/23 3:13 AM, Murray S. Kucherawy wrote: On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas wrote: On 3/24/23 6:19 PM, Barry Leiba wrote: > I don't agree with the premise.  I think what was tried and didn't > work should be documented in the result that the working group

Re: [Ietf-dkim] Clarifying the problem

On 3/25/23 8:17 PM, Murray S. Kucherawy wrote: On Fri, Mar 24, 2023, 10:10 Michael Thomas wrote: On 3/24/23 9:58 AM, Laura Atkins wrote: On 24 Mar 2023, at 16:48, Michael Thomas <mailto:m...@mtcc.com> wrote: On 3/24/23 6:14 AM, Laura Atkins wrote: Please,

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/25/23 11:25 AM, Scott Kitterman wrote: On March 25, 2023 3:13:11 PM UTC, Michael Thomas wrote: On 3/24/23 9:10 PM, Jim Fenton wrote: On 25 Mar 2023, at 8:57, Michael Thomas wrote: Somebody brought up that this could turn into a research project. Frankly I think that is highly likely

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/24/23 9:10 PM, Jim Fenton wrote: On 25 Mar 2023, at 8:57, Michael Thomas wrote: Somebody brought up that this could turn into a research project. Frankly I think that is highly likely the case and is why rechartering was so problematic. Since M3AAWG can't figure it out with lots

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/25/23 2:46 AM, Laura Atkins wrote: I asked yesterday for commentary on the drafts as an attempt to move the discussion forward so we could discuss the shape and scope of the current proposals. I would politely request that you confine discussions of the shape and scope to that thread,

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

it into the problem statement makes it easy to document the failure later instead of adding it to the confusion of whether anything can be done. That is, do the fact finding upfront. Mike Barry On Sat, Mar 25, 2023 at 8:57 AM Michael Thomas wrote: And yes, that means spam filters and the rest

[Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

And yes, that means spam filters and the rest of the ecosystem around email in which DKIM operates. As in, why exactly are we here? Why can't industry groups come up with their own solutions? We either document it now, or argue about it later especially when it becomes plain that there is

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

On 3/24/23 10:22 AM, Murray S. Kucherawy wrote: Fine with me, it's far from a showstopper overall.  I just made the suggestion. This wg should be concerned with DKIM problems, not other wg problems and especially for experimental rfc's of dubious value and complete mysteries as to what

Re: [Ietf-dkim] Problem statement adoption

Neither in their current forms. They are far too vague. They don't specify what has been tried and/or are not adequate or don't work. They should not be considered as the only two options. Also: potential BCP's are in scope via the charter. That requires way more information than any supposed

Re: [Ietf-dkim] Clarifying the problem

On 3/24/23 9:58 AM, Laura Atkins wrote: On 24 Mar 2023, at 16:48, Michael Thomas wrote: On 3/24/23 6:14 AM, Laura Atkins wrote: Please, let’s focus on the current issue with is addressing  and refining the problem statement. So you agree with me that any discussion of ARC and its

Re: [Ietf-dkim] Process Questions

On 3/24/23 6:15 AM, Laura Atkins wrote: On 10 Mar 2023, at 00:30, Michael Thomas <mailto:m...@mtcc.com> wrote: Now that we have a chair, I have a question about process wrt to the charter. The charter states that either the working group will produce doc

Re: [Ietf-dkim] Clarifying the problem

On 3/24/23 6:14 AM, Laura Atkins wrote: Please, let’s focus on the current issue with is addressing  and refining the problem statement. So you agree with me that any discussion of ARC and its complete failings should be out of scope? I would appreciate the chairs enforcing that. Mike

Re: [Ietf-dkim] Clarifying the problem

On 3/23/23 2:52 AM, Alessandro Vesely wrote: On Wed 22/Mar/2023 20:31:51 +0100 Michael Thomas wrote: On 3/21/23 8:01 PM, Murray S. Kucherawy wrote: 1. What percent of incoming email to a mailbox is through     resenders and of that what percent resign? By "resign"

Re: [Ietf-dkim] Replay Attack vs. something else

On 3/22/23 6:00 PM, Scott Kitterman wrote: That's my understanding, however that scenario also describes a normal mailing list if it doesn't make modifications that break an existing DKIM signature or any kind of forwarding with similar characteristics. The issue has little to do with the

Re: [Ietf-dkim] Welcome to the rechartered working group

On 3/22/23 4:00 PM, Emanuel Schorsch wrote: On Wed, Mar 22, 2023 at 11:29 AM Murray S. Kucherawy wrote: On Sun, Mar 19, 2023 at 11:04 PM Emanuel Schorsch wrote: In my mind, there are two important things I would like to see achieved: 1) Distinguish

Re: [Ietf-dkim] Clarifying the problem

Michael Thomas wrote: I've said in multiple threads that the current problem both in the charter and the problem draft are far too vague for us to address. Here are some from me at least: 1. Who are the victims? Just bulk senders? Are the bulk senders signing using

Re: [Ietf-dkim] Clarifying the problem

On 3/22/23 12:57 AM, Evan Burke wrote: Murray's answers are largely correct. I'll fill in some additional detail below. On Fri, Feb 17, 2023 at 11:10 AM Michael Thomas wrote: > 3. Do senders filter outbound traffic for spam? > 4. Do spammers who get a piece of email signed by a

Re: [Ietf-dkim] Clarifying the problem

On 3/22/23 11:22 AM, Murray S. Kucherawy wrote: On Tue, Mar 21, 2023 at 8:37 PM Scott Kitterman wrote: >>    1.  Do receivers keep tabs on which users are using things like >>    mailing lists to differentiate users who expect to get indirect mail vs >>    those who don't?

Re: [Ietf-dkim] Welcome to the rechartered working group

On 3/19/23 11:57 AM, Wei Chuang wrote: On Tue, Mar 7, 2023 at 4:10 AM Laura Atkins wrote: ... One of the panel members has shared the following from what he said at the session: * RFC 6376 itself says "x=" is not a viable mechanism to deal with replay. * There may

Re: [Ietf-dkim] Welcome to the rechartered working group

On 3/19/23 10:08 AM, Wei Chuang wrote: * DKIM replay was considered during development of RFC- hence the "x=" tag Considering that x= was mine from the beginning, I can say without question that replay wasn't what I had in mind. I always considered the replay problem to be bogus since

Re: [Ietf-dkim] Process Questions

On 3/13/23 8:14 AM, Murray S. Kucherawy wrote: Our current milestones are: Apr 2023 - Post a consensus problem statement draft to the datatracker (may  not go to the IESG)  Jun 2023 - Proposal regarding plans for remaining document(s) presented to  the AD

Re: [Ietf-dkim] Clarifying the problem

On 3/10/23 11:21 AM, Emanuel Schorsch wrote: On Fri, Feb 17, 2023 at 11:11 AM Michael Thomas wrote: I've said in multiple threads that the current problem both in the charter and the problem draft are far too vague for us to address. Here are some from me at least: 1. Who

Re: [Ietf-dkim] DKIM replay problem statement

On 3/10/23 2:57 PM, Jim Fenton wrote: On Mar 9, 2023 at 15:55:20 MST, Michael Thomas wrote: On 3/7/23 2:46 PM, Jim Fenton wrote: Section 3.4: I would always expect an inbound filtering service to do SPF/DKIM checks and apply an Authentication-Results header field with the result

Re: [Ietf-dkim] Welcome to the rechartered working group

On 3/10/23 7:54 AM, Scott Kitterman wrote: On Friday, March 10, 2023 9:14:05 AM EST Laura Atkins wrote: What about solutions that have been tried but have drawbacks or are ineffective? It would be nice to know what the current baseline is. In some respects that depends on what form the final

Re: [Ietf-dkim] Process Questions

On 3/10/23 7:46 AM, Laura Atkins wrote: On 10 Mar 2023, at 00:30, Michael Thomas wrote: Now that we have a chair, I have a question about process wrt to the charter. The charter states that either the working group will produce documents addressing the problem, or it will produce

Re: [Ietf-dkim] Welcome to the rechartered working group

On 3/10/23 6:14 AM, Laura Atkins wrote: On 9 Mar 2023, at 22:47, Michael Thomas wrote: On 3/7/23 4:09 AM, Laura Atkins wrote: There is a current problem statement at https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/. Please take a moment to read through it and provide

[Ietf-dkim] Process Questions

Now that we have a chair, I have a question about process wrt to the charter. The charter states that either the working group will produce documents addressing the problem, or it will produce a document saying why it can't do anything about it within the IETF confines. I strongly suspect that

Re: [Ietf-dkim] DKIM replay problem statement

On 3/7/23 2:46 PM, Jim Fenton wrote: Section 3.4: I would always expect an inbound filtering service to do SPF/DKIM checks and apply an Authentication-Results header field with the result. Are there any that don’t? I don't think we should count on Auth-res being there or not. As I

Re: [Ietf-dkim] Welcome to the rechartered working group

On 3/7/23 4:09 AM, Laura Atkins wrote: There is a current problem statement at https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/. Please take a moment to read through it and provide feedback. This chair thinks we should not be providing solutions in the problem statement.

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/17/23 4:51 PM, Evan Burke wrote: On Fri, Feb 17, 2023 at 9:49 AM Michael Thomas wrote: Which brings up another question which is applicable to the problem statement: are mailbox providers like gmail, hotmail, etc getting abused from these replays? Some spam from whokn

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/18/23 8:41 PM, Murray S. Kucherawy wrote: On Sat, Feb 18, 2023 at 8:27 PM Michael Thomas wrote: Beyond this SHOULD, I think we need to consider whether the caller needs to be told specifically when a failure occurs for this reason.  Right now an implementation

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/18/23 8:13 PM, Murray S. Kucherawy wrote: On Sat, Feb 18, 2023 at 12:10 PM Michael Thomas wrote: Beyond this SHOULD, I think we need to consider whether the caller needs to be told specifically when a failure occurs for this reason.  Right now an implementation might

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/17/23 5:02 PM, Murray S. Kucherawy wrote: On Fri, Feb 17, 2023 at 9:35 AM Scott Kitterman wrote: Currently RFC 6376 says, "Signatures MAY be considered invalid".  I think the practical effect as described in protocol terms would be to change the MAY to SHOULD under X

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/18/23 11:52 AM, Barry Leiba wrote: I think that changing this to SHOULD is the wrong approach. An Applicability Statement might well give advice, possibly at the SHOULD level, that goes beyond this and discusses use cases, but the base protocol uses MAY for a good reason, and at the

[Ietf-dkim] Clarifying the problem

I've said in multiple threads that the current problem both in the charter and the problem draft are far too vague for us to address. Here are some from me at least: 1. Who are the victims? Just bulk senders? Are the bulk senders signing using their domain? 2. If there are different types

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/17/23 9:34 AM, Scott Kitterman wrote: Currently RFC 6376 says, "Signatures MAY be considered invalid". I think the practical effect as described in protocol terms would be to change the MAY to SHOULD under X conditions and SHOULD NOT under !X conditions. Not that I'd expect to see

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/16/23 12:56 PM, Barry Leiba wrote: Okay. What's the value for X - T that prevents this problem, but doesn't cause DKIM signatures of "normal" mail to fail? There's not one "right" value; we're talking about distributions of timings for normal mail vs. replay, and yes, there's some

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/15/23 2:12 PM, Murray S. Kucherawy wrote: On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas wrote: At maximum, isn't it just the x= value? It seems to me that if you don't specify an x= value, or it's essentially infinite, they are saying they don't care about "replays&qu

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/14/23 1:16 PM, Evan Burke wrote: On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas wrote: On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas wrote: Have you considered something like rate limiting on the receiver side for things with duplicate msg-id's? Aka, a tar

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/14/23 11:30 AM, Murray S. Kucherawy wrote: On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas wrote: Have you considered something like rate limiting on the receiver side for things with duplicate msg-id's? Aka, a tar pit, iirc? As I recall that technique is sometimes

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/13/23 9:43 PM, Evan Burke wrote: On Fri, Feb 10, 2023 at 2:31 PM Michael Thomas wrote: On 2/10/23 2:10 PM, Evan Burke wrote: The M3AAWG BCP will cover recommended header signing/oversigning policies. I'll make sure that's shared here when it's published. Any idea

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/13/23 2:49 AM, Laura Atkins wrote: Basically saying if you're not filtering outbound mail for abuse, you're part of the problem. I don’t see how that’s relevant to the discussion here. It's extremely relevant. If you don't want to be viewed as a spamming domain, do your part to not

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 3:11 PM, Michael Thomas wrote: On 2/10/23 10:23 AM, Wei Chuang wrote: | resign for DKIM on behalf of the Originator though the | Originator increases risk of losing control of their private key. I'm pretty sure that the best practice here is to just create a selector(s

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/12/23 12:15 AM, Wei Chuang wrote: Consolidating the new points raised and my replies: On Fri, Feb 10, 2023 Michael Thomas wrote: Another thing that should probably be discussed is outbound spam filtering. At a high level, this is really about the sender sending spam

Re: [Ietf-dkim] replay clues

On 2/12/23 1:47 PM, Murray S. Kucherawy wrote: On Sun, Feb 12, 2023 at 11:19 AM Michael Thomas wrote: It's certainly possible to collect data that might correlate something like "Subject signed vs. not signed" with a spam score, and that could feed in to a best

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/12/23 1:34 PM, Murray S. Kucherawy wrote: On Fri, Feb 10, 2023 at 2:13 PM Michael Thomas wrote: Another thing that should probably be discussed is outbound spam filtering. At a high level, this is really about the sender sending spam. But email afaik is silent on whether

Re: [Ietf-dkim] replay clues

On 2/12/23 9:36 AM, Murray S. Kucherawy wrote: It's certainly possible to collect data that might correlate something like "Subject signed vs. not signed" with a spam score, and that could feed in to a best practices document.  I don't know who might be up for investing the time into such a

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 9:36 PM, Murray S. Kucherawy wrote: On Fri, Feb 10, 2023 at 12:06 PM Evan Burke wrote: On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker wrote: On 2/10/2023 11:35 AM, Wei Chuang wrote: > ARC is a tool to help support modern Indirect Mail Flows, and I

Re: [Ietf-dkim] replay clues

On 2/10/23 9:23 PM, Murray S. Kucherawy wrote: On Fri, Feb 10, 2023 at 8:09 PM Michael Thomas wrote: I've always thought that the likelihood of a protocol level solution for this issue is pretty close to zero if not zero. The various proposed solutions in the problem draft

[Ietf-dkim] replay clues

I've always thought that the likelihood of a protocol level solution for this issue is pretty close to zero if not zero. The various proposed solutions in the problem draft haven't given me any reason to dissuade me of that notion. That said, I think that we might be able to catalog some

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01 draft.  It cleans up a lot from the -00 rough draft state so hopefully it's more clear.  It builds

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 10:23 AM, Wei Chuang wrote: | resign for DKIM on behalf of the Originator though the | Originator increases risk of losing control of their private key. I'm pretty sure that the best practice here is to just create a selector(s) for the ESP's, etc, signing keys. You definitely

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 10:23 AM, Wei Chuang wrote: [] SPF authentication is possible, but may not be advisable. The Originator does this by publishing an SPF policy that covers the Outbound Filtering Service IPs but this IP sharing weakens authentication. Why do you say it weakens it? Isn't it pretty

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 2:10 PM, Evan Burke wrote: On Fri, Feb 10, 2023 at 1:55 PM Michael Thomas wrote: | taking advantage of the flexibility in DKIM to | selectively sign headers, the spammer may intentionally leave out | certain headers such as To:, and Subject: that can

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 2:11 PM, Wei Chuang wrote: On Fri, Feb 10, 2023 at 1:48 PM Michael Thomas wrote: | When large amounts of spam are received by the mailbox provider, the | operator’s filtering engine will eventually react by dropping the | reputation of the original DKIM signer

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01 draft.  It cleans up a lot from the -00 rough draft state so hopefully it's more clear.  It builds

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 1:48 PM, Wei Chuang wrote: On Fri, Feb 10, 2023 at 1:29 PM Michael Thomas wrote: On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01 <https://datatracker.ietf.org/doc/draft-chuang-d

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 1:47 PM, Wei Chuang wrote: On Fri, Feb 10, 2023 at 1:33 PM Michael Thomas wrote: On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01 <https://datatracker.ietf.org/doc/draft-chuang-d

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01 draft.  It cleans up a lot from the -00 rough draft state so hopefully it's more clear.  It builds

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01 draft.  It cleans up a lot from the -00 rough draft state so hopefully it's more clear.  It builds

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01 draft.  It cleans up a lot from the -00 rough draft state so hopefully it's more clear.  It builds

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 11:35 AM, Wei Chuang wrote: On Fri, Feb 10, 2023 at 11:09 AM Michael Thomas wrote: On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01 <https://datatracker.ietf.org/doc/draft-chuang-d

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01 draft.  It cleans up a lot from the -00 rough draft state so hopefully it's more clear.  It builds

Re: [Ietf-dkim] Chartering update

On 2/6/23 10:53 AM, Alessandro Vesely wrote: On Sat 04/Feb/2023 00:44:35 +0100 Michael Thomas wrote: Other than removing the ARC references, this seems like a good start. ARC is very similar to DKIM.  Saying that it can have the same problem doesn't seem out of place to me. ARC

Re: [Ietf-dkim] sender signing practices

On 2/6/23 10:34 AM, Alessandro Vesely wrote: On Sat 04/Feb/2023 04:45:15 +0100 Michael Thomas wrote: On 2/3/23 6:25 PM, Murray S. Kucherawy wrote: But with respect to replay: Even if To and Cc are signed, there's nothing in DKIM requiring that they reflect any identities present

Re: [Ietf-dkim] Chartering update

On 2/4/23 11:40 AM, Murray S. Kucherawy wrote: On Sat, Feb 4, 2023 at 11:11 AM Michael Thomas wrote: There are architectural ramifications regardless of whether it's mandatory or not. It would be a lot more reassuring if this were a common and accepted practice. I don't know

Re: [Ietf-dkim] Chartering update

On 2/4/23 12:38 AM, Murray S. Kucherawy wrote: On Thu, Feb 2, 2023 at 3:26 PM Michael Thomas wrote: I guess my concern is more along the lines of what solutions *aren't*. There are a bunch of drafts trying to tie the envelope to the email and I think there needs to be a meta

Re: [Ietf-dkim] Chartering update

On 2/4/23 11:02 AM, Evan Burke wrote: On Sat, Feb 4, 2023 at 10:15 AM Michael Thomas wrote: Marketing email probably does. Whether it's spam or not is often in the eye of the beholder. Having spent some time in the industry, I can tell you that a significant majority of marketing

Re: [Ietf-dkim] Chartering update

On 2/4/23 9:20 AM, Evan Burke wrote: On Sat, Feb 4, 2023 at 8:47 AM Dave Crocker wrote: On 2/4/2023 8:41 AM, Scott Kitterman wrote: > I've yet to see a description of the problem that's distinguishable from a mailing list that preserves DKIM signatures. That seems like an

Re: [Ietf-dkim] sender signing practices

On 2/3/23 6:25 PM, Murray S. Kucherawy wrote: But with respect to replay: Even if To and Cc are signed, there's nothing in DKIM requiring that they reflect any identities present in the envelope. That's not the point. The point is that they are leaving clues to that the message is

[Ietf-dkim] sender signing practices

The original SSP proposal was focused on whether a receiver should expect a valid signature from the domain, but it was more open ended than that. It was really intended as a way for the sending domain to describe to any receivers what it does as a matter of policy. I noticed that in

Re: [Ietf-dkim] Chartering update

On 2/2/23 4:06 PM, Scott Kitterman wrote: There is an existing draft of a problem statement, so there's at least a starting point to consider. I think discussion about what's needed is probably more useful relative to a specific draft than in the abstract:

Re: [Ietf-dkim] Chartering update

ly be made that it is. Mike On Thu, Feb 2, 2023 at 5:32 PM Michael Thomas wrote: On 2/2/23 2:16 PM, Tim Wicinski wrote: On Thu, Feb 2, 2023 at 5:07 PM Michael Thomas wrote: So here is what sticks in my craw. I think I brought up the problem statement, but mayb

Re: [Ietf-dkim] Chartering update

On 2/2/23 2:16 PM, Tim Wicinski wrote: On Thu, Feb 2, 2023 at 5:07 PM Michael Thomas wrote: So here is what sticks in my craw. I think I brought up the problem statement, but maybe somebody else did before me. It's easy to say "here is the problem, fix it!" w

Re: [Ietf-dkim] Chartering update

On 2/2/23 8:22 AM, Murray S. Kucherawy wrote: Colleagues, The IESG is prepared to approve the charter overall.  There was one blocking point about publishing the problem statement, which is that the IESG would like that not to be a "maybe".  I think that's a reasonable change to make.

Re: [Ietf-dkim] Lars Eggert's Block on charter-ietf-dkim-04-05: (with BLOCK and COMMENT)

Also: the date on the problem statement seems awfully aggressive. My thinking is that the problem statement should at least discuss (as is mentioned in the charter) how "replays" are completely legitimate uses of DKIM, and thus limit the solution space to not break those uses. Also: I hope

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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

  1   2   >