Document: draft-ietf-emailcore-rfc5321bis-32.txt
I find myself in agreement with Donald here as far as the Security
Considerations go. Section 5 of RFC 3552 states in part:
Authors MUST describe
1. which attacks are out of scope (and why!)
2. which attacks are in-scope
2.1 and the protocol is susceptible to
2.2 and the protocol protects against
At least the following forms of attack MUST be considered:
eavesdropping, replay, message insertion, deletion, modification, and
man-in-the-middle. Potential denial of service attacks MUST be
identified as well. If the protocol incorporates cryptographic
protection mechanisms, it should be clearly indicated which portions
of the data are protected and what the protections are (i.e.,
integrity only, confidentiality, and/or endpoint authentication,
etc.). Some indication should also be given to what sorts of attacks
the cryptographic protection is susceptible. Data which should be
held secret (keying material, random seeds, etc.) should be clearly
labeled.
...
It is insufficient to simply state that one's protocol should be run
over some lower layer security protocol. If a system relies upon
lower layer security services for security, the protections those
services are expected to provide MUST be clearly specified. In
addition, the resultant properties of the combined system need to be
specified.
I don't believe that Section 7 (and in particular Section 7.1) do this
for SMTP, and I would ordinarily expect discussion of the topics
Donald indicates, namely transport security, DKIM, SPF, etc. I
recognize that this is document a special case in that SMTP was
designed prior to the widespread deployment of cryptographic
techniques and so its relationship with them is different from (say)
that of QUIC and its embedded cryptography, but I think that goes
mostly to the technical details of the protocol, not the need to
clearly state the security properties of the resulting system.
As has been noted, I do see that some of these topics are discussed in
the A/S, though I have not studied it fully enough to determine if
they are adequately covered. In general, I would prefer not to have
the Security Considerations for a protocol deferred to another
document, but I do see that there is some force in the argument for a
separate specification. However, if it is to be separate, then I
believe that document needs to be a normative reference. The purpose
of the Security Considerations section is to ensure that the reader of
the specification is able to understand its security properties, and
therefore it should not be published until we know that together with
its normative references the document provides that clear picture.
I find myself in agreement with Donald here as far as the Security
Considerations go. Section 5 of RFC 3552 states in part:
Authors MUST describe
1. which attacks are out of scope (and why!)
2. which attacks are in-scope
2.1 and the protocol is susceptible to
2.2 and the protocol protects against
At least the following forms of attack MUST be considered:
eavesdropping, replay, message insertion, deletion, modification, and
man-in-the-middle. Potential denial of service attacks MUST be
identified as well. If the protocol incorporates cryptographic
protection mechanisms, it should be clearly indicated which portions
of the data are protected and what the protections are (i.e.,
integrity only, confidentiality, and/or endpoint authentication,
etc.). Some indication should also be given to what sorts of attacks
the cryptographic protection is susceptible. Data which should be
held secret (keying material, random seeds, etc.) should be clearly
labeled.
...
It is insufficient to simply state that one's protocol should be run
over some lower layer security protocol. If a system relies upon
lower layer security services for security, the protections those
services are expected to provide MUST be clearly specified. In
addition, the resultant properties of the combined system need to be
specified.
I don't believe that Section 7 (and in particular Section 7.1) do this
for SMTP, and I would ordinarily expect discussion of the topics
Donald indicates, namely transport security, DKIM, SPF, etc. I
recognize that this is document a special case in that SMTP was
designed prior to the widespread deployment of cryptographic
techniques and so its relationship with them is different from (say)
that of QUIC and its embedded cryptography, but I think that goes
mostly to the technical details of the protocol, not the need to
clearly state the security properties of the resulting system.
As has been noted, I do see that some of these topics are discussed in
the A/S, though I have not studied it fully enough to determine if
they are adequately covered. In general, I would prefer not to have
the Security Considerations for a protocol deferred to another
document, but I do see that there is some force in the argument for a
separate specification. However, if it is to be separate, then I
believe that document needs to be a normative reference. The purpose
of the Security Considerations section is to ensure that the reader of
the specification is able to understand its security properties, and
therefore it should not be published until we know that together with
its normative references the document provides that clear picture.
-Ekr
On Sun, Oct 27, 2024 at 7:05 PM Donald Eastlake <d3e3e3@xxxxxxxxx> wrote:
I have provided the best feedback I could as a reviewer with a bit of
a security focus. I have a partially drafted response re nits but they
are just nits and I have decided it is not worth my effort to perfect
and send it. As a new set of eyes without the WG history, I hope my
feedback has improved the document.
Thanks,
Donald
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e3e3@xxxxxxxxx
On Sun, Oct 27, 2024 at 9:38 PM Dave Crocker <dhc@xxxxxxxxxxxx> wrote:
>
> On 10/27/2024 6:28 PM, Donald Eastlake wrote:
>
> I did not suggest a discussion of DMARK or DKIM. I suggested that they
> be mentioned.
>
> Donald,
>
> SMTP is a protocol specification. The document already attempts to go far beyond it's scope for handling one submission and direct, associated deliveries. It has quite a bit of text that seeks to be an general architecture document, as well as trying to cover activities outside of Internet Mail, per se. It does these added jobs only partially, at best. There are historical reasons given, for not removing those bits of text, but it certainly does not justify adding more material that is best classed as a layer violation.
>
> DMARC, DKIM and SPF are all completely outside of the email transport protocol specification. They are very much IN scope for a broader discussion of email as a service. But that's a different goal.
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> mast:@dcrocker@mastodon.social
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
