At 23:15 29-04-2008, Internet-Drafts(_at_)ietf(_dot_)org wrote:
Title : Applicability Statement for SecureMail: A
framework for increasing email security
In Section 2:
"email delivery until the information is available again - and yet,
email is about speedy delivery. In addition, the behaviour of email"
Email is not about speedy delivery. It is a best effort. From a
user's point of view, it may appear speedy compared to snail
mail. Furthermore, the sender has an expectation that the message
will reach the intended recipient(s). Some operators silently drop
bounces in the bit bucket and delivery failures go unnoticed.
In Section 4:
"It uses Transport Layer Security (TLS) for confidentiality and
integrity of the message and Sender ID [RFC4406] and the Sender
Policy Framework (SPF) [RFC4408] to authenticate the sender."
TLS only creates provides confidentiality and integrity of the
message between the sending server and receiving server. It's all
plain text at the submission and delivery stages. To preserve the
integrity of the message, you'll need some assurance between sender
and receiver. SenderID and SPF does not authenticate the sender. It
only provides a means to restrict which server can send mail for a domain.
In Section 4.2, you mention that the sender authentication methods
mitigate the risk. If you are using an email address from an ISP,
you can put in the address of any of its users unless it restricts
the use of the mailbox as seen in the "From:" header.
In Section 7.3:
"If the sending domain's DNS record is compromised and the SPF record
is modified to include an attacker's address, that device would
appear to be authorised to send mail on the domain's behalf. This
type of attack is unlikely as the types of threat agents (spammers,
phishers, etc.) are unlikely to want the additional effort and risk"
I find this kind of attack less than unlikely in today's
environment. There are several cases of DNS records being
compromised. As your system is meant to provide secure communication
between, government, businesses and citizens, it makes an attractive target.
SecureMail is described as an alternative to the postal system. In
Section 8, you mention:
"It is not intended to specify how the sender or receiver manages their
own email security.".
It's ignoring the fact that the email can be tampered in
transit. Even if the sender and receiver have a good security
policy, they don't have any means to determine the authenticity of
the message. If the system is to be an alternative to the postal
system, it should at least provide some indication for the receiver
to make an assessment about the validity of the message.
The draft mentions using POP3/SSL to retrieve mail. You could also
have mentioned using SMTP AUTH and TLS at the submission stage.
Although the draft describes the New Zealand's experience only, it
might be used as a model by other countries. It may be better to
reassess the proposals in the draft especially as it states to be a
framework for increasing email security.
Regards,
-sm
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf