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

From: thomas schorpp <[email-masked]>
Date: Thu, 01 Sep 2005 10:41:36 +0200

Hallam-Baker, Phillip wrote:
> I don't think this is a good plan.

its not yet a plan. its not even a request. its just to think about.

> 
> 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.

me too. sorry for being "politic populistic". respectively, no
technology cant even suppress crime, its a political problem.

no dna-analysis, face-imaging or fingerprint recognition will help.

history has shown that criminals (street or even in highest ranks) would
take over newer techs.

> I do not think that any scheme that mandates use
> of CA services is likely to be acceptable however.

i would only accept "free" CA's. but youre free to invent a better
system then.

> The biggest mistake
> of S/MIME was to design the toll boths into the protocol. The result is
> a very slow rate of adoption.

agree. end user doesnt even recognize this abstract thing as a "key to
lock something or authenticate with" and suffer from data losses and the
unsolved 20years standing "lost passwords" problem and more.

> 
>>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. 

only applies to commercial ca's. and 100% is impossible due to the above
mentioned losses.

> 
> 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.

which systems has implemented it?

> 
> 
> 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. 

good point. i adressed this issue on the gnupg-dev list last year to
make that "interface" more ergonomical to users with "fingerprint
colorcodes" but nobody cared. surely theres much more to do.
but who will? crypto engineers do crypto and user interface engineers
tasks do not include crypto, eg, mostly... how many mid management and
ceo's do care? theyre priorities are fast selling business applications
diverting all risks including such security issues to customers and end
users by their lawyers and self protecting from them by license
agreements (so they ARE aware of it and have choosen handling it with an
old, cheap way).

e.g. in germany you can order something online without -any- customer
authentication but storno is only possible with paper or qualified
digital signature (if even). amex europe just told me to authenticate
personal at post office for contract and wont accept digital documents
by now but they accepted the -fully unauthenticated - online order.
their hotliners called me 2 times over phone requesting auth by telling
them some private personal data but they authenticated themselves in no
way, not even a caller id from them was shown on my phone.

a unacceptable "todays best e-biz practice".

> 
> 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.

as i said criminals and corruption are at home in every class and
position. motivation is money and power. so only non-commercial and
non-staten authorities are real trustworthy.

> 
> 
> 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. 
> 

i will check it out, thx.

y
tom

> 
> 
> 
> 
>>-----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: thomas schorpp <[email-masked]>
Date: Thu, 01 Sep 2005 11:37:46 +0200

Keith Moore wrote:
> 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 see...

> 
> 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.

hard words...

so lets use state of the art, and thats tls for now.

> Keith

tom