[Top] [All Lists]

RE: email-arch -- Security Considerations

2008-03-11 08:39:44

Well wordsmithed. Why does it remind me of a EULA?


-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Dave 
Sent: Tuesday, March 11, 2008 11:06 AM
To: ietf-smtp(_at_)imc(_dot_)org
Subject: Re: email-arch -- Security Considerations

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>



  Dave Crocker
  Brandenburg InternetWorking

<Prev in Thread] Current Thread [Next in Thread>