-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message <84576ec2-1573-4a3f-9a36-f4f0e5c65...@mtcc.com>, Michael
Thomas writes
>1) Why would knowing the changes in a message be useful?
because you can undo them and check the original signature is valid (or
not) and then use the reputation (an
On 1/5/25 4:58 PM, Dave Crocker wrote:
On 1/5/2025 3:29 PM, Michael Thomas wrote:
One of the key assumptions that was made 20 years ago is that DNSsec
would ultimately be deployed and thus could be counted on to secure
fetching the the DKIM selector record.
The careful assessment at the tim
It's my opinion that it isn't very likely that there needs to be any
breaking changes to DKIM itself. DKIM already has the provision that
unknown tags are just to be ignored, and DKIM is already capable of
signing whichever new headers we come up with. Take the proposed
modifications algebra:
On 1/5/2025 3:29 PM, Michael Thomas wrote:
One of the key assumptions that was made 20 years ago is that DNSsec
would ultimately be deployed and thus could be counted on to secure
fetching the the DKIM selector record.
The careful assessment at the time was that that type of protection was
a
It appears that Michael Thomas said:
>That makes the assumption that there weren't alternatives a housing the
>public keys in DNS that were more secure. There were. There still are,
>and they are widely known and deployed.
If there were any evidence that counterfeit DKIM records were a problem
On 1/5/25 4:58 PM, Richard Clayton wrote:
In message <84576ec2-1573-4a3f-9a36-f4f0e5c65...@mtcc.com>, Michael
Thomas writes
> 1) Why would knowing the changes in a message be useful?
because you can undo them and check the original signature is valid (or
not) and then use the reputation (and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message <53cd4ede-43ea-4136-a8a4-d3897cf7f...@mtcc.com>, Michael
Thomas writes
>The charter, imo, should give the motivation or at least some inkling to it. I
>mean, I was the one who thought salvaging modifications was a good idea, but
>nobody
One of the key assumptions that was made 20 years ago is that DNSsec
would ultimately be deployed and thus could be counted on to secure
fetching the the DKIM selector record. That has turned out to have been
a bad assumption. It's sort of a glaring hole, IMO for a security
protocol to not ha
Considering that there is tons of operational considerations to making
even the smallest change in DKIM, it seems to me that a recharter ought
to justify *why* the listed problems have an operational impact and
whether it is reasonable to believe that there is an actual solution to
them. Cons
On 1/5/25 7:51 PM, Jim Fenton wrote:
On 5 Jan 2025, at 19:07, Murray S. Kucherawy wrote:
On Sat, Dec 28, 2024 at 6:31 PM Bron Gondwana wrote:
- The SMTP RCPT TO address might not be present in the signed header
fields of an email, meaning that the same message can be sent to
arb
Some non-breaking alternatives were discussed back when dkim replay attacks
were the hot topic, (examples below) ultimately they were all band aids over
the already known DKIM replay problem. Addressing that is the better long term
fix.
https://www.ietf.org/archive/id/draft-bradshaw-envelope-va
On 1/5/25 6:45 PM, Murray S. Kucherawy wrote:
On Sun, Jan 5, 2025 at 4:51 PM Michael Thomas wrote:
[...]
To me, the charter should say something like "Solutions that do not
involve breaking changes to DKIM (rfc xxx) should be preferred
unless it
is absolutely necessary. Wh
I've uploaded the revised text to the datatracker. I made a variant of
Tim's suggested change, and included my own suggestion in response to Wei's
point about amending DMARC at some point.
On Sat, Dec 28, 2024 at 6:31 PM Bron Gondwana wrote:
>
>- The SMTP RCPT TO address might not be presen
On Tue, Dec 31, 2024 at 3:55 PM Wei Chuang wrote:
> Second, I prefer the prior language, as it empowers the DKIM2
> working-group-to-be to update to the DMARC RFC to use the DKIM2
> authentication mechanism. My worry is that DMARC working group is not
> chartered to do anything with DKIM2, and w
On 1/5/25 7:07 PM, Murray S. Kucherawy wrote:
On Sat, Dec 28, 2024 at 6:31 PM Bron Gondwana
wrote:
* The SMTP RCPT TO address might not be present in the signed
header fields of an email, meaning that the same message can
be sent to arbitrarily many recipients, and tho
On Sun, Jan 5, 2025 at 4:51 PM Michael Thomas wrote:
> [...]
>
> To me, the charter should say something like "Solutions that do not
> involve breaking changes to DKIM (rfc xxx) should be preferred unless it
> is absolutely necessary. Where a breaking change is something that a
> naive receiver v
Changed to "intended to include them".
-MSK
On Mon, Dec 30, 2024 at 11:02 AM Tim Wicinski wrote:
> Hi
>
> I think V3 is worth having the IESG work over.
>
> I made one small change
>
> s/intended to them as recipients/intended them as recipients/
>
> tim
>
>
> On Sat, Dec 28, 2024 at 9:31 PM B
On Sun, Jan 5, 2025 at 7:11 PM Michael Thomas wrote:
> On 1/5/25 7:07 PM, Murray S. Kucherawy wrote:
>
>
> On Sat, Dec 28, 2024 at 6:31 PM Bron Gondwana 40fastmailteam@dmarc.ietf.org> wrote:
>
>>
>>- The SMTP RCPT TO address might not be present in the signed header
>>fields of an em
On 1/5/25 7:15 PM, Murray S. Kucherawy wrote:
On Sun, Jan 5, 2025 at 7:11 PM Michael Thomas wrote:
On 1/5/25 7:07 PM, Murray S. Kucherawy wrote:
On Sat, Dec 28, 2024 at 6:31 PM Bron Gondwana
wrote:
* The SMTP RCPT TO address might not be present in the
si
On Sun, Jan 5, 2025 at 7:25 PM Michael Thomas wrote:
> I don't think you're talking about the same thing I am. I'm talking about
> the definition provided in Section 8.6 of RFC 6376. There's at least
> anecdotal evidence that this is a problem these days, and if that bullet
> can be referenced
It is my understanding that this (differentiating the benign from the abuse) is
something dkim2 is intended to address. With the current state of play it is
indeed incredibly difficult to differentiate.
DKIM replay is an overloaded term, it can apply to both the benign and the
non-benign. RFC-
Key Changes:
* Removed milestone dates
* Simplified a lot of the supporting text
* No mention of "trust relationships"
* Used the words "hop" and "hops" to align with the terminology in
RFC5322.
The word hop does not appear in RFC5322.
I suspect you mean RFC5321. Unfortunately, i
On Wed, Dec 18, 2024 at 1:19 PM Pete Resnick wrote:
> Murray, are you looking for existing documents to be listed in the
> charter that might be proposed for adoption, or do you want a more
> detailed description of what documents that will fulfill the charter
> will contain?
>
The former. It s
On 1/5/2025 7:07 PM, Murray S. Kucherawy wrote:
Am I poking a hornet's nest here, or is it safe to state that this is
the commonly understood definition of "DKIM replay"?
it isn't.
discussed in my detail comments on the latest draft.
As was brought up elsewhere, do we need to be clear about
On 5 Jan 2025, at 19:07, Murray S. Kucherawy wrote:
> On Sat, Dec 28, 2024 at 6:31 PM Bron Gondwana 40fastmailteam@dmarc.ietf.org> wrote:
>
>>
>>- The SMTP RCPT TO address might not be present in the signed header
>>fields of an email, meaning that the same message can be sent to
>>
On Mon, Jan 6, 2025, at 14:46, Dave Crocker wrote:
>>
>> Key Changes:
>> • Removed milestone dates
>> • Simplified a lot of the supporting text
>> • No mention of "trust relationships"
>> • Used the words "hop" and "hops" to align with the terminology in RFC5322.
> The word hop does not appe
26 matches
Mail list logo
