Subject: RE: RFC 2487 [5]: Suggest dropping of "TLS Required"- forbid and extensions of current standards

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 22 Aug 2005 09:45:52 -0700

I don't think this is a good plan.

I am not at all opposed in principle to the idea of making changes to
the email infrastructure that are effectively mandatory in order to
combat Internet crime. I do not think that any scheme that mandates use
of CA services is likely to be acceptable however. The biggest mistake
of S/MIME was to design the toll boths into the protocol. The result is
a very slow rate of adoption.

>From the point of view of CA providers it is much better to have 30% of
a market that will reach saturation in 4 years than 100% of a market
that will still be far from saturation in 30 years time. 

I agree that getting authentication into the email protocols is a good
thing, but TLS does not achieve much more than SPF/Sender-ID in that
respect. DKIM is a much better platform.

The problem with TLS is that it does not even connect with the weakest
link that the criminals are exploiting. That is the two feet beween the
screen and the user's head. We need to secure that link and do it in a
way that is stronger than an authenticated domain name. 

I think that to combat phishing we have to bind the bank brand into the
signature by means of a highly trustworthy group of trusted third
parties. I call that concept secure internet letterhead.

I can build Secure Internet Letterhead as a layer on top of DKIM, I
cannot do that with TLS. All TLS is really going to provide is transport
layer authentication and confidentiality. Those are worthwhile but not
critical. 

I expect that most CAs that offer Secure Internet Letterhead certs will
also bundle an X.509 cert that can be used for TLS. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of thomas schorpp
> Sent: Saturday, August 20, 2005 12:59 PM
> To: [email-masked]
> Subject: RFC 2487 [5]: Suggest dropping of "TLS Required"- 
> forbid and extensions of current standards
> 
> 
> hi there,
> 
> i cant find the appropriate WG list to discuss this.
> so i posted it here.
> 
> item:
> 
> Hoffman                     Standards Track                   
>   [Page 1]
> > 
> RFC 2487                 SMTP Service Extension             
> January 1999
> 
> 
> 
> 5. The STARTTLS Command
> 
> 
>    A publicly-referenced SMTP server MUST NOT require use of the
>    STARTTLS extension in order to deliver mail locally. This rule
>    prevents the STARTTLS extension from damaging the 
> interoperability of
>    the Internet's SMTP infrastructure. A publicly-referenced 
> SMTP server
>    is an SMTP server which runs on port 25 of an Internet 
> host listed in
>    the MX record (or A record if an MX record is not present) for the
>    domain name on the right hand side of an Internet mail address.
> 
> suggestion:
> 
> 1. will be dropped
> 2. standards will be extended with requirement to present 
> valid approved-CA-signed certificates at using tls with 
> mailservers 3. standards will be extended to require 
> connection with xsmtps first with fallback to normal smtp or 
> implement a fallforward to xsmpts if a server/client requires it..
> 
> reasons:
> 
> - no more state of the art and technology (1999), nearly all 
> products support tls
> - ongoing criminal phishing activity over smtp
> - strong and free certificates for everyone availlable at 
> CACert inc., etc.
> - ongoing ucbe activity, spammers could be caught and charged 
> more easily with their certificates as evidence, same to phishers.
> - the current state breaks xsmtps networking since theres no 
> method to notify clients to reattempt with xsmtps.
> - expected more systems ressources needed for this are more 
> economical than current damage from ucbe and phishing
> - S/MIME is spreading too slow and unergonomical, risky and 
> too high effort for simple end users.
> - see https, better lets do it on transport layer
> - most end users and their certificate trust/intend is 
> controlled mainly by a well known u.s. software company 
> charging horrent and unreasonable fees to distribute so even 
> approved CA Certificates cant be easily mass-provided.
> - several local country signature law issues
> - information freedom and privacy
> 
> ... RFC...
> 
> y
> tom
> 
> 
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Fri, 26 Aug 2005 11:40:54 -0400

> respect. DKIM is a much better platform.

Not clear.  As currently envisioned, DKIM doesn't address phishing 
because it basically says "I saw this message" rather than "I wrote this 
message".  It doesn't authenticate transmission either because it 
doesn't record to whom the message was transmitted.  So it addresses the 
spam problem only if you're willing to take a rather large leap of faith 
in reputation services that have no reliable basis with which to 
determine a domain's reputation, and a few other leaps of faith besides.

I think DKIM is fixable, but if it stays in its current form it will 
only delay adoption of effective anti-phishing and anti-spam solutions 
by a few more years.  And several people in that proto-WG seem to think 
that getting agreement on something that people have blind faith in is 
more important than actually understanding whether and how it will solve 
any real problems.

Keith

---

From: Tony Finch <[email-masked]>
Date: Fri, 26 Aug 2005 16:45:55 +0100

On Fri, 26 Aug 2005, Keith Moore wrote:
>
> I think DKIM is fixable, but if it stays in its current form it will only
> delay adoption of effective anti-phishing and anti-spam solutions by a few
> more years.

Has anyone published a description of an "effective anti-phishing and
anti-spam solution"?

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

---

From: wayne <[email-masked]>
Date: Fri, 26 Aug 2005 10:50:50 -0500

In <[email-masked]> Keith Moore <[email-masked]> writes:

> Not clear.  [a summary of the status of DKIM that I generally agree with]
>
> by a few more years.

What would those "effective anti-phishing and anti-spam solutions" be?
I guess by "effective" I include the requirement of fairly rapid
adoption, which kind of rules out things like PGP and S/MIME.

-wayne

---

From: Mark Baugher <[email-masked]>
Date: Fri, 26 Aug 2005 09:15:19 -0700

I don't necessarily see the two needing to be combined so closely.  
Phishing exploits the web security model where the server authenticates 
the client a lot more than the client the server.  SPAM is one method 
of delivery for a Phishing attack, but there are others.

Mark
On Aug 26, 2005, at 8:45 AM, Tony Finch wrote:

>> only

---

From: Keith Moore <[email-masked]>
Date: Fri, 26 Aug 2005 12:38:35 -0400

> I don't necessarily see the two needing to be combined so closely.  

perhaps not, but if DKIM doesn't address either phishing, spam, or 
viruses, and it doesn't authenticate content authorship, what good is it?

---

From: Mark Baugher <[email-masked]>
Date: Fri, 26 Aug 2005 10:16:09 -0700

> viruses, and it doesn't authenticate content authorship, what good is 

I said that I don't think phishing should be combined so closely with 
the problem of spam.  But you throw in viruses and claim that it 
doesn't address any of the combined three.  Where's this coming from?  
I think you're wrong: DKIM does address spam and email-borne viruses.  
I think it addresses phishing spam as well but the phishing problem has 
yet another complication.

Mark

---

From: Keith Moore <[email-masked]>
Date: Fri, 26 Aug 2005 13:23:32 -0400

> the problem of spam.  But you throw in viruses and claim that it doesn't 
> address any of the combined three.  Where's this coming from?  I think 
> you're wrong: DKIM does address spam and email-borne viruses. 

No it doesn't, it just accepts on faith that signatures with vague 
semantics and poor granularity are enough to distinguish spammers and 
virus propagators from well-behaved senders, and defers the actual work 
of distinguishing between these to a vaguely concept of reputation 
servers, which is out-of-scope for DKIM therefore doesn't have to be 
understood.

In other words, it's not solving the problem or even trying to 
understand the problem, it's just moving it.

Keith

---

From: Mark Baugher <[email-masked]>
Date: Fri, 26 Aug 2005 12:54:53 -0700

All of this has been aired extensively among experts on at least two 
public lists as well as many private ones.  I have personally had a lot 
to say on the matter but don't see the point of repeating it here.

Mark
On Aug 26, 2005, at 10:23 AM, Keith Moore wrote:

> virus propagators from well-behaved senders, and defers the actual 
> work of distinguishing between these to a vaguely concept of 
> reputation servers, which is out-of-scope for DKIM therefore doesn't 
> have to be understood.
>