Subject: [keyassure] WG Review: Keys In DNS (kidns)

From: IESG Secretary <[email-masked]>
Date: Tue, 26 Oct 2010 10:00:01 -0700 (PDT)

A new IETF working group has been proposed in the Security Area.  The IESG
has not made any determination as yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list ([email-masked]) by Tuesday,
November 7, 2010                           

Keys In DNS (kidns)
-----------------------
Last modified: 2010-10-25
Current status: Proposed Working Group

Chairs:
    Warren Kumari <[email-masked]>
    Ondrej Sury <[email-masked]>

Security Area Directors:
    Sean Turner <[email-masked]>
    Tim Polk <[email-masked]>

Security Area Advisor:
    Tim Polk <[email-masked]>

Mailing Lists:
    General Discussion: [email-masked]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/keyassure
    Archive:      
http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html

Objective:
Specify mechanisms and techniques that allow Internet applications to
establish cryptographically secured communications by using information
distributed through the DNS and authenticated using DNSSEC to obtain
public keys which are associated with a service located at a
domain name.

Problem Statement:

Entities on the Internet are usually identified using domain names and
forming a cryptographically secured connection to the entity requires
the entity to authenticate its name. For instance, in HTTPS, a server
responding to a query for <https://www.example.com> is expected to
authenticate as "www.example.com". Security protocols such as TLS and
IPsec accomplish this authentication by allowing an endpoint to prove
ownership of a private key whose corresponding public key is somehow
bound to the name being authenticated. As a pre-requisite for
authentication, then, these protocols require a mechanism for bindings
to be asserted between public keys and domain names.

DNSSEC provides a mechanism for a domain operator to sign DNS
information directly, using keys that are bound to the domain by the
parent domain; relying parties can continue this chain up to any trust
anchor that they accept. In this way, bindings of keys to domains are
asserted not by external entities, but by the entities that operate the
DNS. In addition, this technique inherently limits the scope of any
given entity to the names in zones he controls.

This working group will develop mechanisms for domain operators to
present bindings between names within their control and public keys, in
such a way that these bindings can be integrity-protected (and thus
shown to be authentically from the domain operator) using DNSSEC and
used as a basis for authentication in protocols that use domain names as
identifiers. Possible starting points for these deliverables include
draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and
draft-josefsson-keyassure-tls.

The mechanisms developed by this group will address bindings between
domain names and keys, allowing flexibility for all key-transport
mechanisms supported by the application protocols addressed (e.g., both
self-signed and CA-issued certificates for use in TLS).

The group may also create documents that describe how protocol entities
can discover and validate these bindings in the execution of specific
applications. This work would be done in coordination with the IETF
Working Groups responsible for the protocols.

Milestones:
Dec 2010  First WG draft of standards-track protocol for using DNS to
          associate hosts with keys for TLS and DTLS
Jan 2011  First WG draft of standards-track protocols for using DNS to
          associate hosts with IPsec
Jun 2011  Protocol for using DNS to associate domain names with keys
          for TLS and DTLS to IESG
Aug 2011  Protocols for using DNS to associate domain names with keys
          for IPsec to IESG
Aug 2011  Recharter

---

From: Paul Wouters <[email-masked]>
Date: Tue, 26 Oct 2010 13:16:55 -0400 (EDT)

> Aug 2011  Protocols for using DNS to associate domain names with keys

How is this different from http://tools.ietf.org/html/rfc4322 ?

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 26 Oct 2010 10:33:57 -0700

>How is this different from http://tools.ietf.org/html/rfc4322 ?

- It might not.

- It probably will, because RFC 4322 (I think) assumes that the relying party never wants to see if a key can be validated against the relying party's trust anchor store.

- RFC 4322 underwent very light review because it was describing an already-defined protocol that was in the process of being deployed, and it was not intended for standards track.

- Implementation experience with RFC 4322 (if there is any outside of the community of its original designers) might bring to light different design choices that can be made by the WG.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Tue, 26 Oct 2010 14:55:04 -0400 (EDT)

>> How is this different from http://tools.ietf.org/html/rfc4322 ?

Okay.

> - It probably will, because RFC 4322 (I think) assumes that the relying party never wants to see if a key can be validated against the relying party's trust anchor store.

isn't that local client policy, similar to things like ISAKMP and IPSEC SA lifetime values that are
also not negotiated?

> - RFC 4322 underwent very light review because it was describing an already-defined protocol that was in the process of being deployed, and it was not intended for standards track.

Actually, it was deployed years before. But its deployment never gained traction. One, because we had
no DNSSEC, and two because part of the functionality worked on the reverse zones, which basically no
clients have access to.

> - Implementation experience with RFC 4322 (if there is any outside of the community of its original designers) might bring to light different design choices that can be made by the WG.

Sure. Please keep me in the loop especially about this case, as I have a vested interest in it. If any update to
RFC 4322 will be proposed, I'm more then happy to sheppard it.

Paul

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 Oct 2010 21:46:19 +0200

I believe the KIDNS charter is generally good and I support forming this

> public keys which are associated with a service located at a

I fear this wording will lead to a standards that _requires_ people to
adopt the sloppy security practice to use the same credential for two
(or more) unrelated services.

By only locating services by domain name, the separation between ports
(e.g., 443 or 587) and transport protocols (UDP vs TCP) are lost.

I object to that limitation.  I believe it is important that any
solution in this space supports different certificates for different
ports/protocols on the same host.

My experience with how protocols are deployed is that it is common for
both web (HTTPS) and e-mail (SMTP with STARTTLS) to be hosted on the
same domain name but with different certificates.

For example, the host "lists.debian.org" is reachable with HTTPS (with a
matching certificate) and also through SMTP with STARTTLS (also with a
matching certificate).  The services are using different certificates!

There are other examples, lists.ubuntu.com and even mail.ietf.org, even
if not all appear to support SMTP+STARTTLS.

Thus, I'd like to see the charter clarify that services are located at a
distinct port/protocol/domain-name rather than only at a domain-name.

/Simon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 26 Oct 2010 16:10:34 -0400

There are two sets of work items being proposed for this group.

The first set of work describes mechanisms that allow a domain name owner to
use the DNS to establish the validity of a key.

I think that this mechanism is entirely logical and useful. DNSSEC is
entirely adequate for the purpose of establishing a key as being sufficient
to enable use of encryption.

The second set of proposals relates to security policy. In particular the
TLSFP scheme defines a path validation algorithm that overrides the standard
PKIX processing mechanism in two ways.

First a certificate that has a valid TLSFP validation path is to be
considered valid even if it is a PKIX end entity cert and is invalid under
PKIX path math. This may be acceptable but needs to be carefully considered.

Secondly, there is an assumption in TLSFP that any domain that publishes
CERT records of TLSFP certificate type will publish TLSFP records for ALL
valid SSL certs in use for the domain. So the publication of a TLSFP record
to enable secure communication on the mail server will cause the SSL
certificate on the Web server to be considered invalid.

I find this proposal troubling for severalreasons. First it lacks
orthogonality. It should be able to use the DNSSEC to establish additional
keys without affecting existing trust systems in any way whatsoever. At the
very least this behavior should be optional.

Secondly, I am not at all convinced that enumeration of valid certificates
is a practical method of declaring security policy with respect to TLS trust
anchors. PKIX provides a rich set of semantics for validating certificates.
I dislike any mechanism that requires the administrator to perform
configuration in the DNS for each and every SSL certificate as it is issued.
The only way I can see that approach being practical for a public CA would
be if the CA took over maintenance of the DNS for the zone as well as the
PKI.

Thirdly, the percentage of Internet traffic that is encrypted today is
negligible. I think that we should make encouraging the use of encryption a
higher priority than correcting what some people see as flaws in the trust
provision for existing sites. The security policy that has the highest
leverage is statements of the form 'always use TLS'.

What worries me here is the that the WG should decide to address a single
aspect of security policy, address that aspect from a single point of view
and then optimize for that single scope.

Specification of trust anchors and trust criteria is by far the most complex
and difficult part of security policy in my view. I do not see the logic of
punting on the high leverage aspects of security policy that are fairly well
constrained (always use TLS) and then deciding to address the hardest aspect
of security policy in a fashion that is likely to raise severe scaling
issues.

I think we need to look at security policy separately from the problem of
providing new ways to establish keys.

I think we need to look at the whole problem of security policy together and
not just one aspect of security policy. If we are going to address security
policy in stages we should start from the well defined problem of protocol
security policy and punt on the difficult issue of trust configuration.

On Tue, Oct 26, 2010 at 1:00 PM, IESG Secretary <[email-masked]>wrote:

> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 26 Oct 2010 22:44:23 +0200

I believe it is too early to form a working group for kidns.

The group has not produced a problem statement, nor is one proposed in 
the draft charter. While in most cases you can hide a problem statement 
in the first section or two of an RFC, in this case it is essential that 
the usage scenarios be hashed out before the technical solutions are 
discussed.

With respect, the technical solution from what I've seen doesn't look 
terribly difficult, though we can argue forever about the details. But 
the eventual goal of this work for some of the participants (and one 
which I personally support) is to provide an alternative to PKI. And the 
goal of this work is something that we need to socialize and have 
consensus on. Right now, even at the technical level the draft is 
ambiguous on whether DNS-based validation replaces or not the regular 
PKIX validation, with wording such as "a client MAY choose to trust a 
DNSSEC-secured certificate association".

Lastly, the group includes contributors from the CA industry, which is 
very good. But given that we're putting all our trust in the DNS 
infrastructure and procedures, I would hope to see some domain operators 
in the loop.

To summarize: this is important work; I support a BOF (but not a WG) in 
Beijing and recommend the addition of a problem statement document into 
the charter.

Thanks,
	Yaron

On 10/26/2010 07:00 PM, IESG Secretary wrote:
>      Warren Kumari<[email-masked]>
>      Ondrej Sury<[email-masked]>
>
> Security Area Directors:
>      Sean Turner<[email-masked]>
>      Tim Polk<[email-masked]>
>
> Security Area Advisor:
>      Tim Polk<[email-masked]>
>
> Mailing Lists:
> responding to a query for<https://www.example.com>  is expected to
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Ted Hardie <[email-masked]>
Date: Tue, 26 Oct 2010 11:36:26 -0700

Howdy,

The charter below has the following text:

"The group may also create documents that describe how protocol entities
can discover and validate these bindings in the execution of specific
applications. This work would be done in coordination with the IETF
Working Groups responsible for the protocols."

The "may" in that statement and the ordering involved throw up a tiny
red flag in my head that says "Are we building a technology and then
looking for customers, rather than asking customers what technology
to build"?  (With the parallel that "customers" here are the "protocol entities"
which would discover and use these bindings.)

The answer appears to be "The customers are TLS and IPSEC".  That
seems to me a big enough job for a first go-round. I would personally
suggest re-chartering to include other potential using protocols when
they have been identified, with specific coordination targets at that time
Some protocols developed outside the IETF might also want to use
this method of binding key materials, for example, and the WG coordination
for those might extend beyond IETF WGs.

Just my two cents,

regards,

Ted

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 26 Oct 2010 22:38:14 +0100

Hi folks,
 I entirely disagree with this suggestion to delay protocol work until after
a "full" problem statement/requirements analysis has been done.

It's the IETF, for goodness sakes, and many a proposed group hasn't even
been able to START until it's almost too late for any market due to being
buried under requirements capture and analysis and even building consensus
on terminology [Ahem - Speermint, Drinks, ...]. Also, can we avoid taking
a small and simple idea and burying it under a load of different potential
options before it even gets to be a WG -- [HIP -- sigh].
Let's not do that yet again, please.

The work so far has pretty obvious target uses (TLS, IPSEC), and expanding
this list forever is hardly in keeping with the "small bite" approach that
the IETF is supposed to prefer.

The fact that the work described in the charter is not ALL the work that is
needed to roll out this scheme should be entirely unsurprising. It's surely
not a reason to stop ANY work (apart from deep thought on the problem space).
I trust we don't require a PS-level fully worked system before a WG can begin.

In Maastricht there was quite a bit of support for this work; I do not see
a drop in the effort being applied. It seems to have momentum and people to
work on its charter tasks.
I believe that the WG should begin now, and I would trust that there can be
implementations to test out the initial proposals soon. Running code is good.
This assumes the protocol work is not slugged by being forced to wait for
everything else to be complete first -- it would be a shame if 3GPP (or the
ITU §-) were quicker at delivery that the IETF.

We're wildly agreeing that the potential of DNSSEC as an alternative trust and
validation approach for TLS/IPSEC is interesting, and I for one would like to
be able to add this as part of the toolbox I can apply soon.
Before I retire would be good.

There are bound to be some areas that are local policy -- clients might choose
one policy or another, but at the moment they don't have the choice.
This WG claims to give that choice. One can write documents until one's hand
drops off, but in the end it's up to the market.
IMHO -- give this WG a chance to DEMONSTRATE this scheme, and let's see what
falls.

all the best,
  Lawrence

On 26 Oct 2010, at 21:44, Yaron Sheffer wrote:

> The group has not produced a problem statement, nor is one proposed in the draft charter. While in most cases you can hide a problem statement in the first section or two of an RFC, in this case it is essential that the usage scenarios be hashed out before the technical solutions are discussed.
> 
> With respect, the technical solution from what I've seen doesn't look terribly difficult, though we can argue forever about the details. But the eventual goal of this work for some of the participants (and one which I personally support) is to provide an alternative to PKI. And the goal of this work is something that we need to socialize and have consensus on. Right now, even at the technical level the draft is ambiguous on whether DNS-based validation replaces or not the regular PKIX validation, with wording such as "a client MAY choose to trust a DNSSEC-secured certificate association".
> 
> Lastly, the group includes contributors from the CA industry, which is very good. But given that we're putting all our trust in the DNS infrastructure and procedures, I would hope to see some domain operators in the loop.
> 
> To summarize: this is important work; I support a BOF (but not a WG) in Beijing and recommend the addition of a problem statement document into the charter.
> 
> Thanks,
> 	Yaron
>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 26 Oct 2010 20:06:51 -0400 (EDT)

On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote:

[not sure if such a broad CC: is warranted]

> I think that this mechanism is entirely logical and useful. DNSSEC is entirely adequate for the purpose of establishing
> a key as being sufficient to enable use of encryption. 
> 
> The second set of proposals relates to security policy.

the first is a security policy as well.

> In particular the TLSFP scheme defines a path validation
> algorithm that overrides the standard PKIX processing mechanism in two ways.

Not override, alternative. Depending on client policy. Image systems with no CA's.

> Secondly, there is an assumption in TLSFP that any domain that publishes CERT records of TLSFP certificate type will
> publish TLSFP records for ALL valid SSL certs in use for the domain. So the publication of a TLSFP record to enable
> secure communication on the mail server will cause the SSL certificate on the Web server to be considered invalid.

I don't see that. The browser and its CA policy installation can still ignore TLSFP. In fact, I strongly
suspect they will in at least the near future.

> I find this proposal troubling for severalreasons. First it lacks orthogonality. It should be able to use the DNSSEC to
> establish additional keys without affecting existing trust systems in any way whatsoever.

It does. Its an addon a client can decide to use or not use.

> I dislike
> any mechanism that requires the administrator to perform configuration in the DNS for each and every SSL certificate as
> it is issued.

I dislike needing to delete so many untrusted omnipotent CA's from my
browser. But our personal dislikes are irrelevant to protocol design.

> Thirdly, the percentage of Internet traffic that is encrypted today is negligible. I think that we should make
> encouraging the use of encryption a higher priority than correcting what some people see as flaws in the trust provision
> for existing sites. The security policy that has the highest leverage is statements of the form 'always use TLS'.

The existence of a TLSFP record could mean "always use TLS". The WG is going to discuss whether or not to use
bits for these things in the coming months. I would also like to see more policy options there, such as "only
connect anonymous", or a policy where it is clear if the server does any kind of authentication, or whether it
will allow a BTNS type security policy without client authentication.

> What worries me here is the that the WG should decide to address a single aspect of security policy, address that aspect
> from a single point of view and then optimize for that single scope.

Let's cut the chase here. It's independant of CA's. Yes. It's an alternative. Yes. Your worry has been noted. Again.
You can ensure browser vendors are aware of these limitations in respect to deploying CA's, and recommend
what they implement and support. But there is no reason to try and stop a protocol development that does not
rely on the currently deployed CA infrastructure - an infrastructure some people have lost faith in, with good
reason.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 26 Oct 2010 21:03:23 -0400

Since this is a charter discussion, it goes to the IESG.

My point is not that the IETF should not address Security Policy, it is that
any security mechanism should be completely independent of defining a new
and additional mechanism to sign public keys.

It should be able for a domain to publish public keys in the DNS without
impact on existing deployed SSL certificates and it should be possible for a
domain to publish security policy constraining trusted keys without having
to do so by publishing their keys in the DNS.

If the policy of a site is that every certificate is issued off a local CA
root that is cross certified to a public root, it should suffice to state
that every valid cert is issued of the local CA root.

My reason for wanting this distinction is twofold. First I believe it is a
matter of sound architectural practice to separate the two issued, Secondly
I believe that the IAB and IESG are going to insist on this distinction.

The worst outcome here would be for the WG to be chartered with an ambiguous
remit, spend a year or two working on the issue and then produce a proposal
that is thrown out by the IESG because they insist that the two issues be
kept separate.

The second worse outcome is to be kicked back with a request to define the
problem we are trying to solve. I think that process is going to take longer
than solving the key signing problem. We really do understand the key
signing problem very well.

We have done mechanisms for signing keys before. It is a well constrained
problem. I think that having a mechanism for signing keys on the basis of
DNSSEC is a worthwhile achievement on its own. We should be able to knock
that one off in about six months. Then we can approach the IESG and invoke
the pinball rule under RFC 2418 sec 4: If you win you get to play again.

By that time, I hope that we have some results to show with CAA which
addresses a very limited aspect of security policy that does not affect the
client. Based on the feedback I have had so far from targeted domains and
from CAs, that looks like a win-win.

So at that time I think we can expect to be able to go back to the IESG and
tell them that we want to do security policy and that we are pretty sure
that we understand the issues involved and can produce a nicely abstracted
platform that has strong separation of concerns and reduces the entropy in
the Internet architecture rather than further increasing it..

On Tue, Oct 26, 2010 at 8:06 PM, Paul Wouters <[email-masked]> wrote:

>> entirely adequate for the purpose of establishing
>> CERT records of TLSFP certificate type will
>> publish TLSFP records for ALL valid SSL certs in use for the domain. So
>> the publication of a TLSFP record to enable
>> orthogonality. It should be able to use the DNSSEC to
>> any mechanism that requires the administrator to perform configuration in
>> the DNS for each and every SSL certificate as
>> it is issued.
>>
>
>> negligible. I think that we should make
>> encouraging the use of encryption a higher priority than correcting what
>> some people see as flaws in the trust provision
>> aspect of security policy, address that aspect
> Let's cut the chase here. It's independant of CA's. Yes. It's an
> alternative. Yes. Your worry has been noted. Again.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Oct 2010 10:03:35 +0200

On Tue, Oct 26, 2010 at 10:44:23PM +0200,
 Yaron Sheffer <[email-masked]> wrote 
 a message of 124 lines which said:

> Lastly, the group includes contributors from the CA industry, which
> is very good. But given that we're putting all our trust in the DNS
> infrastructure and procedures, I would hope to see some domain
> operators in the loop.

There are several already, like me or one of the proposed chairs.

> The group has not produced a problem statement, 

It is in the charter. We could add something like:

Currently, the authentication of the domain name is typically done by
the fact that the CA which signed the certificate checked in a way or
the other that the requester was the holder of example.com and that he
was allowed to delegate www.example.com (X.509 method). This
introduces a new party in the authentication process, the CA, while
some people may prefer to keep the process simpler, with only the
server manager and the DNS manager in the loop (they are the people
you need to trust anyway).

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 27 Oct 2010 10:06:48 +0200

On 27.10.2010 03:03, Phillip Hallam-Baker wrote:
> The worst outcome here would be for the WG to be chartered with an
> ambiguous remit, spend a year or two working on the issue and then
> produce a proposal that is thrown out by the IESG because they insist
> that the two issues be kept separate.
 >
> The second worse outcome is to be kicked back with a request to define
> the problem we are trying to solve. I think that process is going to
> take longer than solving the key signing problem. We really do
> understand the key signing problem very well.

I would say that IESG could speak for themselves...  Aftera all, we are 
discussing this on the IESG list.  I think it's futile to discuss what 
other parties may or may not do and not to ask them.

Ondrej
-- 
  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:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 27 Oct 2010 10:25:27 +0200

[Replying to Phillip and Paul simultaneously]

On 27.10.2010 02:06, Paul Wouters wrote:
>> In particular the TLSFP scheme defines a path validation algorithm
>>  that overrides the standard PKIX processing mechanism in two
>> ways.
>

True.

>> Secondly, there is an assumption in TLSFP that any domain that
>> publishes CERT records of TLSFP certificate type will publish TLSFP
>> records for ALL valid SSL certs in use for the domain.

Just a note:  There is no such assumption in the charter.  This is just
one particular I-D.

>> So the publication of a TLSFP record to enable secure
>> communication on the mail server will cause the SSL certificate on
>> the Web server to be considered invalid.
>
> I don't see that. The browser and its CA policy installation can
> still ignore TLSFP. In fact, I strongly suspect they will in at least
> the near future.

And I don't see that as a problem anyway.  The scope of this proposed WG
is to link domain names to certificates.  As stated by Stephane in other
thread in keyassure list, newer protocols generally use (or can use) SRV
record to distinguish between different services.  It will take some
effort on the sysadmin side to make the TLSFP work as intended, but
setting up security was never painless.  And people who will find this
too difficult can still use old CA scheme.  But it will give a people
with a skill the tool to make things more secure than now.

>> I find this proposal troubling for several reasons. First it lacks
>> orthogonality. It should be able to use the DNSSEC to establish
>> additional keys without affecting existing trust systems in any way
>> whatsoever.

I don't understand why it should?  You can decide if you want to use 
DNSSEC or not.  You can decide if you want to use TLSFP or not.  It's up 
to each domain holder if he will use this mechanism or not.

>> Thirdly, the percentage of Internet traffic that is encrypted today
>> is negligible. I think that we should make encouraging the use of
>> encryption a higher priority than correcting what some people see
>> as flaws in the trust provision for existing sites. The security
>> policy that has the highest leverage is statements of the form
>> 'always use TLS'.
>
> The existence of a TLSFP record could mean "always use TLS". The WG
> is going to discuss whether or not to use bits for these things in
> the coming months. I would also like to see more policy options
> there, such as "only connect anonymous", or a policy where it is
> clear if the server does any kind of authentication, or whether it

Yes, I think our proposed charter allows that.

>> What worries me here is the that the WG should decide to address a
>>  single aspect of security policy, address that aspect from a
>> single point of view and then optimize for that single scope.
>
> alternative. Yes. Your worry has been noted. Again. You can ensure
> browser vendors are aware of these limitations in respect to
> deploying CA's, and recommend what they implement and support. But
> there is no reason to try and stop a protocol development that does
> not rely on the currently deployed CA infrastructure - an
> infrastructure some people have lost faith in, with good reason.

My understanding is that this was discussed in the keyassure before and 
the charter was built upon rough consensus.  I don't think it's 
necessary to reiterate through all this again on IESG list.

Ondrej

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 27 Oct 2010 10:47:44 +0200

On 27.10.2010 10:03, Stephane Bortzmeyer wrote:
>   Yaron Sheffer<[email-masked]>  wrote

I could also add that this work was presented on at least two Centr[1] 
meetings and I just asked dns-wg@ripe chairs to present the work on RIPE 
61 in Rome.  But I think it was very well communicated to the TLD 
community through the various interest mailing lists.

1. CENTR is an association of Internet Country Code Top Level Domain 
Registries (www.centr.org)

Ondrej

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 27 Oct 2010 13:07:07 +0200

Hi Stephane,

please see my comments below.

Thanks,
	Yaron

> There are several already, like me or one of the proposed chairs.
I'm glad to hear that. Thanks.

> It is in the charter.

A charter is not an RFC. An RFC undergoes a different process, and is a 
permanent record of IETF consensus (but I don't have to tell you that). 
I think this group is badly in need of a PS document. If the group 
decides to publish one, I would be happy to participate.

> you need to trust anyway).

The parenthetical remark at the end is incorrect: in a perfect world, I 
only have to trust the DNS manager (I assume you mean the operator) for 
*unprotected* communication, which is not our subject here.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 27 Oct 2010 07:41:25 -0400

> the usage scenarios be hashed out before the technical solutions are  

With respect, it seems to me that such a reaction is exactly why
people give up on doing work at the IETF: the bureaucratic hurdles to
completing the job that get thrown up make people go away in
frustration.

We have a community of interested people.  We have a reasonably clear
idea of the initial goal of the work.  We have different and competing
proposals for how to get that work done.  We also have some sceptics
who want to take a completely different approach.  We have people
committed to doing review.  We have a proposed charter with measurable
deliverables.  This sounds to me like a community that has coalesced
around a problem and is ready to do the work.  To me, that means we
already _have_ a working group (i.e. a group of people doing work),
and the question is merely whether the IETF machinery acknowledges it.

I'm not opposed to altering the charter to say, "This work allows
sites to publish keys in the DNS and for clients to use those key
securely without any validation infrastructure apart from DNSSEC," or
something like that.  But I don't believe we need to discuss more
whether there is work to do, whether it can be done in a reasonable
time, or whether there is a community to do that work (all the things
a BOF would determine).  We have ample demonstration, I think.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 27 Oct 2010 07:45:01 -0400

Phillip,

Nothing in this proposal creates security policy.  It creates inputs  
for things that go into security policy.  All that the proposed  
records do is provide another input into the client's *internal*  
process for deciding whether a credential is tied to a particular  
domain.  Clients are free to validate or not validate certificates as  
they choose.  Please stop trying to reinforce the misconception that  
the proposed mechanism overrides PKIX validation in any way.

--Richard

On Oct 26, 2010, at 9:03 PM, Phillip Hallam-Baker wrote:

> My point is not that the IETF should not address Security Policy, it  
> is that any security mechanism should be completely independent of  
> defining a new and additional mechanism to sign public keys.
>
> It should be able for a domain to publish public keys in the DNS  
> without impact on existing deployed SSL certificates and it should  
> be possible for a domain to publish security policy constraining  
> trusted keys without having to do so by publishing their keys in the  
> DNS.
>
> If the policy of a site is that every certificate is issued off a  
> local CA root that is cross certified to a public root, it should  
> suffice to state that every valid cert is issued of the local CA root.
>
>
> My reason for wanting this distinction is twofold. First I believe  
> it is a matter of sound architectural practice to separate the two  
> issued, Secondly I believe that the IAB and IESG are going to insist  
> on this distinction.
>
> produce a proposal that is thrown out by the IESG because they  
> insist that the two issues be kept separate.
>
> The second worse outcome is to be kicked back with a request to  
> define the problem we are trying to solve. I think that process is  
> going to take longer than solving the key signing problem. We really  
> do understand the key signing problem very well.
>
>
> We have done mechanisms for signing keys before. It is a well  
> constrained problem. I think that having a mechanism for signing  
> keys on the basis of DNSSEC is a worthwhile achievement on its own.  
> We should be able to knock that one off in about six months. Then we  
> can approach the IESG and invoke the pinball rule under RFC 2418 sec  
> 4: If you win you get to play again.
>
> By that time, I hope that we have some results to show with CAA  
> which addresses a very limited aspect of security policy that does  
> not affect the client. Based on the feedback I have had so far from  
> targeted domains and from CAs, that looks like a win-win.
>
> So at that time I think we can expect to be able to go back to the  
> IESG and tell them that we want to do security policy and that we  
> are pretty sure that we understand the issues involved and can  
> produce a nicely abstracted platform that has strong separation of  
> concerns and reduces the entropy in the Internet architecture rather  
> than further increasing it..
>
>
>
> I think that this mechanism is entirely logical and useful. DNSSEC  
> is entirely adequate for the purpose of establishing
> publishes CERT records of TLSFP certificate type will
> publish TLSFP records for ALL valid SSL certs in use for the domain.  
> So the publication of a TLSFP record to enable
> secure communication on the mail server will cause the SSL  
> still ignore TLSFP. In fact, I strongly
> any mechanism that requires the administrator to perform  
> is negligible. I think that we should make
> encouraging the use of encryption a higher priority than correcting  
> what some people see as flaws in the trust provision
> for existing sites. The security policy that has the highest  
> is going to discuss whether or not to use
> connect anonymous", or a policy where it is clear if the server does  
> any kind of authentication, or whether it
> single aspect of security policy, address that aspect
> what they implement and support. But there is no reason to try and  
> stop a protocol development that does not
> rely on the currently deployed CA infrastructure - an infrastructure  
> some people have lost faith in, with good
> reason.
>
> Paul
>
>
>
> --

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 27 Oct 2010 14:29:36 +0200

Hi Andrew,

I must be doing something right, if I'm coming out on the side of the 
bad guys :-)

My intention is not to add bureaucratic hurdles. It is to ensure that 
the group has reasonable consensus about its goals. I get worried when I 
see indecision about requirements/goals trickle into the technical spec, 
as I demonstrated in my earlier mail.

If this is really a happy group of like-minded people, it should be easy 
to cut-and-paste the charter, as well as your and Stephane's 
clarifications into a Problem Statement I-D, and get it published soon 
after the working group is formed. It need not block the work on the 
technical solution.

Thanks,
	Yaron

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Oct 2010 08:36:10 -0400

Security policy is generally understood to mean anything that was addressed
in Matt Blaze's PolicyMaker scheme. Thus PKI trust chaining is excluded
because it existed prior to PolicyMaker.

Statements of the form 'always use SSL' or 'only trust these roots' are
considered to be security policy statements.

But whatever they are called, the problem is considered to be very
difficult. In particular the problem of telling relying parties that they
should only trust specific roots or certs for a domain is considered very
difficult.

What is being proposed here is not simply a matter of 'client choice'.

If there are any clients out there that make security policy decisions based
on the existence of TLSFP records then these must be explicit to the domains
publishing the records. Otherwise we end up with a massive interoperability
failure.

I want to be able to publish a TLSFP certificate for my mail server (SMTP
and IMAP) without affecting my Web server.

That is not going to be possible if there is even one client out there that
sees a TLSFP record and decides to reject a perfectly good certificate path
as a result or worse decides that it is not going to connect to my Web
server that does not have TLS and was never intended to.

As for the idea that 'nobody is proposing this'. Paul Wooters just suggested
doing exactly that and the TLSFP code does exactly that.

On Wed, Oct 27, 2010 at 7:45 AM, Richard L. Barnes <[email-masked]> wrote:

> Phillip,
>
> Nothing in this proposal creates security policy.  It creates inputs for
> things that go into security policy.  All that the proposed records do is
> provide another input into the client's *internal* process for deciding
> whether a credential is tied to a particular domain.  Clients are free to
> validate or not validate certificates as they choose.  Please stop trying to
> reinforce the misconception that the proposed mechanism overrides PKIX
> validation in any way.
>
> --Richard
>
>
>
> My point is not that the IETF should not address Security Policy, it is
> that any security mechanism should be completely independent of defining a
> new and additional mechanism to sign public keys.
>
> ambiguous remit, spend a year or two working on the issue and then produce a
> proposal that is thrown out by the IESG because they insist that the two
> issues be kept separate.
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 27 Oct 2010 08:53:44 -0400

> see indecision about requirements/goals trickle into the technical spec,  

Yes, on this we fully agree.

> after the working group is formed. It need not block the work on the  

That sounds like a fine approach to me.  The charter could be amended
to require a problem statement I-D at the beginning.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 27 Oct 2010 15:00:37 +0200

> to require a problem statement I-D at the beginning.

Sounds fine to me.  Any other comments from other interested people?

Ondrej

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 27 Oct 2010 09:22:14 -0400

> Sounds fine to me.  Any other comments from other interested people?

I won't object very strongly to a problem statement I-D, but I don't  
think one is really necessary.

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Oct 2010 09:24:16 -0400

>> Not override, alternative. Depending on client policy. Image systems

Not true at all.

What Paul is saying is that the proposal does not override PKIX semantics
based on CA issuing in a world in which there are no CAs. In the world in
which we currently live TLSFP overrides PKIX semantics. If a TLSFP record
exists then a client that supports TLSFP is required to ignore the PKIX
certificate chain entirely.

> Just a note:  There is no such assumption in the charter.  This is just

Which is precisely the sort of issue that is relevant to a charter
discussion with the IESG.

This is security policy by side effect. I think that is the worst possible
way to go about the security policy problem. I think we can develop a
practical security policy scheme based on direct security policy assertions
'SMTP at example.com always uses TLS'. But doing this through side effects
is looking for trouble.

>> still ignore TLSFP. In fact, I strongly suspect they will in at least
The publishers of a TLSFP record cannot assume that the security policy side
effects are going to be ignored.

Presenting this as a client side choice is nonsense.

I want to be able to publish TLSFP records for my mail server on
example.comwithout affecting the operation of my web server on
example.com in any way whatsoever.

I want to have a means of publishing keys using the DNSSEC that is side
effect free.

> setting up security was never painless.

This is not a responsible approach to security configuration.

The reason I want to have side effect free specifications is that I want to
be able to automate these processes. A specification that makes automated
systems management should be rejected out of hand at this point.

This is what architecture is all about.

There is no necessity for conjoining these two features other than that the
proposers think that they would like to avoid some DNS round trips and are
not prepared to use a completely new DNS RR.

> I don't understand why it should?  You can decide if you want to use DNSSEC
> or not.  You can decide if you want to use TLSFP or not.  It's up to each
> domain holder if he will use this mechanism or not.

Because scripts are stupider than rocks.

Separation of concerns is essential if these processes are going to be
automated.

The number of competent systems managers who can deploy DNSSEC is not very
large. Training is hugely expensive. It is going to take a significant
amount of time to do the job right. I can't see how it is going to be
possible for the typical enterprise to deploy DNSSEC in house and those that
do should probably expect to spend $100K+.

The only way any of this makes sense to me from a cost point of view is if
the process is outsourced and those costs are amortized over a huge number
of instances.

> Yes, I think our proposed charter allows that.

That is precisely the question the IESG needs to decide.

I want to do security policy. I think that DNSSEC only makes sense if it can
be used for security policy. But any security policy mechanism that is done
has to be a first order feature and not implemented by diddling with a few
bits buried in a subfield encoding of a BASE64 encoded blob.

My understanding is that this was discussed in the keyassure before and the
> charter was built upon rough consensus.  I don't think it's necessary to
> reiterate through all this again on IESG list.

As you said in your previous message, shouldn't you let the IESG speak for
itself here?

This type of issue is precisely what the IESG needs to be considering.
Because if they do not discuss it now they are going to DISCUSS the drafts
later and there is a serious risk that we waste several years work.

The current IESG is not necessarily going to be the one that reviews the
specifications. Absent a clear and unambiguous statement from the IESG that
security policy work is in scope of the charter there is a risk that a
future IESG is going to kick back.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 27 Oct 2010 09:33:35 -0400

> What Paul is saying is that the proposal does not override PKIX  
> semantics based on CA issuing in a world in which there are no CAs.  
> In the world in which we currently live TLSFP overrides PKIX  
> semantics. If a TLSFP record exists then a client that supports  
> TLSFP is required to ignore the PKIX certificate chain entirely.

The only instance in which TLSFP "overrides" anything about a PKIX  
cert is the following sentence:
"
If a TLS client fully trusts the association between a domain name and  
the certificate that was provided by the DNS, then that client MUST  
ignore the domain name that is given in the certificate.
"

In fact, the draft goes into some detail about the interaction between  
PKIX validation and the assertions that TLSFP provides.

Unless you can point to text in a document that supports what you're  
saying about that document, quit spreading FUD.

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Oct 2010 09:40:27 -0400

Richard,

Please keep the conversation civil.

I am not spreading FUD, I am basing my statements on extensive discussions
with the proposers.

If they wish to state that they don't want to address security policy then
there is no need for this discussion at all. The charter will simply say
that all the WG does in the first phase is to describe a certificate type
that provides one additional means of validating keys and has no side
effects.

The only reason for a discussion is that some people want to override the
PKIX semantics and use this to edit the set of trusted CA roots for a zone.

On Wed, Oct 27, 2010 at 9:33 AM, Richard L. Barnes <[email-masked]> wrote:

> The only instance in which TLSFP "overrides" anything about a PKIX cert is
> the following sentence:
> "
> If a TLS client fully trusts the association between a domain name and the
> certificate that was provided by the DNS, then that client MUST ignore the
> domain name that is given in the certificate.
> "
>
> In fact, the draft goes into some detail about the interaction between PKIX
> validation and the assertions that TLSFP provides.
>
> Unless you can point to text in a document that supports what you're saying
> about that document, quit spreading FUD.
>
> --Richard
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Oct 2010 12:10:32 -0400

The point at issue here is the following text in Hoffman-03:

   If a match between one of the certificate association(s) and the
   server's end entity certificate in TLS is found, the TLS client
   continues the TLS handshake.  If a match between the certificate
   association(s) and the server's end entity certificate in TLS is not
   found, the TLS client MUST abort the handshake with an
   "access_denied" error.

Now I have discussed this with the authors on several occasions and at least
some of them intend this as a mechanism to guard against what they see as
the risk of unauthorized certificate issue by a CA.

This text is buried in section 3. It comes after a pre-amble that gives no
justification for this behavior and no hint that this is a primary purpose
of the specification.

We can end this discussion now if the proposers are willing to accept:

"If a match between the certificate
   association(s) and the server's end entity certificate in TLS is not
   found, TLS path processing MUST be performed as if no TLSFP record was
published"

At the very minimum, this type of behavior has to be optional.

I am quite happy for the IETF to specify a mechanism to address this
particular use case but it is an aspect of security policy, it is the most
difficult aspect of security policy and I do not want to have it conflated
with a new mechanism for key validation.

At the very least, any mechanism that has this intent should be clearly
and unambiguously specified in the problem statement of the RFC. And there
has to be a very compelling reason given for addressing the two issues
together. Saving a DNS round trip is not a compelling reason in my view.

There is a great tendency for IETF working groups to think about the
difficulty of implementation and efficiency as the most important issues. My
view is that the most important issue is functionality and the next most
important is usability for the system administrator.

We have a whole lot of security infrastructure that remains as shelfware
because the typical administrator is not confident that they understand how
to configure it correctly. Network admins are busy people. Their networks
break for all sorts of reasons that are outside their control. Not deploying
bad ideas is something that is within their control. And if they cannot get
comfortable with an idea quickly their reaction is much more likely to be
that the designer should get a clue rather than that they should get a clue.

If you want them to deploy your stuff you have to be prepared to work with
them and provide a mechanism that they can easily understand and be
comfortable with. They are the gatekeepers.

On Wed, Oct 27, 2010 at 9:40 AM, Phillip Hallam-Baker <[email-masked]>wrote:

> On Wed, Oct 27, 2010 at 9:33 AM, Richard L. Barnes <[email-masked]>wrote:
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 27 Oct 2010 12:16:34 -0400

> The point at issue here is the following text in Hoffman-03:

You seem to be taking issue with particular proposals that the
proposed WG might work on _rather than_ the setting up of the WG in
order to work on these proposals.  Doesn't that seem to you to be
_prima facie_ evidence that the WG in fact has work to do, and can
therefore be chartered to work on it?  (Yes, I know what you were
responding to.  I'm trying to bring the conversation back on the track
of what we were supposed to be talking about.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Oct 2010 09:34:39 -0700

>to require a problem statement I-D at the beginning.

Another option is to include this in the first deliverable protocol document. That saves both the WG and the IESG process time for something that started as a copy-and-paste.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Oct 2010 12:41:28 -0400

I was responding to an unfair and untrue attack that asserted that I was
spreading FUD.

I was not spreading FUD, as you admit, my statement was fully justified by
the proposal in question. I therefore believe that Richard should apologize
for the implication that I was misrepresenting anyone's position.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Oct 2010 09:46:04 -0700

At 8:36 AM -0400 10/27/10, Phillip Hallam-Baker wrote:
>Security policy is generally understood to mean anything that was addressed in Matt Blaze's PolicyMaker scheme.

FWIW, this is the first time I have heard such a definition, and thus suspect that it is not "generally understood". For example, it was never mentioned once on the mailing list for the IETF's (long-concluded) ipsec-policy WG.

>Thus PKI trust chaining is excluded because it existed prior to PolicyMaker.
>
>Statements of the form 'always use SSL' or 'only trust these roots' are considered to be security policy statements.

The concepts of "always use SSL" and "only trust these roots" also existed prior to the publication of their (not his) paper in 1996.

If the IESG wants the KIDNS WG to deal with defining "policy", it should let us know sooner rather than later.

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 27 Oct 2010 10:51:19 -0600

On 10/27/10 10:46 AM, Paul Hoffman wrote:

> If the IESG wants the KIDNS WG to deal with defining "policy", it
> should let us know sooner rather than later.

If anything, this IESG member at least will request that the KIDNS WG
rule out any work on defining "policy", which IMHO will lead to a
rodent-hole of unusual size and perhaps even a fire swamp or two.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Oct 2010 12:57:02 -0400

On Wed, Oct 27, 2010 at 12:34 PM, Paul Hoffman <[email-masked]>wrote:

> Another option is to include this in the first deliverable protocol
> document. That saves both the WG and the IESG process time for something
> that started as a copy-and-paste.

That risks a very long and drawn out conversation between those of us who
are convinced that security policy can be solved very easily and those of us
who think it is difficult but tractable. And that conversation does nothing
to get us any further with the IESG where the problem has been considered a
very hard one for over a decade.

I suggest that we instead follow the precedent of DKIM which was required to
deliver the key publication and message signature draft before working on
policy proposals. I seem to recall that DKIM was however allowed to work on
the problem statement for the policy record at the same time as the key
publication and message format work.

Under this scheme the WG would have two phases, the initial phase being to
produce a key publication mechanism and a problem statement for policy, the
second phase being to work on the policy mechanism itself.

This approach would not in any way delay deployment of DNSSEC published keys
or prevent the group deciding to use a CERT certificate type as the only
means of publishing certificate policy. The only long term consequence would
be that we would end up with four new certificate types instead of just two
and that people who do not want security policy with their key assurance
would be assured of getting it.

The second stage need not be gated on publication as an RFC. It could be
sufficient to have the Security AD's permission to forward the proposal to
the IESG.

The key signing/publication problem is something that I think we can
honestly say is understood really, really well. The number of degrees of
freedom in the problem is really very small and so the only thing left to do
is to write out the path processing semantics and a clear set of security
requirements.

The only real room for argument in the specification is on tagging and
bagging issues. And none of that should affect the semantics.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 27 Oct 2010 12:57:46 -0400

> I was responding to an unfair and untrue attack that asserted that I was

I don't care about that issue.  It's irrelevant to this discussion, I
think, which is supposed to be about whether it's right to form a WG
now.  Since you seem to be responding to substantive issues in
possible WG work, that is evidence that there's work to be done and
even a community to do it.  Right?

> I was not spreading FUD, as you admit

No, I didn't.  I merely observed that I thought I understood why you
seemed to want to explore the details of of a particular proposal, and
I was trying to say that I didn't think it mattered _why_, because
that you were doing it was useful information.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 27 Oct 2010 13:01:33 -0400

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Wednesday, October 27, 2010 12:11 PM
To: Richard L. Barnes
Cc: [email-masked]; [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

Now I have discussed this with the authors on several occasions and at least some of them intend this as a mechanism to guard against what they see as the risk of unauthorized certificate issue by a CA.

This text is buried in section 3. It comes after a pre-amble that gives no justification for this behavior and no hint that this is a primary purpose of the specification.

"If a match between the certificate
   association(s) and the server's end entity certificate in TLS is not
   found, TLS path processing MUST be performed as if no TLSFP record was published"

[CW] Assuming your aim is not to render mismatches meaningless, there are words similar enough to yours in the paragraph before the one you referenced to handle the case where no match is found.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Oct 2010 13:39:31 -0400

This is a charter discussion.

The question of Security Policy is a scope issue for the charter.

Thus the fact that we have proposals that attempt to address that scope is
entirely relevant to this discussion.

I do not understand why you would think otherwise.

The objective of this exercise is for both sides to clearly understand what
is being to agreed to. The worst case outcome would be for the IESG to
approve the WG charter and then reject the WG document proposals as out of
scope because they thought that they were agreeing to something else.

I am finding the rules of engagement here to be rather peculiar. It seems
that it is unacceptable for me to suggest that what is being proposed is
what the documents and the authors say that they are proposing while it is
fine for Richard to make insulting accusations.

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Wed, 27 Oct 2010 11:51:50 -0600

> Thus the fact that we have proposals that attempt to address that scope is entirely relevant to this discussion.

> The objective of this exercise is for both sides to clearly understand what is being to agreed to. The worst case outcome 
> would be for the IESG to approve the WG charter and then reject the WG document proposals as out of scope because 
> they thought that they were agreeing to something else.

OK.  If we store keys in DNS, we aren't doing it as just an FYI.  We're storing them there with the expectation that some bit of "client" software pay attention to them, and consequently make a "policy" decision on what the presence of those keys mean.  I'm fine with calling that a "security policy".  And I'm fine with including it here.

Are we all settled on whether PKIX validation should happen and keys in DNS get us exclusion, or whether keys in dns automatically preclude PKIX validation?  No.  In any case proposing a new way to pass around key information is going to involve some policy choices unless all we define is a way to pass that data, and say absolutely nothing about how a client can tell whether that data is valid.  And frankly, since we are saying that the DNS responses should be using DNSSEC, we *already* are making security policy decisions here. 

Oh, and I'm with Phillip on being civil.  :)

- Andy

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 Oct 2010 14:47:22 -0400 (EDT)

>    found, TLS path processing MUST be performed as if no TLSFP record was published"

I'd rather not see this. If a host is compromised, an attacker can change
the cert, get it signed by a rogue/sloppy CA, and get it to ignore the
entire DNSSEC trust chain. In other words, DNSSEC trust is sacrificed
for another trust hierarchy (The CA one).

I think it makes more sense to say if a DNSSEC protected record is wrong,
then treat it as a problem, don't ignore it, provided your client policy
is to use TLSFP/DNSSEC.

Similarly, I don't expect a client with a CA policy to accept an
invalid/expired CERT based on the fact that the TLSFP record happens
to match.

It is very important we do not start mixing CA and DNSSEC based trust
models, or we end up with the worst of both worlds.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Oct 2010 17:07:19 -0400

I think that this represents a superficial analysis of the problem. If we
were going to act on this set of concerns we have to start from a far more
precise definition of the problem and a considerably more thorough analysis
of the security considerations.

It is reasonably easy to identify issues with the CA SSL system because it
has been deployed 15 years and we have a lot of experience. At the moment,
DNSSEC is an unknown. And what is worse it is really difficult to have a
public debate about the precise level of security DNSSEC achieves because
there are lots of people involved in deployment of DNSSEC who fear that any
open discussion of the limitations might be used to provide a pretext for
further delay.

This is a rather strange definition of 'separating' DNSSEC key assurance
from PKIX. What is being proposed here is that the DNSSEC which is not yet
deployed is to be promoted above PKIX which we have been working on and with
for twenty plus years.

I am not suggesting that we do not support this type of semantics, merely
that these be kept separated from any new mechanism for signing keys.

The ESRV proposal I have a draft out on is a proposal for an extensible
security policy framework. I think that if there is to be any work on
security policy we have to address the pieces that are easiest to define and
provide the greatest benefit first.

Some parts of the security policy swamp are considered to be inevitable rat
holes. Specification of which trust anchor is allowed to be used for which
purpose is considered the swampiest. So I am not proposing to charge into
that part of the swamp first.

If we have a mechanism that allows a domain to state 'SSL is always offered'
and a mechanism that allows sites to generate domain validated keys at no
additional out of pocket cost beyond that of deploying DNSSEC we are then in
a position to be able to make cryptography the default and retire the
padlock icon and DV certificates completely. The swamp is drained.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 Oct 2010 20:12:56 -0400 (EDT)

On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote:

> I think that this represents a superficial analysis of the problem.

No Philip, you keep trying to drag in the cat's meow. I've already ignored
some claims you made about what I said. We understand you value PKIX. So
we do. We value DNSSEC. So should you.

> This is a rather strange definition of 'separating' DNSSEC key assurance from PKIX. What is being proposed here is that the DNSSEC which
> is not yet deployed is to be promoted above PKIX which we have been working on and with for twenty plus years.

It's your fear this is "above PKIX". If your PKIX system works well
enough, and is better then DNSSEC, why do you have this fear? You are
the one who keeps trying to mix DNSSEC and PKIX. I've made statements
I favour to keep these two separate, so they do not HAVE to interfere
with one another. I never said "above". I said "separate" and "according
to client policy". I'm bending over backwards to not interfere with
any current PKIX deployment, and requested the same in return (eg I'm
opposed to a CAA record).

I would be interestd in what others who have not expressed themselves
have to say on these matters, but I believe my views (and yours) on this
topic have been stated clearly. Unless the IESG asks me for more input,
I'll refrain from further adding to this discussion.

Paul

---

From: David Conrad <[email-masked]>
Date: Wed, 27 Oct 2010 14:39:54 -1000

On Oct 27, 2010, at 2:12 PM, Paul Wouters wrote:
> topic have been stated clearly.

To be blunt, I feel keyassure/kidns is being subject to a DoS attack and gave up reading all messages (and most of my hope about timely forward progress on this topic within the IETF) some time ago.

Regards,
-drc

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Oct 2010 21:03:23 -0400

> we do. We value DNSSEC. So should you.

Which is precisely why I have spent the last year developing a security
policy scheme that is based on DNSSEC.

>> from PKIX. What is being proposed here is that the DNSSEC which
>> is not yet deployed is to be promoted above PKIX which we have been
>> working on and with for twenty plus years.
>>
>

You are putting words into my mouth here.

The effect of this proposal is that if it is accepted there will be PKIX
certificates that a client would currently consider valid that will now be
considered invalid. That is not keeping the systems separate as you claim,
it is the opposite. If I define a PGP key it does not invalidate my S/MIME
cert. If I acquire an S/MIME cert it does not invalidate my PGP key.

All I am saying here is that a given mechanism must either validate keys or
it should invalidate keys. Here we have a mechanism where the act of
validating one key automatically invalidates all others bound to the same
name for those clients that observe the MUST requirements of the spec.

I don't think that is necessary, I don't think that is useful. And I
definitely think that we need to have a justification for joining the two
together.

I am pretty sure that there is history here with respect to security policy
and that some section of the community has been burned really badly with an
attempt to do security policy. But nobody seems able to tell me what it is.

> I'll refrain from further adding to this discussion.

So you ask a bunch of slanted questions and then retire from the field with
the implication that I should not answer them?

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 28 Oct 2010 10:05:15 +0200

To be blunt, I feel keyassure/kidns is being subject to a DoS
    attack and gave up reading all messages (and most of my hope
    about timely forward progress on this topic within the IETF)
    some time ago.
    
You are not the ony one. I did he same.

	jaap

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 28 Oct 2010 10:06:00 +0100

On 28 Oct 2010, at 09:05, Jaap Akkerhuis wrote in response to DRC's:
> You are not the only one. I did the same.
> 
> 	jaap

To which I quip:
 I note you don't say a DDoS attack.
It is a pity, as the draft(s) do need IETF review -- they are
still rough in places. That won't be easy in the current noise.
... we're civil to those who cavil.

atb,  Lawrence

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 28 Oct 2010 12:01:21 -0400

I keep asking questions because I never get answers.

I keep asking why you want to conflate a mechanism that enables new means of
establishing a key as valid with a new means of declaring PKIX certificates
to be invalid.

Those are two entirely separate issues in my view and it is not appropriate
to reuse the DNS CERT record to do both.

Each time I ask the question why this has to be a requirement I get
non-response responses and so I keep asking the question and I am going to
keep on asking until I get a substantive response.

The first priority in any IETF working group has to be to do no harm. There
is no reason that using DNSSEC to authenticate keys for my SMTP service
should require me to change the way I manage my Web service. If my objective
was to sabotage the effort as you keep accusing me of, I would do everything
I could to make sure this feature stayed in the draft because it is a poison
pill that is going to totally kill adoption.

I keep asking for a justification and I never get one. Instead I get
non-response responses, to wit:

* Various restatements of the requirements that do not address the question
of why it is necessary to effectively force sites who deploy DNSSEC
authenticated keys to stop all use of CA issued certs.

* This is the wrong time to ask the question.

* It is now too late to ask the question because the group has decided.

* Personal attacks.

* Denials that this is part of the proposal.

* Denials that specifying criteria for evaluating trust chains is part of
security policy

* Claims to the effect that the difficult problems of PKI magically
disappear when the bits are expressed in DNSSEC syntax

* Suggestions to the effect that nobody should discuss this with the IESG
because it has been discussed on the mailing list.

* Suggestions to the effect that this should not be discussed on the mailing
list as it should be decided by the IESG.

It is very simple, if you want to shorten the discussion then stick to the
topic and answer the question.

On Wed, Oct 27, 2010 at 8:39 PM, David Conrad <[email-masked]> wrote:

> To be blunt, I feel keyassure/kidns is being subject to a DoS attack and
> gave up reading all messages (and most of my hope about timely forward
> progress on this topic within the IETF) some time ago.
>
> Regards,
> -drc
>

---

From: Warren Kumari <[email-masked]>
Date: Thu, 28 Oct 2010 12:01:27 -0400

>> You are not the only one. I did the same.

Please come back, we need you all....

> I note you don't say a DDoS attack.

Ok, this is not the first time that I have heard rumblings like this  
-- I have also heard this in person from folk, and it seems to be  
leading to fragmentation of the group, and valuable contributors  
throwing in the towel and not participating. I urge these folk to come  
back, and, if necessary, simply kill-file the source of the DoS or, if  
you feel that that is not enough to allow you to happily participate,  
explicitly ask (on list) for moderation of the source the attack.

I am also asking the list participants to please try and stay on topic  
and not attempt to drag the conversation into areas that are outside  
the interest of the rest of the (proposed) WG. If you are the lone  
voice in the wilderness (or if there is only one other person  
interested), please strongly consider doing your document as an  
individual submission that is mentioned *but not discussed* in the WG.  
The IETF is a consensus driven organization -- one person does not  
consensus make....

The purpose of this list is to make forward progress, come to  
consensus on what the group wants and then get something done.

> still rough in places.

Yes, yes they do... The *group* (and the IETF) will contribute to the  
final documents, and they will incorporate group consensus - I realize  
that there is noise at the moment (for which I apologize), but ask for  
people to *please* try and ignore the noise (and attempts to draw us  
down ratholes) and continue to participate / please come back if they  
have gotten fed up...

> That won't be easy in the current noise.

Yup, and we do our best to tolerate those who are not, even if it it  
trying...

W

--
I once absend-mindedly ordered Three Mile Island dressing in a  
restaurant and, with great presence of mind, they brought Thousand  
Island Dressing and a bottle of chili sauce.
     -- Terry Pratchett

---

From: John Gilmore <[email-masked]>
Date: Thu, 28 Oct 2010 17:04:44 -0700

> >>   about timely forward progress on this topic within the IETF)

I have nothing nice to say on the topic, so I will say nothing.

	John

---

From: Ben Laurie <[email-masked]>
Date: Fri, 29 Oct 2010 13:33:47 +0100

> I'll refrain from further adding to this discussion.

I am with David Conrad on the DoS attack: I don't understand what
useful this seemingly endless discussion is actually _about_.

Paul wants client policy to decide whether to trust PKIX, DNSSEC or
some mixture of the two. This seems not only reasonable, but
unavoidable: clients will implement what suits them, and we are in no
position to change that.

Phillip wants the domain in question to be able to state its
intentions w.r.t. the policy clients should use. This seems not
unreasonable, also. Clients can choose to follow this or not.

He also wants to separate protocols so policy can apply to
domain+protocol, not merely domain. This seems like an obvious
requirement to me.

None of these seem to me to be incompatible with each other. So, what
is being discussed?

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 29 Oct 2010 09:34:22 -0400

> None of these seem to me to be incompatible with each other. So, what

You've said this much more clearly than I've managed to do so far.  I
completely agree.

As an aside, I will note that there has been a similar tension in the
DNSSEC community around trust anchors.  Some operators feel that the
only things that others may use for trust operations on their zones
are the ones that they are publishing _right now_, and anything else
is dangerous.  Others want to be able to build a history of trust
anchors so that it is possible to reconstruct this history and
"replay" RFC5011 events after some of the affected keys have been
withdrawn.

In both the dispute about what to do here and in the DNSSEC
trust-history case, we have what amounts to a disagreement about who
gets to decide the trust properties: whether the domain operator (or
site operator or whatever) gets to determine what things are valid, or
whether a client can make choices for itself using the trade-offs it
likes.

My own view is that the latter is always possible on the Internet, and
therefore I would like to have well-documented ways in which such
trade-offs can be made intelligently, so that users have a predictable
mechanism.  I fully understand the argument from the other point of
view, however, but I think it is unrealistic to imagine that, if we
don't provide some mechanism for clients to make up their own minds,
that they won't start doing all kinds of strange and wonderful things
on their own.

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 29 Oct 2010 09:42:57 -0400

+1

In addition to wanting to separate policy from key authentication for
architectural reasons, I want to at least have the option of expressing the
trust policy in terms of X.509 infrastructure.

One reason for this approach is that we have a lot of infrastructure for
managing X.509 certs already, both commercial and open source. For the
enterprise that is looking to manage large numbers of keys it is going to be
much easier for them to add rules to the DNS that state that all their certs
are issued under an X.509 root than to deploy a new system that interacts
with the DNS on every cert issue.

A second reason is that the X.509 approach has 20 years of history and there
is a lot of prior art we can point to.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 29 Oct 2010 10:12:26 -0400

+1

These are certainly issues, but they are fixable issues.

One way we can fix them is to build up the same set of capabilities in
DNSSEC as has existed in X.509 from the start. X.509 is expressly intended
to provide non repudiable, archival keys. A DS record is not.

A better way is to lightly graft on parts of the X.509 structure that
provide useful enhancements onto DNSSEC.

PKI is the interface between the real world and the online world. As a
result a lot of the reasons something is necessary get into the type of
issue that most engineers simply do not want to think about.

I can address Andrew's issue fairly cleanly by publishing an X.509v3
certificate for the KSK at the apex of each zone. But giving the full
explanation of the reasons why you would want to do it that way is going to
involve a lot of business related issues that a lot of people don't have
patience for.

That is not how I would address those issues if I was building completely
from scratch. Given an unrestricted choice I would probably use something
with angle brackets like SAML assertions. That is one of the use cases I was
originally commissioned to design the assertion infrastructure SAML is based
on for.