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

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 26 Oct 2010 15:30:55 -0500 (GMT-05:00)

Phillip and all,

I fully agree with this approach.

-----Original Message-----
From: Phillip Hallam-Baker
Sent: Oct 26, 2010 3:10 PM
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

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:

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
_______________________________________________
keyassure mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyassure

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

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 26 Oct 2010 16:49:55 -0500 (GMT-05:00)

laurence and all,

  I share lawrences frustration here and believe that the
sooner we get started the better.  Time waits of no man/woman.

-----Original Message-----
>From: Lawrence Conroy <[email-masked]>
>Sent: Oct 26, 2010 4:38 PM
>To: Yaron Sheffer <[email-masked]>
>Cc: [email-masked], [email-masked]
>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:
>
>> 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

Regards,
Jeffrey A. Williams

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 26 Oct 2010 16:56:23 -0500 (GMT-05:00)

Ted and all,

-----Original Message-----
>From: Ted Hardie <[email-masked]>
>Sent: Oct 26, 2010 1:36 PM
>To: [email-masked]
>Cc: [email-masked], [email-masked]
>Howdy,
>The charter below has the following text:
>
>"The group may also create documents that describe how protocol entities
>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.

  I think you need to add DNSSEC to the customers list as well as 
browser vendors/developers, IxP's and DNS providers. Just my .2 cents...
>
>Just my two cents,
>
>regards,
>
>Ted
>
>
>
>On Tue, Oct 26, 2010 at 10:00 AM, IESG Secretary
><[email-masked]> wrote:

Regards,
Jeffrey A. Williams

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 27 Oct 2010 11:40:45 -0500 (GMT-05:00)

Stephane and all,

-----Original Message-----
>From: Stephane Bortzmeyer <[email-masked]>
>Sent: Oct 27, 2010 3:03 AM
>Cc: [email-masked]
>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).

  I think you articulate here rather indirectly but adequately that
the trust model being expanded to include at least the CA, but curiously
leave out the Trust Anchors, of which some are the very same as the CA in
this model which extends the hierarchal trust model proposed last week in
D.C. which although i did not attend have now heard from several that did,
that trust model is under some pressure as to be a workable one.  

  Yes the server manager and DNS manager/provider are people that need to
be able to be trusted, but not need to be trusted, which is how we got
where we are here.
Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 27 Oct 2010 12:02:04 -0500 (GMT-05:00)

Paul and all,

-----Original Message-----
>From: Paul Hoffman <[email-masked]>
>Sent: Oct 27, 2010 11:46 AM
>To: [email-masked], [email-masked]
>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.

  Like it or not, admit it openly or not, the IESG and the IETF have to one degree
or another, been about defining policy in one form or another.  You know this.

  We have found or finnaly <publically> disclosed that for instance, 'only trust these roots' was not always a good thing to do.  But also many of us from even 
before 1996 knew that but were not ever going to say so.  But now we are at another
point that is similar.  "Only trust these CA's and Trust Anchors", when some
of us know that some of the 'Trusted CA's' and 'Trust Anchors' are both one
in the same, AND have had some security problems of their own due to complacency
or other reasons.  Are we not perhaps making the same mistake?  Just my 2 cents...

Regards,
Jeffrey A. Williams

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 27 Oct 2010 14:51:14 -0500 (GMT-05:00)

Phillip and all,

-----Original Message-----
From: Phillip Hallam-Baker
Sent: Oct 27, 2010 12:39 PM
To: Andrew Sullivan
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

This is a charter discussion.

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

Agreed.

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

Logically correct, so agreed.

I do not understand why you would think otherwise.

I do I think.  There seems to be a reluctance to recognize or accept that for some WG security issues are

intertwined with policy decisions and vise versa.

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.

Maybe not the worst outcome, but certainly not a good one IMO.

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.

FWIW, seems that there is some Fear, uncertainty, and doubt , < FUD > as there is with almost any security

related protocol consideration.  That FUD, which is not one of an insulting nature, but one borne of the very

nature of what any WG on such considerations may have in respect to policy and politics < yuk > that are

unfortunately intertwined accordingly.  Of course the rodent-holes and fire pits that all too often unfortunately

come along with same, sometimes get deep/wide/politically-vemin infested/hot accordingly and leaving

uncertainty in the wake.   So I wonder if this sort of FUD was not the FUD Richard was referring to? I'll

assume it was for now or until Richard confers otherwise.

On Wed, Oct 27, 2010 at 12:57 PM, Andrew Sullivan <[email-masked]> wrote:

On Wed, Oct 27, 2010 at 12:41:28PM -0400, Phillip Hallam-Baker wrote:
> I was responding to an unfair and untrue attack that asserted that I was
> spreading FUD.

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.

Regards,
Jeffrey A. Williams

---

From: =JeffH <[email-masked]>
Date: Wed, 27 Oct 2010 15:43:35 -0700

I support a working group being formed.

some specific comments on the proposed chater (best in a fixed-pitch font)...

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

The above paragraph doesn't parse well for me. How about something like..

Specify mechanisms and techniques that facilitate Internet applications to 
establish cryptographically secured communications by leveraging 
DNSSEC-authenticated DNS information; for example public keys associated with a 
service at a domain name.

 > to be asserted between public keys and domain names.

this isn't a "problem statement" -- it just states the status-quo scenario.

building on what Stephane proposed, add a new para here, such as..

Currently, binding of domain names to public keys is typically accomplished 
using public-key certificates issued and signed by Certificate Authorities 
(CAs) [PKIX]. Authentication of a certificate-presenting party by a relying 
party involves checking the certificate's signature and iterating up the 
"certificate chain" until a "trust anchor" is reached, for which the relying 
party has a public-key certificate copy, typically obtained in an out-of-band 
fashion. Relying parties often have a trust anchor certificate store containing 
certificates for many various trust anchors. Typically, the authentication 
process succeeds if examination of a trust anchor's certificate chain 
successfully terminates with a locally-cached trust anchor's certificate. This 
introduces a new ("third") party in a given authentication process. 
Additionally, the relying party is trusting any and all of the various 
"third-party" trust anchors to not accidentally or maliciously issue 
"unauthorized" certificates purporting to be associated with any particular 
target domain.

Objectives and Scope

 > parent domain; relying parties can continue this chain up to any trust
                                      ^^^^^^^^
                                       verify

 > given entity to the names in zones he controls.
                   ^^^                ^^^^^^^^^^^^
                   del            it and/or its delegates control.

 > shown to be authentically from the domain operator) using DNSSEC and
                                                                       ^
                                                                     then

 > self-signed and CA-issued certificates for use in TLS).

probably need to re-word above to be explict that TLS is only presently 
in-scope "client" protocol.

perhaps need an explicit "out of scope" section.

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

HTH,

=JeffH

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 29 Oct 2010 10:59:23 -0500 (GMT-05:00)

Phillip and all,

-----Original Message-----
From: Phillip Hallam-Baker
Sent: Oct 29, 2010 9:12 AM
To: Andrew Sullivan
Cc: [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

+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.

agreed here.

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

not only useful, but perhaps advisable or even necessary.  X.509 IMO has long needed more indepth

review.

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.

Amen!  However seems that we are going to have to at some limited level or to some limited degree get

more involved in the issues regarding this.

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.

Agreed.

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.

On Fri, Oct 29, 2010 at 9:34 AM, Andrew Sullivan <[email-masked]> wrote:

On Fri, Oct 29, 2010 at 01:33:47PM +0100, Ben Laurie wrote:
> None of these seem to me to be incompatible with each other. So, what
> is being discussed?

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

keyassure mailing list
[email-masked]

Regards,
Jeffrey A. Williams

Network Eng. SR. Eng. Network data security

ABA member in good standing member ID 01257402

E-Mail [email-masked]
Phone: 214-244-4827