Subject: [keyassure] Poking the charter bear....

From: Warren Kumari <[email-masked]>
Date: Wed, 25 Aug 2010 16:59:01 -0400

So, a while back we had some discussions about a possible charter for  
a possible working group. This discussion sort of veered off course,  
so this is a new thread, unencumbered by previous grumpiness...

I have tried to distill essence from various folks comments and  
proposed charters and come up with something that we can all (yeah,  
right!) agree on... How do folk feel about the below?

-----------------------------------
Objective:

Specify mechanisms and techniques that allow Internet applications to  
establish cryptographically secured communications through use of  
information distributed through the DNS.

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.  The group may also specify updates or clarifications  
to protocols to describe how protocol entities discover and validate  
these bindings in the execution of specific applications.

---------------------------

I have attempted to pull bits from various people suggestions, and  
this is a compromise -- I don't expect anyone to love it, but I hope  
that it at least acceptable to most. I'm hoping that we can keep this  
discussion on topic....

Whether or not this ends up being considered as a charter for a  
possible WG is not important, what is is that we have some rough idea  
of what we think we are hoping to accomplish...

W

Below are the provided texts that I mainly pulled from (and then  
massaged to try and remove the point ends).

--------------
Ondrej Sury (apologies for pure ASCII munging) and myself had written  
the original draft proposed charter as:
----
Problem Statement:

The DNS Security Extensions are a collection of resource records and  
protocol modifications that provide source authentication for the DNS.

The DNSSEC signed root infrastructure provides a single, well  
published trust-anchor and a method to build a chain of trust from an  
individual resource record (RR)  to that TA. By leveraging this  
infrastructure we can securely bind information (such as a public key,  
certificate identifier, etc) to a DNS name.

Increasingly people would like to be able to take advantage of the  
confidentiality and identity validation provided by protocols such as  
TLS. There are numerous barriers to this, including cost, ease of use,  
complexity, certificate management, etc. By allowing users to securely  
publish public key information we can allow users to easily and  
securely make use of self-signed certificates.

Currently, one of the issues limiting the use of self-signed  
certificates is the difficulty in key-distribution - it is infeasible  
to distribute a key binding at the web scale. By providing a means to  
publish (and securely validate) this information in the DNS, we allow  
for users to attest to the validity of keying information and  
establish trust in the published public key.

The DNSSEC root trust anchor can also be used for additional  
validation during the current path validations. By validating that  
the  certificate presented is the certificate identified by the DNS,  
we can provide additional confidence that the client is connecting to  
the intended server - this helps alleviate concerns that a valid  
certificate has been obtained by an attacker (for example from a CA  
not used by the victim).
-----

Phillip Hallam-Baker has proposed:
----
Objective:

Specify mechanisms that allow Internet applications to establish
cryptographically enhanced communications through use of information
distributed through the DNS.

Problem Statement:

Today the Internet is insecure by default and security is the
exception. If the security of the Internet is to be improved, security
must become the default. In particular modern computers have the
ability to employ cryptographic security enhancements with minimal or
negligible impact on performance, yet only a tiny proportion of
Internet traffic is encrypted or authenticated.

One of the key weaknesses of the current Internet Public Key
Infrastructure (PKI) is that the most widely used Internet PKI is
based on the X.500 Directory scheme intended to support an entirely
different networking infrastructure.

The naming infrastructure of the Internet is the DNS, not X.500. While
the PKIX specifications provide a means of mapping X.509v3 attributes
to DNS names there is currently no widely accepted, generalized means
of achieving the mapping from DNS names to X.509 certificates in
particular or to cryptographic keying material in general. DKIM and
SSH have demonstrated the utility of this approach in specific
domains, these specifications

Recent progress in deployment of DNSSEC has renewed focus on the use
of the DNS naming system to support cryptographic operations. In
particular:

  * Discovery of keying material by DNS name
  * Discovery of security criteria by DNS names
  * Verification of keying material through DNSSEC trust chains

Scope:

  * Use of existing security protocols with DNS established keys
  * Use of DNS to verify existing certificate / keysigning / security
assertion material formats
  * Means of verifying key/certificate chains using DNSSEC exclusively
  * Means of verifying key/certificate chains using DNSSEC in
combination with other existing means

Out-Of-Scope:

* Reason for choice of specific trust paths
* New formats for keying material (other than raw keys)
* New trust architectures (unless they can be expressed in existing  
formats

----
And Richard L. Barnes has provided:
Objective:

Specify mechanisms for Internet applications to use information  
distributed through the DNS to establish cryptographically assured  
bindings between domain names and public keys.

Problem Statement:

Many Internet applications require protocol entities to authenticate  
that they represent a certain domain 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.

In the past, these bindings have been asserted by parties external to  
the DNS, using X.509 certificates.  A certification authority (CA) can  
create certificates that contain a domain name (e.g., as a Common Name  
or dNSName Subject Alternative Name) and a public key.  When a server  
presents this certificate and proves ownership of the private key, a  
relying party that trusts the CA to authenticate domain ownership can  
be assured that the server legitimately represents the domain.

One problem with this model is that the CAs that are typically used  
have no relationship to the DNS infrastructure about which they are  
making assertions.  Modern browsers and operating systems typically  
include more than a hundred CAs as trust anchors, any of which can  
create a certificate for any domain name.

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 to providing a more authoritative way of binding  
DNS names to keys, 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.  The group may also specify updates or clarifications  
to protocols to describe how protocol entities discover and validate  
these bindings in the execution of a specific application.

Note that this working group is specifically focused on bindings  
between domain names and public keys, rather than bindings between  
names and other sorts of information.  For example, an X.509  
certificate can associate many types of information with its subject,  
including things like IP address holdings and images of logos, as well  
as bindings to higher-layer identities (e.g., corporate names).   
Mechanisms developed by this group will not be focused on these  
additional data, only on public keys.  This basic binding might be  
used, however, to associate a domain name with rich data by including  
the same public key in the certificate that is bound to the domain.

--
If the bad guys have copies of your MD5 passwords, then you have way  
bigger problems than the bad guys having copies of your MD5 passwords.
-- Richard A Steenbergen

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 25 Aug 2010 17:05:56 -0400

On Wed, Aug 25, 2010 at 04:59:01PM -0400, Warren Kumari wrote:
> I have tried to distill essence from various folks comments and proposed 
> charters and come up with something that we can all (yeah, right!) agree 
> on... How do folk feel about the below?

I think it's a reasonably generic outline of the things we're trying
to solve.  I think it does not prejudge the solution that will be
reached, in the sense that it doesn't restrict the details of the
eventual approach.  I think it _does_ prejudge the solution in the
sense that it restricts scope to the specific DNS-based approaches
under discussion, rather than opening the discussion up to every
possible authentication mechanism.  So I think it's about right.

A

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 25 Aug 2010 17:14:59 -0400

Best attempt so far!

The problem statement looks fine to me.  My only (minor) comment is  
that I would prefer the Objective be tightened a little to focus on  
authenticating domain names, as opposed to, say, negotiating crypto  
parameters.  Suggested text (just off the top of my head):
"
Specify mechanisms and techniques that allow Internet applications to  
establish cryptographically secured communications by using  
information distributed through the DNS to support domain name  
authentication.
"

On Aug 25, 2010, at 4:59 PM, Warren Kumari wrote:

> So, a while back we had some discussions about a possible charter  
> for a possible working group. This discussion sort of veered off  
> course, so this is a new thread, unencumbered by previous  
> grumpiness...
>
> Specify mechanisms and techniques that allow Internet applications  
> to establish cryptographically secured communications through use of  
> 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.
>
> 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.  The group may also specify updates or  
> clarifications to protocols to describe how protocol entities  
> discover and validate these bindings in the execution of specific  
> applications.
>
> that it at least acceptable to most. I'm hoping that we can keep  
> this discussion on topic....
>
> possible WG is not important, what is is that we have some rough  
> idea of what we think we are hoping to accomplish...
>
>
> W
>
> Ondrej Sury (apologies for pure ASCII munging) and myself had  
> written the original draft proposed charter as:
> ----
> Problem Statement:
>
> published trust-anchor and a method to build a chain of trust from  
> an individual resource record (RR)  to that TA. By leveraging this  
> infrastructure we can securely bind information (such as a public  
> key, certificate identifier, etc) to a DNS name.
>
> confidentiality and identity validation provided by protocols such  
> as TLS. There are numerous barriers to this, including cost, ease of  
> use, complexity, certificate management, etc. By allowing users to  
> securely publish public key information we can allow users to easily  
> and securely make use of self-signed certificates.
>
> certificates is the difficulty in key-distribution - it is  
> infeasible to distribute a key binding at the web scale. By  
> providing a means to publish (and securely validate) this  
> information in the DNS, we allow for users to attest to the validity  
> of keying information and establish trust in the published public key.
>
> we can provide additional confidence that the client is connecting  
> to the intended server - this helps alleviate concerns that a valid  
> that they represent a certain domain 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.
>
> In the past, these bindings have been asserted by parties external  
> to the DNS, using X.509 certificates.  A certification authority  
> (CA) can create certificates that contain a domain name (e.g., as a  
> Common Name or dNSName Subject Alternative Name) and a public key.   
> When a server presents this certificate and proves ownership of the  
> private key, a relying party that trusts the CA to authenticate  
> domain ownership can be assured that the server legitimately  
> represents the domain.
>
> 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 to providing a more authoritative  
> way of binding DNS names to keys, 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 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.  The group may also specify updates or  
> clarifications to protocols to describe how protocol entities  
> discover and validate these bindings in the execution of a specific  
> application.
>
> certificate can associate many types of information with its  
> subject, including things like IP address holdings and images of  
> logos, as well as bindings to higher-layer identities (e.g.,  
> corporate names).  Mechanisms developed by this group will not be  
> focused on these additional data, only on public keys.  This basic  
> binding might be used, however, to associate a domain name with rich  
> data by including the same public key in the certificate that is  
> bound to the domain.
>
>
>
>
>
>
> --
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 25 Aug 2010 17:30:56 -0400

On Wed, Aug 25, 2010 at 05:14:59PM -0400, Richard L. Barnes wrote:
> I would prefer the Objective be tightened a little to focus on  

What do you mwan "authenticating"?  If what you want to do is ensure
yourself that you're actually going to the right address, you can do
that now.  That's all DNSSEC does.

I think the goal here is to make sure that the certificate you're
using is the right one for the service you're trying to talk to.  The
traditional way to do that is already well-defined.  The current work
is aimed at providing an alternate way to do that, using the
assurances you can get from the DNS (using DNSSEC).  So I think the
talk of "negotiating crypto parameters" and such is about right.

A

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

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 25 Aug 2010 14:35:43 -0700

> that now.  That's all DNSSEC does.

Why not "discovering and authenticating cryptographic material which is associated with a service located at a domain name"?

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 25 Aug 2010 17:49:34 -0400

> Why not "discovering and authenticating cryptographic material which is associated with a service located at a domain name"?

Sure, that sounds right to me.

A

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 25 Aug 2010 17:54:48 -0400

Works for me.  I was going to suggest the slightly more compact phrase  
"authenticating services identified by domain name".

FWIW, what I meant by the "negotiating crypto parameters" was  
something quite different, questions like "what cipher suite shall we  
use?", which aren't what we're talking about, but could also be  
construed as helping applications establish secure comms.

On Aug 25, 2010, at 5:49 PM, Andrew Sullivan wrote:

>> Why not "discovering and authenticating cryptographic material  
>> which is associated with a service located at a domain name"?
>>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Aug 2010 18:09:57 -0400

This looks acceptable to me.

Although I am currently working on a draft for the ESRV record, I
consider that an experimental proposal. Although it is in some ways
quite a bit easier to do since there is less legacy to work round.

The approach I prefer there is to allocate a RR, perform some
experiments with the general scheme as an 'Experimental' protocol and
then start a standards track WG to develop specs to address discovery
and security for specific groups of protocols (e.g. Web, Mail).

On Wed, Aug 25, 2010 at 4:59 PM, Warren Kumari <[email-masked]> wrote:
> So, a while back we had some discussions about a possible charter for a
> possible working group. This discussion sort of veered off course, so this
> is a new thread, unencumbered by previous grumpiness...
>
> 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.  The group
> may also specify updates or clarifications to protocols to describe how
> protocol entities discover and validate these bindings in the execution of
> specific applications.
>
> I have attempted to pull bits from various people suggestions, and this is a
> compromise -- I don't expect anyone to love it, but I hope that it at least
> acceptable to most. I'm hoping that we can keep this discussion on topic....
>
> Whether or not this ends up being considered as a charter for a possible WG
> is not important, what is is that we have some rough idea of what we think
> we are hoping to accomplish...
>
>
> W
>
> Below are the provided texts that I mainly pulled from (and then massaged to
> try and remove the point ends).
>
> --------------
> Ondrej Sury (apologies for pure ASCII munging) and myself had written the
> original draft proposed charter as:
> ----
> Problem Statement:
>
> The DNSSEC signed root infrastructure provides a single, well published
> trust-anchor and a method to build a chain of trust from an individual
> resource record (RR)  to that TA. By leveraging this infrastructure we can
> securely bind information (such as a public key, certificate identifier,
> etc) to a DNS name.
>
> confidentiality and identity validation provided by protocols such as TLS.
> There are numerous barriers to this, including cost, ease of use,
> publish public key information we can allow users to easily and securely
> make use of self-signed certificates.
>
> Currently, one of the issues limiting the use of self-signed certificates is
> the difficulty in key-distribution - it is infeasible to distribute a key
> binding at the web scale. By providing a means to publish (and securely
> validate) this information in the DNS, we allow for users to attest to the
> validity of keying information and establish trust in the published public
> key.
>
> The DNSSEC root trust anchor can also be used for additional validation
> during the current path validations. By validating that the  certificate
> presented is the certificate identified by the DNS, we can provide
> additional confidence that the client is connecting to the intended server -
> this helps alleviate concerns that a valid certificate has been obtained by
> an attacker (for example from a CA not used by the victim).
> -----
>
> * New trust architectures (unless they can be expressed in existing formats
>
>
> ----
> Specify mechanisms for Internet applications to use information distributed
> through the DNS to establish cryptographically assured bindings between
> domain names and public keys.
>
> Problem Statement:
>
> Many Internet applications require protocol entities to authenticate that
> they represent a certain domain name.  For instance, in HTTPS, a server
> 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.
>
> In the past, these bindings have been asserted by parties external to the
> DNS, using X.509 certificates.  A certification authority (CA) can create
> certificates that contain a domain name (e.g., as a Common Name or dNSName
> Subject Alternative Name) and a public key.  When a server presents this
> certificate and proves ownership of the private key, a relying party that
> trusts the CA to authenticate domain ownership can be assured that the
> server legitimately represents the domain.
>
> One problem with this model is that the CAs that are typically used have no
> relationship to the DNS infrastructure about which they are making
> assertions.  Modern browsers and operating systems typically include more
> than a hundred CAs as trust anchors, any of which can create a certificate
> for any domain name.
>
> 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 to
> providing a more authoritative way of binding DNS names to keys, 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.  The group
> may also specify updates or clarifications to protocols to describe how
> protocol entities discover and validate these bindings in the execution of a
> specific application.
>
> Note that this working group is specifically focused on bindings between
> domain names and public keys, rather than bindings between names and other
> sorts of information.  For example, an X.509 certificate can associate many
> types of information with its subject, including things like IP address
> holdings and images of logos, as well as bindings to higher-layer identities
> (e.g., corporate names).  Mechanisms developed by this group will not be
> focused on these additional data, only on public keys.  This basic binding
> might be used, however, to associate a domain name with rich data by
> including the same public key in the certificate that is bound to the
> domain.
>
>
>
>
>
>
> --
> If the bad guys have copies of your MD5 passwords, then you have way bigger
> problems than the bad guys having copies of your MD5 passwords.
> -- Richard A Steenbergen
>
>

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Aug 2010 18:14:43 -0400

TLS and most other security protocols already have mechanisms for that
type of parameter negotiation. Provided the credentials supplied are
trustworthy, the negotiation mechanism is sufficient to prevent an
in-protocol downgrade attack (e.g. use of md5in place of SHA256).

The problem is that we do not have a mechanism for preventing
downgrade attack on the security protocol as a whole. We can stop the
use of substandard SSL but can't ensure that SSL is used at all.

On Wed, Aug 25, 2010 at 5:54 PM, Richard L. Barnes <[email-masked]> wrote:
> FWIW, what I meant by the "negotiating crypto parameters" was something
> quite different, questions like "what cipher suite shall we use?", which
> aren't what we're talking about, but could also be construed as helping
> applications establish secure comms.
>
>
>
>>> Why not "discovering and authenticating cryptographic material which is
>>> associated with a service located at a domain name"?
>>>
>>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 25 Aug 2010 18:22:53 -0400

Correct.  But I'm not sure there's consensus on whether that's a  
problem that is in scope for this group.

My opinion, as I've said before, is that the negotiation of SSL usage  
should be done at the application layer, not at the DNS layer.  The  
notion of "SSL usage" can vary quite a bit from one application to  
another, and there are already several existing mechanisms for  
signaling secure transport in different protocols (obvious examples  
include URI schemes and the SIP transport=tls parameter).

On Aug 25, 2010, at 6:14 PM, Phillip Hallam-Baker wrote:

>> something
>>>> which is

---

From: [email-masked]
Date: Thu, 26 Aug 2010 17:35:48 +0000

wander off for a few days and look what happens! :)

 i have a question for the assembled masses...

 when the text below referes to "domain names" does this include
 _all_ domain names or just those in the forward tree?  i.e.

 any problems using 

	53.30.168.192.in-addr.arpa. 

 as a domain name?

--bill

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Aug 2010 11:01:23 -0700

>	53.30.168.192.in-addr.arpa.

Now thar's some good poking!

I definitely have a problem with that name for what is in the charter in that I would hope that there could not be a server running TLS at the addresses in the A or AAAA records returned from a query sent for 53.30.168.192.in-addr.arpa.

And, just in case you were messing with us by choosing a private address space, I would say exactly the same thing for 81.41.182.207.in-addr.arpa.

The CNAME and SRV indirection threads here have not yielded widespread agreement; I think PTR indirection should be added to the list of things we might consider but might gingerly back away from.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Aug 2010 15:55:49 -0400

Looks like a cop out to me.

Putting certs in the reverse DNS may turn out to be useless. But we
have to understand why it is useless if we are going to be able to
claim that we understand the proposals for the forward DNS.

None of these schemes are going to make any sense except in the
context of an application.

Binding a cert to an IP address is does not seem to be very useful in
an application layer protocol. But it could be very useful in a
routing layer protocol. For example, BGP security. I can also see
cases where it might be used to exchange messages reporting abusive
behavior.

In the case of establishing a WiFi connection at an access point such
as a coffee shop, this would seem to me to be a rather useful
approach.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 26 Aug 2010 13:20:01 -0700

> as a coffee shop, this would seem to me to be a rather useful

SSH can connect by both IP and hostname, and the known-hosts file will do things by IP.  Thus at least for SSH it makes sense to store records associated with reverse names as well.

And once again, there is a single possible path-of-trust involved, but this one rather than passing through the chain of

. -> domain registrar -> domain owner -> subdomain owner

it passes through the chain of

. -> network registrar -> ISP -> ?ISP? -> network owner

(and in both cases, a service identifier could be prepended onto the name).

The coffie shop perhaps less so: the access point is probably NAT'ed, so everything is in 10. or 192.168. space.  Getting an external IPv4 address for the WAP seems difficult/uselesss.  But there may be a role in IPv6: you get the key for the gateway's IPv6 address and that might make sense.

Thus to me it makes sense to examine usages which bind key material to reverse names as well as forward names, since the reverse name chain of trust is like the forward name chain of trust: there exists not only a single valid path, but it is along (a different) already established relationships.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Aug 2010 13:21:28 -0700

>Looks like a cop out to me.

One person's prudent use of resources is another person's cop-out.

>claim that we understand the proposals for the forward DNS.

We will never know until there are one or more concrete proposals, hopefully written as Internet Drafts and not just a changing thread on a mailing list.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Thu, 26 Aug 2010 17:00:13 -0400 (EDT)

> We will never know until there are one or more concrete proposals, hopefully written as Internet Drafts and not just a changing thread on a mailing list.

The FreeS/WAN project tried to use the rever tree for TXT records with pubkeys in it.
It failed miserably because endusers tend to not be able to do anything about their reverse.

There might still be a legitimate use for servers and sysadmins though.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Aug 2010 17:16:12 -0400

I very much doubt that we can come to consensus for a use for it.

Provisioning of the reverse DNS is pretty patchy for a start. But I
can definitely see a use for it with SSH. If someone is debugging a
network they are going to see an IP address, not a domain name.

But time spent understanding the problem is not wasted.

If I want to understand a protocol proposal I apply it to something
that the designer probably didn't consider. It is a really great way
to understand the corner cases you have to solve.

I have seen years wasted in IETF WG by people who insisted that
everything apart from their little piece of the problem be out of
scope.There is a particularly bad history of that in the DNS area. It
took four years to get the WG to accept that the EU privacy directive
was significant and less than six months to fix the problem.

What I think we are looking at in the short term is not actually a WG.
It is a fairly short proposal to describe a new prefix based approach
to discovery of CERT records and a couple of new fields for data
types.

I generally try to understand the problem before I write an Internet
Draft. I find that approach is generally better.

---

From: [email-masked]
Date: Thu, 26 Aug 2010 21:22:18 +0000

so, there seems to be tacit agreement that the entire DNS tree
	is fair game under the text Warren posted... mod the existance
	of IDs et.al.

--bill

---

From: Douglas Otis <[email-masked]>
Date: Thu, 26 Aug 2010 15:43:16 -0700

On 8/25/10 2:35 PM, Nicholas Weaver wrote:
> > What do you mean "authenticating"?  If what you want to do is
> > ensure yourself that you're actually going to the right address,
> > you can do that now.  That's all DNSSEC does.
>
>  Why not "discovering and authenticating cryptographic material which
>  is associated with a service located at a domain name"?

There are two end points to consider, which is one of the glaring 
weaknesses found with TLS.

Utilizing IPv6 address space for email will likely require a 
cryptographic means to verify both the client AND the server that are 
supporting a specific service, where there may be intervening address 
translations between connections.

So rewritten just a bit,

"Supporting the cryptographic authentication of either end of a network 
connection related to specific services utilizing resources published 
within DNS."

For SMTP, this could utilize an SMTP Auth extension employing a public 
key referenced from the EHLO host name, or a domain declared within the 
authentication exchange.

For cases where clients do not exchange domain names, reverse DNS could 
be utilized to authenticate clients.

-Doug

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 27 Aug 2010 10:25:23 -0400

> be utilized to authenticate clients.

Except, of course, that you can't really rely on the reverse tree
being managed.

A

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Aug 2010 10:42:06 -0400

The reason that the reverse tree is not properly managed is that doing
so is not necessary for most Web applications.

I would see the utility of this approach being for use with
applications such as SSH and other network management tools that are
used by the type of people who make sure their reverse DNS works
should they actually need it.

It is not going to be possible to use the ICANN root in private IP
space of course (10.x.x.x, 192.168.x.x). But if you have 1000 servers
it is one heck of a lot easier to distribute one private root of trust
to an application like SSH than 1000 end entity keys. And in this
context ease of use means more security.

I would like to get away from the idea of 'using DNSSEC' as the basis
for this group and instead using 'Secure DNS' of which DNSSEC is one
realization. All that matters in order to have a trustworthy means of
keying SSH is that the data in the CERT record is trustworthy and that
the CERT record is presented to the client with a trustworthy means of
authentication trusted by the client.

It is far too late to use DNS Curve for inter-domain security in my
view. But the use of a similar approach to support intra-domain
security between the client and server is very much on the table as
far as I am concerned (albeit not in this group). It is a model that
has considerable sympathy and champions in Microsoft and other major
vendors.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 27 Aug 2010 16:45:43 +0200

> should they actually need it.

May I remind this list, that SSH is out of the scope?  And we already 
have a existing SSHFP RR.  So when you think about reverse tree, please 
don't include SSH nor IPSec.

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: Nicholas Weaver <[email-masked]>
Date: Fri, 27 Aug 2010 07:49:10 -0700

On Aug 27, 2010, at 7:45 AM, Ondřej Surý wrote:

> May I remind this list, that SSH is out of the scope?  And we already have a existing SSHFP RR.  So when you think about reverse tree, please don't include SSH nor IPSec.

Uh, actually SSH IMO, is perfectly in scope.  

The real scope is not new resource records but new APIs and techniques:  You may be able to get the SSHFP RR today, but we need ways for the SSH application to validate that the key is indeed valid, and we need protocol and policy to get reverse lookups to be reliable in this case.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Aug 2010 11:02:38 -0400

At the moment we are still discussing scope. Paul's original list
request was for 'applications'.

Whether design of mechanisms to support email and SSH are in scope for
the group, the group would be remarkably ill advised to ignore DKIM
and SSHFP.

In particular, should the group choose to re-use the CERT record it is
obliged to consider the effect on other applications. and in
particular the question of whether keys presented in certificates
should be presented in the CERT or SSHFP record is going to have to be
considered.

On Fri, Aug 27, 2010 at 10:45 AM, Ondřej Surý <[email-masked]> wrote:
> May I remind this list, that SSH is out of the scope?  And we already have a
> existing SSHFP RR.  So when you think about reverse tree, please don't
> include SSH nor IPSec.
>
> Ondrej
> --
>  Ondřej Surý

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 27 Aug 2010 17:03:06 +0200

On 27.8.2010 16:49, Nicholas Weaver wrote:
>>> The reason that the reverse tree is not properly managed is that
>>> doing so is not necessary for most Web applications.
>>>
>>> applications such as SSH and other network management tools that
>>> are used by the type of people who make sure their reverse DNS
>>> works should they actually need it.
>>
>> May I remind this list, that SSH is out of the scope?  And we
>> already have a existing SSHFP RR.  So when you think about reverse
>> tree, please don't include SSH nor IPSec.
>
> The real scope is not new resource records but new APIs and
> techniques:  You may be able to get the SSHFP RR today, but we need
> ways for the SSH application to validate that the key is indeed
> valid, and we need protocol and policy to get reverse lookups to be
> reliable in this case.

Let me rephrase what I said...

The SSH and IPSec was out of scope when we created this mailing list, 
called the BoF and planned the creation of WG.  So I still think the SSH 
is out-of-the-scope.  And I personally would like to keep it that way.

Ondrej

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Aug 2010 11:14:25 -0400

You called a bar BOF, not a BOF. That does not mean that you now hold
the decision stick on what should be in or out of a proposed charter.

You do not at this point have sanction from an AD.

But regardless of whether designing to support SSH is in or out of
charter, experience from the SSH proposal is in charter.

I suspect that SSH use has not been very extensive given the lack of
an ICANN signed root. I would therefore suggest as an experiment we
look to see if SSH use could be increased by using a CERT record to
declare a local root for a zone and then configure SSH to use that as
its trust anchor.

On Fri, Aug 27, 2010 at 11:03 AM, Ondřej Surý <[email-masked]> wrote:
> The SSH and IPSec was out of scope when we created this mailing list, called
> the BoF and planned the creation of WG.  So I still think the SSH is
> out-of-the-scope.  And I personally would like to keep it that way.
>
> Ondrej
> --
>  Ondřej Surý

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 27 Aug 2010 17:22:57 +0200

On 27.8.2010 17:14, Phillip Hallam-Baker wrote:
> You called a bar BOF, not a BOF.

Apologies, my mistake.

> That does not mean that you now hold the decision stick on what
> should be in or out of a proposed charter.

I am just pointing out, that we had a certain idea in our minds when we 
gathered and created this non-WG mailing list.  So far we have two new 
drafts and both of them are targeting exactly the area why we created 
this mailing list.

> You do not at this point have sanction from an AD.

I am not saying I have.  I am only talking why we created this mailing list.

> declare a local root for a zone and then configure SSH to use that
> as its trust anchor.

There is lot of stuff which could be covered by a future-to-be WG.  But 
the more stuff we put under our wings the less likely this group will 
create any useful output.  I say let's stay focused on the topic we 
started with.

Ondrej

> On Fri, Aug 27, 2010 at 11:03 AM, Ondřej Surý<[email-masked]>
> wrote:
>>>>> The reason that the reverse tree is not properly managed is
>>>>> that doing so is not necessary for most Web applications.
>>>>>
>>>>> applications such as SSH and other network management tools
>>>>> that are used by the type of people who make sure their
>>>>> reverse DNS works should they actually need it.
>>>>
>>>> already have a existing SSHFP RR.  So when you think about
>>>> reverse tree, please don't include SSH nor IPSec.
>>>
>>> techniques:  You may be able to get the SSHFP RR today, but we
>>> need ways for the SSH application to validate that the key is
>>> indeed valid, and we need protocol and policy to get reverse
>>> lookups to be reliable in this case.
>>
>>
>> The SSH and IPSec was out of scope when we created this mailing
>> list, called the BoF and planned the creation of WG.  So I still
>> think the SSH is out-of-the-scope.  And I personally would like to
>> keep it that way.
>>
>> 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 -------------------------------------------
>> _______________________________________________ keyassure mailing
>> list [email-masked]

---

From: [email-masked]
Date: Fri, 27 Aug 2010 16:32:02 +0000

> Except, of course, that you can't really rely on the reverse tree

	and you can rely on the forward tree being managed?
	
	(sorry, don't really want to wander down this path again...
	 debates over how well managed (whatever that means) various
	 parts of the DNS namespace are is fraught w/ (un)considered
	 opinions and spotty emperical data)

 	the point being, that most folks seem to agree on the charter
	being applicable to the entire DNS namespace, not just a portion.
	
	thats all my question was trying to raise.  debate on the relative
	merits of how well any portion of the namespace is "maintained" does
	not seem germaine to the topic at hand - if it is, please let me know.

--bill

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Fri, 27 Aug 2010 10:36:10 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Friday, August 27, 2010 9:32 AM
> 

On the one hand I conceptually agree. On the other hand any mechanism is going to rely on signed data from DNS.  Without getting into the arguments again about what the trust anchors will be, the necessarily restriction is still that the DNS space in question must be trust-anchored somehow.

Yes?

This means that for those using the DNS root as their trust-anchor, the 192.in-addr.arpa. space can't hold any of this data, right?  Or does it not mean that?

- Andy

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 27 Aug 2010 12:40:36 -0400

> 	and you can rely on the forward tree being managed?

You can in fact rely on the forward tree's data pointing to the
machine you actually get to when you use the DNS entry, so there's
never a doubt about what the answer you're using matches.  There's
precious little evidence that the reverse tree's data actually
corresponds to any state of the network.  That said,

> 	being applicable to the entire DNS namespace, not just a portion.

my natural assumption any time we talk about an RR is that one
automatically has to deal with the entire namespace.

A

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Aug 2010 12:48:42 -0400

The only part of DNS space a party can rely on being well managed is
the space that they control.

My approach to securing 10.0.0.0/8 would be as follows:

1) Site generates a CERT record for the KSK of its server and installs
it on each populated node in their rDNS.

2) Extensions to support use of DNSSEC for key assurance in SSH are
extended to allow the KSK key to be added to the trust store as a
trust anchor.

3) Generate SSH keys for each host and install them in the forward and
reverse DNS.

This approach means that the task of managing SSH keys in a large
server farm is reduced to managing one key per host on the client to
managing one key for the entire site.

My ultimate root of trust is always going to be me. I am not going to
validate the entire rest of the world personally, I am going to choose
intermediaries I trust to do that on my behalf. But I am the only
person who is going to do the choosing.

As a rule, applications have to prove their value in the Intranet
before people feel confident about external deployment.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 29 Aug 2010 13:30:54 -0700

> Except, of course, that you can't really rely on the reverse tree
This was not expressing any optimism for reverse DNS, especially with 
IPv6. Nor for that matter, that IPv6 addresses offer suitable 
identifiers for clients either.  However, a transition toward the use of 
domains can avoid some of the complexities imposed by an IPv6 
environment.  Providing conventions that enable opportunistic use of 
reverse DNS with IPv4 addresses might help to accelerate this transition.

-Doug