[foaf-protocols] Fwd: [keyassure] WG Action: DNS-based Authentication of Named Entities (dane)
home_pw at msn.com
Sat Dec 11 18:06:59 CET 2010
I smell Vint Cerf behind this one, especially given the topic AND the Google
hookup. VC would default to formulating a research programme when faced with
the internet trust fissures finally revealed to all over the last month. The
lowest hanging fruit IS DNSsec (which has sat there for 15 years, waiting to
be the bride...).
90% of getting anywhere in IETF is who you know (and how well you are
trusted to fit in with the dynamics of IETF with all the pressures folks
face when dealing with the influence various USG entities exert over it to
conform with US strategic goals).
3 things to note
Main chair is typically lively and outgoing, suitable as front man because
he has lots of energy and charisma (probably). Google related, I note. Seems
a classical Google type in formation and orientation.
Secondary chair is probably the main technical contributor, with background
in zone problems, software-centric HSMs, and leveraging the structure and
organization of DNS resolvers, registries and zoning. European formation.
Typically, won't have experience in American carrier-class terabit/s crypto
and won't have the clearances to get it, either.
Topic focused on DTLS first, IPsec later. Will be interesting to see if they
focus on NSA's authenticated encryption class of ciphers, leveraging
Housley's various counter modes; and be interesting to checkout the degree
to which the chairs turn out just to be channeling NSA-developed work
products (or NSA [open] work products channeled through Google, channelled
through the WG).
If VC does turn out to be behind it, the program may actually be partly open
minded (since he has the political skills to somehow tame the agencies,
deliver tangible strategic benefit for the $$ AND get some actual basic,
internet research done, too). But, you have to watch Polk and Turner, as
both are HIGHLY indoctrinated. As things mature, it's their job to fashion a
strategic benefit from any engineering breakthoughs - which typically means
subverting competing work outputs that are not in US interests.
To be less cynical, there may be an political opening here (and obviously
that is the signal being sent...to W3C). But you HAVE to be Russian-like
when dealing with IETF types. You have to remind them: we WILL wack you one
back, if/when you start being deceitful and untrustworthy.
From: foaf-protocols-bounces at lists.foaf-project.org
[mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of Dan
Sent: Saturday, December 11, 2010 1:18 AM
To: foaf-protocols at lists.foaf-project.org
Subject: [foaf-protocols] Fwd: [keyassure] WG Action: DNS-based
Authentication of Named Entities (dane)
Another day, another WG... :)
---------- Forwarded message ----------
From: IESG Secretary <iesg-secretary at ietf.org>
Date: Fri, Dec 10, 2010 at 7:17 PM
Subject: [keyassure] WG Action: DNS-based Authentication of Named Entities
To: IETF Announcement list <ietf-announce at ietf.org>
Cc: keyassure at ietf.org
A new IETF working group has been formed in the Security Area.
For additional information, please contact the Area Directors or the WG
DNS-based Authentication of Named Entities (dane)
Current Status: Active Working Group
Warren Kumari < <mailto:warren at kumari.net> warren at kumari.net>
Ondrej Sury < <mailto:ondrej.sury at nic.cz> ondrej.sury at nic.cz>
Matt Lepinski < <mailto:mlepinski at bbn.com> mlepinski at bbn.com>
Security Area Directors:
Sean Turner < <mailto:turners at ieca.com> turners at ieca.com>
Tim Polk < <mailto:tim.polk at nist.gov> tim.polk at nist.gov>
Security Area Advisor:
Tim Polk < <mailto:tim.polk at nist.gov> tim.polk at nist.gov>
General Discussion: <mailto:keyassure at ietf.org> keyassure at ietf.org
To Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>
Description of Working Group:
Specify mechanisms and techniques that allow Internet applications to
establish cryptographically secured communications by using information
distributed through DNSSEC for discovering and authenticating public keys
which are associated with a service located at a domain name.
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> https://www.example.com> is
expected to authenticate as " <http://www.example.com> 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 zone 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 zone 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 zone 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 solutions specified by this working group rely upon the security of the
DNS to provide source authentication for public keys. The decision whether
the chain of trust provided by DNSSEC is sufficient to trust the key, or
whether additional mechanisms are required to determine the acceptability of
a key, is left to the entity that uses the key material. In addition to the
protections afforded by DNSSEC, the protocols and mechanisms designed by
this working group require securing the "last hop" by operating a local DNS
resolver or securing the connection to remote resolver - this WG will not
specify new mechanisms to secure that hop, but will reference existing
specifications or document existing methods in order to allow
implementations to interoperate securely.
Initial deliverables for this working group are limited to distribution of
bindings between names within the zone operator's control and public keys.
More general statements of policy for a domain are out of scope, and new
tasks in this area may only be adopted through a re-chartering.
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.
Goals and Milestones:
Apr 2011 First WG draft of standards-track protocol for using DNS to
associate hosts with keys for TLS and DTLS May 2011 First WG draft
of standards-track protocols for using DNS to
associate hosts with IPsec
Sep 2011 Protocol for using DNS to associate domain names with keys for
TLS and DTLS to IESG
Sep 2011 Protocols for using DNS to associate domain names with keys
for IPsec to IESG
Nov 2011 Recharter
keyassure mailing list
<mailto:keyassure at ietf.org> keyassure at ietf.org
foaf-protocols mailing list
<mailto:foaf-protocols at lists.foaf-project.org>
foaf-protocols at lists.foaf-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the foaf-protocols