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: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of thomas schorpp
Sent: Saturday, August 20, 2005 12:59 PM
To: ietf(_at_)ietf(_dot_)org
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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf