Dave Crocker wrote:
A question has been raised about the very brief Security Considerations
section in the email-arch draft. I've modified the section slight, for the
next draft, but the section still defers meaningful discussion to existing
specifications.
Having now received candidate text, and having now worked vigorously to distort
it beyond any hope of its having benefit, here is what I propose for the
Security Considertations section:
<section title="Security Considerations">
<t>This document describes existing Internet Mail architecture. It
introduces no new new capabilities. The security considerations of this deployed
architecture are already documented extensively in the technical specifications
referenced by this document. These specifications cover classic security topics,
such as authentication and privacy. For example, email transfer protocols can
use standardized mechanisms for operation over authenticated and/or encrypted
links, and message content has similar protection standards available. </t>
<t>The core of the Internet Mail architecture does not impose any security
requirements or functions on the end-to-end or hop-by-hop components. For
example, it does not require participant authentication and does not attempt to
prevent data disclosure.</t>
<t>Particular message attributes might expose specific security
considerations. For example, the "blind carbon copy" feature of the
architecture invites disclosure concerns, as discussed in section 7.2 of
[RFC2821] and section 5 of [RFC2822]. Transport of text or non-text content in
this architecture has security considerations that are discussed in [RFC2822],
[RFC2045], [RFC2046], and [RFC4288] as well as the security considerations
present in the IANA media types registry for the respective types. </t>
<t>Agents that automatically respond to email have significant security
considerations, as discussed in [RFC3834]. Gateway behaviors impact end-to-end
security services, as discussed in [RFC2480]. Security considerations for
boundary filters are discussed in [RFC3028].</t>
<t>See section 7.1 of [RFC2821] for a discussion of the topic of
origination validation. As mentioned in section 4.1.4, it is common practice
for components of this architecture to use the RFC0791.SourceAddr to make policy
decisions [RFC2505], although it is possible "spoof" this address -- that is, to
use it without authorization. SMTP and Submission authentication [RFC2554],
[RFC4409] provide more secure alternatives.</t>
<t>The current document's discussion of trust boundaries, ADMDs, actors,
roles and responsibilities all highlight the relevance and potential complexity
of security factors for operation of an Internet mail service. Internet Mail's
core design to encourage open and casual exchange of message's has met with
scaling challenges, as the population of email participants has grown to include
those with problematic practices. For example, spam, as defined in [RFC2505], is
a consequence of this architecture. A number of standards track or BCP
documents on the subject have been issued. [RFC2505],
[ID-spamops],[RFC3685].</t>
</section>
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net