[Top] [All Lists]

Re: [ietf-smtp] [pkix] another attempt to canonicalize local parts

2016-03-11 14:45:58
(Copying Stephen for reasons that will become clear if they are
not immediately obvious)


I think there are three separate issues here and that it would
behoove us to try to keep them separate, especially if there is
any desire to make progress.  In no particular order:

(1) Is it reasonable to try to "canonicalize" email addresses to
make them more usable for purposes other than routing and
delivering email?  RFC 5321 and associated and predecessor
documents are fairly clear on the answer to that question: that
answer is "don't even consider it".  As discussions in this
thread and a recent DANE-related Last Call illustrate, even the
use of the term "canonicalization" dresses us and distorts some
of the actual issues: it may (note "may") be sensible to talk
about canonicalizing a mailbox local part by, e.g., lower-casing
a string that consists entirely of ASCII letters and digits but,
as soon as one starts dealing with strings containing non-ASCII
characters, the possibility of local parts that contain
substrings that are given special interpretation on the system
hosting the mailbox or MUAs that access its content, we aren't
really talking about canonicalization, we are talking about some
member of the "do what someone else means/intends" family.  As a
protocol, the first step in that one is "learn how to read
minds, including the minds of people you don't know".

If people want solutions for the "canonicalization" problem, I
suggest that it starts with trying to devise -- as part of the
email specs-- a profile for "modern" or "security-tool-friendly"
email addresses (and how they are interpreted) in the same
spirit as PRECIS and with a focus on "we aren't banning doing
anything else, but don't expect it to work with some
ever-broadening set of tools".  If that is to go anywhere, it
needs to recognize both the "locally-extended address" (aka
"subaddresses", etc.) ideas and similar issues which which the
IETF has never been willing to engage about, but maybe it is
time.  If it isn't, than anything that depends on guessing the
actual address given some surrogate for the address is both a
dead end and the source of risks of attacks.

(2) How bad MUAs are about handling signatures and encryption,
whether the design of one protocol or the other makes really
good implementations harder, and so on.  The IETF has
traditionally opted out of UI and other MUA interface issues
and, while I think that is usually a good decision, I think it
has led to some rather poor design in this case.  In addition,
we have all seen situations in which some feature has been
incorporated into a software package as a checklist item, i.e.,
because someone claimed that people in general, or a particular
customer, wouldn't buy the package unless some particular
feature was claimed to be present... or that having it present
on a list would be a competitive advantage.   For reasons that
are obvious, at least to anyone who has been around the industry
for a while, that situation often results in very poor
implementations that don't get fixed because, one the checkbox
is checked, no one cares.

Note that John Levine's "almost universally implemented, but
virtually zero use" comment is entirely consistent with the
symptoms of a checklist requirement.  

There are hard problems in that area, including the
(probably-correct) assumption by UI/ MUA developers that they
need to make things as simple and brainless as possible
(leading, among other things, to the assumption that keys should
be auto-selected to match (naively) email addresses) while those
who are more sophisticated about security issues may prefer to
go to the extra effort to hand-pick keys and use that process as
an extra check (see John Levine's recent note for a better and
more complete explanation of this).    I don't believe we know
how to get that balance right, but wish there were more
carefully-written and well-supported MUAs out there to use as
examples or try to get to make improvements.

(3) Whether the key structures are right for this sort of thing?
Even if one could deal with the two issues above, and even more
important if one partially cannot, or if you contact me and get
me to tell you how my email addresses are organized, one needs
to bind information to the keys (or certs) themselves that
provides details or rules that go beyond a simple list of one or
more addresses.  What John has been referring to as an Oracle
either exploits that information or substitutes for it.   The
ancillary information is important because, as we keep
rediscovering with the DNS, being able to look up a string and
find out that it is an alias for another string doesn't imply
being able to generate a complete list of names that are aliases
for some other name and because, not matter how much
standardization we do, we are not going to succeed in
establishing a single simple set of rules (like one
canonicalizing regular expression) for the entire Internet.


--On Friday, March 11, 2016 18:19 +0100 Martin Rex
<mrex(_at_)sap(_dot_)com> wrote:

John R Levine wrote:

S/MIME has been widely available for close to 20 years,
implemented in  nearly all desktop MUAs, and the number of
people who use it (other than  the ones whose employers
demand it) still rounds to zero.  PGP is no  better, despite
the wide availablity of public PGP key servers.  I think  the
poor match between the addresses in certs and the ones in
real mail is  one of the reasons.

I've seen something called S/MIME in MUAs, but it is not even
close to what I would consider usable support for encryption &
digital signatures in EMail.  The original PGP, although it's
not used more often, at least doesn't suffer from obvious
S/MIME fuckups.

What I've been seeing with S/MIME is several obvious total
failures  (1) in aspects of the protocol
 (2) in the MUA handling of archived digitally signed and
encrypted mail  (3) in the management of S/MIME certs (and
S/MIME credentials)      by both the public CAs signing these
 (4) in the management of S/MIME certs and trust by the MUAs

But the underlying fundamental problem is that PKIX only really
works for *online* authentication, and EMail implies archiving
of messages, and PKIX just sucks here and S/MIME is TITSUP
about archived EMails.

Several years go I received an S/MIME signed email from the
car dealer&garage about a maintenance issue with my car.  The
signing certificate was issued under a RootCA cert that was
neither publicly available, nor was it included in the S/MIME
message (an S/MIME protocol defect).

It was simply impossible to make Outlook (2003 on WinXP
64-bit) verify that S/MIME signature due to the lack of the
RootCA cert.  Importing and marking as trusted the
intermediateCA cert (that was included in the S/MIME message)
or the end-entity cert (that was also included in the S/MIME
message) did not help a iota.

The obvious failures here are (1) why does S/MIME allow
sending of S/MIME message with cert _chains_ that are
incomplete.  This is obvious crap and should have been
prohibited in S/MIME from the beginning. The decision which
cert from an X.509v3 cert path to trust, whether to use
"leap-of-faith" to establish this trust, and wether trust
anchor certs for the purpose are pulled from the message or
distributed out-of-band *MUST* be with the end-user.

Not being able to configure trust for this message to that
signature verification would succeed is TITSUP type (4) of the
Outlook MUA.

I also have dozens of S/MIME-signed messages from colleagues
sitting in my EMail archives that are now being reported with
"invalid signature", but which verified just fine at some
point in the past.  That is a total failure of the (3) kind of
the cert-signing CAs, plus a total failure in (2) of the
Outlook MUA in not timestamp-resigning received
digitally-signed mail before archiving it, so that digital
signature can still be verified in 20+ years.

Another issue is with encrypted EMail (one receives) and
having to roll one's own S/MIME keypair when the short-lived
cert expires.  S/MIME MUAs must either be prepared to properly
handle dozens of prior S/MIME credentials in order to access
archived encrypted S/MIME messages, or they will have to
detach the encryption from the S/MIME-credential before
message archival, and re-encrypt the message with a key that
will be long-term available. The options for access of
archived encrypted needs to be *standardized* by S/MIME so
that switching from one MUA to a different one will work
smoothly.  S/MIME is TITSUP in that area of archived encrypted


*TITSUP = "Totally Incapable To Support Usual Performance"

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>