Subject: Re: draft-pearson-securemail-02.txt

From: SM <[email-masked]>
Date: Sat, 03 May 2008 14:14:42 -0700

At 23:15 29-04-2008, [email-masked] 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 4 May 2008 00:44:03 +0200

SM wrote:
 
> SenderID and SPF does not authenticate the sender.

For starters they have different concepts of "sender",
PRA and envelope sender, and RFC 4408 section 10.4 
offers references (AUTH + SUBMIT) for folks wanting
more.  

> It only provides a means to restrict which server
> can send mail for a domain.

A domain indicated by PRA *or* envelope sender, with 
different ideas about this "or" being exclusive or
inclusive, and as indicated in the HELO or EHLO.  

The public enthusiasm for adding op=auth indicating
RFC 4409 option 6.1 "enforced submission rights" was
limited, IMO it would add what is missing "for folks
wanting more" wrt RFC 4408, but as long as receivers
are not interested it's pointless.

An op=auth for PRA would be slightly more convoluted:

It would indicate RFC 4409 option 8.1 "add 'sender'"
*plus* a fix for this section covering Resent-From,
but the RFC 4409 authors already said that they are
not interested to fix section 8.1 in 4409bis, and the
Last Called 2822upd also did not update its section
boiling down to "PRA violates MUSTard in 2822(upd)".

Admittedly my enthusiasm to fix PRA is also limited,
the SPF options draft specifies op=auth for SPF, not
for PRA, with RFC 4409 8.1 "as is" this cannot work.

Besides, why would receivers be interested in public
claims by a (PASSing) PRA about "auth" vs. "dunno" ?
It would take a fairly complex reputation scheme to
do something with this info.

> You could also have mentioned using SMTP AUTH and
> TLS at the submission stage.

The draft references RFC 4409, that is good.  But it
could also reference RFC 4954 and RFC 5068 for a more
complete picture of the state of the art.  And maybe
RFC 4949 for the terminology.

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Mon, 5 May 2008 18:17:58 -0700

On May 3, 2008, at 3:44 PM, Frank Ellermann wrote:

> For starters they have different concepts of "sender", PRA and  
> envelope sender, and RFC 4408 section 10.4 offers references (AUTH +  
> SUBMIT) for folks wanting more.

Agreed.  Neither SenderID or SPF offers authentication.  Both of these  
schemes provide a method for domains to _authorize_ IP addresses used  
by SMTP clients.  This can not be described as authentication since  
SMTP clients are often shared by more than one domain.  This scheme is  
fully dependent upon secure routing through questionable boundary  
issues.  In addition to the section 10.4 references, DKIM is another  
possible choice.

-Doug