Re: draft-pearson-securemail-02.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At 23:15 29-04-2008, Internet-Drafts@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]