[Ietf-dkim] Re: DKIM with body length

On May 23, 2024 6:13:07 PM UTC, John Levine wrote: >It appears that Murray S. Kucherawy said: >>I've read the middle part a few times and I don't understand either the >>attack or the proposed mitigation, so I think some examples might help. > >The attack requires l= and an unsigned

[Ietf-dkim] Re: RFC 8463: errata needed?

On May 8, 2024 11:25:11 PM UTC, Steffen Nurpmeso wrote: >Hello. > >So i have had a problem with the little DKIM sign milter i had >written in that users (receivers, actually) reported back that the >ED25519 signature produces verification failures (i saw result >headers of two, and got informed

Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified

On April 14, 2024 7:13:55 PM UTC, Steffen Nurpmeso wrote: >Scott Kitterman wrote in > <2c92eb24-3332-436c-a0bb-d4bac3322...@kitterman.com>: > |On April 14, 2024 1:53:07 AM UTC, Steffen Nurpmeso \ > |wrote: > |>Scott Kitterman wrote in > |> <5368ac9a-51d5-4ae

Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified

On April 14, 2024 1:53:07 AM UTC, Steffen Nurpmeso wrote: >Scott Kitterman wrote in > <5368ac9a-51d5-4aec-ab19-613dbead7...@kitterman.com>: > |On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso \ > |wrote: > |>Hello. > |> > |>Thanks to Hanno Böck (know

Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified

On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso wrote: >Hello. > >Thanks to Hanno Böck (known from ossec and more) i was pointed to >my falsely published ED25519 DKIM key. >Until now that simply was the complete ED25519 public key, just >like for RSA, instead of extracting the actual

Re: [Ietf-dkim] Testing a DKIM implementation

On March 22, 2024 11:31:16 PM UTC, Steffen Nurpmeso wrote: >David Harris wrote in > <65fd789c.26406.50826...@david.harris.pmail.gen.nz>: > |My thanks to Murray S. Kucherawy, who was most helpful in answering my > |previous questions about specifics of RFC6376.. > | > |I now have my

Re: [Ietf-dkim] Fwd: Re: [..] Recommendation for dkim signing

On March 6, 2024 11:12:38 PM UTC, Jeremy Harris wrote: >On 06/03/2024 22:41, Steffen Nurpmeso wrote: >> exam i do not know > >exim, possibly? Yes. Sorry. It looks like autocorrect got me. Scott K ___ Ietf-dkim mailing list Ietf-dkim@ietf.org

Re: [Ietf-dkim] Fwd: Re: [..] Recommendation for dkim signing

On March 6, 2024 10:41:51 PM UTC, Steffen Nurpmeso wrote: >Scott Kitterman wrote in > : > |On March 6, 2024 9:56:50 PM UTC, Steffen Nurpmeso \ > |wrote: > |>--- Forwarded from Steffen Nurpmeso --- > |>Date: Wed, 06 Mar 2024 22:49:48 +0100 > |>Author: Steff

Re: [Ietf-dkim] Fwd: Re: [..] Recommendation for dkim signing

On March 6, 2024 9:56:50 PM UTC, Steffen Nurpmeso wrote: >--- Forwarded from Steffen Nurpmeso --- >Date: Wed, 06 Mar 2024 22:49:48 +0100 >Author: Steffen Nurpmeso >From: Steffen Nurpmeso >... >Subject: Re: [pfx] Recommendation for dkim signing >Message-ID:

Re: [Ietf-dkim] DKIM Signature

How many algorithms do you think is enough and why? Scott K On October 28, 2023 10:54:42 PM UTC, Thomas Vincent wrote: >Future proofing? The history of encryption is riddled with examples of >overconfidence. > >On Fri, Oct 27, 2023 at 2:02 PM John Levine wrote: > >>

Re: [Ietf-dkim] DKIM Signature

On October 27, 2023 2:56:30 PM UTC, "Murray S. Kucherawy" wrote: >On Sun, Oct 1, 2023 at 1:50 AM Jan Dušátko >wrote: > >> I would like to ask to consider the possibility of defining a DKIM >> signature using Ed448. [...] > > >Which DKIM implementations are known to be willing to support this

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

On August 9, 2023 3:15:36 AM UTC, Jesse Thompson wrote: >On Tue, Aug 8, 2023, at 6:37 AM, Scott Kitterman wrote: >> On August 8, 2023 10:18:58 AM UTC, Laura Atkins >> wrote: >> >> On 6 Aug 2023, at 19:07, Jesse Thompson wrote: >> >> >> >>

Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments

On August 8, 2023 2:08:05 PM UTC, "Murray S. Kucherawy" wrote: >On Tue, Aug 8, 2023 at 2:16 AM Alessandro Vesely wrote: > >> On Mon 07/Aug/2023 23:52:02 + Scott Kitterman wrote: >> > On Monday, August 7, 2023 7:47:47 PM EDT Murray S. Kucherawy wrote: >&g

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

On August 8, 2023 10:18:58 AM UTC, Laura Atkins wrote: > > >> On 6 Aug 2023, at 19:07, Jesse Thompson wrote: >> >> On Sat, Aug 5, 2023, at 6:50 AM, Laura Atkins wrote: On 5 Aug 2023, at 02:43, Jesse Thompson >>> > wrote: On Thu, Aug 3, 2023, at 11:08

Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments

On Monday, August 7, 2023 7:47:47 PM EDT Murray S. Kucherawy wrote: > On Mon, Aug 7, 2023 at 3:58 PM Scott Kitterman > > wrote: > > On Monday, August 7, 2023 6:53:19 PM EDT Murray S. Kucherawy wrote: > > ... > > > > > (2) Throughout the docu

Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments

On August 7, 2023 11:10:07 PM UTC, Dave Crocker wrote: >On 8/7/2023 3:58 PM, Scott Kitterman wrote: >> I think a definition that describes a condition that's technically >> distinguishable from normal DKIM operations is essential if we are going to >> make any progress. >

Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments

On Monday, August 7, 2023 6:53:19 PM EDT Murray S. Kucherawy wrote: ... > (2) Throughout the document, the proper term "Replay Attack" (and sometimes > "Replay") is used, but it's never directly defined. I don't think you need > it to be formal, but if you really want to do it that way, please

Re: [Ietf-dkim] Moving forward - from the chairs

On April 10, 2023 7:16:41 PM UTC, Laura Atkins wrote: > > >> On 10 Apr 2023, at 19:38, Murray S. Kucherawy wrote: >> >> On Mon, Apr 10, 2023 at 11:24 AM Scott Kitterman > <mailto:ietf-d...@kitterman.com>> wrote: >>> On Monday, Apr

Re: [Ietf-dkim] Moving forward - from the chairs

On Monday, April 10, 2023 2:05:28 PM EDT Laura Atkins wrote: ... > There is currently an active Call for Adoption for a draft. ... What's the plan for closing this out? I haven't seen any objections to the idea and as of tomorrow it will have been over a week since the formal call for

Re: [Ietf-dkim] The DKIM WG has placed draft-chuang-dkim-replay-problem in state "Call For Adoption By WG Issued"

On Tuesday, April 4, 2023 12:52:51 PM EDT Michael Thomas wrote: > While a good start, this document is far too vague about what the > current state of the problem actually is for those who of us who are not > part of industry groups privy to more information. To this specific point, I think any

Re: [Ietf-dkim] Call for adoption

My view as well. +1 for adoption. Scott K On April 4, 2023 4:10:41 PM UTC, Barry Leiba wrote: >I do not object to using this as a starting point (which is how I >think "adoption" should generally be framed). > >Barry > >On Tue, Apr 4, 2023 at 11:50 AM Laura Atkins wrote: >> >> I want to thank

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

On Sunday, April 2, 2023 4:56:16 PM EDT Wei Chuang wrote: > A -03 draft is available at > https://www.ietf.org/archive/id/draft-chuang-dkim-replay-problem-03.html. Thanks. While I haven't given it a thorough review, based on a quick read, I think this should serve as the basis for further work

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

hairs) > > > On 27 Mar 2023, at 17:04, Michael Thomas wrote: > > > > 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 > &g

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

On Monday, March 27, 2023 12:42:25 PM EDT Laura Atkins wrote: > > On 27 Mar 2023, at 16:46, Scott Kitterman wrote: > > > > On March 27, 2023 3:10:40 PM UTC, Laura Atkins wrote: > >>> On 26 Mar 2023, at 11:13, Murray S. Kucherawy > >>> wrote: >

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

On March 27, 2023 3:10:40 PM UTC, Laura Atkins wrote: > > >> On 26 Mar 2023, at 11:13, 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

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

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 the case and is why

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

On March 24, 2023 5:42:41 PM UTC, Michael Thomas wrote: > >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

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

On Wednesday, March 22, 2023 8:21:55 PM EDT Dave Crocker wrote: > My understanding is that the term DKI MReplay Attack refers to a very > specific scenario. > > The scenario is re-posting a message such that the original DKIM > signature remains valid. > > Any other sort of re-posting

Re: [Ietf-dkim] Clarifying the problem

On March 22, 2023 3:01:40 AM UTC, "Murray S. Kucherawy" wrote: >There was one prior answer to this. Here's another. > >There's a claim here that the problem statement(s) is/are too vague. I'm a >little worried that tightening up the problem definition along these 20 >vectors will give us

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

On March 19, 2023 6:57:13 PM UTC, 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. >> *

Re: [Ietf-dkim] DKIM signature algorithms

On Friday, March 10, 2023 2:32:36 PM EST Jan Dušátko wrote: > Dear, > I would like to recommend change/extend support of algorithms for DKIM > signage. Last update of algorithms are in RFC 8463, still not widely > supported. Right now we facing issues with the long DKIM key > distribution and

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

On Friday, March 10, 2023 9:14:05 AM EST 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

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

Y for a good reason, and at the protocol level it >should stay that way. > >Barry > >On Fri, Feb 17, 2023 at 8:02 PM Murray S. Kucherawy >wrote: >> >> On Fri, Feb 17, 2023 at 9:35 AM Scott Kitterman >> wrote: >>> >>> Currently RFC 6376 says, &

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

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 this appear in a protocol document (maybe some

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

expired is >simply another factor in the decision, I think we might be OK, keeping >in mind that "x=" is purely advice to the validator. To *really* >expire a signature, one has to stop publishing the key associated with >the selector. > >Barry > >On

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

On February 16, 2023 9:21:51 PM UTC, Michael Thomas wrote: > >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

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

On February 16, 2023 8:03:01 PM UTC, Evan Burke wrote: >On Thu, Feb 16, 2023 at 10:45 AM Scott Kitterman >wrote: > >> >> On February 16, 2023 6:10:39 PM UTC, Evan Burke > 40mailchimp@dmarc.ietf.org> wrote: >> >The biggest current problem wi

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

On February 16, 2023 6:10:39 PM UTC, Evan Burke wrote: >On Thu, Feb 16, 2023 at 7:30 AM Murray S. Kucherawy >wrote: > >> >> If my prior formulation is right, i.e., that the attack only takes a few >> seconds to complete, what "x=" value are we proposing that will work here >> without also

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

On February 15, 2023 10:18:50 PM UTC, "Murray S. Kucherawy" wrote: >On Wed, Feb 15, 2023 at 5:39 AM Scott Kitterman >wrote: > >> Any reputation based solution does have down scale limits. Small mail >> sources >> (such as your random Nebraska forward

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

On Wednesday, February 15, 2023 5:23:34 AM EST Alessandro Vesely wrote: > On Tue 14/Feb/2023 23:42:36 +0100 Scott Kitterman wrote: > > On Tuesday, February 14, 2023 4:16:00 PM EST Evan Burke wrote: > >> On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas wrote: > >>> On

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

On Tuesday, February 14, 2023 4:16:00 PM EST 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?

Re: [Ietf-dkim] replay clues

On February 11, 2023 5:23:39 AM UTC, "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

Re: [Ietf-dkim] Chartering update

On February 4, 2023 5:20:27 PM UTC, Evan Burke wrote: >On Sat, Feb 4, 2023 at 8:47 AM Dave Crocker wrote: > >> On 2/4/2023 8:41 AM, Scott Kitterman wrote: >> > I've yet to see a description of the problem that's distinguishable from >> a mailing list tha

Re: [Ietf-dkim] Chartering update

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

Re: [Ietf-dkim] Chartering update

There is an existing draft of a problem statement, so there's at least a starting point to consider. I think discussion about what's needed is probably more useful relative to a specific draft than in the abstract: https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/ Scott K On

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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.

Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)

And it also doesn't solve the problem in any meaningful way. This highlights my concern with the originally proposed charter language. As drafted, since this doesn't break DKIM, it's fine. We don't actually need to get that far in this case, but I still think we need broader language about

Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)

On Tuesday, November 22, 2022 8:48:48 AM EST Alessandro Vesely wrote: > On Tue 22/Nov/2022 01:21:00 +0100 Murray S. Kucherawy wrote: > > Just for the sake of being complete, we should probably come up with > > something to say about this, which is in RFC 4686, the DKIM "threats" > > > > document:

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

On November 16, 2022 4:11:27 AM UTC, Roland Turner wrote: >On 15/11/22 23:29, Murray S. Kucherawy wrote: > >> Wei might argue that their signature means "We attest that this passed >> through us, and we did our best to make sure it was legitimate before it >> went out", than the more

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

On November 15, 2022 3:12:22 PM UTC, Barry Leiba wrote: >On Mon, Nov 14, 2022 at 11:03 AM Alessandro Vesely wrote: >> >> On Mon 14/Nov/2022 05:50:42 +0100 Roland Turner wrote: >> > I'd point out that all but one of those things is either redundant (vs. say >> > ARC), unacceptably harmful (we

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

On November 12, 2022 6:46:13 PM UTC, Wei Chuang wrote: >On Fri, Nov 11, 2022 at 9:31 PM Scott Kitterman >wrote: > >> On Friday, November 11, 2022 5:18:57 PM EST Wei Chuang wrote: >> > Sorry I'm late to this thread. >> > >> > On Thu, Nov 10, 2022 a

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

On Friday, November 11, 2022 12:27:38 PM EST Scott Kitterman wrote: > On Friday, November 11, 2022 10:09:52 AM EST Murray S. Kucherawy wrote: > > On Fri, Nov 11, 2022 at 5:05 AM Scott Kitterman > > wrote: ... > > > I can imagine the market solving this. If th

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

On November 13, 2022 9:07:21 PM UTC, Jim Fenton wrote: >On 9 Nov 2022, at 13:08, Barry Leiba wrote: > >> Murray is looking at re-opening the DKIM working group, chartering it >> to work on replay mitigation. > >IIRC the result from Monday’s dispatch session was to go ahead and charter the

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

On Friday, November 11, 2022 5:18:57 PM EST Wei Chuang wrote: > Sorry I'm late to this thread. > > On Thu, Nov 10, 2022 at 4:42 AM Scott Kitterman > > wrote: > > I agree that we don't want too much detail in the charter about the > > technical > > nature

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

OK. Let's alter your scenario slightly. In step 2, instead of sending to yourself, you send it to an email list which (as we have been begging them to do for 15 years) does not make any changes in the message to invalidate that DKIM signature. So in step 3, the message goes to X thousands

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

On Friday, November 11, 2022 10:09:52 AM EST Murray S. Kucherawy wrote: > On Fri, Nov 11, 2022 at 5:05 AM Scott Kitterman > > wrote: > > > A heuristic I’ve suggested previously is “If the recipient’s email > > > > address > > > > > is not

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

On Friday, November 11, 2022 4:23:44 AM EST Laura Atkins wrote: > Snipping a bunch. > > > On 11 Nov 2022, at 05:04, Scott Kitterman wrote: > >>> 2) The messages often have two different To: lines > >>> > >>> This violates RFC 5322, so it would b

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

On Thursday, November 10, 2022 8:32:16 AM EST Steve Atkins wrote: > > On 10 Nov 2022, at 13:17, Murray S. Kucherawy wrote: > > > > On Thu, Nov 10, 2022 at 12:54 PM Laura Atkins > > wrote: In many cases, the reason the > > mail isn’t going out through the signing

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

On Thursday, November 10, 2022 7:54:25 AM EST Murray S. Kucherawy wrote: > On Thu, Nov 10, 2022 at 12:42 PM Scott Kitterman > > wrote: > > I agree that we don't want too much detail in the charter about the > > technical > > nature of the problem, but I would like to u

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

I don’t > think more of that detail needs to be in the charter either, but if you > disagree please suggest specific text you’d like to see. > > Barry > > On Wed, Nov 9, 2022 at 7:56 PM Scott Kitterman wrote: > > I think having a precised understanding of the problem that th

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

I think having a precised understanding of the problem that the charter is meant to address is important. I am having a hard time finding a technical distinction between a "replay attack" and the, by design, nature of DKIM's independence from transport details. I have not read all the drafts,

Re: [Ietf-dkim] DKIM replay mitigations

At least as I read it, I don't think you are describing the same issue as RFC 8376, Section 8.6. It describes the concern as "banking on the reputation of the signing domain (e.g., a large popular mailbox provider) rather than its own". I believe that's meant to describe an unaligned (in a

Re: [Ietf-dkim] Adding an aim= tag to DKIM Signature Tag Specifications

On Tuesday, May 12, 2020 2:14:11 PM EDT Alessandro Vesely wrote: > On Tue 12/May/2020 19:09:55 +0200 Murray S. Kucherawy wrote: > > On Tue, May 12, 2020 at 9:30 AM Alessandro Vesely wrote: > >> On Tue 12/May/2020 17:48:38 +0200 Murray S. Kucherawy wrote: > >>> On Tue, May 12, 2020 at 1:20 AM

Re: [Ietf-dkim] Adding an aim= tag to DKIM Signature Tag Specifications

On Tuesday, May 12, 2020 1:09:55 PM EDT Murray S. Kucherawy wrote: > On Tue, May 12, 2020 at 9:30 AM Alessandro Vesely wrote: > > On Tue 12/May/2020 17:48:38 +0200 Murray S. Kucherawy wrote: > > > On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely > > > > wrote: > > >> On Mon 11/May/2020

Re: [Ietf-dkim] Adding an aim= tag to DKIM Signature Tag Specifications

On Tuesday, May 12, 2020 5:31:30 AM EDT Steve Atkins wrote: > On 12/05/2020 09:20, Alessandro Vesely wrote: > > On Tue 12/May/2020 00:08:15 +0200 Dave Crocker wrote: > >> On 5/11/2020 1:33 PM, Jim Fenton wrote: > >>> There might also be the situation where a domain wants to delegate a key > >> >