ietf-mxcomp
[Top] [All Lists]

RE: User experience

2004-04-06 17:28:37

S/Mime MUAs verify that the RFC 2822 From: field matches that specified in
the subjectAltName attribute of the signing certificate.

Actual implementations will actually accept matches to other parts of the
spec but this is now depricated.

One of the issues we discussed in the antiphishing working group that I am
chairing is that S/MIME clients probably take the wrong approach to
verification. Given that most email is not authenticated at all and that the
most likely reason verification fails is that the mail infrastructure
mangled the message, should failure to verify be highlighted as a major
error, warning alert type event or should it just not tell you it is
authenticated?

Similarly, instead of pushing for everyone to check S/MIME message
signatures a first step would be to convince folk to do no harm, to always
present S/MIME messages to the user with a user experience at least as good
as for unsigned messages.


                Phill

-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Mark 
Baugher
Sent: Tuesday, April 06, 2004 3:17 PM
To: Markus Stumpf
Cc: ietf-mxcomp(_at_)imc(_dot_)org
Subject: Re: User experience



At 11:54 AM 4/6/2004, Markus Stumpf wrote:

On Tue, Apr 06, 2004 at 10:26:28AM -0700, Harry Katz wrote:
1. Whenever possible, we must validate the domain used on 
the From line
of the message, the RFC2822 From header to be precise. 
Because that's
what the user sees.

Maybe I'm missing something here, but isn't that exactly what PGP and
S/MIME does? (ok, it validates the user, not only the domain)


No, I don't believe either of these include the From or any 
header in the
integrity check of the mail message.  At least I don't 
believe PGP does.
I think you've mentioned in an earlier message, these fields are very
malleable in today's mail infrastructure and difficult to 
integrity check.

Mark


We already have a mechanism that is perfectly capable to 
verify 2822.From,
so why should we build another? Isn't it much easier so simply push
the distribution of this existing method (i.e. support in 
MUAs) than to
build a new system that probably is less efficient?

When signing messages one could make use of muliple 
keysigns, such that
a message is both signed by the key of a user and by a key 
for a domain
and the public key for that domain is e.g. stored in DNS.

May I also bring a caveat here: we should not use DNS based 
verification
with MUAs. Still (and probably also in the future) a lot of 
eMail readers
are behind firewalls and they read their mail on computers that
don't have a direct connection to the Internet and they cannot access
DNS from the MUA when reading their eMails.
Or they simply poll their eMails and read offline.

        \Maex

--
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: 
+49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: 
+49 (89) 32356-299
"The security, stability and reliability of a computer 
system is reciprocally
 proportional to the amount of vacuity between the ears of 
the admin"