Hi!
For my answers, I'll disclose: I don't have the resources to look at
drafts besides what seems like the WG "mainline" to me.
So my comments/questions are about what are _actual_ problems with the
mainline you're trying to solve with your alternatives. I'd be
interested to see them described _specifically_ (but not by "read my
whole draft").
On 9/9/26 18:14, Vittorio wrote:
to be clear on scope: my objection to JSON concerns header handling on
the critical path, not body recipes.
If I understand, the "mainline" drafts don't require to rewind
Message-Instance versions in the synchronous code path at all. The
minimum verification needed before sending the SMTP dialogue response is
just the newest DKIM2-Signature/Message-Instance. I.e. some
cryptography, and base64 yes (for hashes and the "shallow" envelope
sender/recipient info checking).
Other checks described in the draft (Message-Instance chain, full chain
of custody) are, as far as I understand, optional. You can decide to do
them synchronously (as we will do probably), asynchronously (e.g. for
assessing whose reputation you need to take into account), or not at
all. Bounceability is already ensured by the shallow check. If the
previous hop broke Message-Instances or chain of custody and you
asynchronously bounce the message, any issues with relaying the bounce
further upstream is their problem, not yours.
Body recipes are a separate design question - my position on their
optional status is documented in the draft and is not the subject of
this thread.
And the comparison isn't JSON versus MIME, but JSON versus tag=value -
the DKIM1/ARC style, which has worked reliably for years, to the point
that I reused it in DarkChain.
For me, MIME _is_ in the game. Many MTAs handle MIME in some ways. E.g.
for 8BITMIME related transforms - or in mail analysis for spam scoring
etc. And I can tell you, MIME is a beast, even when looking only on
what's needed for those transforms.
The overall RFC5322 message syntax is in the game too. That one is less
hard, but even there, we've seen corner cases (e.g. some MTAs being
tolerant with LF-only line endings over the wire despite the spec being
clear, it's only CRLF; which has led to a security bounty finding not so
long ago)!
On parsing: the concern isn't raw speed, it's that JSON introduces a
dependency on parser libraries whose behaviour differs on edge cases
(parser differentials, type confusion) - attack surface that tag=value
does not carry, in a security protocol.
That's an implementation detail. If I/we were wary about an external
JSON parser library, I'd personally not hesitate to re-implement the
needed JSON subset parsing/generation manually, with much less qualms
than things like RFC5322 address header parsing (harder than you might
think and also showing behavior differences between implementations),
RFC2047 de- and especially encoding (that one is harder than you'd
think) or MIME.
We have differential behavior in many mail related IETF standards
already. As said, MIME (which is IMO more in the game than you might
thing), but even in more basic RFC5322 (LF tolerance, address headers,
..., see above). I don't think this is categorially new issue with JSON
over other email related syntax. In a way, JSON is IMO more clearly
defined in a way to reduce possible confusion leading to critical
behavior differences. Especially in the subset we need (object, array,
string, integers; no true/false/floating point).
A suggestion would be if at least one participant in interop testing
would write a very strict parser for just that subset to show if others
produce weird stuff and if so have them correct course early. Personally
I'd like to, just at work I won't get the ressources probably.
On logging, your "decode it yourself" confirms the opacity rather than
answering it. Routing information that every other transit header
carries in clear now needs a decoding step to be inspected and
building a logging layer to compensate only adds complexity on top of
what DKIM2 already introduces.
You talked about logging. Not about the original representation in the
mail. Or did I misunderstand you?
For logging, I'd not include original D2-S or M-I information as is,
even if it were more human readable.
In the message itself, you could imagine things like in earlier drafts.
But we found that ad-hoc more cleartext-like syntax was frought with
many difficulties. I was part in those discussions. I found some of
those difficulties in those drafts.
And apparently the WG at large _wants_ (at least) the change tracking in
the current "mainline" draft. So I'd ask you if you have a
_constructive_ alternative: Same/similar change tracking (instead of
reducing/dropping it), and an alternative syntax that doesn't have its
own issues (like the pre JSON predecessors of the "mainline" draft).
On memory you confirm the mechanism: holding two adjacent versions in
memory during verification. That is the buffering that tag=value avoids;
That's not true. A naive parser parses the tag=value stuff completely as
to be able to consistency-check stuff later instead of just in one
linear "forgetful" pass.
And the other way round, you can parse JSON in a stream-based fashion
(e.g. 2-pass: first pass just validate JSON and recipe syntax
constraints without keeping information; second pass using a SAX-like
parsing model intertwined with streaming revision rewind).
DarkChain verifies at constant memory per header and runs on a 2GB
server in tens of milliseconds.
I don't think my verifier will need anything even close to 2GB. Even
allowing for our current, generous mail size limit. And as said, I've
got a prototype that streams mail bodies once through recipe rewind/M-I
verification quite fine. (For simplicity it doesn't interleave
incremental JSON parsing, but with header size limits, there are
implicit limits to the RAM use of parsed M-I/recipe values, still).
CPU is not scarce in general, but whose CPU? 1&1 and the large
providers, or the university or small associations running a single
server? That is the question RFC 3935 asks: the internet is for
everyone, not only for those who can absorb the overhead.
I don't expect my verifier to use so much CPU that it would be extra
slow even on my private very old desktop PC (Core 2 Duo, 4G RAM). Or if
we were to port the code even to my old smartphone. But contemporary
internet won't exactly run on an old C64 or PDP11 either; those will be
constrained out in other places already, like TLS. So let's stay
realistic with "the internet is for everyone" and not assume "everyone"
includes computing constraints from low- to mid-end consumer hardware
from more than a decade ago (or the expectation that someone who
arbitrarily limits themselves to a small Z80 microcontroller would run
an MTA specifically on that)?
I think DKIM2 (current draft) is very implementable for something like
my very old private desktop, which should be good enough for a
contemporary small VPS/Raspi/... too. And I think you don't even need
very special optimization techniques (i.e. I think even non-streaming
recipe verification will be good enough even for such smaller hardaware).
I'd like to try to encourage you to try it out by making your own draft
implementation, not _extra_ wasteful, but also not _extra_ optimized to
the point of making code very complicated.
[...]
Kind regards,
Hannah.
PS: I see "base64" also mentioned in the Subject line. Do you still have
issues even with that, too?
--
Hannah Stern
Software Developer
Mail Transfer Development
1&1 Mail & Media Development & Technology GmbH | | |
Phone: +49 721 91374-4519
E-Mail: [email protected] | Web: www.mail-and-media.com www.gmx.net
www.web.de www.mail.com www.united-internet-media.de
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452
Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig, Dr.
Verena Patzelt
Member of United Internet
Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen
enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail
irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten
Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt,
diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise
auch immer zu verwenden.
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient of this e-mail, you are hereby notified that saving,
distribution or use of the content of this e-mail in any way is prohibited. If
you have received this e-mail in error, please notify the sender and delete the
e-mail.
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
