Subject: Re: [saag] IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?)

From: joel jaeggli <[email-masked]>
Date: Sun, 01 Jul 2012 09:39:36 -0700

On 6/30/12 6:04 AM, Yaron Sheffer wrote:
> This is highly speculative, highly subjective of course, but I don't 
> think an API would have gotten IPsec to dominate the world. On the 
> contrary, app developers are happy to focus on their own stuff and not 
> spend too much time on security.
>
> From an application point of view, TLS has two important advantages 
> over IPsec (IKE really):
>
> - The well known advantage is that TLS is usually happy to 
> authenticate only the server, leaving client auth to the application. 
> This makes deployment so much easier.
>
> - The dirty little secret is that many people do not even authenticate 
> the server. In the cloud computing space (today's Wild West?) I have 
> seen several cases of popular tools that just don't bother, with no 
> apparent justification that I can think of. Another example is EAP-TLS 
> configuration on Windows.
offhand I'd say that's the case for most smtp mta implementations as well...
> I'm not trying to imply that TLS is insecure. But clearly if 
> widespread deployment is a goal (and it should be, otherwise why 
> bother writing RFCs) you should let deployers/developers choose their 
> appropriate level of security. In some cases, sadly, they will make 
> the wrong choice.
>
> Thanks,
>     Yaron

---

From: Tony Finch <[email-masked]>
Date: Mon, 2 Jul 2012 12:22:56 +0100

joel jaeggli <[email-masked]> wrote:
> > - The dirty little secret is that many people do not even authenticate the
> > server. In the cloud computing space (today's Wild West?) I have seen
> > several cases of popular tools that just don't bother, with no apparent
> > justification that I can think of. Another example is EAP-TLS configuration
> > on Windows.

> offhand I'd say that's the case for most smtp mta implementations as well...

That's mainly because there's no spec for which identity to check against
the cert. Consequently bad certs don't cause operational problems, so most
certs that have been installed can't be verified.

http://www.imc.org/ietf-smtp/mail-archive/msg05366.html

Working on a fix: http://tools.ietf.org/html/draft-fanf-dane-smtp

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Tyne, Dogger: South 5 or 6, decreasing 3 or 4. Slight or moderate. Rain, fog
patches developing. Good, becoming moderate, occasionally very poor.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Jul 2012 12:04:01 -0400

>...
>
>x.500 naming is just not useful.  Humans can handle name@domain and
>only slightly more complex name forms, but x.500 is impossible.  And
>we're stuck with Name because that's what TBSCertificate uses for
>subjectName.  We can't switch to GeneralName for subjectName.  We're
>screwed.  I'm tempted to propose the use of UUIDs in subjectName and
>then treat the first subjectAltName as the canonical name, banning the
>use of Name, but that wouldn't fly either.  We're stuck.

X.509 has supported DNS names as Subject Alt names since 1998.

Steve

---

From: Nico Williams <[email-masked]>
Date: Mon, 2 Jul 2012 11:12:23 -0500

> X.509 has supported DNS names as Subject Alt names since 1998.

Right, but not as subjectName, because subjectName is only a Name, not
a GeneralName.  And so we're still stuck with Name, and Name is simply
awful.

Nico
--

---

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Jul 2012 12:46:39 -0400

>a GeneralName.  And so we're still stuck with Name, and Name is simply

Two observations:
	- one need not use the subject name for access control decisions
	- one can represent a DNS name as Subject name, using the DC attribute

Steve

---

From: Nico Williams <[email-masked]>
Date: Mon, 2 Jul 2012 12:23:42 -0500

>         - one can represent a DNS name as Subject name, using the DC

The former would be nice, but since that's not what's implemented,
it's not really possible to issue certificates with meaningless
(unique, effectively pseudonymous) subjectNames.  The latter works for
only one name type, and it's a hack.  But that's the point: being
forced to use the useless Name type means we're forced to encode
better name types as Name using ad-hoc conventions.  x.500-style
naming is stupid and worse than useless -- it is harmful.

Nico
--

---

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Jul 2012 14:14:40 -0400

At 12:23 PM -0500 7/2/12, Nico Williams wrote:
>(unique, effectively pseudonymous) subjectNames.

are you familiar with the RPKI, where the Subject and Issuer names
typically are hashes of public keys? See RFCs 6480-6493.

>   The latter works for
>only one name type, and it's a hack.

it is precisely the name type that you cited as a more natural one.
IP addresses are are supported via Alt names, too.

>   But that's the point: being
>better name types as Name using ad-hoc conventions.

I should have mentioned that PKIX does NOT require a Subject name
in an end-entity cert, which is the type of cert relevant to end-point
authentication in these contexts.  So, the only directory name in
such certs would be for the issuer.

>   x.500-style

that's a personal perspective, not an objective characterization.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Jul 2012 14:18:32 -0400

>The former would be nice, but since that's not what's implemented,

implemented by whom? we have lots of examples of bad code for all sorts of
IET standards. My favorite, recent example is an apparent lack of support for
the name constraints extension in a OS of a major vendor. this failure to
support a mandatory feature that has been part of X.509 & PKIX for over
a decade is causing problems as browser vendors and TAs try to limit some
of the damage that results from the unconstrained browser TA model.

>(unique, effectively pseudonymous) subjectNames.

not true. see my previous message.

Steve