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

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

+1 on the RFC 5507

This was actually a major change that was made to the document.
Originally there was a blanket proscription on prefixes that some of
us spent a lot of time and effort to get changed.

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.

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.


I think that we should first decide on all the features we might want
and then look at how we implement.

Certificates typically bind to an entire domain.

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


I may use the same certificate for my mail and web servers. But I
almost certainly have not configured them identically.

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.

So I am thinking that we are going to end up with a requirement for
protocol specific key assurance.


On Wed, Nov 3, 2010 at 12:36 PM, Paul Hoffman <[e-mail]> wrote:
> At 4:03 PM +0000 11/3/10, Tony Finch wrote:
>>On Sat, 30 Oct 2010, Warren Kumari wrote:
>>>
>>> I (no hats) was against the _selector_ idea as I feel that all records
>>> related to a thingie (technical term) should exist at the same level
>>> [...], but this is an elegance viewpoint and enough folk have pointed
>>> out that this is a needed feature that I'm open to it as an idea....
>>>
>>> Another option (which has some (IMO) of the elegance retained, but
>>> probably has scalability and leakage issues) is [...] basically, have
>>> the records for foo.example.com (or just exmaple.com) all at the same
>>> level, but have the ports included in the response.
>>
>>I think both of these are argued against by section 3.1 of RFC 5507.
>>
>>That RFC also argues against a _prefix approach, but it also fails to
>>provide any solution for RRs that can apply to any service and which need
>>to be selected per service.
>
> I read that section (and lots of other sections of 5507) as saying "don't assume one solution fits all". But I also note that the section 3.1 talks about the problems of "a large number of services for a single domain name" causing fallback to TCP. In the case of KIDNS, the solution is simple: don't allow a large number of services to be accessed by that domain name just because they are all running on the same box. That is, if the use of subtyping causes a TCP-fallback problem for the nameserver of a particular domain name, the solution is in the hands of the affected parties: use subdomains (which they probably are already doing anyhow...).
>
>>Another argument against putting all the records at the same domain name
>>is that it couples the policies for the services together. For instance, I
>>would want to be able to put certs or fingerprints in the DNS for my
>>secure services without forcing my colleagues to upgrade their services to
>>secure-only. (It's reasonable not to prioritize the deployment of
>>encryption for anonyous services.)
>
> First off, the proposal for "say which services require TLS" is not part of KIDNS, despite what it might seem from reading some of the list traffic. When that protocol is specified, it does not (and I think should not) be linked to the KIDNS key association.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/keyassure
>



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