For the past month I have been participating in the KEYASSURE discussions. One aspect of those discussions that was not made clear in the original notice sent out is that the group is not only considering key assurance, the proposals made are also intended to have security policy semantics.
This was not apparent to me from reading the list announcement, the initial proposed charter or the Internet drafts. I have asked the organizers of the group to clarify the matter in the wider IETF community but they have not done so. In particular I am very concerned about the particular approach being taken to security policy. What the proposers are attempting to do is to create a mechanism that allows a site that only uses one particular high assurance CA to 'protect' themselves against SSL certificates being issued by low assurance CAs. As such, this is an objective I approve of and is one that I would like to see supported in a generalized security policy. It should be possible for a site to make security policy statements of the form 'all valid PKIX certs for example.com have cert X in the validation path'. What I object to is the approach being taken which is to use DNSSEC to replace PKIX certificate validation entirely. Now the proponents are trying to downplay this by saying that 'all' they are doing is to tell people to 'ignore' PKIX validation. But that approach really offends my sense of layering. Worse still, the proponents refuse to allow any method of shutting this system off. So if I have a site where I want to use DNSSEC validated certificates on the mail server, deployment is going to impact my Web server. Specifically the proposal amounts to using the DNS CERT record to publish a fingerprint of all the certificates permitted for use with TLS at a specific domain: example.com CERT TLSFP 0 0 <digest cert 1> example.com CERT TLSFP 0 0 <digest cert 2> It is proposed to replace current TLS certificate processing semantics with the following: 1) Query for CERT record at example.com 2) If no CERT record with TLSFP certificate type exists then perform normal PKIX validation and return that result 3) Otherwise attempt to match the TLS end entity certificate with one of the fingerprints specified in the published TLSFP RRs 4) If a match is found return VALID, otherwise return INVALID Note here that if there is a TLSFP RR that it takes precedence over PKIX processing rules. There should of course be DNSSEC validation performed in that process as well, but the authors have not explained how that is meant to work in the context of their proposal so I left it out. The defenses made for this approach are of the form 'you have to wear big pants to play this game'. In other words if people are going to administer these systems and not be burned they are going to have to understand what they are doing. I do not consider this a responsible approach to protocol design. What I would prefer is to have systems that do not need to be administered by people at all. That is not possible when the approach has hidden side effects that cannot be anticipated by scripts. I am very much committed to the idea of doing security policy. But this is not an approach I can support. Any policy mechanism has to be orthogonal to the key validation strategy in my view. I should be able to use any DNS security policy mechanism that the IETF endorses with PKIX certificate processing semantics. I have proposed an alternative approach in http://tools.ietf.org/html/draft-hallambaker-esrv-00 This does not currently contain a mechanism to express trust restrictions but is designed to be extensible to support such. When I proposed ESRV I was unaware that the KEYASSURE proposal was intended to have a security policy aspect at all. It is still not made explicit in their draft. Using the revised version of ESRV I am currently writing, a security policy of the form 'always use TLS with any protocol at example.com' would have the form: example.com ESRV "tls=required" A security policy that was specific to http would be expressed as: example.com ESRV "prefix=_http._tcp" _http._tcp.example.com ESRV "tls=required" or example.com ESRV "prefix=*" _http._tcp.example.com ESRV "tls=required" The reason for this change from the -00 version is that this approach supports CNAMEs. The reason that I started with the requirement to use SSL is that security policy relating to trust criteria is meaningless until you have a statement that use of SSL is required. I have no objection to doing security policy. But I do have a real objection to an approach that negates PKIX semantics as the TLSFP approach does. -------- Original Message -------- > Subject: New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC > Date: Tue, 17 Aug 2010 11:36:02 -0700 (PDT) > From: IETF Secretariat <ietf-secretar...@ietf.org> > To: IETF Announcement list <ietf-annou...@ietf.org> > CC: keyass...@ietf.org, ondrej.s...@nic.cz, war...@kumari.net > > A new IETF non-working group email list has been created. > > List address: keyass...@ietf.org > Archive: > http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html > To subscribe: https://www.ietf.org/mailman/listinfo/keyassure > > Description: This list is for discussion relating to using > DNSSEC-protected DNS queries to get greater assurance for keys and > certificates that are passed in existing IETF protocols. The main idea is > that a relying party can get additional information about a domain name to > eliminate the need for using a certificate in a protocol, to eliminate the > need for sending certificates in the protocol if they are optional, and/or > to assure that the certificate given in a protocol is associated with the > domain name used by the application. In all three cases, the application > associates the key or key fingerprint securely retrieved from the DNS with > the domain name that was used in the DNS query. > > For additional information, please contact the list administrators. > > > -- > Ondřej Surý > vedoucí výzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.s...@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > _______________________________________________ > saag mailing list > s...@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Website: http://hallambaker.com/
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop