Subject: Re: Scale (and the SRV record)

From: Stephen Kent <[email-masked]>
Date: Wed, 4 Nov 1998 17:17:52 -0500

Phill,

Although I'm very late getting into this particular debate due to being
away on travel (mostly not Internet connected) for almost 2 weeks, I concur
with several of the themes of your observations, although I might prefer
storing certs and CRLs in the DNS per se, rather than using DNS records as
pointers to othyer repositories.

The DNS is the only robust, distributed directory system the Internet has.
That makes it attractive for two things: storing data, such as certs and
CRLs, and for its naming tree.  Note that anytime we use a name in a cert
that is not exactly the same as the name we use in an application, we are
required to perform a mapping between two name spaces, and that introduces
another database which imposes significant additional management overhead
and another place to make errors with adverse security implications.  So,
for example, for IPsec, i really want certs with DNS names and IP
addresses, since these are the native name forms that the applications
employ and upon which access control decisions are made.  For SSL, browsers
check a DNS name in a certificate against the corresponding portion of the
URL, and ignore the rest of the DN in the subject field.  For e-mail the
case may not be so strong, since people may mentally map identifies
irrespective of e-mail addresses, but even there I worry that cognitive
overload can eaisly set in and cause people to make perception mistakes.
(If one has an S/MIME system that automatically checks for the
correspondence between the "from" address and the sender's DN from his
cert, instead of presenting the subject DN from the certificate, then the
above arguments apply.) So, here too, I really prefer certs with e-mail
addresses, which is a change from a stance I adopted years ago when I wrote
RFC 1422.

Steve

---

From: "Frank O'Dwyer" <[email-masked]>
Date: Thu, 05 Nov 1998 22:52:32 +0000

Stephen Kent wrote:
> URL, and ignore the rest of the DN in the subject field.   

I think this is an extremely important point--any mapping between name
spaces must be done securely and where such mapping can be avoided then
all the better. However I think it's important to understand that the
important native name forms are those that appear on the user interfaces
of applications, which are not necessarily those used deep in the
technical undergrowth. In fact, SSL as used for web browsing got that
wrong and is vulnerable as a result; it authenticated DNS names whereas
most users click on icons and natural language hyperlinks. The linkage
between those hyperlinks and DNS names is not supplied securely and thus
web spoofing is possible. (The situation is even worse today, since now
the browsers automatically map keywords when you type them into the
location bar.)  

The whole issue of naming is critical for PKI security, however I think
it's fair to say that even among experts there is no common
understanding of how PKI naming works in detail, and that does not augur
well for the security of PKI applications. The "end-to-end" naming
solution you describe above (native names in certificates) removes many
vulnerabilities, but I think you need to be sure that the names really
go end-to-end, in the sense of going all the way up onto the user's
screen, and from the user's keyboard. The issue of local vs. global
names raised by the SPKI group is also highly relevant, and really needs
to be taken on board here--for example the existence of NAT and network
10 addresses makes it staringly obvious that many distinct machines will
have the same IP address in their certificates, therefore they cannot
share the same namespace. Or will public CAs issue certs for 10.0.0.0?

For e-mail the
> addresses, which is a change from a stance I adopted years ago when I wrote

Unfortunately that still suffers from a name mapping problem. I
occasionally receive emails from people who have confused me with some
other Frank O'Dwyer on the Internet. I also have a friend who has the
same name as another person in the company where he works; he regularly
receives email about the golf society his namesake belongs to--I had to
phone him to verify his email address. The risks for encrypted email
should be obvious. The difficulty is that authenticating the email
address is insufficient if the email address itself is not obtained
securely (i.e. if it does not correspond to the user's understanding of
the name presented on the mailer's user interface). Another way of
looking at it is that securely mapping an email address to a key is only
one half of the problem; the other half is securely mapping a warm body
(or a machine recipient) to an email address.

Cheers,
Frank O'Dwyer.

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Thu, 5 Nov 1998 18:08:27 -0500

> all the better.

Frank makes some excellent points. What he is addressing is the 
interface between PKIX and SSL (TLS). Is this a PKIX-WG issue or a
TLS-WG issue?

I think it is something which TLS should address since it naming
is an issue which must be handled separately by each 'PKIX aware'
protocol. The naming issues of S/MIME are very different for example.
Indeed the naming issues of TLS-HTTP and TLS-LDAP could well be
different.

	Phill

---

From: EKR <[email-masked]>
Date: 05 Nov 1998 21:10:16 -0800

> Indeed the naming issues of TLS-HTTP and TLS-LDAP could well be
Folks, there is a draft on this topic:
draft-ietf-tls-https-02.txt

I believe I've done a reasonable job of covering the appropriate
issues, and the TLS-WG has pretty much come to a consensus that
the name matching stuff is done correctly. If PKIX people
have problems with how it's done, I'd like to hear them.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]

---

From: "Frank O'Dwyer" <[email-masked]>
Date: Fri, 06 Nov 1998 11:19:53 +0000

> have problems with how it's done, I'd like to hear them.

I think that there are two flaws in how that's done, one minor and
reasonably easily fixed, and one major and difficult to fix. I'm working
off draft-ietf-tls-https-01.txt, though, so maybe something's changed
meanwhile.

The minor flaw may apply to TLS in general, in that UDP/TCP transport
connections are identified by a 4-tuple {source host, source port,
destination host, destination port} but tls-https only authenticates the
destination host, not the port. This leaves scope for one TLS service to
impersonate another, provided they have the same DNS hostname. The same
problem exists for different and seperately-administered HTTPS services
at the same DNS hostname but at different well-known ports. This might
be fixable via appropriate trust criteria on the certificates, but I
think a more straightforward fix is to either include the port number in
the server identity and mechanically check for it, and/or (for backward
compatibility) to forbid reuse of a DNS hostname for TLS services
running on different well-known ports.

The major problem is hyperlink/web spoofing (see
http://www.brd.ie/papers/sslpaper/sslpaper.html/ and
http://www.cs.princeton.edu/sip/). This issue should at least be pointed
out in a "security considerations" section or similar. It's difficult to
fix, but in some cases mechanical checks can be made. For example, if a
user clicks on a pepsi logo with a https link, the server certificate
could contain that logo in an appropriate extension and it could be
mechanically checked for. Similarly, if the user clicks on the phrase
"Bank of Foo online banking", the server certificate could contain that
phrase and it could be checked for.

Cheers,
Frank O'Dwyer.

---

From: EKR <[email-masked]>
Date: 06 Nov 1998 07:48:11 -0800

> running on different well-known ports.
Yes, this is an issue, but I consider it a much less important one.
Primarily, end-node machines should arrange that this can't
happen.

> http://www.cs.princeton.edu/sip/).
Sure. This has been a problem since day one. But it's basically 
unfixable. This isn't just a problem with TLS. It's a problem with
any system anywhere that's ever purported to verify certificates
mechanically. To whit: You need to verify that the user's expectations
for who they are talking to match who they are in fact talking to.
Except that we don't have direct access to the user's expectations.

> This issue should at least be pointed
> mechanically checked for.
This really can't work, in the face of the n different sizes and color
variants of the logos. Worse yet, the certificate ISN'T in the
certificate.

> Similarly, if the user clicks on the phrase
Except that this is easily spoofed by having the certificate say
"Bank of Mafia" and getting the user to click on "bank" when you
change the page.

-Ekr

---

From: "Frank O'Dwyer" <[email-masked]>
Date: Fri, 06 Nov 1998 18:13:59 +0000

> Primarily, end-node machines should arrange that this can't

OK, but this should be stated somewhere (perhaps the base TLS spec).

> Except that we don't have direct access to the user's expectations.

Yes, it's a general problem, and there is no 100% fix, but still some
certificate checks are better than others (otherwise why specify any
check at all?). For most applications the vulnerability is significantly
reduced by ensuring that the certificate corresponds to the user
interface, and removing any name mappings that are subvertible and
hidden from the user. For example TLS used with a normal telnet client
would be less vulnerable since a DNS name is what you type in there. 

> variants of the logos. 

That's not true. Images can be scaled in HTML (so you just need the logo
in its largest size). As far as color and other variants go there will
be a small number of those, and in any case only one is necessary to
identify a secure service. To reduce the size of the extension, a hash
of the image bits could be used instead of the bits themselves.

> Worse yet, the certificate ISN'T in the
> certificate.

That is easily fixed (I assume you mean the logo isn't there today). I'm
not sure if a suitable extension already exists for it (probably not)
but it should be just another alt name form. (It would certainly be more
useful than some of the cruft that is currently allowed in
certificates.) However the tls-https spec currently has a MUST for using
the dns altname if it is present--it's not clear if that simply means it
is to be used instead of the common name, or if you are barred from
performing other checks instead or additionally. The latter
interpretation precludes the use of a superior check if you have one.

> "Bank of Mafia" and getting the user to click on "bank" when you

No, I didn't mean to imply a substring check--I meant actually checking
that the phrases exactly matched. You could put a regular expression or
wildcards in the cert but then you'd need to be careful of attacks like
the one you describe. To avoid having to include every hyperlink phrase
used on a https site, or unduly constraining the content of those sites,
this really only needs to be checked when you move from one site to
another. 

Cheers,
Frank O'Dwyer

---

From: EKR <[email-masked]>
Date: 06 Nov 1998 10:47:32 -0800

> OK, but this should be stated somewhere (perhaps the base TLS spec).
Feel free to tell the TLS editors.

> hidden from the user.
The number of applications for which that can be done is shrinking
rapidly, as users get increasingly divorced from network naming.

> in its largest size).
1. Images are almost never done in HTML. They're GIFs.
2. Images aren't CANONICALLY scaled, so this makes the rescaled
logo unverifiable. 

> As far as color and other variants go there will
> identify a secure service.
Right, but this requires the web page developer to choose only
one logo and stick with it. I don't believe it.

> However the tls-https spec currently has a MUST for using
> performing other checks instead or additionally.
It seems clear enough to me. You MUST do the subjectAltName check. It
certainly doesn't preclude other checks as well.
Moreover, -02 says
   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted.

Your check would fall into this category.

> that the phrases exactly matched.
Yeah, I still don't buy it. 
I don't believe users will carefully check for the difference
between 
"Bank of Foo"
and 
"Bank of a Foo"

for instance.

There are simply too many lookalike variants. Now, if there was only
one CA, you could expect them to enforce uniqueness across variants,
as the PTO does (poorly). However, in the face of multiple CAs ,
I don't believe this will work.

To be blunt, I believe this is a lost cause. I've heard
a nearly infinite number of such proposals over the years,
and IMHO none of them stand up to close scrutiny.

-Ekr

---

From: "Frank O'Dwyer" <[email-masked]>
Date: Fri, 06 Nov 1998 23:03:42 +0000

EKR wrote:
> > For most applications the vulnerability is significantly

All the more reason to stop checking just those names and check the name
forms that are actually visible. (I just mean removing dependency on
those name mappings for security btw., obviously they will still be
present.)

> 1. Images are almost never done in HTML. They're GIFs.

Right, but they are presented by dereferencing and rendering HTML IMG
tags, which may contain scaling attributes. This means that the same
source image can be presented at different scales just by rewriting the
HTML.

> 2. Images aren't CANONICALLY scaled, so this makes the rescaled

No, that's not correct. If the IMG tag is used to do the scaling, then
the source image is the same string of bits no matter how it is scaled
for presentation. Only the enclosing HTML differs. (Some other image
formats are even designed to render the same image at any scale, but
unfortunately those aren't used by the browsers. I don't know whether
PNG is like that or not.)

> one logo and stick with it. I don't believe it.

The only difficulty I see is where a corporation alters its logo, which
does happen. But that is no different than a corporate or DNS name
change, which also happen -- you just get a new certificate. As for web
developers, they can be made use what ever logos they are given. Given
the current risk of (say) spoofing an online banking service, which is
considerable, there is plenty of incentive for an organisation to make
this happen. Nor would there be any added security risk if the developer
used the wrong logo, either, it would just mean the page would load with
severe security warnings (assuming browsers actually made this check).

> Your check would fall into this category.

OK, then that is just a misreading on my part. The version I have says
"if a subjectAltName of type dNSName is present, that MUST be used as
the identity". I took that to override the previous paragraph, which
contains your text above.

> I don't believe users will carefully check for the difference

OK, on one level it's a mechanical check, and the browser would do it.
On another level, yes, the user could confuse the text of the link with
some other name and still be spoofed. The nastiest case of that would be
where two separate organisations actually possess the same name in
different jurisdictions. That is a problem of reliance on global names,
which is a general PKIX problem. Other cases include things like
"Micros0ft", however I can't think of any plausible variant of (say)
"Bank of Ireland" that misdirects to an attacker AND that someone could
get a trustworthy certificate for. ("Bank of 1reland" is the best I can
come up with--and I can't see any trustworthy CA issuing that, unless in
error to the bank itself.) Regardless, this is still a stronger defense
than the hostname check alone. Without this check the user doesn't need
to misread the link at all (it need only be unaware of network names)
and the attacker has to do less work. 

> I don't believe this will work.

Even if so, a lot of organisations propose to be their own CA. If it
worked for them, that's better than not addressing the problem at all.

> and IMHO none of them stand up to close scrutiny.

Well, the difficulty with that view is that the proposal to only check
the DNS hostname doesn't stand up to close scrutiny either. Why dismiss
the others and accept that? Regardless, if you agree it's a serious
concern and you think it's not fixable, then I think the spec should at
least bring it to people's attention. 

Cheers,
Frank O'Dwyer.