It appears that Alessandro Vesely said:
>My verifier, in particular, works every time on my messages. It doesn't mean
>it doesn't work at scale.
Nor, of course, does it mean that it does.
Could you give us a list of the list managers that you've tried it
with? I presume you've done Mailman 2
It appears that Alessandro Vesely said:
>I did try and use it. You have to be careful to put the subject tag on new
>messages or write /Re:/ in the right place. You must not sign MIME-Version:
>and other fields that the MLM writes anew (yes, also Content-Type:). Oh, and
>never send
It appears that Jon Callas said:
>And look at it -- l= is intended to increase robustness and strictness of
>interpreting the message.
I don't see how that followes. In all the years I've been futzing with
email I can't ever think of a time where a message showed up with
added crud at the end
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 Content-Type header.
If Content-Type isn't signed, the bad guy can
It appears that Wei Chuang said:
>-=-=-=-=-=-
>
>Hi DKIM folks,
>As many of you know there was a DKIM security vulnerability disclosure
>Friday around the signature header body length tag "l=".
It looks like the l= senders are largely one ESP who said today they
have stopped doing it, and
It appears that Alessandro Vesely said:
>On Mon 20/May/2024 20:10:44 +0200 John Levine wrote:
>> It appears that Jeremy Harris said:
>>>On 20/05/2024 09:06, Alessandro Vesely wrote:
>>>> Content-Type: is a technical field
>>>
>>>Not a ter
It appears that Murray S. Kucherawy said:
>(a) Inertia will mean "l=" is generated and/or accepted for a long time to
>come no matter what we say or do; and
Yup.
>(b) Even if (a) weren't true, "l=" then becomes an unrecognized tag at
>verifiers, which will mean those signatures break and we
It appears that Wei Chuang said:
>-=-=-=-=-=-
>
>Hi DKIM folks,
>As many of you know there was a DKIM security vulnerability disclosure
>Friday around the signature header body length tag "l=". The blog post is
>here: https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/
>The authors
It appears that Jeremy Harris said:
>On 20/05/2024 09:06, Alessandro Vesely wrote:
>> Content-Type: is a technical field
>
>Not a term I've met before. Is there a formal definition?
As Dave said, no. There isn't even an informal definition.
>And as far as "which forwarders need to change"
It appears that Dave Crocker said:
>What I am suggesting is /first/ getting a substantial base of industry
>agreement, through collective action and field practice, and /then/
>codifying it with an update specification.
>
>The specification through the IETF would then merely document a new
It appears that Steve Atkins said:
>> Do people really think that senders that are ignoring Sec. 8.2 of RFC 6376
>> are going to pay attention to a separate RFC
>that updates that RFC?
>
>+1. Senders, no.
Honestly, I don't know. Of the trickle of mail I see with l=, most is
from the
It appears that Steffen Nurpmeso said:
> |I realize that RFC 8463 says repeatedly that the base64-encoded
> |representation of an ED25519 key is 44 bytes, and that the
> |examples go for this. Still there is no wording that the entire
> |ASN.1 structure shall be thrown away.
Yeah, I should
It appears that Scott Kitterman said:
>This isn't horrible. The main reason for RFC 8463 was, in my view, as a hedge
>for some discovery that suddenly made RSA
>obsolete, which hasn't happened yet. From a standards perspective, it is
>there if needed.
Yes, that is exactly the reason I wrote
It appears that Murray S. Kucherawy said:
>-=-=-=-=-=-
>
>On Mon, Feb 5, 2024 at 1:39 PM Steffen Nurpmeso wrote:
>
>> If a graphical user interface gives you a green "ok" button to
>> click, or "red" otherwise, that is even better as in browser URL
>> lines. Then pop up a tree-view of message
It appears that Jim Fenton said:
>On 5 Feb 2024, at 14:02, Dave Crocker wrote:
>
>> On 2/5/2024 1:56 PM, Jim Fenton wrote:
>>> And you will also provide citations to refereed research about what you
>>> just asserted as well, yes?
>>
>>
>> Ahh, you want me to prove the negative. That's not
It appears that Dave Crocker said:
>> Any DKIM signer or verifier already has a state machine looking for CR
>> and LF to do header or body canonicalization. When the state machine
>> runs into a bare CR or LF, it has to do something. The only options
>> are to produce a wrong result, since
It appears that Dave Crocker said:
>The prohibition is not in DKIM. So the violation is not within DKIM.
>And why should DKIM care?
RFC 6376 says what to do with 5322 messages. It says nothing about
what to do with blobs of bytes that are sort of like but not quite
5322 messages. It even has
It appears that Murray S. Kucherawy said:
>-=-=-=-=-=-
>
>On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso wrote:
>
>> But i cannot read this from RFC 6376.
>
>Sections 2.8 and 3.4.4 don't answer this?
Not really. They say what to do with CRLF but not with a lone CR or lone LF.
RFC5322 says:
It appears that Evan Burke said:
>> Insisting on using the same term for these two different cases has an
>> academic purity to it, but has already been demonstrated to be destructive
>> in practical terms, because it creates confused discussion.
>No, that's exactly backwards. The oversigning
It appears that Mike Hillyer said:
>In the interest of the rule of unforseen consequences, we're trying to avoid
>oversigning any headers that would break further downstream processing. Does
>anyone
>know of any headers that *should* be DKIM signed, but *should not* be
>oversigned?
Offhand,
It appears that Scott Kitterman said:
>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. [...]
>My view is that more
21 matches
Mail list logo
