Re: [TLS] Cert Enumeration and Key Assurance With DNSSEC

[Ondřej Surý <[e-mail]>]

Phillip,

you present your views by cross-posting several other IETF mailing list 
without posting this to [e-mail].  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 <[e-mail]
>     <mailto:[e-mail]>>
>     To: IETF Announcement list <[e-mail]
>     <mailto:[e-mail]>>
>     CC: [e-mail] <mailto:[e-mail]>,
>     [e-mail] <mailto:[e-mail]>, [e-mail]
>     <mailto:[e-mail]>
>
>     A new IETF non-working group email list has been created.
>
>     List address: [e-mail] <mailto:[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] <mailto:[e-mail]> http://nic.cz/
>       tel:[phone]       fax:[phone]
>       -------------------------------------------
>     _______________________________________________
>     saag mailing list
>     [e-mail] <mailto:[e-mail]>
>     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:[e-mail]    http://nic.cz/
  tel:[phone]       fax:[phone]
  -------------------------------------------