Re: [certid] Fwd: secdir review of draft-saintandre-tls-server-id-check-09

[Phillip Hallam-Baker <[e-mail]>]

The question in my view is what you intend to do with the certificate
information.

Let us consider some outsourcing cases:

A)  Alice writes a blog, she has her own DNS name and the Web site is hosted
as a virtual Web server on a machine with 1000 other blogs

B) Bob writes a blog, but he rents use of a whole machine, not just a
virtual partition.

C) Carol writes a blog and also sells T-shirts with witty slogans on that
people buy through a hosted checkout.

D) Doug runs a business with a large e-commerce shop and manages the credit
card data directly.


Question, which ones of these should be using SSL?
Answer, all of them.

Question, which identity should the application client be presenting to the
user.
Answer: Doug is the only party that has a corporate identity.
Alice, Bob and Carol probably don't want to reveal their personal identity
so the only identity we have that we can present is a domain name.


The reason I raise this is that I see several possible conclusions that can
result from cert processing query:

1) Organizational Validation or Extended Validation that establishes
accountability.

2) Certificate is bound to the domain name on which the resolution process
was begun

3) Certificate is bound to a domain name to which the resolution points

4) There is no particular connection between the cert and the domain name.


Which outcome is sufficient depends on whether your objective is to turn on
use of crypto or tell the user that they are safe.

Another point to bear in mind is that applications are not necessarily
applying the traditional SSL model in which the application looks at the
information provided by the Web site and determines if that meets a
particular safety threshold and the user is responsible for working out if
they are safe or not.

For the past five years or so, the model that has been emerging is one in
which the application takes data from multiple sources and fuses them to
establish a safety evaluation. For example, if a domain name is on the
Anti-Phishing Working Group suspicious URL list, the browser might well want
to block access regardless of whether the Web Site has a certificate or not.


So rather than having a spec state what is 'safe' and what is not. We really
need to look at how many potential points of vulnerability have accumulated.

Running Web servers and running DNS servers 24/7 is complex and time
consuming. There are clear economies of scale. So people are inevitably
going to outsource.

The number of potential points of vulnerability are a consequence of the
outsourcing and not the use of CNAME. The use of CNAME is merely a
consequence of the easiest way to implement outsourcing.

More points of vulnerability does not correspond to higher risk. What
matters is the vulnerability of the weakest link in a chain (or the weakest
critical path in a redundant mesh).



On Thu, Sep 16, 2010 at 1:39 AM, Matt McCutchen <[e-mail]>wrote;wrote:

> On Thu, 2010-09-16 at 07:27 +0200, Martin Rex wrote:
> > Clearly unsafe operations:
> >
> >   - building a reference identifier from the result of a
> >     DNS CNAME lookup
>
> > (the use of DNSSEC does not make this safe)
>
> Why not?  I'm not saying it's good practice, but I don't see an actual
> vulnerability.
>
> I agree with everything else you said; nicely put.
>
> --
> Matt
>
> _______________________________________________
> certid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/certid
>



-- 
Website: http://hallambaker.com/