ietf
[Top] [All Lists]

RE: namedroppers, continued

2002-12-09 09:54:08
Well, it's also the availability of the right signature
facility in the
myriad email clients people use.

I disagree here, I believe it is a case of supporting the
overwhelming majority of the platforms with software that
is freely available and free.

I don't believe that we should consider support for Open
Genera to be a 'must support' issue. Years ago people used
to whinge when someone sent a MIME attachment of 10K or
so because it took too long to download over a 300 baud
modem.

I don't think it is a bad thing to consider that high
bandwidth connectivity is still a constrained resource
absent in many less developed parts of the world. However
the complaints about using MIME never come from those
quarters.


I could write that up in an internet
draft if folks
think it makes sense. That would be a more global procedure
that didn't
require a PKI and only addressed spoofed addresses.

Wasn't me...

The problem is not the PKI, the problem is the directory.

Deployment of PKI is easy. It is the Directory baggage that
people foisted onto PKI that is the failure. X.500 has set
us back more than the NSA crypto export regulations ever did.
LDAP merely compounds the problem, building failure on top
of failure.

We need a DNS linked PKI, not a directory linked PKI.

We need a PKI that only cares about the addresses the
applications route on. The idea of using human names for
PKI is bogus.

The directory PKI model fails for the Internet for many
reasons. First taxonomic organization is a broken concept.
No real world information is stuctured in that fashion,
not even genealogies (cousins marry cousins). The reason
that so many enterprise directory projects are fiascos
is that they are trying to fit data into a representation
that is simply inappropriate.

The other main reason that directories are a failure for
Internet PKI is that they are exclusively an internal
data resource. VeriSign has an employee directory accessible
from the inside of the company. There is no way it is
ever going to be accessible from the outside.

At the Internet level trust relationships are complex,
they are certainly not hierarchical. Trying to store that
data in a taxanomic sturcture then do path discovery is
nonsense on stilts.


Linking the PKI to the DNS completes the picture. I want
to send Fred Baker an email, well I had better know his
email address first. My email client can follow an SRV
record from cisco.com to find an XKMS service for cisco.com
where I can ask 'what key should I use to send an
encrypted S/MIME email to fred(_at_)cisco(_dot_)com'.

Allowing organizations to find out that Fred(_at_)cisco(_dot_)com is still
working for Cisco is actually a security improvement. It
means that Office Max can shut off his personal stationary
account ordering privs the minute he leaves Cisco.


Don't reject the leverage that public key provides just
because you don't like the package people tried to wrap
arround it. The protocol you describe requires state and
is simply not deployable for large systems like hotmail.

It would be nice if the IETF could get ahead of the curve
this time instead of being the brake. We still have members
of the IESG speaking to security forums disputing the
utility of network security measures such as firewalls
even after Steve became a security area director.

We need to shift towards a comprehensive multi-level
security approach which accepts that there are problems
that cannot be addressed by the end to end argument.

Real users are saying that SPAM is their number one
internet related problem today. Classify it how you like
but deal with it with a security mentality. The spamers
are seriously degrading the utility of email. We need
a short term approach to mitigate the problem (filtering)
and long term approaches that have the potential to
put them out of business. Authenticating the good signal
is completely complimentary with rejecting the bad.

                Phill

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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