Subject: Re: WG Review: Keys In DNS (kidns)

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

Howdy,

The charter below has the following text:

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

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

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

Just my two cents,

regards,

Ted

On Tue, Oct 26, 2010 at 10:00 AM, 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
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

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

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

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

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

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

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

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

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

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

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

/Simon