Bron,
I read with interest the proposal published at
https://www.ietf.org/id/draft-gondwana-dkim2-motivation-01.html
I think it could contribute to the development, with all due respect to
DKIM technology, the core approach already deserves it. But there are a
few points that should be mentioned that I'm missing.
DKIM provides, like ARC, the ability to verify the authenticity of the
sender. But all this verification is useless unless the organisation
also has the ability to specify a signature policy. So, the following
options:
- NONE: not specified or explicitly stated that there is no signature
- MAY: can be signed
- MUST: all must be signed
- DISCARD: all must be signed and those that are not signed are
counterfeit and must be discarded
- DISABLED: if it should be complete, there should also be the ability
to disable the signature, but I can't think of a reason to do it
This in particular is a fairly topical pain that simply cannot be dealt
with. I know there is a daily distribution of spam under the headers of
existing companies that are sent "like" from the company, but due to the
existing gaps between SPF, DKIM and DMARC there is nothing that can be
done about it. All past efforts like ADSP and the like have fizzled out,
they have been called unnecessary, historic and there is no chance to
enforce the policy. DMARC is a solution that supports SPF or DKIM, the
recipient can verify the information, but that's about it. At the
moment, DKIM relies on DMARC, which accesses either SPF or DKIM, I only
need one. Even in DMARC, it is not possible to enforce this signature.
So, maybe I'm asking silly, but why is there such a signature anyway? Is
it there for decoration, to make it look nice, or is it to fulfil the
purpose required by the organisation? And if it is to fulfil this
purpose, the organisation should also have a tool to manage it. If it is
to have meaning, then the meaning must be quite clear. So do I want to
sign or not? If I want to sign, how much do I want to sign, or do I want
to sign everything? And if I want to sign everything, do I want to throw
away what is unsigned? With these rules, the deployment of cryptographic
protection is starting to make sense. The policy must not be part of a
separate extension, but part of the RFC for DKIM. Otherwise, it will be
overlooked and it will never be possible to enforce its implementation.
As a result, it will die just like the ADSP.
In addition to managing the rules for signatures, there is also a need
to collect information about the evaluation of signatures and possible
errors. The original design for DKIM reporting, which would have
included return codes for signature errors, is outdated, did not allow
the centralization of the reception of reports for multiple domains.
Moreover, almost no one collects the reported reports. Still, I would
often welcome information about how many emails were sent and signed
with a specific key, how many were evaluated erroneously due to a key
material error (public key in DNS), a signature error (content
manipulation, unknown algorithm, etc...). At the moment, TLS reports,
DMARC reports are available, and although the DKIM report is defined in
the extension, no one uses it. This is precisely because it is part of
the extension, not DKIM.
The basic ARC error is relying on a trusted first hop. More precisely,
the first signed hop. This is designed to verify the validity of the
sender and is also a weakness of the whole approach. It would be
advisable to avoid a similar trap. In my opinion, it is not important
whether the first step on the path is trusted. What is important is
whether the first step on the path signs the previous path with its key
and announces that the email has actually arrived from this address.
This makes it possible to trace where the email left from and
potentially block the first unsigned servers.
Last and most important, especially recently, is the support for
algorithms. Currently, existing digital signature algorithms are in
decline. The RSA algorithm is still currently secure, but for how long.
An alternative is Ed25519, where the vast majority of organisations
providing software for receiving and sending e-mail have not been able
to implement it since 2018 and still do not support it. Although it is
faster, more economical in terms of signature etc.
Into this situation comes a new wave of cryptography, which should be
resistant to attacks led by quantum computers (preferably quantum
FPGAs). According to the standards and roadmap in Europe and the USA,
there should be a transition to algorithms for key exchange by 2030 and
for digital signature by 2035. For critical infrastructure by 2027. At
that point, there will be pressure to move from e-mail to another
communication channel, although I do not know what the alternative might be.
Standards in this area:
- FIPS 203 ML-KEM (Krystal Cyber, Key Exchange Mechanism, SVP+LWE)
- FIPS 204 ML-DSA (Krystal Dilithium, Digital Signature Algorithm, SVP+LWE)
- FIPS 205 SHL-DSA (Stateless Hash Based DSA, Digital Signature
Algorithm, uses stateless hash trees)
- draft FIPS 206 FN-DSA (Falcon - Fast-fourier transform over
NTRU-lattice based DSA, Digital Signature Algorithm, uses stateless hash
trees)
- RFC 8391: XMSS: eXtended Merkle Signature Scheme
- RFC 8554: Leighton-Micali Hash-Based Signatures
In my opinion, only FIPS 205 and FIPS 206 could be usable in the DKIM
signature at this point. For use with DKIM, it is advisable to avoid
possible problems and use stateless methods for simplification. I can
imagine a system using state schemes, but these changes could also have
an impact on the whole architecture of the system.
A very good overview of the levels of nervousness, consternation and
panic from quantum computers can be found at
https://www.gsma.com/newsroom/post-quantum-government-initiatives-by-country-and-region/
And the transition to quantum-resistant mechanisms may be an opportunity
to cut into the structure of DKIM as well. In the next few years, RSA
and ECC will be fully shut down, so backward compatibility can be
forgotten. More specifically, policy definitions will have to be
extended to deal with outdated technologies that are potentially
dangerous. This is a huge opportunity to do the right thing. But,
please, do not implement RSA again. It is a waste of time.
I apologize for this extensive contribution
Jan
Dne 28. 11. 24 v 1:15 Dave Crocker napsal(a):
On 11/21/2024 1:21 AM, Bron Gondwana wrote:
I have made a second pass at it. Text below, or see the raw copy at:
https://notes.ietf.org/YGynIPpYS7yqg5G7ZeSQeA
Summary:
* As provided, this is an extremely broad and extremely vague
statement of work. It continues to sound far more appropriate for
the IRTF than the IETF, especially absent a concete draft
specification to take as input. (It's not as if the IETF hasn't
accepted charters like this. But it /is/ as if such working groups
have typically not fared well. Stated more baldly, "let's charter a
group and then figure out what we are going to do" has a bad history
in the IETF.)
* The draft seems to include a target of 'trust relationships' which
is an open research topic that DKIM only indirectly relates to,
except for trusting a signature.
* IETF Internet Mail handling really only covers a single
posting/delivery sequence. It touches on more elaborate sequences,
but only piecemeal. And draft charter does not really note or deal
with this difference in scope. So the proffered 'holistic' effort is
a very considerable increase in scope from something labeled DKIMbis
or DKIM2.
Detailed comments:
DKIM2 Draft Charter
// <https://notes.ietf.org/#Background>Background
Emails often flow indirectly through multiple systems, undergoing
redirection, expansion into multiple copies via aliases and mailing
lists, as well as rewriting and filtering before eventually arriving
at a mailbox or being processed by a receiving software agent.
The opening sentence sets a stage that matches many end-user
experience views of email, but misses the basic technical distinction
that is the essence of the enhancement being sought. *As described in
that sentence, email is delivered more than once, before it is
'finally' delivered.*
So instead, perhaps:
It is common for an email to go through multiple posting/delivery
sequences, before eventually arriving at a 'final' mailbox or being
processed by a 'final' receiving software agent. Examples of such
'indirect' flow include redirection through an alis, expansion into
multiple copies via an alias or a mailing list, as well as rewriting
and filtering before eventually arriving at a mailbox or being
processed by a receiving software agent.
I left 'rewriting' in but actually don't know what it refers to, nor
why 'filtering' is relevant to DKIM signature survival.
(By the way, I thought that posting from an ESP was also classed as an
indirect flow. Is this not correct?)
DKIM provides a way to detect that the content of a message was not
altered between the signing domain and its eventual destination.
This sounds correct but can be misleading, given the 'eventual'.
DKIM was designed to work from one posting to one delivery. It was
never intended to survive the vagaries of what can happen between a
delivery and a next posting. That it sometimes does survive is nice,
but was not a design goal.
So what is being sought here is a very basic and very substantial
increase in scope for DKIM.
Several attempts have been made to address the issues that arise with
alterations made by intermediate systems. For various reasons, these
technologies have failed to provide the information to reliably
distinguish between legitimate mail, and replay or alteration of
messages by bad actors.
DKIM does not attempt to distinguish 'legitimate' mail from mail that
is not legitimate.
As for 'replay' it needs to be precisely defined here, especially
since there are different views about what it refers to.
As for alteration by bad actors, I was not aware that that is
considered a problem for DKIM. In fact I thought it was /not/ a
problem. So this needs to be explained and documented.
Objectives
This working group will take a holistic approach to the underlying
problems of message alterations, error handling, and trust
relationships between the systems involved in handling an email -
from its inception to arrival at its final destination.
There are problems with error handling? What are they? I don't
recall seeing discussion of this. What is the actual work to be
done? What goals for improvement are sought?
Trust relationships are far -- very far -- beyond the scope of DKIM,
other than whether a DKIM signature can be trusted.
Given the considerable increase of scope for DKIM and range of topics
cited here for improvement, the charter should have a concrete
proposal to take as input, if only to provide an example of how one
might approach dealing with these topics.
The working group will use the mechanisms of DKIM as a basis,
extending and modifying them to solve problems that have been
identified in real-world usage.
Since they have been identified, they should be documented here,
clearly enough to aid the working group in knowing whether something
is in-scope our out of scope.
It will be necessary for any new design to work in parallel with the
existing mechanisms, and have a clear upgrade path.
If it is parallel, it is independent. So I don't know what it means
'to work' in parallel. And I don't know what it means to not work in
parallel.
To achieve its goals, this work requires a wide scope. The design may
supersede, modify, or replace many parts of the current email
infrastructure and associated reporting mechanisms - while retaining
the ability to support existing use-cases.
Oh. In parallel with existing /email/. You want to replace the
current Internet Mail infrastructure. Gosh...
Forgive me, but, again, this is something for the IRTF, not the IETF.
Deliverables
To gain widespread adoption, it is expected that proposed solutions
will be tested during the development of specifications. The working
group will favor designs which have been tested for interoperability
at scale.
This working group will produce multiple documents, at least:
* A overview document describing the problem area and proposed
mechanism (informational)
* One or more documents on implementation of the mechanism
(standards track)
* A guide for implementation during the changeover period, in which
interoperability with existing mechanisms needs to be maintained
(informational)
This working group will also liaise with the DMARC working group on
adding this as a recognised authentication mechanism.
Milestones
* WG Formation: Dec 2024
* Overview document adopted: Jan 2025
You think it will take only one month to complete the overview
document, given what time-frames other email work has been taking?
* Mechanism document draft(s) adopted: Mar 2025
Only two more months for a stable specification effort? Really?
* Experiments and updated drafts: Apr 2025 - Nov 2025
* Implementation guide adopted: Nov 2025
* Group of documents sent to IESG: Dec 2025
d/
--
--
-- --- ----- -
Jan Dušátko
Tracker number: +420 602 427 840
e-mail: j...@dusatko.org
GPG: https://keys.dusatko.org/2E7D58B90FC2867C.asc
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
