[TLS] Cert Enumeration and Key Assurance With DNSSEC

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

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 <[e-mail]>
> To: IETF Announcement list <[e-mail]>
> CC: [e-mail], [e-mail], [e-mail]
>
> A new IETF non-working group email list has been created.
>
> List address: [e-mail]
> 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:[e-mail]    http://nic.cz/
>  tel:[phone]       fax:[phone]
>  -------------------------------------------
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>



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