Phillip,
you present your views by cross-posting several other IETF mailing list
without posting this to keyass...@ietf.org. This doesn't give potential
readers full picture about what's happening in the keyassure and what is
the general consensus in the list.
So please all - if you want to respond to Phillip's message, first go to
keyassure mailing list archive[1], then join the the list[2] and comment
there. I don't think we want to fill our inboxes with this discussion
(which should really happen in keyassure) in several copies.
While we value input from other working groups it is already hard to
follow the discussion in one mailing list and when it splits to many, it
will be just a mess.
Ondrej
1. http://www.ietf.org/mail-archive/web/keyassure/
2. https://www.ietf.org/mailman/listinfo/keyassure
On 1.10.2010 17:29, Phillip Hallam-Baker wrote:
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 <http://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 <http://example.com> CERT TLSFP 0 0 <digest cert 1>
example.com <http://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 <http://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
<http://example.com>' would have the form:
example.com <http://example.com> ESRV "tls=required"
A security policy that was specific to http would be expressed as:
example.com <http://example.com> ESRV "prefix=_http._tcp"
_http._tcp.example.com <http://tcp.example.com> ESRV "tls=required"
or
example.com <http://example.com> ESRV "prefix=*"
_http._tcp.example.com <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
<mailto:ietf-secretar...@ietf.org>>
To: IETF Announcement list <ietf-annou...@ietf.org
<mailto:ietf-annou...@ietf.org>>
CC: keyass...@ietf.org <mailto:keyass...@ietf.org>,
ondrej.s...@nic.cz <mailto:ondrej.s...@nic.cz>, war...@kumari.net
<mailto:war...@kumari.net>
A new IETF non-working group email list has been created.
List address: keyass...@ietf.org <mailto: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 <mailto:ondrej.s...@nic.cz> http://nic.cz/
tel:+420.222745110 fax:+420.222745112
-------------------------------------------
_______________________________________________
saag mailing list
s...@ietf.org <mailto:s...@ietf.org>
https://www.ietf.org/mailman/listinfo/saag
--
Website: http://hallambaker.com/
--
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
-------------------------------------------
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
