Subject: [keyassure] Updated draft charter

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Sep 2010 16:03:02 +0200

Hi,

me and Warren had an conf call with ADs and it was suggested we add 
something about different models we have and that we don't want to limit 
either of those neither in the charter nor in the working group.

So we have added following wording to the draft charter:

-- cut here --
The selection of trust anchors and security policies is also in the 
scope of this working group, for example, chaining public keys to 
existing trust anchors or allowing domain owners to publish and 
reference their own trust anchors.
-- cut here --

Feel free to put some constructive criticism to improve the wording, so 
we can have the best charter ever. :-)

Ondrej

Full charter can be found at:
http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure

And currently looks like this:

Objective:
Specify mechanisms and techniques that allow Internet applications to 
establish cryptographically secured communications by using information 
distributed through the DNS for discovering and authenticating 
cryptographic material which is associated with a service located at a 
domain name.

Problem Statement:
Entities on the Internet are usually identified by 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 selection of trust anchors and security policies is also in the 
scope of this working group, for example, chaining public keys to 
existing trust anchors or allowing domain owners to publish and 
reference their own trust anchors.

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:
Nov 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 non-TLS security protocols
Jun 2011   Protocol for using DNS to associate hosts with keys for TLS 
and DTLS to IESG
Aug 2011   Protocols for using DNS to associate hosts with non-TLS 
security protocols to IESG
Aug 2011   Recharter

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: Stephen Farrell <[email-masked]>
Date: Fri, 24 Sep 2010 15:17:56 +0100

So does that mean none of the comments I posted yesterday were
accepted or you've not gotten around to them yet?

S.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 24 Sep 2010 10:20:14 -0400

Looking at the draft text, I get the feeling that "trust anchor" is  
kind of an ill-suited phrase.  Referring to RFC 4949:
"
$ trust anchor (I) /PKI/ An established point of trust (usually based  
on the authority of some person, office, or organization) from which a  
certificate user begins the validation of a certification path.
"
So a trust anchor is something that a "certificate user" or relying  
party has; the phrase "domain owner's trust anchor" seems either  
nonsensical or irrelevant.

Could you clarify what the goal of this text is?  What are the use  
cases you're trying to enable; i.e., what would the domain owner be  
telling the RP?

--Richard

On Sep 24, 2010, at 10:03 AM, Ondřej Surý wrote:

> something about different models we have and that we don't want to  
> limit either of those neither in the charter nor in the working group.
>
> Feel free to put some constructive criticism to improve the wording,  
> so we can have the best charter ever. :-)
>
> Ondrej
>
> Specify mechanisms and techniques that allow Internet applications  
> to establish cryptographically secured communications by using  
> information distributed through the DNS for discovering and  
> authenticating cryptographic material which is associated with a  
> service located at a domain name.
>
> Problem Statement:
> 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.
>
> 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.
>
> 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 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:
> Nov 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 non-TLS security protocols
> Jun 2011   Protocol for using DNS to associate hosts with keys for  
> TLS and DTLS to IESG
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Sep 2010 16:22:36 +0200

> accepted or you've not gotten around to them yet?

Second option.  But I am going on the vacation next week, so I may have 
catch up on the mailing list traffic :-).

>> responding to a query for<  https://www.example.com>  is expected to

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Sep 2010 16:24:32 +0200

We were trying to say, that we won't be chosing neither only self-signed 
nor only CA-signed (+ DNSSEC assured) in the charter.

Ondrej

On 24.9.2010 16:20, Richard L. Barnes wrote:
> Looking at the draft text, I get the feeling that "trust anchor" is kind
> of an ill-suited phrase. Referring to RFC 4949:
> "
> $ trust anchor (I) /PKI/ An established point of trust (usually based on
> the authority of some person, office, or organization) from which a
> Could you clarify what the goal of this text is? What are the use cases
> you're trying to enable; i.e., what would the domain owner be telling
> the RP?
>
> --Richard
>
>
>
>
>> establish cryptographically secured communications by using
>> 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.
>>
>> in such a way that these bindings can be integrity-protected (and thus
>> 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.
>>
>> 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:

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 24 Sep 2010 10:34:28 -0400

Then how about something like the following:
"
The mechanisms developed by this group will allow domain owners to  
attest to both self-signed and CA-signed certificates.
"

I get the sense that there is also some desire in the group to express  
constraints on things other than keys (e.g., only EV), in which case:
"
These mechanisms may also allow domain owners to express other  
constraints on certificates, as a recommendation to relying parties.   
For example, a domain owner may indicate that servers authenticating  
as the domain should only present self-signed certificates or only  
only certificates under a given CA.
"

I think that's a little clearer.  Does that align with your  
expectations?

--Richard

On Sep 24, 2010, at 10:24 AM, Ondřej Surý wrote:

> We were trying to say, that we won't be chosing neither only self- 
> signed nor only CA-signed (+ DNSSEC assured) in the charter.
>
> Ondrej
>
>> kind
>> cases
>>> to
>>> requires
>>> trust
>>> thus
>>> of
>>> to

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Sep 2010 10:42:07 -0400

That looks good to me, but I would like you to

1) Add the ESRV draft to the list of possible starting points:

draft-hallambaker-esrv

The primary purpose of ESRV is to express security policy. I started with
'must use SSL' because that is difficult for people to argue against as a
requirement. The plan was always to add in the ability to express other
policy information such as trust criteria.

2) Reword the amendment as follows:

The working group will also consider and may propose mechanism(s) to express
security policy information. For example restricting or requiring the use of
specific security protocols and/or authorizing or requiring the use of
specific cryptographic credentials.

I believe that the intent is the same here.

Trust Anchor selection is really a form of security policy. So the statement
on security policy should come first. What is being proposed is not limited
to trust anchor selection. The TLSFP mechanism is actually an enumeration of
the valid end point certificates which is a different approach.

While I do not want (and will not accept) enumeration of allowable
end-entity certificates as being a mandatory side effect of CERT record
processing, I am much less unhappy if the policy statement is explicit (e.g.
separate certificate type) and I actually approve of this mechanism as one
option in a general security policy mechanism.

So for example, the following would be one allowable option in my ideal
case:

_http._tcp.www.example.com   ESRV "ssl=required cert-assure=required"

That would be out of scope if the charter specifies trust anchor selection
as would be TLSFP.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Sep 2010 15:50:02 +0100

> attest to both self-signed and CA-signed certificates.

I think that depends on whether its meant to exclude all other
options or not. It certainly makes sense if all we think about
it TLS (but in which case, why not do the work in the TLS WG?),
but I've no idea if its enough for the "non-TLS protocols" in
the current charter text.

> For example, a domain owner may indicate that servers authenticating as
> the domain should only present self-signed certificates or only only
> certificates under a given CA.
> "
> 
> I think that's a little clearer.  

I think that's a potentially huge rathole (figuring out what policy
statements to allow/disallow) and maybe just broken, e.g. if
example.com says "must chain up to ca.example.com" and some bridge
CA issues a cert for ca.example.com then what? It might also
bring up issues with wildcards in DNS I suppose (not sure).

In DKIM, as well as a never-ending and rarely amusing debate, that
kind of "recommendation" (with ADSP "discardable") has also caused
unexpected problems (with mailing lists) and there could be similar
gotchas here, e.g. in the case of SIP or something with intermediaries
where there could be more than one verifier for the same signature.

I think DKIM would have gone more smoothly if we'd had consensus to
make such things experimental from the start (we didn't). That might
be worth considering here too, perhaps something like doing the
basic DNS name/key-or-cert binding as a standards-track item, but
doing policy stuff as experimental until its been tested a bit in
the real world.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Sep 2010 15:50:44 +0100

> catch up on the mailing list traffic :-).

Well, enjoy the vacation and I'll look forward to your
response in a week and a bit:-)

S.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 24 Sep 2010 11:11:24 -0400

> The working group will also consider and may propose mechanism(s) to  
> express security policy information. For example restricting or  
> requiring the use of specific security protocols and/or authorizing  
> or requiring the use of specific cryptographic credentials.

This is not the proper level at which to address *general* security  
policy information, e.g., the use of a secure form of a protocol.  For  
example, as I've said before, different protocols have significantly  
different sets of security features, so a single "use secure mode"  
flag is insufficient.  These sorts of indications should be developed  
in the context of individual protocols; HTTP in particular is already  
being addressed in the HASMAT group.

I think we should keep a tight focus here on what credentials can be  
used to authenticate a domain name.  The crux of that is binding keys  
to domain names.  There may be some room for binding other stuff to  
domain names (e.g., other certificate constraints), but not things  
like ESRV.

Not trying to say that using DNSSEC for other things (like ESRV) isn't  
valuable, just that this isn't the venue for it.  Getting name-key  
bindings would be a big enough win.

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 24 Sep 2010 11:15:17 -0400

> the current charter text.

I'm confused.  We're talking about certs here, not application  
protocols.  Certs can be used in many protocols.  How does the above  
relate to constraining to TLS?

> doing policy stuff as experimental until its been tested a bit in

I would be perfectly happy with that plan, keeping the focus for now  
on name-key/cert bindings.  I just suggested the text to try clarify  
what I thought the original suggested text meant.

--Richard

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Sep 2010 17:22:28 +0200

> attest to both self-signed and CA-signed certificates.

I like it, but I feel it is too strict and I am not sure that we want to 
limit our options only to those two.

> constraints on certificates, as a recommendation to relying parties. For
> example, a domain owner may indicate that servers authenticating as the
> domain should only present self-signed certificates or only only
> I think that's a little clearer. Does that align with your expectations?
>
> --Richard
>
>
>> We were trying to say, that we won't be chosing neither only
>> self-signed nor only CA-signed (+ DNSSEC assured) in the charter.
>>
>> Ondrej
>>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 24 Sep 2010 11:32:44 -0400

On Sep 24, 2010, at 11:22 AM, Ondřej Surý wrote:
> I like it, but I feel it is too strict and I am not sure that we  
> want to limit our options only to those two.

How about we turn it around:
"
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).
"

---

From: Warren Kumari <[email-masked]>
Date: Fri, 24 Sep 2010 11:37:00 -0400

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

That sounds better -- I had started trying to just change the "will"  
to a "may" in your first suggestion, but that sounded funny! This  
sounds much better (IMO).
W

-- 
Do not meddle in the affairs of wizards, for they are subtle and quick  
to anger.
     -- J.R.R. Tolkien

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Sep 2010 17:42:59 +0200

On 24.9.2010 17:32, Richard L. Barnes wrote:
>> I like it, but I feel it is too strict and I am not sure that we want
>> to limit our options only to those two.
>
> mechanisms supported by the application protocols addressed (e.g., both
> self-signed and CA-issued certificates for use in TLS).
> "

That would work for me.  Thanks.

I have updated proposed charter accordingly.

Ondrej

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Sep 2010 12:03:15 -0400

On Fri, Sep 24, 2010 at 10:50 AM, Stephen Farrell <[email-masked]
> wrote:

> doing policy stuff as experimental until its been tested a bit in

I agree and I think we should make use of experimental RFCs here as well.

Providing additional ways to assert that a key should be trusted for a
domain using DNSSEC without affecting any other processing is as close as
anything gets to being a slam dunk in the standards world.

Security policy has a lot of complexity and deployment experience is
essential. And not just to uncover potential issues. Often times real world
deployment shuts down an entire chain of argument because the corner case
that exists in the spec does not matter in the real world (often there is
another bigger corner case that dominates it).

In order to gain that experience we need to have real world deployment and
real world applications.

And to do that we need to have some DNS assignments for which we will
require RFCs.

Although the IETF is in theory going to a two stage process (maybe) there
was actually a rationale for the original first step and that was that
people need code points assigned to start writing code.

I suggest that we submit experimental drafts under the existing DNS process
to request the following code points:

1) DNS Resource Record number for ESRV
2) DNS CERT Certificate Type for ASSURE
3) DNS CERT Certificate Type for TLSFP

Clearly we will want to get the ASSURE and TLSFP drafts to the point where
they both use identical mechanism / syntax. The only difference being what
is done when there is no matching FP.

We are open to merging the ASSURE/TLSFP drafts.

We have a new version of the ASSURE draft that is much longer and has a very
comprehensive Security Considerations that we will submit after internal
reviewers get back to us.

It is not quite ready yet, but it is very close to being ready for
EXPERIMENTAL.

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Sep 2010 17:19:48 +0100

> That would work for me.  Thanks.

Much better. I'd say maybe s/all key-transport/key-transport/
but that's maybe a nit.

S.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 24 Sep 2010 12:28:23 -0400

On Sep 24, 2010, at 12:19 PM, Stephen Farrell wrote:

>>> both

Oooh, yes, that *does* sound much better...

W

--
Hope is not a strategy.
       --  Ben Treynor, Google