Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

[Ilari Liusvaara <[e-mail]>]

On Wed, Nov 03, 2010 at 01:14:11PM -0400, Phillip Hallam-Baker wrote:
> 
> There are certainly issues that arise with prefixes as I mentioned in
> my other post. But they are tractable provided that:
> 
> 1) You are prepared to allow an additional DNS round trip.
> 2) You are prepared to introduce a new DNS RR.

Considering the adoption of CERT RR, CERT RR can almost be treated as
new RR.

And there's a diffrence between having to serialize the query and
firing off the query in parallel with some other qurey one would have
to do anyway.

> We have to keep an eye on efficiency, but anything we do here is going
> to depend on deployment of new DNS support infrastructure and require
> transport that supports new RRs.

Well, there's RFC 3597. But of course, new RRs (even if RFC 3597-compliant)
have issues with adminstration.

> Certificates typically bind to an entire domain.

They may, or they may not. Some services use certificates in bizarre
manner and can't share them with anything.

> Statements concerning configuration of a security policy naturally
> bind to a specific service at a domain.

If you think HSTS is good example of security policy, consider that
HSTS is really a special kind of protcol-level redirect and is only
well-defined because of interactions between HSTS spec and HTTPS
spec.

That's why I think that records specifying secure equivalent of service
must specify where to locate the service and how to connect to it
(there are essentially two ways).

> When we start to look at the consequences of outsourcing, the fact
> that I have outsourced my Web site to outsource.net does not
> necessarily mean I want to trust them with my mail service so maybe
> the assumption that certificates are global to a domain also starts to
> break down.

Actually, HTTP is just about the worst in this regard since it does
not support any kind of protocol-specific redirect from DNS. Yes, it
supports CNAME, but CNAME isn't prtocol-specific.

SMTP has MX records, many protocols have SRV, but HTTP does not have
anything like that.
 
> So I am thinking that we are going to end up with a requirement for
> protocol specific key assurance.

Actually, at key assurance level, port numbers/services only matter
if you can partition port numbers/services (which might not be
possible) or if you have services with different security levels on
one name (to prevent attacking higher-security services using stolen
key from lower-security service).

-Ilari