many also
send the majority of their traffic signed with body length and thus
much more easily found.
Best Regards,
Taavi Eomäe
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe s
On 18/11/2024 00:19, Bron Gondwana wrote:
And I do agree there needs to be a way to say "I made changes, and I'm
not telling you how to undo them" as well.
This has the risk of completely nullifying the intent behind the new
standard by providing a path of least resistance too many would take.
On 07/01/2025 15:29, Richard Clayton wrote:
I can't see any value in knowing how the signer of a message obtained a
key ... on my system it fetches the private key from a file and never
uses the public key at all -- so DNSSEC is not at all relevant at that
end of the connection.
The hypothetica
multiple signatures!)
[1]: https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
[2]:
https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism/cyber-security-guidelines/guidelines-cryptography
Best Regards,
Taavi Eomäe
smime.p7s
Description: S/MIME Cry
On 06/01/2025 19:58, Michael Thomas wrote:
This pretty much tells you everything you need to know about the state
of DNSSec [...]
I don't think the fact if Google has or has not deployed something
should be the deciding factor here.
Are you against DNS (and by extension its security mechan
On 06/01/2025 03:01, Michael Thomas wrote:
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.
Wouldn't it suffice if Authentication-Results header were to option
On 20/11/2024 15:31, Richard Clayton wrote:
Since we're meant to be discussing whether to open a WG and what it's
charter should be, should superseding ARC be specifically mentioned ?
Once again I have to disagree that DKIM2 should mix "just trust me"
operations with "you can see what I did" o
On 07/01/2025 23:02, Michael Thomas wrote:
Has NIST given a timeline of when they are going to pick the quantum
resistant algorithm? I suppose if it's far enough out, it might be
worthwhile to wait, but on the other hand figuring out a transition
sooner rather than later might be good.
The
On 07/01/2025 23:15, Murray S. Kucherawy wrote:
Do we need to say explicitly in a charter that the best contemporary
practices in terms of cryptography have to be used in the development
of a new thing? If so, it seems like every charter would need to be
explicit about it.
Is there any harm
On 16.04.2025 13:01, Steffen Nurpmeso wrote:
Ie, it is a quality-of-implementation issue, and standards cannot
cover everything. Ie dkimpy's default set, or my one with
one-letter shortcuts to very easily have a comprehensive default
set at hand (that then can be added to or subtracted from).
If
Hi,
On 05.05.2025 21:29, Wei Chuang wrote:
One idea is to ask receivers to fully trust the security gateway as
the modifications done are to protect the receiver's users with best
effort by the gateway.
In this case ARC would be the only correct solution.
While DKIMv2 might provide some theo
On 08.05.2025 01:54, Tero Kivinen wrote:
I think all this is bad idea. The recipient should do everything it
does based in its own policies, whatever the sender wants or does not
want does not matter.
I have to agree. Same goes for the forwarding part.
Mostly just reiterating what you've just
Hi,
On 07.05.2025 00:57, Wei Chuang wrote:
I put out the "certification" process as a strawman to see if such
flexibility for arbitrary modification by a "trusted" security way is
of interest to the community. Looking at the other similar reply as
well, it sounds like no, this is a bridge too
On 31/03/2025 11:55, Alessandro Vesely wrote:
If we don't change the canonicalizations, a DKIM1 verifier will be
able to verify a DKIM2 signature, limited to DKIM1 semantics. A
successful verification still adds something to the properties of a
message.
And as mentioned in some other thread I
On 31/03/2025 18:11, Michael Thomas wrote:
If they ignore the plain and clear text of STD 76, what makes you
think they will honor it in a new protocol?
Which is what is not being asked from those implementations, if the
version is incremented instead of a new set of headers. Those
implement
On 31/03/2025 15:25, Brotman, Alex wrote:
I have a hard time believing that all the libraries focusing on DKIMv1 will go
back and create some code to handle this case.
Indeed, they probably won't. Which is exactly why it might be better to
have those old implementations continue stripping sig
On 31/03/2025 21:09, Michael Thomas wrote:
Is there actually evidence of this "punishment"? Filtering is
notoriously opaque. Sounds more like paranoid behavior on the part of
some deployments.
Yes.
Rspamd for example is assigning the R_DKIM_REJECT symbol a weight of 1.0
(not 0.0 or 0.1, like
On 31/03/2025 19:35, John Levine wrote:
I don't understand what point you are making. The spec says that's
wrong. How would the presence or absence of v=2 make it less wrong?
It's not about if it's wrong or not, it's only an observation that this
behavior already exists in the ecosystem as a
On 31/03/2025 17:53, Michael Thomas wrote:
It was always a bad idea to strip signatures, and continues to be. The
text of DKIM couldn't be more clear that a broken signature is
equivalent to no signature and broken signatures have always had
forensic value.
Unfortunately in reality broken si
Hi,
On 08.05.2025 20:03, John Levine wrote:
Except that DKIM2 will let recipients reliably look back through the changes
that forwarders make.
Which was exactly the point I was trying to make.
a) If the changes are reversible (they're not "arbitrary
modifications"), validity is easy to veri
Hi,
On 24.07.2025 14:26, Alessandro Vesely wrote:
However, the implementation considerations that guided the choices of
RFC 8463 may still apply to a PQ algorithm. Therefore, we should
devise a format in which some tags have multiple values, dependent on
the algorithm, while others are valid
21 matches
Mail list logo
