Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns
From: Matt McCutchen <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Date: Sun, 31 Oct 2010 13:38:58 -0400
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>

On Sat, 2010-10-30 at 21:48 -0400, Phillip Hallam-Baker wrote:
> We have multiple protocols in use at most sites on a given domain. 
> 
> The easiest way to get to critical mass in my view is to enable sites
> to deploy for SMTP, IMAP, POP and other protocols where SSL is used
> but the clients do not make much use of the CA infrastructure
> and there is no use of EV.

Umm, all the protocols use the CA infrastructure to make boolean
accept/reject decisions for certificates.  I guess you mean other use of
the certificate information?

Sure.  But I'd argue the same is true of non-EV web sites: I haven't
seen any meaningful use made of the certificate information there.
Browsers will show you the certificate under which the main HTML page
was received, but that tells you nothing about any other acceptable
certificates floating around that might allow others to tamper with the
page under the same-origin policy.

> To make that practical it has to be possible to have statements of the
> form 'only trust these certs for protocol X'.

Or simply make the statement "trust this cert" specific to the protocol
by placing the record at the SRVName.  That seems more elegant to me.

> The other reason for wanting something other than a flag is that
> managing public keys on a large scale is time consuming and requires
> infrastructure. That infrastructure already exists for X.509/PKIX,
> many if not most enterprises who would be possible early adopters of
> this type of management scheme already have an X.509/PKIX
> infrastructure deployed.
> 
> So for those domains it is going to be much easier to publish a
> statement 'all valid certs fall under this hierarchy' than 'all valid
> certs have a fingerprint'.

Good point.  This is probably true of my university, which just made a
deal with a public CA to provide all their certificates.

Will it work to accept a presented certificate that either matches or
chains up to a TLSFP certificate?  Then one could publish the hash of
the end-entity certificate or some intermediate or root certificate,
possibly modified (and re-signed, the client doesn't care about the
signature anyway) to apply whatever extra PKIX-y restrictions the
software might support.  Any certificates the client can't be assumed to
have and the server doesn't send can be published in unassured CERT
records.

> No, I am saying that it has been very difficult to get anything that
> falls under the 'security policy' bracket accepted as a WG charter
> item because security policy is a notorious rat hole.
> 
> What we are proposing is a set of protocol specific security
> assertions and not a security policy processing mechanism.
> 
> So what I am saying is that I think we can craft a very precise
> statement that allows us to do exactly what we would like to do
> without triggering rodent dwelling concerns.

Good.

-- 
Matt

Date: Sun, 31 Oct 2010 12:40:02 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: James Cloos <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

--20cf30434784d729a90493ec579a
Content-Type: text/plain; charset=ISO-8859-1

+1

I think that the key to doing this effectively and efficiently is to look
carefully at SRV, NAPTR and URI while we do this.

Prefix records have some pretty complicated limitations. But I think they
are necessary in this case and I think we can avoid all of the problems that
they entail.

On Sun, Oct 31, 2010 at 12:51 AM, James Cloos <[email-masked]> wrote:

> >>>>> "IL" == Ilari Liusvaara <[email-masked]> writes:
>
> IL> If the lookups are done after resolving indirection by SRV, one
> IL> could get along with optional port numbers and protocols (as in,
> IL> UDP, TCP, SCTP...).
>
> I do like the idea of using SRV or NAPTR RRs.  Of course, if you are
> going to resolve _sip._tcp.example.com. IN SRV, then it makes sense to
> also resolve _sip._tcp.example.com. IN TLSFP.  Maybe it would even be
> better to just resolve _sip._tcp.example.com. IN ANY and expect both
> in the same reply.  (Is that, with the dnssec overhead, still small
> enough for a udp packet?)
>
> IL> Basically, a way to limit some TLSFP record to just some
> (protocol,port)
> IL> pairs and then the client would remove the entries that have wrong
> ports
> IL> just like entries that have unknown hash function.
>
> Makes sense.
>
> IL> This would also allow the "assure SMTP but not yet HTTP" case (by
> putting
> IL> an entry that covers just the SMTP ports)...
>
> IL> But of course that plan wouldn't work as-is if TLSFP lookups would have
> IL> to be done before SRV for some reason...
>
> Unless the TLSFP lookup is for the same name as the SRV lookup, rather
> than having to be for the result of the SRV lookup.
>
> If I have '_sip._tcp.b.net. 3600 IN SRV 0 0 5060 a.b.net.' and someone
> wants to talk to sip:[email-masked] <[email-masked]>, should they expect the TLS
> cert to cover
> b.net or a.b.net?
>
> -JimC
> --
> James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

--20cf30434784d729a90493ec579a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1<div><br></div><div>I think that the key to doing this effectively and ef=
ficiently is to look carefully at SRV, NAPTR and URI while we do this.</div=
><div><br></div><div>Prefix records have some pretty complicated limitation=
s. But I think they are necessary in this case and I think we can avoid all=
 of the problems that they entail.</div>
<div><br></div><div><br></div><div><br><div class=3D"gmail_quote">On Sun, O=
ct 31, 2010 at 12:51 AM, James Cloos <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex;">
&gt;&gt;&gt;&gt;&gt; &quot;IL&quot; =3D=3D Ilari Liusvaara &lt;<a href=3D"m=
ailto:[email-masked]">[email-masked]</a>&gt; writ=
es:<br>
<br>
IL&gt; If the lookups are done after resolving indirection by SRV, one<br>
IL&gt; could get along with optional port numbers and protocols (as in,<br>
IL&gt; UDP, TCP, SCTP...).<br>
<br>
I do like the idea of using SRV or NAPTR RRs. =A0Of course, if you are<br>
going to resolve _sip._<a href=3D"http://tcp.example.com" target=3D"_blank"=
>tcp.example.com</a>. IN SRV, then it makes sense to<br>
also resolve _sip._<a href=3D"http://tcp.example.com" target=3D"_blank">tcp=
.example.com</a>. IN TLSFP. =A0Maybe it would even be<br>
better to just resolve _sip._<a href=3D"http://tcp.example.com" target=3D"_=
blank">tcp.example.com</a>. IN ANY and expect both<br>
in the same reply. =A0(Is that, with the dnssec overhead, still small<br>
enough for a udp packet?)<br>
<br>
IL&gt; Basically, a way to limit some TLSFP record to just some (protocol,p=
ort)<br>
IL&gt; pairs and then the client would remove the entries that have wrong p=
orts<br>
IL&gt; just like entries that have unknown hash function.<br>
<br>
Makes sense.<br>
<br>
IL&gt; This would also allow the &quot;assure SMTP but not yet HTTP&quot; c=
ase (by putting<br>
IL&gt; an entry that covers just the SMTP ports)...<br>
<br>
IL&gt; But of course that plan wouldn&#39;t work as-is if TLSFP lookups wou=
ld have<br>
IL&gt; to be done before SRV for some reason...<br>
<br>
Unless the TLSFP lookup is for the same name as the SRV lookup, rather<br>
than having to be for the result of the SRV lookup.<br>
<br>
If I have &#39;_sip._<a href=3D"http://tcp.b.net" target=3D"_blank">tcp.b.n=
et</a>. 3600 IN SRV 0 0 5060 <a href=3D"http://a.b.net" target=3D"_blank">a=
.b.net</a>.&#39; and someone<br>
wants to talk to <a href=3D"mailto:[email-masked]">sip:[email-masked]</a>, should=
 they expect the TLS cert to cover<br>
<a href=3D"http://b.net" target=3D"_blank">b.net</a> or <a href=3D"http://a=
.b.net" target=3D"_blank">a.b.net</a>?<br>
<div class=3D"im"><br>
-JimC<br>
--<br>
James Cloos &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&=
gt; =A0 =A0 =A0 =A0 OpenPGP: 1024D/ED7DAEA6<br>
_______________________________________________<br>
</div><div><div></div><div class=3D"h5">keyassure mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf30434784d729a90493ec579a--

From: James Cloos <[email-masked]>
To: Warren Kumari <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
Copyright: Copyright 2009 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Sun, 31 Oct 2010 00:53:54 -0400
Lines: 13
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

>>>>> "WK" == Warren Kumari <[email-masked]> writes:

WK> One huge consideration is minimizing the number of DNS lookups
WK> needed to make all the magic happen -- if this system requires lots
WK> of lookups, the browser folk will be unwilling to implement as the
WK> user experience will be horrendous....

Agreed.  That was why I posed the 'either/or but use the most specific'
as a question.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

From: James Cloos <[email-masked]>
To: Ilari Liusvaara <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
Copyright: Copyright 2009 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Sun, 31 Oct 2010 00:51:32 -0400
Lines: 35
Cc: Steve Schultze <[email-masked]>, [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

>>>>> "IL" == Ilari Liusvaara <[email-masked]> writes:

IL> If the lookups are done after resolving indirection by SRV, one
IL> could get along with optional port numbers and protocols (as in,
IL> UDP, TCP, SCTP...).

I do like the idea of using SRV or NAPTR RRs.  Of course, if you are
going to resolve _sip._tcp.example.com. IN SRV, then it makes sense to
also resolve _sip._tcp.example.com. IN TLSFP.  Maybe it would even be
better to just resolve _sip._tcp.example.com. IN ANY and expect both
in the same reply.  (Is that, with the dnssec overhead, still small
enough for a udp packet?)

IL> Basically, a way to limit some TLSFP record to just some (protocol,port)
IL> pairs and then the client would remove the entries that have wrong ports
IL> just like entries that have unknown hash function.

Makes sense.

IL> This would also allow the "assure SMTP but not yet HTTP" case (by putting
IL> an entry that covers just the SMTP ports)...

IL> But of course that plan wouldn't work as-is if TLSFP lookups would have
IL> to be done before SRV for some reason...

Unless the TLSFP lookup is for the same name as the SRV lookup, rather
than having to be for the result of the SRV lookup.

If I have '_sip._tcp.b.net. 3600 IN SRV 0 0 5060 a.b.net.' and someone
wants to talk to sip:[email-masked], should they expect the TLS cert to cover
b.net or a.b.net?

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

Date: Sat, 30 Oct 2010 21:48:41 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

--20cf301d42ea280d1a0493dfe431
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Oct 30, 2010 at 4:29 PM, Matt McCutchen <[email-masked]>wrote:

> On Sat, 2010-10-30 at 14:24 -0400, Phillip Hallam-Baker wrote:
> > I am fine with this as an option.
> >
> > But I think that making it useful and scalable requires us to provide
> more
> > than just a flag.
>
> Can you provide a specific, compelling example?
>

We have multiple protocols in use at most sites on a given domain.

The easiest way to get to critical mass in my view is to enable sites to
deploy for SMTP, IMAP, POP and other protocols where SSL is used but the
clients do not make much use of the CA infrastructure and there is no use of
EV.

To make that practical it has to be possible to have statements of the form
'only trust these certs for protocol X'.

The other reason for wanting something other than a flag is that managing
public keys on a large scale is time consuming and requires infrastructure.
That infrastructure already exists for X.509/PKIX, many if not most
enterprises who would be possible early adopters of this type of management
scheme already have an X.509/PKIX infrastructure deployed.

So for those domains it is going to be much easier to publish a statement
'all valid certs fall under this hierarchy' than 'all valid certs have a
fingerprint'.

I think we need to offer both options.

>
> > What we are proposing here is an aspect of security policy. Which gets us
> > into territory that is generally considered 'difficult' and every
> security
> > AD that I have ever discussed this with has expressed extreme skepticism
> as
> > to whether a WG can get to closure if it addresses security policy. The
> term
> > 'rat hole' is used. [...]
>
> The flag has a simple and clear semantic, "I authorize this certificate
> and only this certificate for use on my TLS server", and is already
> useful to folks like me who can't wait to publish a single exclusive
> certificate in DNSSEC and no longer be exposed to the likes of Etisalat.
> You seem to be saying that we should hold off on standardizing the
> exclusivity flag because there are some use cases that require a more
> sophisticated scheme, but also that we might never complete such a
> scheme.  So what can be the benefit of waiting, compared to
> standardizing the flag now?
>

No, I am saying that it has been very difficult to get anything that falls
under the 'security policy' bracket accepted as a WG charter item because
security policy is a notorious rat hole.

What we are proposing is a set of protocol specific security assertions and
not a security policy processing mechanism.

So what I am saying is that I think we can craft a very precise statement
that allows us to do exactly what we would like to do without triggering
rodent dwelling concerns.

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

--20cf301d42ea280d1a0493dfe431
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Sat, Oct 30, 2010 at 4:29 PM, Matt Mc=
Cutchen <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">mat=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;=
">
<div class=3D"im">On Sat, 2010-10-30 at 14:24 -0400, Phillip Hallam-Baker w=
rote:<br>
&gt; I am fine with this as an option.<br>
&gt;<br>
&gt; But I think that making it useful and scalable requires us to provide =
more<br>
&gt; than just a flag.<br>
<br>
</div>Can you provide a specific, compelling example?<br></blockquote><div>=
<br></div><div>We have multiple protocols in use at most sites on a given d=
omain.=A0</div><div><br></div><div>The easiest way to get to critical mass =
in my view is to enable sites to deploy for SMTP, IMAP, POP and other proto=
cols where SSL is used but the clients do not make much use of the CA infra=
structure and there is no use of EV.</div>
<div><br></div><div>To make that practical it has to be possible to have st=
atements of the form &#39;only trust these certs for protocol X&#39;.</div>=
<div><br></div><div><br></div><div>The other reason for wanting something o=
ther than a flag is that managing public keys on a large scale is time cons=
uming and requires infrastructure. That infrastructure already exists for X=
.509/PKIX, many if not most enterprises who would be possible early adopter=
s of this type of management scheme already have an X.509/PKIX infrastructu=
re deployed.</div>
<div><br></div><div>So for those domains it is going to be much easier to p=
ublish a statement &#39;all valid certs fall under this hierarchy&#39; than=
 &#39;all valid certs have a fingerprint&#39;.</div><div><br></div><div>
I think we need to offer both options.</div><div><br></div><div><br></div><=
div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im"><br>
&gt; What we are proposing here is an aspect of security policy. Which gets=
 us<br>
&gt; into territory that is generally considered &#39;difficult&#39; and ev=
ery security<br>
&gt; AD that I have ever discussed this with has expressed extreme skeptici=
sm as<br>
&gt; to whether a WG can get to closure if it addresses security policy. Th=
e term<br>
</div>&gt; &#39;rat hole&#39; is used. [...]<br>
<br>
The flag has a simple and clear semantic, &quot;I authorize this certificat=
e<br>
and only this certificate for use on my TLS server&quot;, and is already<br=
>
useful to folks like me who can&#39;t wait to publish a single exclusive<br=
>
certificate in DNSSEC and no longer be exposed to the likes of Etisalat.<br=
>
You seem to be saying that we should hold off on standardizing the<br>
exclusivity flag because there are some use cases that require a more<br>
sophisticated scheme, but also that we might never complete such a<br>
scheme. =A0So what can be the benefit of waiting, compared to<br>
standardizing the flag now?<br></blockquote></div><div><br></div><div>No, I=
 am saying that it has been very difficult to get anything that falls under=
 the &#39;security policy&#39; bracket accepted as a WG charter item becaus=
e security policy is a notorious rat hole.</div>
<div><br></div><div>What we are proposing is a set of protocol specific sec=
urity assertions and not a security policy processing mechanism.</div><div>=
<br></div><div>So what I am saying is that I think we can craft a very prec=
ise statement that allows us to do exactly what we would like to do without=
 triggering rodent dwelling concerns.</div>
<br clear=3D"all"><br>-- <br>Website: <a href=3D"http://hallambaker.com/">h=
ttp://hallambaker.com/</a><br><br>

--20cf301d42ea280d1a0493dfe431--

Date: Sun, 31 Oct 2010 03:37:35 +0200
From: Ilari Liusvaara <[email-masked]>
To: Warren Kumari <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Sat, Oct 30, 2010 at 09:02:20PM -0400, Warren Kumari wrote:
> 
> On Oct 30, 2010, at 8:07 PM, James Cloos wrote:
> 
> >>>>>> "MM" == Matt McCutchen <[email-masked]> writes:
> > 
> > The only possible issue is the question of whether the client should
> > perform queries for names like www.example.com. or _http._tcp.www.example.com.?
> 
> This is another question that has been repeatedly raised (partly in the guise
> of "if you post a record for your webserver it will break mail").

> Another option (which has some (IMO) of the elegance retained, but probably
> has scalability and leakage issues) is 
> foo.example.com     IN A 192.0.2.1
>                     IN KIDNS 443 545254634563546354
>                     IN KIDNS 993 435245243523452345
>                     IN KIDNS 5222 23452345435234545
> ) -- basically, have the records for foo.example.com (or just exmaple.com)
> all at the same level, but have the ports included in the response.

Or allow multiple ports per entry (and also "all ports"?). Multi-port
responses could be useful for example for covering webserver supporting
upgrades (TCP80/TCP433) or SMTP server supporting upgrades
(TCP25/TCP465/TCP587).

Oh, and sometimes TCP X and UDP X are not the same service (usually those
are). But I think all cases are some legacy services that aren't going
to support KIDNS anyway... So just going by port number and forgetting
the proto is likely feasible...

Designing wire format for that is not difficult. Getting sane master
format notation might be...

Also, this doesn't solve the service leakage issues.

> > 
> > Or both, preferring the more specific if both exist?
> 
> Oooh, that's interesting -- to be honest I hadn't thought of that...
>
> One huge consideration is minimizing the number of DNS lookups needed
> to make all the magic happen -- if this system requires lots of
> lookups, the browser folk will be unwilling to implement as the user
> experience will be horrendous....

What's the likely amount of stuff in those _<serv>._<prot>.<domain>
spaces? Little enough to make issuing QCLASS * requests feasible?

Being able to QCLASS * it could also get other possibly usable
stuff (like secure service discovery[1] data, but that's a seperate
topic...)

[1] Inform client that secure service exists and how to connect to
it. 

-Ilari

From: Warren Kumari <[email-masked]>
Date: Sat, 30 Oct 2010 21:18:53 -0400
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

[ Replying to myself ]=20

Apologies to the list, I have just reinstalled a machine for bringing to =
the meeting and forgot to turn off the "Rich Text with Random Markups =
and Embedded Garbage" knob in my MUA before replying...

While on the topic of list etiquette and similar things, I just wanted =
to thank everyone for playing nicely on this thread -- I feel that we =
are beginning to make progress again and are (hopefully) starting to see =
each others points again...

W=20

On Oct 30, 2010, at 9:02 PM, Warren Kumari wrote:
>=20
> On Oct 30, 2010, at 8:07 PM, James Cloos wrote:
>=20
>>>>>>> "MM" =3D=3D Matt McCutchen <[email-masked]> writes:
>>=20
>> MM> Yes, I think it is cleanest to treat DNSSEC as a black box that
>> MM> produces one of the four security states and build from there.
>> MM> Here is some proposed text for Section 3. ...
>>=20
>> That seems to sum up what I'd like to see from KIDNS:  the =
possibility
>> of using dnssec as one's only trust anchor and also the ability to
>> slowly transition from current practice.  Clients will need to do the
>> latter anyway; any KIDNS standard should cover that explicitly.  And
>> the former is a big win, long term, over the status quo.
>>=20
>> The only possible issue is the question of whether the client should
>> perform queries for names like www.example.com. or =
_http._tcp.www.example.com.?
>=20
> This is another question that has been repeatedly raised (partly in =
the guise of "if you post a record for your webserver it will break =
mail").
> I (no hats) was against the _selector_ idea as I feel that all records =
related to a thingie (technical term) should exist at the same level (
>=20
> foo.example.com         IN   A     192.0.2.1
> 		        IN   BAR     42
>                         IN   KIDNS  54690765349763590
> ), but this is an elegance viewpoint and enough folk have pointed out =
that this is a needed feature that I'm open to it as an idea....
>=20
> Another option (which has some (IMO) of the elegance retained, but =
probably has scalability and leakage issues) is=20
> foo.example.com     IN A 192.0.2.1
>                     IN KIDNS 443 545254634563546354
>                     IN KIDNS 993 435245243523452345
>                     IN KIDNS 5222 23452345435234545
> ) -- basically, have the records for foo.example.com (or just =
exmaple.com) all at the same level, but have the ports included in the =
response.
>=20
>>=20
>> Or both, preferring the more specific if both exist?
>=20
> Oooh, that's interesting -- to be honest I hadn't thought of that... =
One huge consideration is minimizing the number of DNS lookups needed to =
make all the magic happen -- if this system requires lots of lookups, =
the browser folk will be unwilling to implement as the user experience =
will be horrendous....
>=20
>>=20
>> The more specifc option permits different certs for, eg, _http._tcp
>> vs _smtp._tcp vs _sip._tcp, but also means maintaining probably
>> identical RRs for eg _sip._tcp, _sip._udp and _sip._sctp.
>>=20
>> I can see how each might be perceived as necessary, but also how each
>> might be perceived as undesirable.
>=20
> Yes, both are (IMO) sub-optimal -- my *personal* view of the world =
involves having unique names for each service (www.example.com, =
imap.exmaple.com, jabber.example.com) which sidesteps this issue, but =
enough folk have raised this issue that it needs to be addressed....
>=20
> As for exactly how (ports in the response, selectors, something else), =
that is something that we (with input from DNS folk) need to discuss and =
come to agreement on....
>=20
> W=20
>=20
>=20
>>=20
>> (Incidently, in the more-specific case, would the CA for a given =
RHS's
>> smime certs be sought at _smime.example.org. or =
_smime._???.example.org?)
>>=20
>> -JimC
>> --=20
>> James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>=20
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Warren Kumari <[email-masked]>
Date: Sat, 30 Oct 2010 21:02:20 -0400
To: James Cloos <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

--Apple-Mail-1-942094901
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Oct 30, 2010, at 8:07 PM, James Cloos wrote:

>>>>>> "MM" =3D=3D Matt McCutchen <[email-masked]> writes:
>=20
> MM> Yes, I think it is cleanest to treat DNSSEC as a black box that
> MM> produces one of the four security states and build from there.
> MM> Here is some proposed text for Section 3. ...
>=20
> That seems to sum up what I'd like to see from KIDNS:  the possibility
> of using dnssec as one's only trust anchor and also the ability to
> slowly transition from current practice.  Clients will need to do the
> latter anyway; any KIDNS standard should cover that explicitly.  And
> the former is a big win, long term, over the status quo.
>=20
> The only possible issue is the question of whether the client should
> perform queries for names like www.example.com. or =
_http._tcp.www.example.com.?

This is another question that has been repeatedly raised (partly in the =
guise of "if you post a record for your webserver it will break mail").
I (no hats) was against the _selector_ idea as I feel that all records =
related to a thingie (technical term) should exist at the same level (

foo.example.com         IN   A     192.0.2.1
		        IN   BAR     42
                        IN   KIDNS  54690765349763590
), but this is an elegance viewpoint and enough folk have pointed out =
that this is a needed feature that I'm open to it as an idea....

Another option (which has some (IMO) of the elegance retained, but =
probably has scalability and leakage issues) is=20
foo.example.com     IN A 192.0.2.1
                    IN KIDNS 443 545254634563546354
                    IN KIDNS 993 435245243523452345
                    IN KIDNS 5222 23452345435234545
) -- basically, have the records for foo.example.com (or just =
exmaple.com) all at the same level, but have the ports included in the =
response.

>=20
> Or both, preferring the more specific if both exist?

Oooh, that's interesting -- to be honest I hadn't thought of that... One =
huge consideration is minimizing the number of DNS lookups needed to =
make all the magic happen -- if this system requires lots of lookups, =
the browser folk will be unwilling to implement as the user experience =
will be horrendous....

>=20
> The more specifc option permits different certs for, eg, _http._tcp
> vs _smtp._tcp vs _sip._tcp, but also means maintaining probably
> identical RRs for eg _sip._tcp, _sip._udp and _sip._sctp.
>=20
> I can see how each might be perceived as necessary, but also how each
> might be perceived as undesirable.

Yes, both are (IMO) sub-optimal -- my *personal* view of the world =
involves having unique names for each service (www.example.com, =
imap.exmaple.com, jabber.example.com) which sidesteps this issue, but =
enough folk have raised this issue that it needs to be addressed....

As for exactly how (ports in the response, selectors, something else), =
that is something that we (with input from DNS folk) need to discuss and =
come to agreement on....

W=20

>=20
> (Incidently, in the more-specific case, would the CA for a given RHS's
> smime certs be sought at _smime.example.org. or =
_smime._???.example.org?)
>=20
> -JimC
> --=20
> James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

--Apple-Mail-1-942094901
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><font =
class=3D"Apple-style-span" face=3D"'Courier =
New'"><br></font><div><div><font class=3D"Apple-style-span" =
face=3D"'Courier New'">On Oct 30, 2010, at 8:07 PM, James Cloos =
wrote:</font></div><font class=3D"Apple-style-span" face=3D"'Courier =
New'"><br class=3D"Apple-interchange-newline"></font><blockquote =
type=3D"cite"><div><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"><font class=3D"Apple-style-span" =
face=3D"'Courier New'">"MM" =3D=3D Matt McCutchen &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
writes:<br></font></blockquote></blockquote></blockquote></blockquote></bl=
ockquote><font class=3D"Apple-style-span" face=3D"'Courier =
New'"><br>MM&gt; Yes, I think it is cleanest to treat DNSSEC as a black =
box that<br>MM&gt; produces one of the four security states and build =
from there.<br>MM&gt; Here is some proposed text for Section 3. =
...<br><br>That seems to sum up what I'd like to see from KIDNS: =
&nbsp;the possibility<br>of using dnssec as one's only trust anchor and =
also the ability to<br>slowly transition from current practice. =
&nbsp;Clients will need to do the<br>latter anyway; any KIDNS standard =
should cover that explicitly. &nbsp;And<br>the former is a big win, long =
term, over the status quo.<br><br>The only possible issue is the =
question of whether the client should<br>perform queries for names like =
<a href=3D"http://www.example.com">www.example.com</a>. or =
_http._tcp.www.example.com.?<br></font></div></blockquote><div><font =
class=3D"Apple-style-span" face=3D"'Courier =
New'"><br></font></div><div><font class=3D"Apple-style-span" =
face=3D"'Courier New'">This is another question that has been repeatedly =
raised (partly in the guise of "if you post a record for your webserver =
it will break mail").</font></div><div><font class=3D"Apple-style-span" =
face=3D"'Courier New'">I (no hats) was against the _selector_ idea as I =
feel that all records related to a thingie (technical term) should exist =
at the same level (</font></div><div><font class=3D"Apple-style-span" =
face=3D"'Courier New'"><br></font></div><div><font =
class=3D"Apple-style-span" face=3D"'Courier New'"><a =
href=3D"http://foo.example.com">foo.example.com</a> &nbsp; &nbsp; &nbsp; =
&nbsp; IN &nbsp; A &nbsp; &nbsp; 192.0.2.1</font></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre"><font =
class=3D"Apple-style-span" face=3D"'Courier New'">		        =
</font></span><font class=3D"Apple-style-span" face=3D"'Courier New'">IN =
&nbsp; BAR &nbsp; &nbsp; 42</font></div><div><font =
class=3D"Apple-style-span" face=3D"'Courier New'">&nbsp;&nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;IN =
&nbsp; KIDNS &nbsp;54690765349763590</font></div><div><font =
class=3D"Apple-style-span" face=3D"'Courier New'">), but this is an =
elegance viewpoint and enough folk have pointed out that this is a =
needed feature that I'm open to it as an idea....</font></div><div><font =
class=3D"Apple-style-span" face=3D"'Courier =
New'"><br></font></div><div><font class=3D"Apple-style-span" =
face=3D"'Courier New'">Another option (which has some (IMO) of the =
elegance retained, but probably has scalability and leakage issues) =
is&nbsp;</font></div><div><font class=3D"Apple-style-span" =
face=3D"'Courier New'"><a =
href=3D"http://foo.example.com">foo.example.com</a> &nbsp; &nbsp; IN A =
192.0.2.1</font></div><div><font class=3D"Apple-style-span" =
face=3D"'Courier New'">&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp;IN KIDNS 443 =
545254634563546354</font></div><div><font class=3D"Apple-style-span" =
face=3D"'Courier New'">&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp;IN KIDNS 993 =
435245243523452345</font></div><div><font class=3D"Apple-style-span" =
face=3D"'Courier New'">&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp;IN KIDNS 5222 =
23452345435234545</font></div><div><font class=3D"Apple-style-span" =
face=3D"'Courier New'">) -- basically, have the records for <a =
href=3D"http://foo.example.com">foo.example.com</a> (or just <a =
href=3D"http://exmaple.com">exmaple.com</a>) all at the same level, but =
have the ports included in the response.</font></div><font =
class=3D"Apple-style-span" face=3D"'Courier New'"><br></font><blockquote =
type=3D"cite"><div><font class=3D"Apple-style-span" face=3D"'Courier =
New'"><br>Or both, preferring the more specific if both =
exist?<br></font></div></blockquote><div><br></div><div>Oooh, that's =
interesting -- to be honest I hadn't thought of that... One huge =
consideration is minimizing the number of DNS lookups needed to make all =
the magic happen -- if this system requires lots of lookups, the browser =
folk will be unwilling to implement as the user experience will be =
horrendous....</div><br><blockquote type=3D"cite"><div><font =
class=3D"Apple-style-span" face=3D"'Courier New'"><br>The more specifc =
option permits different certs for, eg, _http._tcp<br>vs _smtp._tcp vs =
_sip._tcp, but also means maintaining probably<br>identical RRs for eg =
_sip._tcp, _sip._udp and _sip._sctp.<br><br>I can see how each might be =
perceived as necessary, but also how each<br>might be perceived as =
undesirable.<br></font></div></blockquote><div><br></div><div>Yes, both =
are (IMO) sub-optimal -- my *personal* view of the world involves having =
unique names for each service (<a =
href=3D"http://www.example.com">www.example.com</a>, <a =
href=3D"http://imap.exmaple.com">imap.exmaple.com</a>, <a =
href=3D"http://jabber.example.com">jabber.example.com</a>) which =
sidesteps this issue, but enough folk have raised this issue that it =
needs to be addressed....</div><div><br></div><div>As for exactly how =
(ports in the response, selectors, something else), that is something =
that we (with input from DNS folk) need to discuss and come to agreement =
on....</div><div><br></div><div>W&nbsp;</div><div><br></div><br><blockquot=
e type=3D"cite"><div><font class=3D"Apple-style-span" face=3D"'Courier =
New'"><br>(Incidently, in the more-specific case, would the CA for a =
given RHS's<br>smime certs be sought at _smime.example.org. or =
_smime._???.example.org?)<br><br>-JimC<br>-- <br>James Cloos &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;OpenPGP: =
1024D/ED7DAEA6<br>_______________________________________________<br>keyas=
sure mailing list<br><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>https://www.i=
etf.org/mailman/listinfo/keyassure<br></font></div></blockquote></div><br>=
</body></html>=

--Apple-Mail-1-942094901--

Date: Sun, 31 Oct 2010 03:01:46 +0200
From: Ilari Liusvaara <[email-masked]>
To: James Cloos <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: Steve Schultze <[email-masked]>, [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Sat, Oct 30, 2010 at 08:07:18PM -0400, James Cloos wrote:
> >>>>> "MM" == Matt McCutchen <[email-masked]> writes:
> 
> MM> Yes, I think it is cleanest to treat DNSSEC as a black box that
> MM> produces one of the four security states and build from there.
> MM> Here is some proposed text for Section 3. ...
> 
> 
> The only possible issue is the question of whether the client should
> perform queries for names like www.example.com. or _http._tcp.www.example.com.?
> 
> Or both, preferring the more specific if both exist?

If the lookups are done after resolving indirection by SRV, one could
get along with optional port numbers and protocols (as in, UDP, TCP,
SCTP...).

Basically, a way to limit some TLSFP record to just some (protocol,port)
pairs and then the client would remove the entries that have wrong ports
just like entries that have unknown hash function.

This would also allow the "assure SMTP but not yet HTTP" case (by putting
an entry that covers just the SMTP ports)...

But of course that plan wouldn't work as-is if TLSFP lookups would have
to be done before SRV for some reason...

-Ilari

From: Warren Kumari <[email-masked]>
Date: Sat, 30 Oct 2010 20:30:02 -0400
To: Steve Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Oct 30, 2010, at 11:05 AM, Steve Schultze wrote:

> Ben, I'm porting your comment below into this thread for the sake of =
subject-line clarity (none of this is WG-formation specific, I believe).
>=20
> On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote:
>> Paul wants client policy to decide whether to trust PKIX, DNSSEC or
>> some mixture of the two. This seems not only reasonable, but
>> unavoidable: clients will implement what suits them, and we are in no
>> position to change that.
>>=20
>> Phillip wants the domain in question to be able to state its
>> intentions w.r.t. the policy clients should use. This seems not
>> unreasonable, also. Clients can choose to follow this or not.
>=20
> What effect does this have on the MUST vs. MAY suggestions I made to =
the draft-hoffman-keys-linkage-from-dns-03 text?  I believe that what =
you are saying is that the spec should leave it open to the client how =
to react to different validation outcome permutations from PKIX and =
DNSSEC-secured KIDNS.  In that case, the two excerpts I quoted should be =
MAY, as I suggested.  This also means that I disagree with Paul, who =
thinks that MUST should be used.
>=20
> I would note that, presuming KIDNS only affects client behavior when =
the client can directly verify that the records were validly =
DNSSEC-signed (is this everybody's assumption?), using a MUST creates a =
downgrade attack in which a MITM can force PKIX-only validation by =
simply blocking DNSSEC-validated DNS results.

Actually, a MITM who is blocking DNSSEC-validated DNS results is =
detectable and (IMO) evidence that Something Bad(tm) is happening, and =
that you should take your ball and go home....=20

Also, not quite sure that this is the best place to bring this up (but I =
couldn't find a better place in the thread), but the "client can =
directly verify that records were validly DNSSEC-signed" has some =
subtleties -- there are three options (although I could have forgotten =
some):

1: The client just blindly trusts the AD bit (a bit set by the recursive =
resolver to say (basically) "I have done the DNSSEC verification magic =
and this is all authenticated data, trust me...."). I'm assuming that =
everyone here agrees that this is a horrendous idea.

2: The client performs all of the DNSSEC verification itself -- I'm =
assuming again that everyone here agrees that (from a security =
standpoint) this is good.

3: The client trusts a response with the AD bit set but ONLY if it has =
received this response over some sort of "secure" channel that provides =
authentication of the transport and validation that you are talking to =
the correct recursive resolver, and the client has some reason to trust =
the resolver. An example of this would be a VPN (or SIG(0)) to a =
corporate or contracted resolver operator. To me, while still much much =
better than option 1, it is not actually a *good* idea -- I would like =
to know what the list thinks though....

W

>=20
> "If the application receives zero usable certificate associations, it =
[MUST] process TLS in the normal fashion."
>=20
> We want the client to be able to choose to require DNSSEC-validated =
KIDNS for all requests, if it wishes.  Otherwise what we're doing offers =
no greater security than the status quo.
>=20
> On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote:
>> Thank you for being explicit!
>>=20
>> At 10:14 PM +0100 10/28/10, Stephen Farrell wrote:
>>> Having now caught up with the many recent messages, I'd also
>>> be a bit concerned about the impact of:
>>>=20
>>>> "If a match between the certificate association(s) and the
>>>> server's end entity certificate in TLS is not found, the
>>>> TLS client MUST abort the handshake with an "access_denied" error."
>>>=20
>>> The concerns I have about it would include:
>>>=20
>>> - I'm not really sure if that same rule would be appropriate
>>> for all applications that use TLS, nor for all deployments
>>> of each protocol using TLS - basically the policy slippery
>>> slope PHB is raising (from time to time:-)
>>=20
>> OK, maybe try being more explicit. For example, if this document was =
in fact an update to TLS, would you have the same concern? Or, if you =
want a SHOULD rather than a MUST, what would the specific exceptions be =
(or are you asking for a typical IETF mushy SHOULD)?
>=20
> I don't know what Stephen Farrell is arguing for, but I'm arguing for =
an even more mushy MAY ;)
>=20
> However, this is a feature because it gives the clients more =
options... including the option to improve upon the status quo of PKIX =
security even in the presence of a MITM (our assumed threat model).  It =
does so without forcing all clients to do this on day one, an =
impractical requirement.
>=20
> On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote:
>> "If the application receives zero usable certificate associations, it =
process TLS in the normal fashion."
>> "If a match between the certificate association(s) and the server's =
end entity certificate in TLS is not found, the TLS client MUST abort =
the handshake with an "access_denied" error."
>>=20
>> I suggest:
>>=20
>> "If the application receives zero usable certificate associations, it =
MAY process TLS in the normal fashion."
>> "If a match between the certificate association(s) and the server's =
end entity certificate in TLS is not found, the TLS client MAY abort the =
handshake with an "access_denied" error."
>=20
>=20
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Warren Kumari <[email-masked]>
Date: Sat, 30 Oct 2010 20:28:52 -0400
To: Steve Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Oct 30, 2010, at 11:05 AM, Steve Schultze wrote:

> Ben, I'm porting your comment below into this thread for the sake of =
subject-line clarity (none of this is WG-formation specific, I believe).
>=20
> On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote:
>> Paul wants client policy to decide whether to trust PKIX, DNSSEC or
>> some mixture of the two. This seems not only reasonable, but
>> unavoidable: clients will implement what suits them, and we are in no
>> position to change that.
>>=20
>> Phillip wants the domain in question to be able to state its
>> intentions w.r.t. the policy clients should use. This seems not
>> unreasonable, also. Clients can choose to follow this or not.
>=20
> What effect does this have on the MUST vs. MAY suggestions I made to =
the draft-hoffman-keys-linkage-from-dns-03 text?  I believe that what =
you are saying is that the spec should leave it open to the client how =
to react to different validation outcome permutations from PKIX and =
DNSSEC-secured KIDNS.  In that case, the two excerpts I quoted should be =
MAY, as I suggested.  This also means that I disagree with Paul, who =
thinks that MUST should be used.
>=20
> I would note that, presuming KIDNS only affects client behavior when =
the client can directly verify that the records were validly =
DNSSEC-signed (is this everybody's assumption?), using a MUST creates a =
downgrade attack in which a MITM can force PKIX-only validation by =
simply blocking DNSSEC-validated DNS results.

Actually, a MITM who is blocking DNSSEC-validated DNS results is =
detectable and (IMO) evidence that Something Bad(tm) is happening, and =
that you should take your ball and go home....=20

Also, not quite sure that this is the best place to bring this up (but I =
couldn't find a better place in the thread), but the "client can =
directly verify that records were validly DNSSEC-signed" has some =
subtleties -- there are three options (although I could have forgotten =
some):

1: The client just blindly trusts the AD bit (a bit set by the recursive =
resolver to say (basically) "I have done the DNSSEC verification magic =
and this is all authenticated data, trust me...."). I'm assuming that =
everyone here agrees that this is a horrendous idea.

2: The client performs all of the DNSSEC verification itself -- I'm =
assuming again that everyone here agrees that (from a security =
standpoint) this is good.

3: The client trusts a response with the AD bit set but ONLY if it has =
received this response over some sort of "secure" channel that provides =
authentication of the transport and validation that you are talking to =
the correct recursive resolver, and the client has some reason to trust =
the resolver. An example of this would be a VPN (or SIG(0)) to a =
corporate or contracted resolver operator. To me, while still much much =
better than option 1, it is not actually a *good* idea -- I would like =
to know what the list thinks though....

W

>=20
> "If the application receives zero usable certificate associations, it =
[MUST] process TLS in the normal fashion."
>=20
> We want the client to be able to choose to require DNSSEC-validated =
KIDNS for all requests, if it wishes.  Otherwise what we're doing offers =
no greater security than the status quo.
>=20
> On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote:
>> Thank you for being explicit!
>>=20
>> At 10:14 PM +0100 10/28/10, Stephen Farrell wrote:
>>> Having now caught up with the many recent messages, I'd also
>>> be a bit concerned about the impact of:
>>>=20
>>>> "If a match between the certificate association(s) and the
>>>> server's end entity certificate in TLS is not found, the
>>>> TLS client MUST abort the handshake with an "access_denied" error."
>>>=20
>>> The concerns I have about it would include:
>>>=20
>>> - I'm not really sure if that same rule would be appropriate
>>> for all applications that use TLS, nor for all deployments
>>> of each protocol using TLS - basically the policy slippery
>>> slope PHB is raising (from time to time:-)
>>=20
>> OK, maybe try being more explicit. For example, if this document was =
in fact an update to TLS, would you have the same concern? Or, if you =
want a SHOULD rather than a MUST, what would the specific exceptions be =
(or are you asking for a typical IETF mushy SHOULD)?
>=20
> I don't know what Stephen Farrell is arguing for, but I'm arguing for =
an even more mushy MAY ;)
>=20
> However, this is a feature because it gives the clients more =
options... including the option to improve upon the status quo of PKIX =
security even in the presence of a MITM (our assumed threat model).  It =
does so without forcing all clients to do this on day one, an =
impractical requirement.
>=20
> On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote:
>> "If the application receives zero usable certificate associations, it =
process TLS in the normal fashion."
>> "If a match between the certificate association(s) and the server's =
end entity certificate in TLS is not found, the TLS client MUST abort =
the handshake with an "access_denied" error."
>>=20
>> I suggest:
>>=20
>> "If the application receives zero usable certificate associations, it =
MAY process TLS in the normal fashion."
>> "If a match between the certificate association(s) and the server's =
end entity certificate in TLS is not found, the TLS client MAY abort the =
handshake with an "access_denied" error."
>=20
>=20
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: James Cloos <[email-masked]>
To: [email-masked]
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
Copyright: Copyright 2009 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Sat, 30 Oct 2010 20:07:18 -0400
Lines: 30
Cc: Steve Schultze <[email-masked]>
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

>>>>> "MM" == Matt McCutchen <[email-masked]> writes:

MM> Yes, I think it is cleanest to treat DNSSEC as a black box that
MM> produces one of the four security states and build from there.
MM> Here is some proposed text for Section 3. ...

That seems to sum up what I'd like to see from KIDNS:  the possibility
of using dnssec as one's only trust anchor and also the ability to
slowly transition from current practice.  Clients will need to do the
latter anyway; any KIDNS standard should cover that explicitly.  And
the former is a big win, long term, over the status quo.

The only possible issue is the question of whether the client should
perform queries for names like www.example.com. or _http._tcp.www.example.com.?

Or both, preferring the more specific if both exist?

The more specifc option permits different certs for, eg, _http._tcp
vs _smtp._tcp vs _sip._tcp, but also means maintaining probably
identical RRs for eg _sip._tcp, _sip._udp and _sip._sctp.

I can see how each might be perceived as necessary, but also how each
might be perceived as undesirable.

(Incidently, in the more-specific case, would the CA for a given RHS's
smime certs be sought at _smime.example.org. or _smime._???.example.org?)

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

Date: Sun, 31 Oct 2010 02:22:02 +0300
From: Ilari Liusvaara <[email-masked]>
To: Matt McCutchen <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: Steve Schultze <[email-masked]>, [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Sat, Oct 30, 2010 at 06:23:23PM -0400, Matt McCutchen wrote:
> On Sat, 2010-10-30 at 16:39 -0400, Steve Schultze wrote:
> 
> If any query cannot be completed or gives a "bogus" result as described
> in RFC 4033 section 5, validation MUST fail and the client MUST abort
> the TLS handshake (if it has been started) with a "TBD" error.
> Otherwise, if any query gives an "insecure" or "indeterminate" result,
> KIDNS cannot be used with this TLS server, and the client MAY use an
> alternative certificate validation method.

Looking at the list of error codes, the only ones that I think could apply
would be codes 80(internal_error) and 90(user_canceled).

-Ilari

From: Matt McCutchen <[email-masked]>
To: Steve Schultze <[email-masked]>
Date: Sat, 30 Oct 2010 18:23:23 -0400
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Sat, 2010-10-30 at 16:39 -0400, Steve Schultze wrote:
> What the current draft does not say is what the client MUST or MAY do
> if the client is not able to request, perform, or verify DNSSEC
> validation at all.  The answer will affect the viability of my MITM
> scenario.

Yes, I think it is cleanest to treat DNSSEC as a black box that produces
one of the four security states and build from there.  Here is some
proposed text for Section 3.

-----
To validate the certificate of a TLS server using KIDNS, the client
SHALL perform a DNSSEC query for TLSFP and TLSRQ records at the domain
name of the TLS server.  If a TLSRQ record is returned, the client SHALL
perform a second query based on the certificate actually presented by
the TLS server as described in section 2.2.

If any query cannot be completed or gives a "bogus" result as described
in RFC 4033 section 5, validation MUST fail and the client MUST abort
the TLS handshake (if it has been started) with a "TBD" error.
Otherwise, if any query gives an "insecure" or "indeterminate" result,
KIDNS cannot be used with this TLS server, and the client MAY use an
alternative certificate validation method.

In the remaining case, all queries have given "secure" results.  The
client collects all TLSFP records from the initial query and the second
query if applicable and discards any whose hash types it does not
understand.  If no records remain, KIDNS does not apply and the client
MAY use an alternative method.  Otherwise, if the certificate presented
by the server matches any of the TLSFP records, validation succeeds; if
not, it fails and the client MUST abort the TLS handshake with an
"unknown_ca" error.
-----

Note, I think the proper error when the certificate doesn't match any of
the TLSFP records is "unknown_ca", by analogy to a certificate that
doesn't chain to any PKIX trust anchor.  Based on the description in RFC
5246, I think "access_denied" is for a server to tell a properly
authenticated client that authorization to use the service is denied.

I'm not sure what would be the best error for when the DNSSEC query
fails.

This is still assuming TLSFP is exclusive.  If that were made a flag,
then we would just change the last case (presented certificate doesn't
match any TLSFP) to fall back to the alternative method if the flag is
off.

-- 
Matt

Date: Sat, 30 Oct 2010 15:54:15 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and	draft-hoffman-keys-linkage-from-dns
Reply-To: "Jeffrey A. Williams" <[email-masked]>

<HEAD>
<STYLE>body{font-size:10pt;font-family:arial,sans-serif;background-color:#ffffff;color:black;}p{margin:0px;}</STYLE>

<META name=GENERATOR content="MSHTML 8.00.6001.18975"></HEAD>
<BODY><BR><BR><BR>
<BLOCKQUOTE style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 0px">-----Original Message----- <BR>From: Steve Schultze <[email-masked]><BR>Sent: Oct 30, 2010 3:39 PM <BR>To: [email-masked] <BR>Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns <BR><BR><ZZZHTML><ZZZHEAD></ZZZHEAD><ZZZBODY style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space"><BR>
<DIV>
<DIV>On Oct 30, 2010, at 4:13 PM, Matt McCutchen wrote:</DIV>
<BLOCKQUOTE type="cite">
<DIV>
<BLOCKQUOTE type="cite">Ok, and I am suggesting the client should be allowed to do that in our<BR></BLOCKQUOTE>
<BLOCKQUOTE type="cite">spec. &nbsp;In the language of RFC 4033, it seems that the client would<BR></BLOCKQUOTE>
<BLOCKQUOTE type="cite">require &nbsp;"secure" state plus a valid KIDNS record.<BR></BLOCKQUOTE><BR>Right.<FONT class=Apple-style-span color=#006312><FONT class=Apple-style-span color=#144fae><BR></FONT></FONT><BR>Or a "secure" denial of existence of an exclusive KIDNS record. &nbsp;Signed<BR>zones don't necessarily use exclusive KIDNS. &nbsp;People would be up in arms<BR>if signing their zone suddenly broke all their TLS servers.<BR></DIV></BLOCKQUOTE>
<DIV><BR></DIV>Right.</DIV>
<DIV><BR>
<BLOCKQUOTE type="cite">
<DIV>
<BLOCKQUOTE type="cite">They might also allow an "insecure" state plus a validating PKIX cert.<BR></BLOCKQUOTE><BR>Right, that is the idea for a backward-compatible client. &nbsp;"Secure"<BR>zones that opt in to exclusive KIDNS get the presumed security benefits,<BR>everyone else's traditional PKIX certificates continue to work.<BR></DIV></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Right.</DIV><BR>
<BLOCKQUOTE type="cite">
<DIV>
<BLOCKQUOTE type="cite">The vulnerability would only manifest itself if the client allowed<BR></BLOCKQUOTE>
<BLOCKQUOTE type="cite">"indeterminate" state and a validating PKIX cert.<BR></BLOCKQUOTE><BR>As I read it, "indeterminate" means the zone is not within the scope of<BR>any of the configured trust anchors. &nbsp;This is basically equivalent to<BR>"insecure": in both cases, the client knows that, with respect to its<BR>trust anchor configuration, the zone is not signed. &nbsp;This condition<BR>cannot be faked by a MITM attacker.<BR></DIV></BLOCKQUOTE>
<DIV>Right,</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp; Unless the trust anchor was the culprit OR the Trust anchor had itself been compermised in some</DIV>
<DIV>way, and/or the CA Cert Database had been corrupted accordingly.<BR></DIV>
<DIV>Yes, "indeterminate" == "insecure" if the client requires DNSSEC validation. But that would require a MUST NOT in place of the current (implied) MUST in&nbsp;draft-hoffman-keys-linkage-from-dns:</DIV>
<DIV><BR></DIV>
<DIV>
<DIV>"If the application receives zero usable certificate associations, it [MUST] process TLS in the normal fashion."</DIV></DIV>
<DIV><BR></DIV>
<DIV>...or maybe that's not actually the right place because it presumes that the response is already validated by DNSSEC:</DIV>
<DIV><BR></DIV>
<DIV>"The DNSSEC signature MUST be validated on all responses in order to assure the proof of origin of the data."</DIV>
<DIV><BR></DIV>
<DIV>What the current draft does not say is what the client MUST or MAY do if the client is not able to request, perform, or verify DNSSEC validation at all. &nbsp;The answer will affect the viability of my MITM scenario.</DIV><BR>
<BLOCKQUOTE type="cite">
<DIV>DNSSEC guarantees that if the client queries a zone that is signed (with<BR>respect to its trust anchor configuration), it either gets an<BR>authenticated answer or fails. &nbsp;We can build upon this property to<BR>distribute KIDNS info in signed zones and know that KIDNS-aware clients<BR>will not proceed without it.&nbsp;</DIV></BLOCKQUOTE><BR></DIV>
<DIV>It's not clear to me, at least in the&nbsp;draft-hoffman-keys-linkage-from-dns draft, that we can "know that KIDNS-aware clients</DIV>
<DIV>will not proceed without it."&nbsp;&nbsp;I don't see any explicit statement to this effect. &nbsp;I encourage Paul or the others to chime in as to whether this was their intent.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp; Good point and I agree.&nbsp; Diliniating the intent is important here.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Jeffrey A. Williams<BR>"Obedience of the law is the greatest freedom" -<BR>&nbsp;&nbsp; Abraham Lincoln<BR><BR>"Credit should go with the performance of duty and not with what is very<BR>often the accident of glory" - Theodore Roosevelt<BR><BR>"If the probability be called P; the injury, L; and the burden, B; liability<BR>depends upon whether B is less than L multiplied by<BR>P: i.e., whether B is less than PL."<BR>United States v. Carroll Towing&nbsp; (159 F.2d 169 [2d Cir. 1947]<BR>===============================================================<BR>Updated 1/26/04<BR>Network Eng. SR. Eng. Network data security<BR>ABA member in good standing member ID 01257402 <BR>E-Mail [email-masked]<BR>Phone: 214-244-4827<BR><BR></DIV><BR></ZZZBODY></ZZZHTML></BLOCKQUOTE></BODY>

From: Steve Schultze <[email-masked]>
Date: Sat, 30 Oct 2010 16:39:24 -0400
To: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

--Apple-Mail-2-926319224
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Oct 30, 2010, at 4:13 PM, Matt McCutchen wrote:
>> Ok, and I am suggesting the client should be allowed to do that in =
our
>> spec.  In the language of RFC 4033, it seems that the client would
>> require  "secure" state plus a valid KIDNS record.
>=20
> Right.
>=20
> Or a "secure" denial of existence of an exclusive KIDNS record.  =
Signed
> zones don't necessarily use exclusive KIDNS.  People would be up in =
arms
> if signing their zone suddenly broke all their TLS servers.

Right.

>> They might also allow an "insecure" state plus a validating PKIX =
cert.
>=20
> Right, that is the idea for a backward-compatible client.  "Secure"
> zones that opt in to exclusive KIDNS get the presumed security =
benefits,
> everyone else's traditional PKIX certificates continue to work.

Right.

>> The vulnerability would only manifest itself if the client allowed
>> "indeterminate" state and a validating PKIX cert.
>=20
> As I read it, "indeterminate" means the zone is not within the scope =
of
> any of the configured trust anchors.  This is basically equivalent to
> "insecure": in both cases, the client knows that, with respect to its
> trust anchor configuration, the zone is not signed.  This condition
> cannot be faked by a MITM attacker.

Yes, "indeterminate" =3D=3D "insecure" if the client requires DNSSEC =
validation. But that would require a MUST NOT in place of the current =
(implied) MUST in draft-hoffman-keys-linkage-from-dns:

"If the application receives zero usable certificate associations, it =
[MUST] process TLS in the normal fashion."

...or maybe that's not actually the right place because it presumes that =
the response is already validated by DNSSEC:

"The DNSSEC signature MUST be validated on all responses in order to =
assure the proof of origin of the data."

What the current draft does not say is what the client MUST or MAY do if =
the client is not able to request, perform, or verify DNSSEC validation =
at all.  The answer will affect the viability of my MITM scenario.

> DNSSEC guarantees that if the client queries a zone that is signed =
(with
> respect to its trust anchor configuration), it either gets an
> authenticated answer or fails.  We can build upon this property to
> distribute KIDNS info in signed zones and know that KIDNS-aware =
clients
> will not proceed without it.=20

It's not clear to me, at least in the =
draft-hoffman-keys-linkage-from-dns draft, that we can "know that =
KIDNS-aware clients
will not proceed without it."  I don't see any explicit statement to =
this effect.  I encourage Paul or the others to chime in as to whether =
this was their intent.

--Apple-Mail-2-926319224
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Oct 30, 2010, at 4:13 PM, Matt McCutchen =
wrote:</div><blockquote type=3D"cite"><div><blockquote type=3D"cite">Ok, =
and I am suggesting the client should be allowed to do that in =
our<br></blockquote><blockquote type=3D"cite">spec. &nbsp;In the =
language of RFC 4033, it seems that the client =
would<br></blockquote><blockquote type=3D"cite">require &nbsp;"secure" =
state plus a valid KIDNS record.<br></blockquote><br>Right.<font =
class=3D"Apple-style-span" color=3D"#006312"><font =
class=3D"Apple-style-span" color=3D"#144FAE"><br></font></font><br>Or a =
"secure" denial of existence of an exclusive KIDNS record. =
&nbsp;Signed<br>zones don't necessarily use exclusive KIDNS. =
&nbsp;People would be up in arms<br>if signing their zone suddenly broke =
all their TLS =
servers.<br></div></blockquote><div><br></div>Right.</div><div><br><blockq=
uote type=3D"cite"><div><blockquote type=3D"cite">They might also allow =
an "insecure" state plus a validating PKIX =
cert.<br></blockquote><br>Right, that is the idea for a =
backward-compatible client. &nbsp;"Secure"<br>zones that opt in to =
exclusive KIDNS get the presumed security benefits,<br>everyone else's =
traditional PKIX certificates continue to =
work.<br></div></blockquote><div><br></div><div>Right.</div><br><blockquot=
e type=3D"cite"><div><blockquote type=3D"cite">The vulnerability would =
only manifest itself if the client allowed<br></blockquote><blockquote =
type=3D"cite">"indeterminate" state and a validating PKIX =
cert.<br></blockquote><br>As I read it, "indeterminate" means the zone =
is not within the scope of<br>any of the configured trust anchors. =
&nbsp;This is basically equivalent to<br>"insecure": in both cases, the =
client knows that, with respect to its<br>trust anchor configuration, =
the zone is not signed. &nbsp;This condition<br>cannot be faked by a =
MITM attacker.<br></div></blockquote><div><br></div><div>Yes, =
"indeterminate" =3D=3D "insecure" if the client requires DNSSEC =
validation. But that would require a MUST NOT in place of the current =
(implied) MUST =
in&nbsp;draft-hoffman-keys-linkage-from-dns:</div><div><br></div><div><div=
>"If the application receives zero usable certificate associations, it =
[MUST] process TLS in the normal =
fashion."</div></div><div><br></div><div>...or maybe that's not actually =
the right place because it presumes that the response is already =
validated by DNSSEC:</div><div><br></div><div>"The DNSSEC signature MUST =
be validated on all responses in order to assure the proof of origin of =
the data."</div><div><br></div><div>What the current draft does not say =
is what the client MUST or MAY do if the client is not able to request, =
perform, or verify DNSSEC validation at all. &nbsp;The answer will =
affect the viability of my MITM scenario.</div><br><blockquote =
type=3D"cite"><div>DNSSEC guarantees that if the client queries a zone =
that is signed (with<br>respect to its trust anchor configuration), it =
either gets an<br>authenticated answer or fails. &nbsp;We can build upon =
this property to<br>distribute KIDNS info in signed zones and know that =
KIDNS-aware clients<br>will not proceed without =
it.&nbsp;</div></blockquote><br></div><div>It's not clear to me, at =
least in the&nbsp;draft-hoffman-keys-linkage-from-dns draft, that we can =
"know that KIDNS-aware clients</div><div>will not proceed without =
it."&nbsp;&nbsp;I don't see any explicit statement to this effect. =
&nbsp;I encourage Paul or the others to chime in as to whether this was =
their intent.</div><br></body></html>=

--Apple-Mail-2-926319224--

From: Matt McCutchen <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 30 Oct 2010 16:29:32 -0400
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Sat, 2010-10-30 at 14:24 -0400, Phillip Hallam-Baker wrote:
> I am fine with this as an option.
> 
> But I think that making it useful and scalable requires us to provide more
> than just a flag.

Can you provide a specific, compelling example?

> What we are proposing here is an aspect of security policy. Which gets us
> into territory that is generally considered 'difficult' and every security
> AD that I have ever discussed this with has expressed extreme skepticism as
> to whether a WG can get to closure if it addresses security policy. The term
> 'rat hole' is used. [...]

The flag has a simple and clear semantic, "I authorize this certificate
and only this certificate for use on my TLS server", and is already
useful to folks like me who can't wait to publish a single exclusive
certificate in DNSSEC and no longer be exposed to the likes of Etisalat.
You seem to be saying that we should hold off on standardizing the
exclusivity flag because there are some use cases that require a more
sophisticated scheme, but also that we might never complete such a
scheme.  So what can be the benefit of waiting, compared to
standardizing the flag now?

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: Steve Schultze <[email-masked]>
Date: Sat, 30 Oct 2010 16:13:29 -0400
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Sat, 2010-10-30 at 15:04 -0400, Steve Schultze wrote:
> On Oct 30, 2010, at 2:20 PM, Matt McCutchen wrote:
> > On Sat, 2010-10-30 at 13:50 -0400, Steve Schultze wrote:
> >> On Oct 30, 2010, at 12:19 PM, Ben Laurie wrote:
> >>>> I would note that, presuming KIDNS only affects client behavior
> >>>> when the client can directly verify that the records were validly
> >>>> DNSSEC-signed (is this everybody's assumption?), using a MUST creates
> >>>> a downgrade attack in which a MITM can force PKIX-only validation by
> >>>> simply blocking DNSSEC-validated DNS results.
> >>> 
> >>> Surely not - in this case the client sees DNS failures, rather than a
> >>> lack of results and so should squawk about that problem.
> >> 
> >> There would only be DNS failures if the MITM were blocking responses
> >> altogether, rather than returning bogus responses containing no KIDNS
> >> (non-DNSSEC-validated, of course).  Unless you assumed that a client
> >> would always bail unless it got a validated DNSSEC response, which is
> >> not viable to mandate... especially on day one.
> > 
> > DNSSEC was specifically designed to address this concern (see RFC 4033
> > section 5).  
> 
> Ah, interesting.  The four states described there is illuminating.
> 
> > The client can require either a valid DNSSEC response
> 
> Ok, and I am suggesting the client should be allowed to do that in our
> spec.  In the language of RFC 4033, it seems that the client would
> require  "secure" state plus a valid KIDNS record.

Right.

> They might also allow an "insecure" state

Or a "secure" denial of existence of an exclusive KIDNS record.  Signed
zones don't necessarily use exclusive KIDNS.  People would be up in arms
if signing their zone suddenly broke all their TLS servers.

> plus a validating PKIX cert.

Right, that is the idea for a backward-compatible client.  "Secure"
zones that opt in to exclusive KIDNS get the presumed security benefits,
everyone else's traditional PKIX certificates continue to work.

> The vulnerability would only manifest itself if the client allowed
> "indeterminate" state and a validating PKIX cert.

As I read it, "indeterminate" means the zone is not within the scope of
any of the configured trust anchors.  This is basically equivalent to
"insecure": in both cases, the client knows that, with respect to its
trust anchor configuration, the zone is not signed.  This condition
cannot be faked by a MITM attacker.

Note that if you use the IANA trust anchor for the root zone, nothing
will be indeterminate.

> I think that it is just another way of expressing what I was
> describing.

I'm not sure what you mean.

DNSSEC guarantees that if the client queries a zone that is signed (with
respect to its trust anchor configuration), it either gets an
authenticated answer or fails.  We can build upon this property to
distribute KIDNS info in signed zones and know that KIDNS-aware clients
will not proceed without it.  For everyone else (signed zones without
KIDNS info, and zones known to be unsigned), the old semantics apply.

-- 
Matt

From: Steve Schultze <[email-masked]>
Date: Sat, 30 Oct 2010 15:04:04 -0400
To: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Oct 30, 2010, at 2:20 PM, Matt McCutchen wrote:
> On Sat, 2010-10-30 at 13:50 -0400, Steve Schultze wrote:
>> On Oct 30, 2010, at 12:19 PM, Ben Laurie wrote:
>>>> I would note that, presuming KIDNS only affects client behavior
>>>> when the client can directly verify that the records were validly
>>>> DNSSEC-signed (is this everybody's assumption?), using a MUST =
creates
>>>> a downgrade attack in which a MITM can force PKIX-only validation =
by
>>>> simply blocking DNSSEC-validated DNS results.
>>>=20
>>> Surely not - in this case the client sees DNS failures, rather than =
a
>>> lack of results and so should squawk about that problem.
>>=20
>> There would only be DNS failures if the MITM were blocking responses
>> altogether, rather than returning bogus responses containing no KIDNS
>> (non-DNSSEC-validated, of course).  Unless you assumed that a client
>> would always bail unless it got a validated DNSSEC response, which is
>> not viable to mandate... especially on day one.
>=20
> DNSSEC was specifically designed to address this concern (see RFC 4033
> section 5). =20

Ah, interesting.  The four states described there is illuminating.

> The client can require either a valid DNSSEC response

Ok, and I am suggesting the client should be allowed to do that in our =
spec.  In the language of RFC 4033, it seems that the client would =
require  "secure" state plus a valid KIDNS record.  They might also =
allow an "insecure" state plus a validating PKIX cert.  The =
vulnerability would only manifest itself if the client allowed =
"indeterminate" state and a validating PKIX cert.  I think that it is =
just another way of expressing what I was describing.  Presuming the =
client can know these states, or the default behavior of the client's =
resolving code prohibits "indeterminate" responses (is this likely?), I =
think you're right that it solves my problem.  Right?

> or a proof that the target zone is not using DNSSEC

Of course this _also_ requires a valid DNSSEC response in the state of =
"insecure", per Section 5:
"at some delegation point, signed proof of the non-existence of a DS =
record"

> in which case the client behaves as if the zone contains no KIDNS =
information.

Date: Sat, 30 Oct 2010 13:26:36 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and	draft-hoffman-keys-linkage-from-dns
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Steve and all,

-----Original Message-----
>From: Steve Schultze <[email-masked]>
>Sent: Oct 30, 2010 12:50 PM
>To: [email-masked]
>Subject: Re: [keyassure] PKIX/KIDNS validation results and	draft-hoffman-keys-linkage-from-dns
>
>On Oct 30, 2010, at 12:19 PM, Ben Laurie wrote:
>>> I would note that, presuming KIDNS only affects client behavior when the client can directly verify that the records were validly DNSSEC-signed (is this everybody's assumption?), using a MUST creates a downgrade attack in which a MITM can force PKIX-only validation by simply blocking DNSSEC-validated DNS results.
>> 
>> Surely not - in this case the client sees DNS failures, rather than a
>> lack of results and so should squawk about that problem.
>
>There would only be DNS failures if the MITM were blocking responses altogether, rather than returning bogus responses containing no KIDNS (non-DNSSEC-validated, of course).  Unless you assumed that a client would always bail unless it got a validated DNSSEC response, which is not viable to mandate... especially on day one.

  Good reiterated point, and agreed.  Especially that we do not now, nor
can I ever invision that we can ever will have absolute trust that ALL DNSSEC responses that fail or not, are properly/accurately validated although they may be "authoritatively".
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

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
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402 
E-Mail [email-masked]
Phone: 214-244-4827

Date: Sat, 30 Oct 2010 14:24:12 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Steve Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

--90e6ba6e89648952820493d9aece
Content-Type: text/plain; charset=ISO-8859-1

I am fine with this as an option.

But I think that making it useful and scalable requires us to provide more
than just a flag.

What we are proposing here is an aspect of security policy. Which gets us
into territory that is generally considered 'difficult' and every security
AD that I have ever discussed this with has expressed extreme skepticism as
to whether a WG can get to closure if it addresses security policy. The term
'rat hole' is used.

I think that we have to divide the security policy into two parts. The first
part is providing inputs to security policy, the second part is security
policy processing.

I think we can point to a lot of experience in defining standards for
presenting information in a form that can be used as input to security
policy processing. We have many proof points for being able to get to
closure (DKIM, SAML, etc.)

The second half, security policy processing is where it is very difficult to
get agreement on in my view. That is the place that we could not address
usefully in SAML, it is also a minefield for IPR.

If we can agree on a mechanism for specifying 'my valid keys look like X', I
think we can certainly agree on 'I always offer SSL on SMTP'.

On Sat, Oct 30, 2010 at 1:58 PM, Steve Schultze <[email-masked]> wrote:

> On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote:
>
> What I do have a problem with is 'this is the fingerprint of the ONLY
> certificate(s) I will use".
>
>
> +1 on Ben's question.  Would you be fine if the semantics allow the holder
> to specify that it is exclusive?  If so, assume that case in my comments
> below.
>
> On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote:
>
> > The only role that the client can play is to choose to respect those
>> semantics or not.
>>
>> And in my version this is the case.  The client decides whether a
>> validated KIDNS record is sufficient or necessary.
>>
>
> That is only possible if you have an expectation that every domain that
> publishes the records will publish them for every certificate and keep them
> up to date.
>
>
> What is only possible?  Allowing the client to choose?  I don't understand
> what you're getting at.  There should be no reason why a client shouldn't be
> able to say "I will only accept connections when the cert is validated via
> DNSSEC-KIDNS."  Sure, this means they can't connect to any sites that
> haven't done that, but that's the point.
>
> If you want to have interoperability every client has to draw the same
> semantics from a given record. They do not have to react in the same way but
> they do have to interpret the intention of the domain holder in the same
> way.
>
>
> I don't see how we disagree.  If all that is needed is to have a flag such
> that the holder can indicate exclusivity, then let's do that and we all
> agree.
>
> In the PKIX model and the OpenPGP model the certificates have the exact
> same semantics for every relying party.
>
> Different relying parties may react differently because the local site
> policy is different. In some cases a client may be allowed to act on a
> certificate with only a partial understanding of those semantics., in others
> the critical bit is set to force a client to ignore a cert it does not fully
> understand.
>
>
> Again, presuming a "yes" answer to Ben's question I think we all agree.
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>
>

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

--90e6ba6e89648952820493d9aece
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I am fine with this as an option.<div><br></div><div>But I think that makin=
g it useful and scalable requires us to provide more than just a flag.</div=
><div><br></div><div><br></div><div>What we are proposing here is an aspect=
 of security policy. Which gets us into territory that is generally conside=
red &#39;difficult&#39; and every security AD that I have ever discussed th=
is with has expressed extreme skepticism as to whether a WG can get to clos=
ure if it addresses security policy. The term &#39;rat hole&#39; is used.</=
div>
<div><br></div><div>I think that we have to divide the security policy into=
 two parts. The first part is providing inputs to security policy, the seco=
nd part is security policy processing.</div><div><br></div><div>I think we =
can point to a lot of experience in defining standards for presenting infor=
mation in a form that can be used as input to security policy processing. W=
e have many proof points for being able to get to closure (DKIM, SAML, etc.=
)</div>
<div><br></div><div><br></div><div>The second half, security policy process=
ing is where it is very difficult to get agreement on in my view. That is t=
he place that we could not address usefully in SAML, it is also a minefield=
 for IPR.</div>
<div><br></div><div>If we can agree on a mechanism for specifying &#39;my v=
alid keys look like X&#39;, I think we can certainly agree on &#39;I always=
 offer SSL on SMTP&#39;.</div><div><br><br><div class=3D"gmail_quote">On Sa=
t, Oct 30, 2010 at 1:58 PM, Steve Schultze <span dir=3D"ltr">&lt;<a href=3D=
"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div style=3D"word-wrap:break-word"><div cl=
ass=3D"im"><div>On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote:</d=
iv><div>
<blockquote type=3D"cite"><span style=3D"border-collapse:separate;font-fami=
ly:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;lette=
r-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;whi=
te-space:normal;word-spacing:0px;font-size:medium">What I do have a problem=
 with is &#39;this is the fingerprint of the ONLY certificate(s) I will use=
&quot;.</span></blockquote>
</div><div><br></div></div>+1 on Ben&#39;s question. =A0Would you be fine i=
f the semantics allow the holder to specify that it is exclusive? =A0If so,=
 assume that case in my comments below.<div><br><div><div class=3D"im"><div=
>On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote:</div>
<blockquote type=3D"cite"><span style=3D"border-collapse:separate;font-fami=
ly:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;lette=
r-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;whi=
te-space:normal;word-spacing:0px;font-size:medium"><blockquote class=3D"gma=
il_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin=
-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);bord=
er-left-style:solid;padding-left:1ex">
<div>&gt; The only role that the client can play is to choose to respect th=
ose semantics or not.<br><br></div>And in my version this is the case. =A0T=
he client decides whether a validated KIDNS record is sufficient or necessa=
ry.<br>
</blockquote><div><br></div><div>That is only possible if you have an expec=
tation that every domain that publishes the records will publish them for e=
very certificate and keep them up to date.</div></span></blockquote><div>
<br></div></div><div>What is only possible? =A0Allowing the client to choos=
e? =A0I don&#39;t understand what you&#39;re getting at. =A0There should be=
 no reason why a client shouldn&#39;t be able to say &quot;I will only acce=
pt connections when the cert is validated via DNSSEC-KIDNS.&quot; =A0Sure, =
this means they can&#39;t connect to any sites that haven&#39;t done that, =
but that&#39;s the point.</div>
<div class=3D"im"><br><blockquote type=3D"cite"><span style=3D"border-colla=
pse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;fo=
nt-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;t=
ext-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><d=
iv>
If you want to have interoperability every client has to draw the same sema=
ntics from a given record. They do not have to react in the same way but th=
ey do have to interpret the intention of the domain holder in the same way.=
</div>
</span></blockquote><div><br></div></div>I don&#39;t see how we disagree. =
=A0If all that is needed is to have a flag such that the holder can indicat=
e exclusivity, then let&#39;s do that and we all agree.</div><div class=3D"=
im">
<div><br></div><div><blockquote type=3D"cite"><span style=3D"border-collaps=
e:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font=
-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;tex=
t-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div=
>
In the PKIX model and the OpenPGP model the certificates have the exact sam=
e semantics for every relying party.</div><div><br></div><div>Different rel=
ying parties may react differently because the local site policy is differe=
nt. In some cases a client may be allowed to act on a certificate with only=
 a partial understanding of those semantics., in others the critical bit is=
 set to force a client to ignore a cert it does not fully understand.</div>
</span></blockquote><br></div></div><div>Again, presuming a &quot;yes&quot;=
 answer to Ben&#39;s question I think we all agree.</div></div></div><br>__=
_____________________________________________<br>
keyassure mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D=
"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--90e6ba6e89648952820493d9aece--

From: Matt McCutchen <[email-masked]>
To: Steve Schultze <[email-masked]>
Date: Sat, 30 Oct 2010 14:20:40 -0400
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Sat, 2010-10-30 at 13:50 -0400, Steve Schultze wrote:
> On Oct 30, 2010, at 12:19 PM, Ben Laurie wrote:
> >> I would note that, presuming KIDNS only affects client behavior
> when the client can directly verify that the records were validly
> DNSSEC-signed (is this everybody's assumption?), using a MUST creates
> a downgrade attack in which a MITM can force PKIX-only validation by
> simply blocking DNSSEC-validated DNS results.
> > 
> > Surely not - in this case the client sees DNS failures, rather than
> a
> > lack of results and so should squawk about that problem.
> 
> There would only be DNS failures if the MITM were blocking responses
> altogether, rather than returning bogus responses containing no KIDNS
> (non-DNSSEC-validated, of course).  Unless you assumed that a client
> would always bail unless it got a validated DNSSEC response, which is
> not viable to mandate... especially on day one.

DNSSEC was specifically designed to address this concern (see RFC 4033
section 5).  The client can require either a valid DNSSEC response or a
proof that the target zone is not using DNSSEC, in which case the client
behaves as if the zone contains no KIDNS information.

-- 
Matt

Date: Sat, 30 Oct 2010 13:19:14 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Steve Schultze <[email-masked]>, [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns
Reply-To: "Jeffrey A. Williams" <[email-masked]>

<HEAD>
<STYLE>body{font-size:10pt;font-family:arial,sans-serif;background-color:#ffffff;color:black;}p{margin:0px;}</STYLE>

<META name=GENERATOR content="MSHTML 8.00.6001.18975"></HEAD>
<BODY id=compText>
<P>Steve and all,</P>
<P>&nbsp;</P>
<P>&nbsp; I think we all agree here.&nbsp; I also think that perhaps there is and has been a language conjugation</P>
<P>problem here.&nbsp; That being how someone else specifically understands the conjugation of </P>
<P>anothers writing...&nbsp; But I do think that Phillip is right that the language in draft-hoffman-keys-linkage-from-dns</P>
<P>misses the mark in respect to it's explicitness and as such lends it self to perhaps some interpratation,</P>
<P>which has already been pointed out before and seemingly again here, as to it's lack of clarity in some</P>
<P>respects.&nbsp; <BR><BR><BR></P>
<BLOCKQUOTE style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 0px">-----Original Message----- <BR>From: Steve Schultze <[email-masked]><BR>Sent: Oct 30, 2010 12:58 PM <BR>To: [email-masked] <BR>Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns <BR><BR><ZZZHTML><ZZZHEAD></ZZZHEAD><ZZZBODY style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">
<DIV>On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote:</DIV>
<DIV>
<BLOCKQUOTE type="cite"><SPAN style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; ORPHANS: 2; LETTER-SPACING: normal; WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px" class=Apple-style-span>What I do have a problem with is 'this is the fingerprint of the ONLY certificate(s) I will use".</SPAN></BLOCKQUOTE></DIV>
<DIV><BR></DIV>+1 on Ben's question. &nbsp;Would you be fine if the semantics allow the holder to specify that it is exclusive? &nbsp;If so, assume that case in my comments below. 
<DIV><BR>
<DIV>
<DIV>On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote:</DIV>
<BLOCKQUOTE type="cite"><SPAN style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; ORPHANS: 2; LETTER-SPACING: normal; WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px" class=Apple-style-span>
<BLOCKQUOTE style="Z-INDEX: auto; POSITION: static; BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class=gmail_quote>
<DIV class=im>&gt; The only role that the client can play is to choose to respect those semantics or not.<BR><BR></DIV>And in my version this is the case. &nbsp;The client decides whether a validated KIDNS record is sufficient or necessary.<BR></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>That is only possible if you have an expectation that every domain that publishes the records will publish them for every certificate and keep them up to date.</DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>What is only possible? &nbsp;Allowing the client to choose? &nbsp;I don't understand what you're getting at. &nbsp;There should be no reason why a client shouldn't be able to say "I will only accept connections when the cert is validated via DNSSEC-KIDNS." &nbsp;Sure, this means they can't connect to any sites that haven't done that, but that's the point.</DIV><BR>
<BLOCKQUOTE type="cite"><SPAN style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; ORPHANS: 2; LETTER-SPACING: normal; WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px" class=Apple-style-span>
<DIV>If you want to have interoperability every client has to draw the same semantics from a given record. They do not have to react in the same way but they do have to interpret the intention of the domain holder in the same way.</DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>I don't see how we disagree. &nbsp;If all that is needed is to have a flag such that the holder can indicate exclusivity, then let's do that and we all agree.</DIV>
<DIV><BR></DIV>
<DIV>
<BLOCKQUOTE type="cite"><SPAN style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; ORPHANS: 2; LETTER-SPACING: normal; WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px" class=Apple-style-span>
<DIV>In the PKIX model and the OpenPGP model the certificates have the exact same semantics for every relying party.</DIV>
<DIV><BR></DIV>
<DIV>Different relying parties may react differently because the local site policy is different. In some cases a client may be allowed to act on a certificate with only a partial understanding of those semantics., in others the critical bit is set to force a client to ignore a cert it does not fully understand.</DIV></SPAN></BLOCKQUOTE><BR></DIV>
<DIV>Again, presuming a "yes" answer to Ben's question I think we all agree.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,<BR>Jeffrey A. Williams<BR>"Obedience of the law is the greatest freedom" -<BR>&nbsp;&nbsp; Abraham Lincoln<BR><BR>"Credit should go with the performance of duty and not with what is very<BR>often the accident of glory" - Theodore Roosevelt<BR><BR>"If the probability be called P; the injury, L; and the burden, B; liability<BR>depends upon whether B is less than L multiplied by<BR>P: i.e., whether B is less than PL."<BR>United States v. Carroll Towing&nbsp; (159 F.2d 169 [2d Cir. 1947]<BR>===============================================================<BR>Updated 1/26/04<BR>Network Eng. SR. Eng. Network data security<BR>ABA member in good standing member ID 01257402 <BR>E-Mail [email-masked]<BR>Phone: 214-244-4827<BR><BR></DIV></DIV></ZZZBODY></ZZZHTML></BLOCKQUOTE></BODY>

Date: Sat, 30 Oct 2010 13:58:53 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

--90e6ba6e89640991b10493d95481
Content-Type: text/plain; charset=ISO-8859-1

Yes, the holder should have the option.

But it does need to be an option and not something that is automatically
assumed.

And it has to be something that is considered explicitly in the design.

On Sat, Oct 30, 2010 at 1:16 PM, Ben Laurie <[email-masked]> wrote:

> On 30 October 2010 18:03, Phillip Hallam-Baker <[email-masked]> wrote:
> >
> >
> > On Sat, Oct 30, 2010 at 11:42 AM, Steve Schultze <[email-masked]>
> wrote:
> >> What is being suggested is that the domain name holder has the semantics
> >> to say, "this is the fingerprint of the certificate I will use."
> >
> > Which I have no problem with.
> > What I do have a problem with is 'this is the fingerprint of the ONLY
> > certificate(s) I will use".
>
> You do agree that the holder should have the _option_ to say that, right?
>

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

--90e6ba6e89640991b10493d95481
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yes, the holder should have the option.<div><br></div><div>But it does need=
 to be an option and not something that is automatically assumed.</div><div=
><br></div><div>And it has to be something that is considered explicitly in=
 the design.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Sat, Oct 30, 2010 at =
1:16 PM, Ben Laurie <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 30 October 2010 18:03, Phillip Hallam-Baker &lt;<a hre=
f=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Sat, Oct 30, 2010 at 11:42 AM, Steve Schultze &lt;<a href=3D"mailto=
:[email-masked]">[email-masked]</a>&gt; wrote:<br>
</div><div class=3D"im">&gt;&gt; What is being suggested is that the domain=
 name holder has the semantics<br>
&gt;&gt; to say, &quot;this is the fingerprint of the certificate I will us=
e.&quot;<br>
&gt;<br>
&gt; Which I have no problem with.<br>
&gt; What I do have a problem with is &#39;this is the fingerprint of the O=
NLY<br>
&gt; certificate(s) I will use&quot;.<br>
<br>
</div>You do agree that the holder should have the _option_ to say that, ri=
ght?<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--90e6ba6e89640991b10493d95481--

From: Steve Schultze <[email-masked]>
Date: Sat, 30 Oct 2010 13:58:20 -0400
To: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

--Apple-Mail-1-916655826
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote:
> What I do have a problem with is 'this is the fingerprint of the ONLY =
certificate(s) I will use".

+1 on Ben's question.  Would you be fine if the semantics allow the =
holder to specify that it is exclusive?  If so, assume that case in my =
comments below.

On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote:
> > The only role that the client can play is to choose to respect those =
semantics or not.
>=20
> And in my version this is the case.  The client decides whether a =
validated KIDNS record is sufficient or necessary.
>=20
> That is only possible if you have an expectation that every domain =
that publishes the records will publish them for every certificate and =
keep them up to date.

What is only possible?  Allowing the client to choose?  I don't =
understand what you're getting at.  There should be no reason why a =
client shouldn't be able to say "I will only accept connections when the =
cert is validated via DNSSEC-KIDNS."  Sure, this means they can't =
connect to any sites that haven't done that, but that's the point.

> If you want to have interoperability every client has to draw the same =
semantics from a given record. They do not have to react in the same way =
but they do have to interpret the intention of the domain holder in the =
same way.

I don't see how we disagree.  If all that is needed is to have a flag =
such that the holder can indicate exclusivity, then let's do that and we =
all agree.

> In the PKIX model and the OpenPGP model the certificates have the =
exact same semantics for every relying party.
>=20
> Different relying parties may react differently because the local site =
policy is different. In some cases a client may be allowed to act on a =
certificate with only a partial understanding of those semantics., in =
others the critical bit is set to force a client to ignore a cert it =
does not fully understand.

Again, presuming a "yes" answer to Ben's question I think we all agree.=

--Apple-Mail-1-916655826
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div>On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker =
wrote:</div><div><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">What I do =
have a problem with is 'this is the fingerprint of the ONLY =
certificate(s) I will use".</span></blockquote></div><div><br></div>+1 =
on Ben's question. &nbsp;Would you be fine if the semantics allow the =
holder to specify that it is exclusive? &nbsp;If so, assume that case in =
my comments below.<div><br><div><div>On Oct 30, 2010, at 1:03 PM, =
Phillip Hallam-Baker wrote:</div><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><blockquote =
class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; =
border-left-color: rgb(204, 204, 204); border-left-style: solid; =
padding-left: 1ex; position: static; z-index: auto; "><div =
class=3D"im">&gt; The only role that the client can play is to choose to =
respect those semantics or not.<br><br></div>And in my version this is =
the case. &nbsp;The client decides whether a validated KIDNS record is =
sufficient or necessary.<br></blockquote><div><br></div><div>That is =
only possible if you have an expectation that every domain that =
publishes the records will publish them for every certificate and keep =
them up to date.</div></span></blockquote><div><br></div><div>What is =
only possible? &nbsp;Allowing the client to choose? &nbsp;I don't =
understand what you're getting at. &nbsp;There should be no reason why a =
client shouldn't be able to say "I will only accept connections when the =
cert is validated via DNSSEC-KIDNS." &nbsp;Sure, this means they can't =
connect to any sites that haven't done that, but that's the =
point.</div><br><blockquote type=3D"cite"><span class=3D"Apple-style-span"=
 style=3D"border-collapse: separate; font-family: Helvetica; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div>If you =
want to have interoperability every client has to draw the same =
semantics from a given record. They do not have to react in the same way =
but they do have to interpret the intention of the domain holder in the =
same way.</div></span></blockquote><div><br></div>I don't see how we =
disagree. &nbsp;If all that is needed is to have a flag such that the =
holder can indicate exclusivity, then let's do that and we all =
agree.</div><div><br></div><div><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div>In the =
PKIX model and the OpenPGP model the certificates have the exact same =
semantics for every relying party.</div><div><br></div><div>Different =
relying parties may react differently because the local site policy is =
different. In some cases a client may be allowed to act on a certificate =
with only a partial understanding of those semantics., in others the =
critical bit is set to force a client to ignore a cert it does not fully =
understand.</div></span></blockquote><br></div><div>Again, presuming a =
"yes" answer to Ben's question I think we all =
agree.</div></div></body></html>=

--Apple-Mail-1-916655826--

From: Steve Schultze <[email-masked]>
Date: Sat, 30 Oct 2010 13:50:45 -0400
To: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Oct 30, 2010, at 12:19 PM, Ben Laurie wrote:
>> I would note that, presuming KIDNS only affects client behavior when =
the client can directly verify that the records were validly =
DNSSEC-signed (is this everybody's assumption?), using a MUST creates a =
downgrade attack in which a MITM can force PKIX-only validation by =
simply blocking DNSSEC-validated DNS results.
>=20
> Surely not - in this case the client sees DNS failures, rather than a
> lack of results and so should squawk about that problem.

There would only be DNS failures if the MITM were blocking responses =
altogether, rather than returning bogus responses containing no KIDNS =
(non-DNSSEC-validated, of course).  Unless you assumed that a client =
would always bail unless it got a validated DNSSEC response, which is =
not viable to mandate... especially on day one.=

Date: Sat, 30 Oct 2010 18:16:10 +0100
From: Ben Laurie <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On 30 October 2010 18:03, Phillip Hallam-Baker <[email-masked]> wrote:
>
>
> On Sat, Oct 30, 2010 at 11:42 AM, Steve Schultze <[email-masked]> wrote:
>> What is being suggested is that the domain name holder has the semantics
>> to say, "this is the fingerprint of the certificate I will use."
>
> Which I have no problem with.
> What I do have a problem with is 'this is the fingerprint of the ONLY
> certificate(s) I will use".

You do agree that the holder should have the _option_ to say that, right?

Date: Sat, 30 Oct 2010 13:03:10 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Steve Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

--20cf30434864bef0f00493d88c82
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Oct 30, 2010 at 11:42 AM, Steve Schultze <[email-masked]> wrote:

> On Oct 30, 2010, at 11:28 AM, Phillip Hallam-Baker wrote:
> > What it sounds like to me is that people are suggesting that it is up to
> the client to decide what semantics that the domain name holder intended
> when they published the record.
>
> What is being suggested is that the domain name holder has the semantics to
> say, "this is the fingerprint of the certificate I will use."

Which I have no problem with.

What I do have a problem with is 'this is the fingerprint of the ONLY
certificate(s) I will use".

We cannot have interoperability unless the clients all have a precise
agreement on the intended semantics. The person (or robot) who publishes the
name in the domain needs to understand precisely how clients will react and
plan for the most restrictive case.

> > The only role that the client can play is to choose to respect those
> semantics or not.
>
> And in my version this is the case.  The client decides whether a validated
> KIDNS record is sufficient or necessary.
>

That is only possible if you have an expectation that every domain that
publishes the records will publish them for every certificate and keep them
up to date.

If you want to have interoperability every client has to draw the same
semantics from a given record. They do not have to react in the same way but
they do have to interpret the intention of the domain holder in the same
way.

> (There may be other things that the domain holder can state in DNS, along
> the lines of what you have suggested elsewhere, which I think are equally
> subject to client discretion in the same fashion.)
>
> This is parallel to what we have today with the PKIX/CA model.  Servers
> present certs which the client decides to trust or not, based on its root
> cert store, customized trust bits, and user override.  This is a feature
> because it allows clients with different trust preferences to operate in a
> way that respects those.

In the PKIX model and the OpenPGP model the certificates have the exact same
semantics for every relying party.

Different relying parties may react differently because the local site
policy is different. In some cases a client may be allowed to act on a
certificate with only a partial understanding of those semantics., in others
the critical bit is set to force a client to ignore a cert it does not fully
understand.

Specifying standards for specifying local security policy is hard and
possibly unnecessary. SAML specifies attributes for Authentication,
Authentication and Attributes, all of which provide inputs to security
policy but does not specify how those inputs are to be processed.

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

--20cf30434864bef0f00493d88c82
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Sat, Oct 30, 2010 at 11:42 AM, Steve =
Schultze <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">sjs@pri=
nceton.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Oct 30, 2010, at 11:28 AM, Phillip Hallam-Baker wrote:=
<br>
&gt; What it sounds like to me is that people are suggesting that it is up =
to the client to decide what semantics that the domain name holder intended=
 when they published the record.<br>
<br>
</div>What is being suggested is that the domain name holder has the semant=
ics to say, &quot;this is the fingerprint of the certificate I will use.&qu=
ot;</blockquote><div><br></div><div>Which I have no problem with.</div>
<div><br></div><div>What I do have a problem with is &#39;this is the finge=
rprint of the ONLY certificate(s) I will use&quot;.</div><div><br></div><di=
v><br></div><div>We cannot have interoperability unless the clients all hav=
e a precise agreement on the intended semantics. The person (or robot) who =
publishes the name in the domain needs to understand precisely how clients =
will react and plan for the most restrictive case.</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"=
im">
&gt; The only role that the client can play is to choose to respect those s=
emantics or not.<br>
<br>
</div>And in my version this is the case. =A0The client decides whether a v=
alidated KIDNS record is sufficient or necessary.<br></blockquote><div><br>=
</div><div>That is only possible if you have an expectation that every doma=
in that publishes the records will publish them for every certificate and k=
eep them up to date.</div>
<div><br></div><div>If you want to have interoperability every client has t=
o draw the same semantics from a given record. They do not have to react in=
 the same way but they do have to interpret the intention of the domain hol=
der in the same way.</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
(There may be other things that the domain holder can state in DNS, along t=
he lines of what you have suggested elsewhere, which I think are equally su=
bject to client discretion in the same fashion.)<br>
<br>
This is parallel to what we have today with the PKIX/CA model. =A0Servers p=
resent certs which the client decides to trust or not, based on its root ce=
rt store, customized trust bits, and user override. =A0This is a feature be=
cause it allows clients with different trust preferences to operate in a wa=
y that respects those.</blockquote>
<div><br></div><div>In the PKIX model and the OpenPGP model the certificate=
s have the exact same semantics for every relying party.</div><div><br></di=
v><div>Different relying parties may react differently because the local si=
te policy is different. In some cases a client may be allowed to act on a c=
ertificate with only a partial understanding of those semantics., in others=
 the critical bit is set to force a client to ignore a cert it does not ful=
ly understand.</div>
<div><br></div><div><br></div><div>Specifying standards for specifying loca=
l security policy is hard and possibly unnecessary. SAML specifies attribut=
es for Authentication, Authentication and Attributes, all of which provide =
inputs to security policy but does not specify how those inputs are to be p=
rocessed.</div>
<div><br></div></div><br>-- <br>Website: <a href=3D"http://hallambaker.com/=
">http://hallambaker.com/</a><br><br>

--20cf30434864bef0f00493d88c82--

Date: Sat, 30 Oct 2010 11:28:49 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Steve Schultze <[email-masked]>, [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and	draft-hoffman-keys-linkage-from-dns
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Steve and all,

-----Original Message-----
>From: Steve Schultze <[email-masked]>
>Sent: Oct 30, 2010 10:05 AM
>To: [email-masked]
>Subject: Re: [keyassure] PKIX/KIDNS validation results and	draft-hoffman-keys-linkage-from-dns
>
>Ben, I'm porting your comment below into this thread for the sake of subject-line clarity (none of this is WG-formation specific, I believe).
>
>On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote:
>> Paul wants client policy to decide whether to trust PKIX, DNSSEC or
>> some mixture of the two. This seems not only reasonable, but
>> unavoidable: clients will implement what suits them, and we are in no
>> position to change that.
>> 
>> Phillip wants the domain in question to be able to state its
>> intentions w.r.t. the policy clients should use. This seems not
>> unreasonable, also. Clients can choose to follow this or not.
>
>What effect does this have on the MUST vs. MAY suggestions I made to the draft-hoffman-keys-linkage-from-dns-03 text?  I believe that what you are saying is that the spec should leave it open to the client how to react to different validation outcome permutations from PKIX and DNSSEC-secured KIDNS.  In that case, the two excerpts I quoted should be MAY, as I suggested.  This also means that I disagree with Paul, who thinks that MUST should be used.

  I prefer MAY over must, but only barely.  I thought Paul H. suggested MAY?
Anyway, MAY covers the corner cases discussed, which is why I only barely
prefer it.  
>
>I would note that, presuming KIDNS only affects client behavior when the client can directly verify that the records were validly DNSSEC-signed (is this everybody's assumption?), using a MUST creates a downgrade attack in which a MITM can force PKIX-only validation by simply blocking DNSSEC-validated DNS results.

Very good point!  And yes to your question from me anyway.
>
>"If the application receives zero usable certificate associations, it [MUST] process TLS in the normal fashion."
>
>We want the client to be able to choose to require DNSSEC-validated KIDNS for all requests, if it wishes.  Otherwise what we're doing offers no greater security than the status quo.

  I agree.
>
>On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote:
>> Thank you for being explicit!
>> 
>> At 10:14 PM +0100 10/28/10, Stephen Farrell wrote:
>>> Having now caught up with the many recent messages, I'd also
>>> be a bit concerned about the impact of:
>>> 
>>>> "If a match between the certificate association(s) and the
>>>> server's end entity certificate in TLS is not found, the
>>>> TLS client MUST abort the handshake with an "access_denied" error."
>>> 
>>> The concerns I have about it would include:
>>> 
>>> - I'm not really sure if that same rule would be appropriate
>>> for all applications that use TLS, nor for all deployments
>>> of each protocol using TLS - basically the policy slippery
>>> slope PHB is raising (from time to time:-)
>> 
>> OK, maybe try being more explicit. For example, if this document was in fact an update to TLS, would you have the same concern? Or, if you want a SHOULD rather than a MUST, what would the specific exceptions be (or are you asking for a typical IETF mushy SHOULD)?
>
>I don't know what Stephen Farrell is arguing for, but I'm arguing for an even more mushy MAY ;)
>
>However, this is a feature because it gives the clients more options... including the option to improve upon the status quo of PKIX security even in the presence of a MITM (our assumed threat model).  It does so without forcing all clients to do this on day one, an impractical requirement.
>
>On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote:
>> "If the application receives zero usable certificate associations, it process TLS in the normal fashion."
>> "If a match between the certificate association(s) and the server's end entity certificate in TLS is not found, the TLS client MUST abort the handshake with an "access_denied" error."
>> 
>> I suggest:
>> 
>> "If the application receives zero usable certificate associations, it MAY process TLS in the normal fashion."
>> "If a match between the certificate association(s) and the server's end entity certificate in TLS is not found, the TLS client MAY abort the handshake with an "access_denied" error."
>
>
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

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
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402 
E-Mail [email-masked]
Phone: 214-244-4827

Date: Sat, 30 Oct 2010 17:21:34 +0100
From: Ben Laurie <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On 30 October 2010 16:28, Phillip Hallam-Baker <[email-masked]> wrote:
> Lets think about 'client makes a choice'
>
> What it sounds like to me is that people are suggesting that it is up to =
the
> client to decide what semantics that the domain name holder intended when
> they published the record.
> That cannot possibly work.
> The publisher of the record has to have sole control of what the semantic=
s
> of the record are.
> The only role that the client can play is to choose to respect those
> semantics or not.

Exactly, though it could also be that the semantics even if respected
give the client choice about how to react.

> We cannot address this 'Phill wants one thing', 'others want another' by
> deciding that client can interpret the same set of bits in different ways=
.
> We have to have different bits for the two purposes.
>
> I want to have a clean separation because the only way I can see support =
for
> draft-hoffman being feasible is if either the site operates its own PKI a=
nd
> DNS or the CA operates both the DNS and the certs for the site.
> I know what everyone here (myself included) would prefer the first. I wou=
ld
> much rather be teaching people how to run their DNS CA infrastructure at
> $800 per person per day through my private consulting business or selling
> them training videos. But most people just want this to be something they
> just sign a cheque for and forget.
>
> On Sat, Oct 30, 2010 at 11:05 AM, Steve Schultze <[email-masked]> wrot=
e:
>>
>> Ben, I'm porting your comment below into this thread for the sake of
>> subject-line clarity (none of this is WG-formation specific, I believe).
>>
>> On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote:
>> > Paul wants client policy to decide whether to trust PKIX, DNSSEC or
>> > some mixture of the two. This seems not only reasonable, but
>> > unavoidable: clients will implement what suits them, and we are in no
>> > position to change that.
>> >
>> > Phillip wants the domain in question to be able to state its
>> > intentions w.r.t. the policy clients should use. This seems not
>> > unreasonable, also. Clients can choose to follow this or not.
>>
>> What effect does this have on the MUST vs. MAY suggestions I made to the
>> draft-hoffman-keys-linkage-from-dns-03 text? =A0I believe that what you =
are
>> saying is that the spec should leave it open to the client how to react =
to
>> different validation outcome permutations from PKIX and DNSSEC-secured
>> KIDNS. =A0In that case, the two excerpts I quoted should be MAY, as I
>> suggested. =A0This also means that I disagree with Paul, who thinks that=
 MUST
>> should be used.
>>
>> I would note that, presuming KIDNS only affects client behavior when the
>> client can directly verify that the records were validly DNSSEC-signed (=
is
>> this everybody's assumption?), using a MUST creates a downgrade attack i=
n
>> which a MITM can force PKIX-only validation by simply blocking
>> DNSSEC-validated DNS results.
>>
>> "If the application receives zero usable certificate associations, it
>> [MUST] process TLS in the normal fashion."
>>
>> We want the client to be able to choose to require DNSSEC-validated KIDN=
S
>> for all requests, if it wishes. =A0Otherwise what we're doing offers no
>> greater security than the status quo.
>>
>> On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote:
>> > Thank you for being explicit!
>> >
>> > At 10:14 PM +0100 10/28/10, Stephen Farrell wrote:
>> >> Having now caught up with the many recent messages, I'd also
>> >> be a bit concerned about the impact of:
>> >>
>> >>> "If a match between the certificate association(s) and the
>> >>> server's end entity certificate in TLS is not found, the
>> >>> TLS client MUST abort the handshake with an "access_denied" error."
>> >>
>> >> The concerns I have about it would include:
>> >>
>> >> - I'm not really sure if that same rule would be appropriate
>> >> for all applications that use TLS, nor for all deployments
>> >> of each protocol using TLS - basically the policy slippery
>> >> slope PHB is raising (from time to time:-)
>> >
>> > OK, maybe try being more explicit. For example, if this document was i=
n
>> > fact an update to TLS, would you have the same concern? Or, if you wan=
t a
>> > SHOULD rather than a MUST, what would the specific exceptions be (or a=
re you
>> > asking for a typical IETF mushy SHOULD)?
>>
>> I don't know what Stephen Farrell is arguing for, but I'm arguing for an
>> even more mushy MAY ;)
>>
>> However, this is a feature because it gives the clients more options...
>> including the option to improve upon the status quo of PKIX security eve=
n in
>> the presence of a MITM (our assumed threat model). =A0It does so without
>> forcing all clients to do this on day one, an impractical requirement.
>>
>> On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote:
>> > "If the application receives zero usable certificate associations, it
>> > process TLS in the normal fashion."
>> > "If a match between the certificate association(s) and the server's en=
d
>> > entity certificate in TLS is not found, the TLS client MUST abort the
>> > handshake with an "access_denied" error."
>> >
>> > I suggest:
>> >
>> > "If the application receives zero usable certificate associations, it
>> > MAY process TLS in the normal fashion."
>> > "If a match between the certificate association(s) and the server's en=
d
>> > entity certificate in TLS is not found, the TLS client MAY abort the
>> > handshake with an "access_denied" error."
>>
>>
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>
>
>
> --
> Website: http://hallambaker.com/
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>
>

Date: Sat, 30 Oct 2010 17:19:57 +0100
From: Ben Laurie <[email-masked]>
To: Steve Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On 30 October 2010 16:05, Steve Schultze <[email-masked]> wrote:
> Ben, I'm porting your comment below into this thread for the sake of subj=
ect-line clarity (none of this is WG-formation specific, I believe).
>
> On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote:
>> Paul wants client policy to decide whether to trust PKIX, DNSSEC or
>> some mixture of the two. This seems not only reasonable, but
>> unavoidable: clients will implement what suits them, and we are in no
>> position to change that.
>>
>> Phillip wants the domain in question to be able to state its
>> intentions w.r.t. the policy clients should use. This seems not
>> unreasonable, also. Clients can choose to follow this or not.
>
> What effect does this have on the MUST vs. MAY suggestions I made to the =
draft-hoffman-keys-linkage-from-dns-03 text?

I have temporarily given up on trying to stay up-to-date with the
various I-Ds until the dust on chartering settles so I can't currently
answer that.

> =A0I believe that what you are saying is that the spec should leave it op=
en to the client how to react to different validation outcome permutations =
from PKIX and DNSSEC-secured KIDNS. =A0In that case, the two excerpts I quo=
ted should be MAY, as I suggested. =A0This also means that I disagree with =
Paul, who thinks that MUST should be used.
>
> I would note that, presuming KIDNS only affects client behavior when the =
client can directly verify that the records were validly DNSSEC-signed (is =
this everybody's assumption?), using a MUST creates a downgrade attack in w=
hich a MITM can force PKIX-only validation by simply blocking DNSSEC-valida=
ted DNS results.

Surely not - in this case the client sees DNS failures, rather than a
lack of results and so should squawk about that problem.

>
> "If the application receives zero usable certificate associations, it [MU=
ST] process TLS in the normal fashion."
>
> We want the client to be able to choose to require DNSSEC-validated KIDNS=
 for all requests, if it wishes. =A0Otherwise what we're doing offers no gr=
eater security than the status quo.
>
> On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote:
>> Thank you for being explicit!
>>
>> At 10:14 PM +0100 10/28/10, Stephen Farrell wrote:
>>> Having now caught up with the many recent messages, I'd also
>>> be a bit concerned about the impact of:
>>>
>>>> "If a match between the certificate association(s) and the
>>>> server's end entity certificate in TLS is not found, the
>>>> TLS client MUST abort the handshake with an "access_denied" error."
>>>
>>> The concerns I have about it would include:
>>>
>>> - I'm not really sure if that same rule would be appropriate
>>> for all applications that use TLS, nor for all deployments
>>> of each protocol using TLS - basically the policy slippery
>>> slope PHB is raising (from time to time:-)
>>
>> OK, maybe try being more explicit. For example, if this document was in =
fact an update to TLS, would you have the same concern? Or, if you want a S=
HOULD rather than a MUST, what would the specific exceptions be (or are you=
 asking for a typical IETF mushy SHOULD)?
>
> I don't know what Stephen Farrell is arguing for, but I'm arguing for an =
even more mushy MAY ;)
>
> However, this is a feature because it gives the clients more options... i=
ncluding the option to improve upon the status quo of PKIX security even in=
 the presence of a MITM (our assumed threat model). =A0It does so without f=
orcing all clients to do this on day one, an impractical requirement.
>
> On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote:
>> "If the application receives zero usable certificate associations, it pr=
ocess TLS in the normal fashion."
>> "If a match between the certificate association(s) and the server's end =
entity certificate in TLS is not found, the TLS client MUST abort the hands=
hake with an "access_denied" error."
>>
>> I suggest:
>>
>> "If the application receives zero usable certificate associations, it MA=
Y process TLS in the normal fashion."
>> "If a match between the certificate association(s) and the server's end =
entity certificate in TLS is not found, the TLS client MAY abort the handsh=
ake with an "access_denied" error."
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

From: Steve Schultze <[email-masked]>
Date: Sat, 30 Oct 2010 11:42:30 -0400
To: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Oct 30, 2010, at 11:28 AM, Phillip Hallam-Baker wrote:
> What it sounds like to me is that people are suggesting that it is up =
to the client to decide what semantics that the domain name holder =
intended when they published the record.

What is being suggested is that the domain name holder has the semantics =
to say, "this is the fingerprint of the certificate I will use."=20

> The publisher of the record has to have sole control of what the =
semantics of the record are.

And they do, presuming they are articulating what I stated above.

> The only role that the client can play is to choose to respect those =
semantics or not.

And in my version this is the case.  The client decides whether a =
validated KIDNS record is sufficient or necessary.

(There may be other things that the domain holder can state in DNS, =
along the lines of what you have suggested elsewhere, which I think are =
equally subject to client discretion in the same fashion.)

This is parallel to what we have today with the PKIX/CA model.  Servers =
present certs which the client decides to trust or not, based on its =
root cert store, customized trust bits, and user override.  This is a =
feature because it allows clients with different trust preferences to =
operate in a way that respects those.=

Date: Sat, 30 Oct 2010 11:28:57 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Steve Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

--90e6ba6e8128d233a20493d73b13
Content-Type: text/plain; charset=ISO-8859-1

Lets think about 'client makes a choice'

What it sounds like to me is that people are suggesting that it is up to the
client to decide what semantics that the domain name holder intended when
they published the record.

That cannot possibly work.

The publisher of the record has to have sole control of what the semantics
of the record are.

The only role that the client can play is to choose to respect those
semantics or not.

We cannot address this 'Phill wants one thing', 'others want another' by
deciding that client can interpret the same set of bits in different ways.

We have to have different bits for the two purposes.

I want to have a clean separation because the only way I can see support for
draft-hoffman being feasible is if either the site operates its own PKI and
DNS or the CA operates both the DNS and the certs for the site.

I know what everyone here (myself included) would prefer the first. I would
much rather be teaching people how to run their DNS CA infrastructure at
$800 per person per day through my private consulting business or selling
them training videos. But most people just want this to be something they
just sign a cheque for and forget.

On Sat, Oct 30, 2010 at 11:05 AM, Steve Schultze <[email-masked]> wrote:

> Ben, I'm porting your comment below into this thread for the sake of
> subject-line clarity (none of this is WG-formation specific, I believe).
>
> On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote:
> > Paul wants client policy to decide whether to trust PKIX, DNSSEC or
> > some mixture of the two. This seems not only reasonable, but
> > unavoidable: clients will implement what suits them, and we are in no
> > position to change that.
> >
> > Phillip wants the domain in question to be able to state its
> > intentions w.r.t. the policy clients should use. This seems not
> > unreasonable, also. Clients can choose to follow this or not.
>
> What effect does this have on the MUST vs. MAY suggestions I made to the
> draft-hoffman-keys-linkage-from-dns-03 text?  I believe that what you are
> saying is that the spec should leave it open to the client how to react to
> different validation outcome permutations from PKIX and DNSSEC-secured
> KIDNS.  In that case, the two excerpts I quoted should be MAY, as I
> suggested.  This also means that I disagree with Paul, who thinks that MUST
> should be used.
>
> I would note that, presuming KIDNS only affects client behavior when the
> client can directly verify that the records were validly DNSSEC-signed (is
> this everybody's assumption?), using a MUST creates a downgrade attack in
> which a MITM can force PKIX-only validation by simply blocking
> DNSSEC-validated DNS results.
>
> "If the application receives zero usable certificate associations, it
> [MUST] process TLS in the normal fashion."
>
> We want the client to be able to choose to require DNSSEC-validated KIDNS
> for all requests, if it wishes.  Otherwise what we're doing offers no
> greater security than the status quo.
>
> On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote:
> > Thank you for being explicit!
> >
> > At 10:14 PM +0100 10/28/10, Stephen Farrell wrote:
> >> Having now caught up with the many recent messages, I'd also
> >> be a bit concerned about the impact of:
> >>
> >>> "If a match between the certificate association(s) and the
> >>> server's end entity certificate in TLS is not found, the
> >>> TLS client MUST abort the handshake with an "access_denied" error."
> >>
> >> The concerns I have about it would include:
> >>
> >> - I'm not really sure if that same rule would be appropriate
> >> for all applications that use TLS, nor for all deployments
> >> of each protocol using TLS - basically the policy slippery
> >> slope PHB is raising (from time to time:-)
> >
> > OK, maybe try being more explicit. For example, if this document was in
> fact an update to TLS, would you have the same concern? Or, if you want a
> SHOULD rather than a MUST, what would the specific exceptions be (or are you
> asking for a typical IETF mushy SHOULD)?
>
> I don't know what Stephen Farrell is arguing for, but I'm arguing for an
> even more mushy MAY ;)
>
> However, this is a feature because it gives the clients more options...
> including the option to improve upon the status quo of PKIX security even in
> the presence of a MITM (our assumed threat model).  It does so without
> forcing all clients to do this on day one, an impractical requirement.
>
> On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote:
> > "If the application receives zero usable certificate associations, it
> process TLS in the normal fashion."
> > "If a match between the certificate association(s) and the server's end
> entity certificate in TLS is not found, the TLS client MUST abort the
> handshake with an "access_denied" error."
> >
> > I suggest:
> >
> > "If the application receives zero usable certificate associations, it MAY
> process TLS in the normal fashion."
> > "If a match between the certificate association(s) and the server's end
> entity certificate in TLS is not found, the TLS client MAY abort the
> handshake with an "access_denied" error."
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

--90e6ba6e8128d233a20493d73b13
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Lets think about &#39;client makes a choice&#39;=A0<div><br></div><div><br>=
</div><div>What it sounds like to me is that people are suggesting that it =
is up to the client to decide what semantics that the domain name holder in=
tended when they published the record.</div>
<div><br></div><div>That cannot possibly work.</div><div><br></div><div>The=
 publisher of the record has to have sole control of what the semantics of =
the record are.</div><div><br></div><div>The only role that the client can =
play is to choose to respect those semantics or not.</div>
<div><br></div><div><br></div><div>We cannot address this &#39;Phill wants =
one thing&#39;, &#39;others want another&#39; by deciding that client can i=
nterpret the same set of bits in different ways.</div><div><br></div><div>
We have to have different bits for the two purposes.</div><div><br></div><d=
iv><br></div><div>I want to have a clean separation because the only way I =
can see support for draft-hoffman being feasible is if either the site oper=
ates its own PKI and DNS or the CA operates both the DNS and the certs for =
the site.</div>
<div><br></div><div>I know what everyone here (myself included) would prefe=
r the first. I would much rather be teaching people how to run their DNS CA=
 infrastructure at $800 per person per day through my private consulting bu=
siness or selling them training videos. But most people just want this to b=
e something they just sign a cheque for and forget.</div>
<div><br><br><div class=3D"gmail_quote">On Sat, Oct 30, 2010 at 11:05 AM, S=
teve Schultze <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">sj=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Ben, I&#39;m porting your comment below into this thread for the sake of su=
bject-line clarity (none of this is WG-formation specific, I believe).<br>
<br>
On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote:<br>
&gt; Paul wants client policy to decide whether to trust PKIX, DNSSEC or<br=
>
&gt; some mixture of the two. This seems not only reasonable, but<br>
&gt; unavoidable: clients will implement what suits them, and we are in no<=
br>
&gt; position to change that.<br>
&gt;<br>
&gt; Phillip wants the domain in question to be able to state its<br>
&gt; intentions w.r.t. the policy clients should use. This seems not<br>
&gt; unreasonable, also. Clients can choose to follow this or not.<br>
<br>
What effect does this have on the MUST vs. MAY suggestions I made to the dr=
aft-hoffman-keys-linkage-from-dns-03 text? =A0I believe that what you are s=
aying is that the spec should leave it open to the client how to react to d=
ifferent validation outcome permutations from PKIX and DNSSEC-secured KIDNS=
. =A0In that case, the two excerpts I quoted should be MAY, as I suggested.=
 =A0This also means that I disagree with Paul, who thinks that MUST should =
be used.<br>

<br>
I would note that, presuming KIDNS only affects client behavior when the cl=
ient can directly verify that the records were validly DNSSEC-signed (is th=
is everybody&#39;s assumption?), using a MUST creates a downgrade attack in=
 which a MITM can force PKIX-only validation by simply blocking DNSSEC-vali=
dated DNS results.<br>

<br>
&quot;If the application receives zero usable certificate associations, it =
[MUST] process TLS in the normal fashion.&quot;<br>
<br>
We want the client to be able to choose to require DNSSEC-validated KIDNS f=
or all requests, if it wishes. =A0Otherwise what we&#39;re doing offers no =
greater security than the status quo.<br>
<div class=3D"im"><br>
On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote:<br>
&gt; Thank you for being explicit!<br>
&gt;<br>
&gt; At 10:14 PM +0100 10/28/10, Stephen Farrell wrote:<br>
&gt;&gt; Having now caught up with the many recent messages, I&#39;d also<b=
r>
&gt;&gt; be a bit concerned about the impact of:<br>
&gt;&gt;<br>
&gt;&gt;&gt; &quot;If a match between the certificate association(s) and th=
e<br>
&gt;&gt;&gt; server&#39;s end entity certificate in TLS is not found, the<b=
r>
&gt;&gt;&gt; TLS client MUST abort the handshake with an &quot;access_denie=
d&quot; error.&quot;<br>
&gt;&gt;<br>
&gt;&gt; The concerns I have about it would include:<br>
&gt;&gt;<br>
&gt;&gt; - I&#39;m not really sure if that same rule would be appropriate<b=
r>
&gt;&gt; for all applications that use TLS, nor for all deployments<br>
&gt;&gt; of each protocol using TLS - basically the policy slippery<br>
&gt;&gt; slope PHB is raising (from time to time:-)<br>
&gt;<br>
&gt; OK, maybe try being more explicit. For example, if this document was i=
n fact an update to TLS, would you have the same concern? Or, if you want a=
 SHOULD rather than a MUST, what would the specific exceptions be (or are y=
ou asking for a typical IETF mushy SHOULD)?<br>

<br>
</div>I don&#39;t know what Stephen Farrell is arguing for, but I&#39;m arg=
uing for an even more mushy MAY ;)<br>
<br>
However, this is a feature because it gives the clients more options... inc=
luding the option to improve upon the status quo of PKIX security even in t=
he presence of a MITM (our assumed threat model). =A0It does so without for=
cing all clients to do this on day one, an impractical requirement.<br>

<div class=3D"im"><br>
On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote:<br>
&gt; &quot;If the application receives zero usable certificate associations=
, it process TLS in the normal fashion.&quot;<br>
</div><div class=3D"im">&gt; &quot;If a match between the certificate assoc=
iation(s) and the server&#39;s end entity certificate in TLS is not found, =
the TLS client MUST abort the handshake with an &quot;access_denied&quot; e=
rror.&quot;<br>

&gt;<br>
</div><div class=3D"im">&gt; I suggest:<br>
&gt;<br>
&gt; &quot;If the application receives zero usable certificate associations=
, it MAY process TLS in the normal fashion.&quot;<br>
</div>&gt; &quot;If a match between the certificate association(s) and the =
server&#39;s end entity certificate in TLS is not found, the TLS client MAY=
 abort the handshake with an &quot;access_denied&quot; error.&quot;<br>

<div><div></div><div class=3D"h5"><br>
<br>
_______________________________________________<br>
keyassure mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--90e6ba6e8128d233a20493d73b13--

From: Steve Schultze <[email-masked]>
Date: Sat, 30 Oct 2010 11:05:50 -0400
To: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

Ben, I'm porting your comment below into this thread for the sake of =
subject-line clarity (none of this is WG-formation specific, I believe).

On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote:
> Paul wants client policy to decide whether to trust PKIX, DNSSEC or
> some mixture of the two. This seems not only reasonable, but
> unavoidable: clients will implement what suits them, and we are in no
> position to change that.
>=20
> Phillip wants the domain in question to be able to state its
> intentions w.r.t. the policy clients should use. This seems not
> unreasonable, also. Clients can choose to follow this or not.

What effect does this have on the MUST vs. MAY suggestions I made to the =
draft-hoffman-keys-linkage-from-dns-03 text?  I believe that what you =
are saying is that the spec should leave it open to the client how to =
react to different validation outcome permutations from PKIX and =
DNSSEC-secured KIDNS.  In that case, the two excerpts I quoted should be =
MAY, as I suggested.  This also means that I disagree with Paul, who =
thinks that MUST should be used.

I would note that, presuming KIDNS only affects client behavior when the =
client can directly verify that the records were validly DNSSEC-signed =
(is this everybody's assumption?), using a MUST creates a downgrade =
attack in which a MITM can force PKIX-only validation by simply blocking =
DNSSEC-validated DNS results.

"If the application receives zero usable certificate associations, it =
[MUST] process TLS in the normal fashion."

We want the client to be able to choose to require DNSSEC-validated =
KIDNS for all requests, if it wishes.  Otherwise what we're doing offers =
no greater security than the status quo.

On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote:
> Thank you for being explicit!
>=20
> At 10:14 PM +0100 10/28/10, Stephen Farrell wrote:
>> Having now caught up with the many recent messages, I'd also
>> be a bit concerned about the impact of:
>>=20
>>> "If a match between the certificate association(s) and the
>>> server's end entity certificate in TLS is not found, the
>>> TLS client MUST abort the handshake with an "access_denied" error."
>>=20
>> The concerns I have about it would include:
>>=20
>> - I'm not really sure if that same rule would be appropriate
>> for all applications that use TLS, nor for all deployments
>> of each protocol using TLS - basically the policy slippery
>> slope PHB is raising (from time to time:-)
>=20
> OK, maybe try being more explicit. For example, if this document was =
in fact an update to TLS, would you have the same concern? Or, if you =
want a SHOULD rather than a MUST, what would the specific exceptions be =
(or are you asking for a typical IETF mushy SHOULD)?

I don't know what Stephen Farrell is arguing for, but I'm arguing for an =
even more mushy MAY ;)

However, this is a feature because it gives the clients more options... =
including the option to improve upon the status quo of PKIX security =
even in the presence of a MITM (our assumed threat model).  It does so =
without forcing all clients to do this on day one, an impractical =
requirement.

On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote:
> "If the application receives zero usable certificate associations, it =
process TLS in the normal fashion."
> "If a match between the certificate association(s) and the server's =
end entity certificate in TLS is not found, the TLS client MUST abort =
the handshake with an "access_denied" error."
>=20
> I suggest:
>=20
> "If the application receives zero usable certificate associations, it =
MAY process TLS in the normal fashion."
> "If a match between the certificate association(s) and the server's =
end entity certificate in TLS is not found, the TLS client MAY abort the =
handshake with an "access_denied" error."

Date: Fri, 29 Oct 2010 10:59:23 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>, Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)
Reply-To: "Jeffrey A. Williams" <[email-masked]>

<HEAD>
<STYLE>body{font-family: Geneva,Arial,Helvetica,sans-serif;font-size:10pt;f=
ont-family:arial,sans-serif;background-color:#ffffff;color:black;}p{margin:=
0px}</STYLE>

<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18975"></HEAD>
<BODY id=3DcompText>Phillip and all,<BR><BR><BR>
<BLOCKQUOTE style=3D"BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MAR=
GIN-LEFT: 0px">-----Original Message----- <BR>From: Phillip Hallam-Baker <H=
[email-masked]><BR>Sent: Oct 29, 2010 9:12 AM <BR>To: Andrew Sullivan <AJS=
@SHINKURO.COM><BR>Cc: [email-masked] <BR>Subject: Re: [keyassure] WG Re=
view: Keys In DNS (kidns) <BR><BR>+1
<DIV><BR></DIV>
<DIV>These are certainly issues, but they are fixable issues.&nbsp;</DIV>
<DIV><BR></DIV>
<DIV>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.</DIV>
<DIV>&nbsp;</DIV>
<DIV>agreed here.</DIV>
<DIV><BR></DIV>
<DIV>A better way is to lightly graft on parts of the X.509 structure that =
provide useful enhancements onto DNSSEC.\</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp; not only useful, but perhaps advisable or even necessary.&nbsp;=
 X.509 IMO has long needed more indepth</DIV>
<DIV>review.<BR></DIV>
<DIV>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 is=
sue that most engineers simply do not want to think about.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Amen!&nbsp; However seems that we are going to have to at some limited=
 level or to some limited degree get</DIV>
<DIV>more involved in the issues regarding this.</DIV>
<DIV><BR></DIV>
<DIV>I can address Andrew's issue fairly cleanly by publishing an X.509v3 c=
ertificate for the KSK at the apex of each zone. But giving the full explan=
ation of the reasons why you would want to do it that way is going to invol=
ve a lot of business related issues that a lot of people don't have patienc=
e for.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Agreed.</DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV>That is not how I would address those issues if I was building complet=
ely from scratch. Given an unrestricted choice I would probably use somethi=
ng with angle brackets like SAML assertions. That is one of the use cases I=
 was originally&nbsp;commissioned&nbsp;to design the assertion&nbsp;infrast=
ructure&nbsp;SAML is based on for.</DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV class=3Dgmail_quote>On Fri, Oct 29, 2010 at 9:34 AM, Andrew Sullivan <=
SPAN dir=3Dltr>&lt;<A href=3D"mailto:[email-masked]" target=3D_blank>ajs@=
shinkuro.com</A>&gt;</SPAN> wrote:<BR>
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV class=3Dim>On Fri, Oct 29, 2010 at 01:33:47PM +0100, Ben Laurie wrote:=
<BR>&gt; None of these seem to me to be incompatible with each other. So, w=
hat<BR>&gt; is being discussed?<BR><BR></DIV>You've said this much more cle=
arly than I've managed to do so far. &nbsp;I<BR>completely agree.<BR><BR>As=
 an aside, I will note that there has been a similar tension in the<BR>DNSS=
EC community around trust anchors. &nbsp;Some operators feel that the<BR>on=
ly things that others may use for trust operations on their zones<BR>are th=
e ones that they are publishing _right now_, and anything else<BR>is danger=
ous. &nbsp;Others want to be able to build a history of trust<BR>anchors so=
 that it is possible to reconstruct this history and<BR>"replay" RFC5011 ev=
ents after some of the affected keys have been<BR>withdrawn.<BR><BR>In both=
 the dispute about what to do here and in the DNSSEC<BR>trust-history case,=
 we have what amounts to a disagreement about who<BR>gets to decide the tru=
st properties: whether the domain operator (or<BR>site operator or whatever=
) gets to determine what things are valid, or<BR>whether a client can make =
choices for itself using the trade-offs it<BR>likes.<BR><BR>My own view is =
that the latter is always possible on the Internet, and<BR>therefore I woul=
d like to have well-documented ways in which such<BR>trade-offs can be made=
 intelligently, so that users have a predictable<BR>mechanism. &nbsp;I full=
y understand the argument from the other point of<BR>view, however, but I t=
hink it is unrealistic to imagine that, if we<BR>don't provide some mechani=
sm for clients to make up their own minds,<BR>that they won't start doing a=
ll kinds of strange and wonderful things<BR>on their own.<BR><BR>Best,<BR>
<DIV class=3Dim><BR>A<BR><BR>--<BR>Andrew Sullivan<BR><A href=3D"mailto:ajs=
@shinkuro.com" target=3D_blank>[email-masked]</A><BR>Shinkuro, Inc.<BR>__=
_____________________________________________<BR></DIV>
<DIV>
<DIV></DIV>
<DIV class=3Dh5>keyassure mailing list<BR><A href=3D"mailto:keyassure@ietf.=
org" target=3D_blank>[email-masked]</A><BR><A href=3D"https://www.ietf.=
org/mailman/listinfo/keyassure" target=3D_blank>https://www.ietf.org/mailma=
n/listinfo/keyassure</A><BR></DIV></DIV></BLOCKQUOTE></DIV>
<DIV><BR><BR clear=3Dall><BR>-- <BR>Website: <A href=3D"http://hallambaker.=
com/" target=3D_blank>http://hallambaker.com/</A><BR><BR>Regards,<BR>Jeffre=
y A. Williams<BR>"Obedience of the law is the greatest freedom" -<BR>&nbsp;=
&nbsp; Abraham Lincoln<BR><BR>"Credit should go with the performance of dut=
y and not with what is very<BR>often the accident of glory" - Theodore Roos=
evelt<BR><BR>"If the probability be called P; the injury, L; and the burden=
, B; liability<BR>depends upon whether B is less than L multiplied by<BR>P:=
 i.e., whether B is less than PL."<BR>United States v. Carroll Towing&nbsp;=
 (159 F.2d 169 [2d Cir. 1947]<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR=
>Updated 1/26/04<BR>Network Eng. SR. Eng. Network data security</DIV>
<DIV>ABA member in good standing member ID 01257402 </DIV>
<DIV>E-Mail [email-masked]<BR>Phone: 214-244-4827<BR><BR><BR><BR></=
DIV></BLOCKQUOTE></BODY>

Date: Fri, 29 Oct 2010 10:12:26 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

--90e6ba2124fd529b2f0493c20ce1
Content-Type: text/plain; charset=ISO-8859-1

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

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

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.

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.

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

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

--90e6ba2124fd529b2f0493c20ce1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1<div><br></div><div>These are certainly issues, but they are fixable issu=
es.=A0</div><div><br></div><div>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.</div>
<div><br></div><div>A better way is to lightly graft on parts of the X.509 =
structure that provide useful enhancements onto DNSSEC.</div><div><br></div=
><div><br></div><div>PKI is the interface between the real world and the on=
line world. As a result a lot of the reasons something is necessary get int=
o the type of issue that most engineers simply do not want to think about.<=
/div>
<div><br></div><div>I can address Andrew&#39;s issue fairly cleanly by publ=
ishing an X.509v3 certificate for the KSK at the apex of each zone. But giv=
ing the full explanation of the reasons why you would want to do it that wa=
y is going to involve a lot of business related issues that a lot of people=
 don&#39;t have patience for.</div>
<div><br></div><div><br></div><div>That is not how I would address those is=
sues if I was building completely from scratch. Given an unrestricted choic=
e I would probably use something with angle brackets like SAML assertions. =
That is one of the use cases I was originally=A0commissioned=A0to design th=
e assertion=A0infrastructure=A0SAML is based on for.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Fri, Oct 29, 2010 at =
9:34 AM, Andrew Sullivan <span dir=3D"ltr">&lt;<a href=3D"mailto:ajs@shinku=
ro.com">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex;">
<div class=3D"im">On Fri, Oct 29, 2010 at 01:33:47PM +0100, Ben Laurie wrot=
e:<br>
&gt; None of these seem to me to be incompatible with each other. So, what<=
br>
&gt; is being discussed?<br>
<br>
</div>You&#39;ve said this much more clearly than I&#39;ve managed to do so=
 far. =A0I<br>
completely agree.<br>
<br>
As an aside, I will note that there has been a similar tension in the<br>
DNSSEC community around trust anchors. =A0Some operators feel that the<br>
only things that others may use for trust operations on their zones<br>
are the ones that they are publishing _right now_, and anything else<br>
is dangerous. =A0Others want to be able to build a history of trust<br>
anchors so that it is possible to reconstruct this history and<br>
&quot;replay&quot; RFC5011 events after some of the affected keys have been=
<br>
withdrawn.<br>
<br>
In both the dispute about what to do here and in the DNSSEC<br>
trust-history case, we have what amounts to a disagreement about who<br>
gets to decide the trust properties: whether the domain operator (or<br>
site operator or whatever) gets to determine what things are valid, or<br>
whether a client can make choices for itself using the trade-offs it<br>
likes.<br>
<br>
My own view is that the latter is always possible on the Internet, and<br>
therefore I would like to have well-documented ways in which such<br>
trade-offs can be made intelligently, so that users have a predictable<br>
mechanism. =A0I fully understand the argument from the other point of<br>
view, however, but I think it is unrealistic to imagine that, if we<br>
don&#39;t provide some mechanism for clients to make up their own minds,<br=
>
that they won&#39;t start doing all kinds of strange and wonderful things<b=
r>
on their own.<br>
<br>
Best,<br>
<div class=3D"im"><br>
A<br>
<br>
--<br>
Andrew Sullivan<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
Shinkuro, Inc.<br>
_______________________________________________<br>
</div><div><div></div><div class=3D"h5">keyassure mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--90e6ba2124fd529b2f0493c20ce1--

Date: Fri, 29 Oct 2010 09:42:57 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

--0016368e24c4e8afb10493c1a2f0
Content-Type: text/plain; charset=ISO-8859-1

+1

In addition to wanting to separate policy from key authentication for
architectural reasons, I want to at least have the option of expressing the
trust policy in terms of X.509 infrastructure.

One reason for this approach is that we have a lot of infrastructure for
managing X.509 certs already, both commercial and open source. For the
enterprise that is looking to manage large numbers of keys it is going to be
much easier for them to add rules to the DNS that state that all their certs
are issued under an X.509 root than to deploy a new system that interacts
with the DNS on every cert issue.

A second reason is that the X.509 approach has 20 years of history and there
is a lot of prior art we can point to.

On Fri, Oct 29, 2010 at 8:33 AM, Ben Laurie <[email-masked]> wrote:

> On 28 October 2010 01:12, Paul Wouters <[email-masked]> wrote:
> > On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote:
> >
> >> I think that this represents a superficial analysis of the problem.
> >
> > No Philip, you keep trying to drag in the cat's meow. I've already
> ignored
> > some claims you made about what I said. We understand you value PKIX. So
> > we do. We value DNSSEC. So should you.
> >
> >> This is a rather strange definition of 'separating' DNSSEC key assurance
> >> from PKIX. What is being proposed here is that the DNSSEC which
> >> is not yet deployed is to be promoted above PKIX which we have been
> >> working on and with for twenty plus years.
> >
> > It's your fear this is "above PKIX". If your PKIX system works well
> > enough, and is better then DNSSEC, why do you have this fear? You are
> > the one who keeps trying to mix DNSSEC and PKIX. I've made statements
> > I favour to keep these two separate, so they do not HAVE to interfere
> > with one another. I never said "above". I said "separate" and "according
> > to client policy". I'm bending over backwards to not interfere with
> > any current PKIX deployment, and requested the same in return (eg I'm
> > opposed to a CAA record).
> >
> > I would be interestd in what others who have not expressed themselves
> > have to say on these matters, but I believe my views (and yours) on this
> > topic have been stated clearly. Unless the IESG asks me for more input,
> > I'll refrain from further adding to this discussion.
>
> I am with David Conrad on the DoS attack: I don't understand what
> useful this seemingly endless discussion is actually _about_.
>
> Paul wants client policy to decide whether to trust PKIX, DNSSEC or
> some mixture of the two. This seems not only reasonable, but
> unavoidable: clients will implement what suits them, and we are in no
> position to change that.
>
> Phillip wants the domain in question to be able to state its
> intentions w.r.t. the policy clients should use. This seems not
> unreasonable, also. Clients can choose to follow this or not.
>
> He also wants to separate protocols so policy can apply to
> domain+protocol, not merely domain. This seems like an obvious
> requirement to me.
>
> None of these seem to me to be incompatible with each other. So, what
> is being discussed?
>
> >
> > Paul
> > _______________________________________________
> > keyassure mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/keyassure
> >
>

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

--0016368e24c4e8afb10493c1a2f0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1=A0<div><br></div><div>In addition to wanting to separate policy from key=
 authentication for architectural reasons, I want to at least have the opti=
on of expressing the trust policy in terms of X.509 infrastructure.</div><d=
iv>
<br></div><div>One reason for this approach is that we have a lot of infras=
tructure for managing X.509 certs already, both commercial and open source.=
 For the enterprise that is looking to manage large numbers of keys it is g=
oing to be much easier for them to add rules to the DNS that state that all=
 their certs are issued under an X.509 root than to deploy a new system tha=
t interacts with the DNS on every cert issue.</div>
<div><br></div><div>A second reason is that the X.509 approach has 20 years=
 of history and there is a lot of prior art we can point to.</div><div><br>=
<br><div class=3D"gmail_quote">On Fri, Oct 29, 2010 at 8:33 AM, Ben Laurie =
<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a=
>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div><div></div><div class=3D"h5">On 28 Oct=
ober 2010 01:12, Paul Wouters &lt;<a href=3D"mailto:[email-masked]">pau=
[email-masked]</a>&gt; wrote:<br>

&gt; On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote:<br>
&gt;<br>
&gt;&gt; I think that this represents a superficial analysis of the problem=
.<br>
&gt;<br>
&gt; No Philip, you keep trying to drag in the cat&#39;s meow. I&#39;ve alr=
eady ignored<br>
&gt; some claims you made about what I said. We understand you value PKIX. =
So<br>
&gt; we do. We value DNSSEC. So should you.<br>
&gt;<br>
&gt;&gt; This is a rather strange definition of &#39;separating&#39; DNSSEC=
 key assurance<br>
&gt;&gt; from PKIX. What is being proposed here is that the DNSSEC which<br=
>
&gt;&gt; is not yet deployed is to be promoted above PKIX which we have bee=
n<br>
&gt;&gt; working on and with for twenty plus years.<br>
&gt;<br>
&gt; It&#39;s your fear this is &quot;above PKIX&quot;. If your PKIX system=
 works well<br>
&gt; enough, and is better then DNSSEC, why do you have this fear? You are<=
br>
&gt; the one who keeps trying to mix DNSSEC and PKIX. I&#39;ve made stateme=
nts<br>
&gt; I favour to keep these two separate, so they do not HAVE to interfere<=
br>
&gt; with one another. I never said &quot;above&quot;. I said &quot;separat=
e&quot; and &quot;according<br>
&gt; to client policy&quot;. I&#39;m bending over backwards to not interfer=
e with<br>
&gt; any current PKIX deployment, and requested the same in return (eg I&#3=
9;m<br>
&gt; opposed to a CAA record).<br>
&gt;<br>
&gt; I would be interestd in what others who have not expressed themselves<=
br>
&gt; have to say on these matters, but I believe my views (and yours) on th=
is<br>
&gt; topic have been stated clearly. Unless the IESG asks me for more input=
,<br>
&gt; I&#39;ll refrain from further adding to this discussion.<br>
<br>
</div></div>I am with David Conrad on the DoS attack: I don&#39;t understan=
d what<br>
useful this seemingly endless discussion is actually _about_.<br>
<br>
Paul wants client policy to decide whether to trust PKIX, DNSSEC or<br>
some mixture of the two. This seems not only reasonable, but<br>
unavoidable: clients will implement what suits them, and we are in no<br>
position to change that.<br>
<br>
Phillip wants the domain in question to be able to state its<br>
intentions w.r.t. the policy clients should use. This seems not<br>
unreasonable, also. Clients can choose to follow this or not.<br>
<br>
He also wants to separate protocols so policy can apply to<br>
domain+protocol, not merely domain. This seems like an obvious<br>
requirement to me.<br>
<br>
None of these seem to me to be incompatible with each other. So, what<br>
is being discussed?<br>
<br>
&gt;<br>
&gt; Paul<br>
<div><div></div><div class=3D"h5">&gt; ____________________________________=
___________<br>
&gt; keyassure mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D"=
_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
&gt;<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--0016368e24c4e8afb10493c1a2f0--

Date: Fri, 29 Oct 2010 09:34:22 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

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

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

Date: Fri, 29 Oct 2010 13:33:47 +0100
From: Ben Laurie <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked], Phillip Hallam-Baker <[email-masked]>, [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

On 28 October 2010 01:12, Paul Wouters <[email-masked]> wrote:
> On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote:
>
>> I think that this represents a superficial analysis of the problem.
>
> No Philip, you keep trying to drag in the cat's meow. I've already ignored
> some claims you made about what I said. We understand you value PKIX. So
> we do. We value DNSSEC. So should you.
>
>> This is a rather strange definition of 'separating' DNSSEC key assurance
>> from PKIX. What is being proposed here is that the DNSSEC which
>> is not yet deployed is to be promoted above PKIX which we have been
>> working on and with for twenty plus years.
>
> It's your fear this is "above PKIX". If your PKIX system works well
> enough, and is better then DNSSEC, why do you have this fear? You are
> the one who keeps trying to mix DNSSEC and PKIX. I've made statements
> I favour to keep these two separate, so they do not HAVE to interfere
> with one another. I never said "above". I said "separate" and "according
> to client policy". I'm bending over backwards to not interfere with
> any current PKIX deployment, and requested the same in return (eg I'm
> opposed to a CAA record).
>
> I would be interestd in what others who have not expressed themselves
> have to say on these matters, but I believe my views (and yours) on this
> topic have been stated clearly. Unless the IESG asks me for more input,
> I'll refrain from further adding to this discussion.

I am with David Conrad on the DoS attack: I don't understand what
useful this seemingly endless discussion is actually _about_.

Paul wants client policy to decide whether to trust PKIX, DNSSEC or
some mixture of the two. This seems not only reasonable, but
unavoidable: clients will implement what suits them, and we are in no
position to change that.

Phillip wants the domain in question to be able to state its
intentions w.r.t. the policy clients should use. This seems not
unreasonable, also. Clients can choose to follow this or not.

He also wants to separate protocols so policy can apply to
domain+protocol, not merely domain. This seems like an obvious
requirement to me.

None of these seem to me to be incompatible with each other. So, what
is being discussed?

>
> Paul
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

To: Warren Kumari <[email-masked]>
Comments: In-reply-to Warren Kumari <[email-masked]> message dated "Thu, 28 Oct 2010 12:01:27 -0400."
Date: Thu, 28 Oct 2010 17:04:44 -0700
From: John Gilmore <[email-masked]>
Cc: [email-masked], Jaap Akkerhuis <[email-masked]>, IESG IESG <[email-masked]>, Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

> > On 28 Oct 2010, at 09:05, Jaap Akkerhuis wrote in response to DRC's:
> >>   To be blunt, I feel keyassure/kidns is being subject to a DoS
> >>   attack and gave up reading all messages (and most of my hope
> >>   about timely forward progress on this topic within the IETF)
> >>   some time ago.

I have nothing nice to say on the topic, so I will say nothing.

	John

Date: Thu, 28 Oct 2010 17:17:48 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Stephen Farrell <[email-masked]>,  Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and	draft-hoffman-keys-linkage-from-dns
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Stephen and all,

-----Original Message-----
>From: Stephen Farrell <[email-masked]>
>Sent: Oct 28, 2010 4:14 PM
>To: Paul Hoffman <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] PKIX/KIDNS validation results and	draft-hoffman-keys-linkage-from-dns
>
>
>Having now caught up with the many recent messages, I'd also
>be a bit concerned about the impact of:
>
>> "If a match between the certificate association(s) and the 
>> server's end entity certificate in TLS is not found, the
>> TLS client MUST abort the handshake with an "access_denied" error."
>
>The concerns I have about it would include:
>
>- I'm not really sure if that same rule would be appropriate
>  for all applications that use TLS, nor for all deployments
>  of each protocol using TLS - basically the policy slippery
>  slope PHB is raising (from time to time:-)

yeah this is a valid concern, but we do need to be explicit here.

>- I think the security implications (e.g. potential for it
>  being a DoS vector e.g. if some DNS management nodes
>  were compromised) would need to be considered

Absolutely.

>- We'd need to think about whether any corner cases might be
>  problematic e.g. where an LDAP query for a CRL was running
>  over TLS or something

Agreed here as well for what i would consider obvious and
perhaps significant reasons.  As such the relevant discussions
regarding this should be cooridinated with the LDAP WG accordingly.
How that is to be effected may be problamatic.

>- I'm not sure what RFCs would be being UPDATED by an
>  RFC saying that, nor whether something like that should
>  really be left to the TLS WG

Good point.  I'm not sure either.  But just leaving it to the
TLS WG without close coordination would seem to be a bit 
unwieldy to me.

>
>It could be that folks have already thought through some
>or all of that, and that that MUST is the right thing to
>do, but that's not clear to me at this stage, so I do think
>that a kidns WG (which I think is worth forming) would really
>have to figure out answers to the above.

FWIW and going out on a limb here, the kidns WG would seem to be
the most logical place to centeralize the discussion on your above
reasonable concerns/considerations.  
>
>S.
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

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

Date: Thu, 28 Oct 2010 14:52:53 -0700
To: Stephen Farrell <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

Thank you for being explicit!

At 10:14 PM +0100 10/28/10, Stephen Farrell wrote:
>Having now caught up with the many recent messages, I'd also
>be a bit concerned about the impact of:
>
>> "If a match between the certificate association(s) and the
>> server's end entity certificate in TLS is not found, the
>> TLS client MUST abort the handshake with an "access_denied" error."
>
>The concerns I have about it would include:
>
>- I'm not really sure if that same rule would be appropriate
>  for all applications that use TLS, nor for all deployments
>  of each protocol using TLS - basically the policy slippery
>  slope PHB is raising (from time to time:-)

OK, maybe try being more explicit. For example, if this document was in fact an update to TLS, would you have the same concern? Or, if you want a SHOULD rather than a MUST, what would the specific exceptions be (or are you asking for a typical IETF mushy SHOULD)?

>- I think the security implications (e.g. potential for it
>  being a DoS vector e.g. if some DNS management nodes
>  were compromised) would need to be considered

If a DNS management node were compromised, all bets are off anyway. I guess we thought that was obvious, but we should say that in the Security Considerations.

>- We'd need to think about whether any corner cases might be
>  problematic e.g. where an LDAP query for a CRL was running
>  over TLS or something

Those are no different in this document than in normal TLS, are they? That is, what does this document change in TLS that would add such a corner case? That would be important to analyze.

>- I'm not sure what RFCs would be being UPDATED by an
>  RFC saying that, nor whether something like that should
>  really be left to the TLS WG

It should be done in coordination with the TLS WG, if this WG is formed and this is the way that the WG wants to go.

>It could be that folks have already thought through some
>or all of that, and that that MUST is the right thing to
>do, but that's not clear to me at this stage, so I do think
>that a kidns WG (which I think is worth forming) would really
>have to figure out answers to the above.

Fully agree. Please fill in any of the above after the WG is formed and if this is the direction that the WG goes.

--Paul Hoffman, Director
--VPN Consortium

Date: Thu, 28 Oct 2010 17:25:21 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: =JeffH <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] fyi: draft-turner-dnssec-centric-pki-00.txt

On Thu, 28 Oct 2010, =JeffH wrote:

>
> 	Title		: DNSSEC-centric PKI
> 	Author(s)	: R. Housley, T. Polk, S. Turner
> 	Filename	: draft-turner-dnssec-centric-pki-00.txt
> 	Pages		: 6
> 	Date		: 2010-10-18

    Certification Authorities (CAs) take great care to ensure that the
    private key holder is associated with the domain name contained in
    the certificate. DNSSEC [RFC4033][RFC4034][RFC4035] offers an
    opportunity to eliminate complicated off-line processes.

I would not add value judgements like  with "take great care". Research
papers from  Kaminsky, Appelbaum and others have claimed otherwise. Nor
is it "offline" as it most often is just an email/MX verification.

Perhaps something like:

    Certification Authorities (CAs) ensure that the private key holder is
    associated with the domain name contained in the certificate, usually
    requiring some form of human interaction by the private key holder.
    DNSSEC [RFC4033][RFC4034][RFC4035] offers an alternative method where
    the association of private key holder and domain name is automated via
    the DNSSEC signing operations of the DNS zone.

Regarding Section 2 / 3

I prefer this solution of returning a CA/EE over the addition of a new CAA
record, if one wants to add to the existing PKIX infrastructure with DNSSEC.

    For TLS [RFC5246], when the TLS looks up the IP address in the DNS it
    can also request the CERT RR.  If the certificate that is provided in
    the TLS handshake matches the one retrieved from DNSSEC, then the
    client can accept it as a trusted certificate for that site, provided
    local policy allows this.  If the CA certificate is returned in the
    TLS handshake, the TLS client can verify that the TLS server
    certificate was issued under that CA.

It is not entirely clear what to do with conflicting results. If the
CERT (or CA) has expired, or contains an invalid SIG, should the CERT
be rejected?  If the DNSSEC sig was bad, the record would never be
received for processing, and a servfail would be returned. Should a
client continue with only PKIX after a ServFail or not? These should
probably be local policy decisions, but the draft does not state these.

I'm also not entirely sure how to do this for a large site with many domains.
Does the CN= and/or subjectAltname matter? Does it need to match the DNS
queried hostname? Or is it ignored? (If it is ignored, one could argue that
the TLSFP approach might make more sense - we would have smaller DNS packets
to deal with as a fingerprint is much smaller then a full cert with many
subjectAltnames)

Paul

Date: Thu, 28 Oct 2010 22:14:19 +0100
From: Stephen Farrell <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

Having now caught up with the many recent messages, I'd also
be a bit concerned about the impact of:

> "If a match between the certificate association(s) and the 
> server's end entity certificate in TLS is not found, the
> TLS client MUST abort the handshake with an "access_denied" error."

The concerns I have about it would include:

- I'm not really sure if that same rule would be appropriate
  for all applications that use TLS, nor for all deployments
  of each protocol using TLS - basically the policy slippery
  slope PHB is raising (from time to time:-)
- I think the security implications (e.g. potential for it
  being a DoS vector e.g. if some DNS management nodes
  were compromised) would need to be considered
- We'd need to think about whether any corner cases might be
  problematic e.g. where an LDAP query for a CRL was running
  over TLS or something
- I'm not sure what RFCs would be being UPDATED by an
  RFC saying that, nor whether something like that should
  really be left to the TLS WG

It could be that folks have already thought through some
or all of that, and that that MUST is the right thing to
do, but that's not clear to me at this stage, so I do think
that a kidns WG (which I think is worth forming) would really
have to figure out answers to the above.

S.

Date: Thu, 28 Oct 2010 13:35:46 -0700
From: =JeffH <[email-masked]>
To: [email-masked]
Subject: [keyassure] fyi: draft-turner-dnssec-centric-pki-00.txt

Subject: I-D ACTION:draft-turner-dnssec-centric-pki-00.txt
From: [email-masked]
Date: Mon, 18 Oct 2010 16:45:02 -0700 (PDT)
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: DNSSEC-centric PKI
	Author(s)	: R. Housley, T. Polk, S. Turner
	Filename	: draft-turner-dnssec-centric-pki-00.txt
	Pages		: 6
	Date		: 2010-10-18
	
This draft is input to the KIDNS discussion.  The procedures defined
    herein provide a general Public Key Infrastructure (PKI) mechanism
    that leverages DNSSEC.  This is compatible with RFC 5280.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-turner-dnssec-centric-pki-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Date: Thu, 28 Oct 2010 10:31:21 -0700
To: Stephen Schultze <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

At 1:11 PM -0400 10/28/10, Stephen Schultze wrote:
>draft-hoffman-keys-linkage-from-dns-03:
>
>"If the application receives zero usable certificate associations, it process TLS in the normal fashion."
>"If a match between the certificate association(s) and the server's end entity certificate in TLS is not found, the TLS client MUST abort the handshake with an "access_denied" error."
>
>I suggest:
>
>"If the application receives zero usable certificate associations, it MAY process TLS in the normal fashion."
>"If a match between the certificate association(s) and the server's end entity certificate in TLS is not found, the TLS client MAY abort the handshake with an "access_denied" error."
>
>This leaves it up to the client how to deal with the relationship between KIDNS and PKIX validation results.

RFC 2119 language is used for two reasons: interoperability and security.

The first of your two changes makes no sense: if there are no usable certificate associations, then there is no new information for TLS. If an implementer has chosen not to follow the TLS semantics, there is nothing that this protocol has to offer.

Can you say how you think your second change improves either interoperability or security?

--Paul Hoffman, Director
--VPN Consortium

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Thu, 28 Oct 2010 13:11:56 -0400
Subject: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

draft-hoffman-keys-linkage-from-dns-03:

"If the application receives zero usable certificate associations, it  
process TLS in the normal fashion."
"If a match between the certificate association(s) and the server's  
end entity certificate in TLS is not found, the TLS client MUST abort  
the handshake with an "access_denied" error."

I suggest:

"If the application receives zero usable certificate associations, it  
MAY process TLS in the normal fashion."
"If a match between the certificate association(s) and the server's  
end entity certificate in TLS is not found, the TLS client MAY abort  
the handshake with an "access_denied" error."

This leaves it up to the client how to deal with the relationship  
between KIDNS and PKIX validation results.

From: Warren Kumari <[email-masked]>
To: Lawrence Conroy <[email-masked]>
Date: Thu, 28 Oct 2010 12:01:27 -0400
Cc: Jaap Akkerhuis <[email-masked]>, [email-masked], IESG IESG <[email-masked]>, Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

On Oct 28, 2010, at 5:06 AM, Lawrence Conroy wrote:

> On 28 Oct 2010, at 09:05, Jaap Akkerhuis wrote in response to DRC's:
>>   To be blunt, I feel keyassure/kidns is being subject to a DoS
>>   attack and gave up reading all messages (and most of my hope
>>   about timely forward progress on this topic within the IETF)
>>   some time ago.
>>
>> You are not the only one. I did the same.

Please come back, we need you all....

>>
>> 	jaap
>
> To which I quip:
> I note you don't say a DDoS attack.

Ok, this is not the first time that I have heard rumblings like this  
-- I have also heard this in person from folk, and it seems to be  
leading to fragmentation of the group, and valuable contributors  
throwing in the towel and not participating. I urge these folk to come  
back, and, if necessary, simply kill-file the source of the DoS or, if  
you feel that that is not enough to allow you to happily participate,  
explicitly ask (on list) for moderation of the source the attack.

I am also asking the list participants to please try and stay on topic  
and not attempt to drag the conversation into areas that are outside  
the interest of the rest of the (proposed) WG. If you are the lone  
voice in the wilderness (or if there is only one other person  
interested), please strongly consider doing your document as an  
individual submission that is mentioned *but not discussed* in the WG.  
The IETF is a consensus driven organization -- one person does not  
consensus make....

The purpose of this list is to make forward progress, come to  
consensus on what the group wants and then get something done.

> It is a pity, as the draft(s) do need IETF review -- they are
> still rough in places.

Yes, yes they do... The *group* (and the IETF) will contribute to the  
final documents, and they will incorporate group consensus - I realize  
that there is noise at the moment (for which I apologize), but ask for  
people to *please* try and ignore the noise (and attempts to draw us  
down ratholes) and continue to participate / please come back if they  
have gotten fed up...

> That won't be easy in the current noise.
> ... we're civil to those who cavil.

Yup, and we do our best to tolerate those who are not, even if it it  
trying...

W

>
> atb,  Lawrence
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

--
I once absend-mindedly ordered Three Mile Island dressing in a  
restaurant and, with great presence of mind, they brought Thousand  
Island Dressing and a bottle of chili sauce.
     -- Terry Pratchett

Date: Thu, 28 Oct 2010 12:01:21 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: David Conrad <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

--0016e68ee136fd50750493af7328
Content-Type: text/plain; charset=ISO-8859-1

I keep asking questions because I never get answers.

I keep asking why you want to conflate a mechanism that enables new means of
establishing a key as valid with a new means of declaring PKIX certificates
to be invalid.

Those are two entirely separate issues in my view and it is not appropriate
to reuse the DNS CERT record to do both.

Each time I ask the question why this has to be a requirement I get
non-response responses and so I keep asking the question and I am going to
keep on asking until I get a substantive response.

The first priority in any IETF working group has to be to do no harm. There
is no reason that using DNSSEC to authenticate keys for my SMTP service
should require me to change the way I manage my Web service. If my objective
was to sabotage the effort as you keep accusing me of, I would do everything
I could to make sure this feature stayed in the draft because it is a poison
pill that is going to totally kill adoption.

I keep asking for a justification and I never get one. Instead I get
non-response responses, to wit:

* Various restatements of the requirements that do not address the question
of why it is necessary to effectively force sites who deploy DNSSEC
authenticated keys to stop all use of CA issued certs.

* This is the wrong time to ask the question.

* It is now too late to ask the question because the group has decided.

* Personal attacks.

* Denials that this is part of the proposal.

* Denials that specifying criteria for evaluating trust chains is part of
security policy

* Claims to the effect that the difficult problems of PKI magically
disappear when the bits are expressed in DNSSEC syntax

* Suggestions to the effect that nobody should discuss this with the IESG
because it has been discussed on the mailing list.

* Suggestions to the effect that this should not be discussed on the mailing
list as it should be decided by the IESG.

It is very simple, if you want to shorten the discussion then stick to the
topic and answer the question.

On Wed, Oct 27, 2010 at 8:39 PM, David Conrad <[email-masked]> wrote:

> On Oct 27, 2010, at 2:12 PM, Paul Wouters wrote:
> > I would be interestd in what others who have not expressed themselves
> > have to say on these matters, but I believe my views (and yours) on this
> > topic have been stated clearly.
>
> To be blunt, I feel keyassure/kidns is being subject to a DoS attack and
> gave up reading all messages (and most of my hope about timely forward
> progress on this topic within the IETF) some time ago.
>
> Regards,
> -drc
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

--0016e68ee136fd50750493af7328
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I keep asking questions because I never get answers.<div><br></div><div>I k=
eep asking why you want to conflate a mechanism that enables new means of e=
stablishing a key as valid with a new means of declaring PKIX certificates =
to be invalid.</div>
<div><br></div><div>Those are two entirely separate issues in my view and i=
t is not appropriate to reuse the DNS CERT record to do both.=A0</div><div>=
<br></div><div><br></div><div>Each time I ask the question why this has to =
be a requirement I get non-response responses and so I keep asking the ques=
tion and I am going to keep on asking until I get a substantive response.</=
div>
<div><br></div><div>The first priority in any IETF working group has to be =
to do no harm. There is no reason that using DNSSEC to authenticate keys fo=
r my SMTP service should require me to change the way I manage my Web servi=
ce. If my objective was to sabotage the effort as you keep accusing me of, =
I would do everything I could to make sure this feature stayed in the draft=
 because it is a poison pill that is going to totally kill adoption.=A0</di=
v>
<div><br></div><div><br></div><div>I keep asking for a justification and I =
never get one. Instead I get non-response responses, to wit:</div><div><br>=
</div><div>* Various restatements of the requirements that do not address t=
he question of why it is necessary to effectively force sites who deploy DN=
SSEC authenticated keys to stop all use of CA issued certs.</div>
<div><br></div><div>* This is the wrong time to ask the question.</div><div=
><br></div><div>* It is now too late to ask the question because the group =
has decided.</div><div><br></div><div>* Personal attacks.=A0</div><div><br>
</div><div>* Denials that this is part of the proposal.</div><div><br></div=
><div>* Denials that specifying criteria for evaluating trust chains is par=
t of security policy=A0</div><div><br></div><div>* Claims to the effect tha=
t the difficult problems of PKI magically disappear when the bits are expre=
ssed in DNSSEC syntax</div>
<div><br></div><div>* Suggestions to the effect that nobody should discuss =
this with the IESG because it has been discussed on the mailing list.</div>=
<div><br></div><div>* Suggestions to the effect that this should not be dis=
cussed on the mailing list as it should be decided by the IESG.</div>
<div><br></div><div>It is very simple, if you want to shorten the discussio=
n then stick to the topic and answer the question.=A0</div><div><br><br><di=
v class=3D"gmail_quote">On Wed, Oct 27, 2010 at 8:39 PM, David Conrad <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]=
</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On Oct 27, 2010, at 2:12 =
PM, Paul Wouters wrote:<br>
&gt; I would be interestd in what others who have not expressed themselves<=
br>
&gt; have to say on these matters, but I believe my views (and yours) on th=
is<br>
&gt; topic have been stated clearly.<br>
<br>
</div>To be blunt, I feel keyassure/kidns is being subject to a DoS attack =
and gave up reading all messages (and most of my hope about timely forward =
progress on this topic within the IETF) some time ago.<br>
<br>
Regards,<br>
-drc<br>
<div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
keyassure mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--0016e68ee136fd50750493af7328--

From: Lawrence Conroy <[email-masked]>
Date: Thu, 28 Oct 2010 10:06:00 +0100
To: Jaap Akkerhuis <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

On 28 Oct 2010, at 09:05, Jaap Akkerhuis wrote in response to DRC's:
>    To be blunt, I feel keyassure/kidns is being subject to a DoS
>    attack and gave up reading all messages (and most of my hope
>    about timely forward progress on this topic within the IETF)
>    some time ago.
> 
> You are not the only one. I did the same.
> 
> 	jaap

To which I quip:
 I note you don't say a DDoS attack.
It is a pity, as the draft(s) do need IETF review -- they are
still rough in places. That won't be easy in the current noise.
... we're civil to those who cavil.

atb,  Lawrence

To: David Conrad <[email-masked]>
Comments: In-reply-to David Conrad <[email-masked]> message dated "Wed, 27 Oct 2010 14:39:54 -1000."
Date: Thu, 28 Oct 2010 10:05:15 +0200
From: Jaap Akkerhuis <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

    To be blunt, I feel keyassure/kidns is being subject to a DoS
    attack and gave up reading all messages (and most of my hope
    about timely forward progress on this topic within the IETF)
    some time ago.
    
You are not the ony one. I did he same.

	jaap

Date: Wed, 27 Oct 2010 21:03:23 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

--0016363b82769e87820493a2e8a8
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Oct 27, 2010 at 8:12 PM, Paul Wouters <[email-masked]> wrote:

> On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote:
>
>  I think that this represents a superficial analysis of the problem.
>>
>
> No Philip, you keep trying to drag in the cat's meow. I've already ignored
> some claims you made about what I said. We understand you value PKIX. So
> we do. We value DNSSEC. So should you.

Which is precisely why I have spent the last year developing a security
policy scheme that is based on DNSSEC.

>  This is a rather strange definition of 'separating' DNSSEC key assurance
>> from PKIX. What is being proposed here is that the DNSSEC which
>> is not yet deployed is to be promoted above PKIX which we have been
>> working on and with for twenty plus years.
>>
>
> It's your fear this is "above PKIX". If your PKIX system works well
> enough, and is better then DNSSEC, why do you have this fear? You are
> the one who keeps trying to mix DNSSEC and PKIX. I've made statements
> I favour to keep these two separate, so they do not HAVE to interfere
> with one another. I never said "above". I said "separate" and "according
> to client policy". I'm bending over backwards to not interfere with
> any current PKIX deployment, and requested the same in return (eg I'm
> opposed to a CAA record).
>

You are putting words into my mouth here.

The effect of this proposal is that if it is accepted there will be PKIX
certificates that a client would currently consider valid that will now be
considered invalid. That is not keeping the systems separate as you claim,
it is the opposite. If I define a PGP key it does not invalidate my S/MIME
cert. If I acquire an S/MIME cert it does not invalidate my PGP key.

All I am saying here is that a given mechanism must either validate keys or
it should invalidate keys. Here we have a mechanism where the act of
validating one key automatically invalidates all others bound to the same
name for those clients that observe the MUST requirements of the spec.

I don't think that is necessary, I don't think that is useful. And I
definitely think that we need to have a justification for joining the two
together.

I am pretty sure that there is history here with respect to security policy
and that some section of the community has been burned really badly with an
attempt to do security policy. But nobody seems able to tell me what it is.

I would be interestd in what others who have not expressed themselves
> have to say on these matters, but I believe my views (and yours) on this
> topic have been stated clearly. Unless the IESG asks me for more input,
> I'll refrain from further adding to this discussion.
>

So you ask a bunch of slanted questions and then retire from the field with
the implication that I should not answer them?

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

--0016363b82769e87820493a2e8a8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, Oct 27, 2010 at 8:12 PM, Paul Wo=
uters <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul@xele=
rance.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote:<br>
<br>
</div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think that this represents a superficial analysis of the problem.<br>
</blockquote>
<br></div>
No Philip, you keep trying to drag in the cat&#39;s meow. I&#39;ve already =
ignored<br>
some claims you made about what I said. We understand you value PKIX. So<br=
>
we do. We value DNSSEC. So should you.</blockquote><div><br></div><div>Whic=
h is precisely why I have spent the last year developing a security policy =
scheme that is based on DNSSEC.</div><div><br></div><div><br></div><div>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
This is a rather strange definition of &#39;separating&#39; DNSSEC key assu=
rance from PKIX. What is being proposed here is that the DNSSEC which<br>
is not yet deployed is to be promoted above PKIX which we have been working=
 on and with for twenty plus years.<br>
</blockquote>
<br></div>
It&#39;s your fear this is &quot;above PKIX&quot;. If your PKIX system work=
s well<br>
enough, and is better then DNSSEC, why do you have this fear? You are<br>
the one who keeps trying to mix DNSSEC and PKIX. I&#39;ve made statements<b=
r>
I favour to keep these two separate, so they do not HAVE to interfere<br>
with one another. I never said &quot;above&quot;. I said &quot;separate&quo=
t; and &quot;according<br>
to client policy&quot;. I&#39;m bending over backwards to not interfere wit=
h<br>
any current PKIX deployment, and requested the same in return (eg I&#39;m<b=
r>
opposed to a CAA record).<br>
</blockquote><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote=
">You are putting words into my mouth here.=A0</div><div class=3D"gmail_quo=
te"><br></div><div class=3D"gmail_quote">The effect of this proposal is tha=
t if it is accepted there will be PKIX certificates that a client would cur=
rently consider valid that will now be considered invalid. That is not keep=
ing the systems separate as you claim, it is the opposite. If I define a PG=
P key it does not invalidate my S/MIME cert. If I acquire an S/MIME cert it=
 does not invalidate my PGP key.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">All I am sa=
ying here is that a given mechanism must either validate keys or it should =
invalidate keys. Here we have a mechanism where the act of validating one k=
ey automatically invalidates all others bound to the same name for those cl=
ients that observe the MUST requirements of the spec.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">I don&#39;t=
 think that is necessary, I don&#39;t think that is useful. And I definitel=
y think that we need to have a justification for joining the two together.=
=A0</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><br></div><=
div class=3D"gmail_quote">I am pretty sure that there is history here with =
respect to security policy and that some section of the community has been =
burned really badly with an attempt to do security policy. But nobody seems=
 able to tell me what it is.=A0</div>
<div class=3D"gmail_quote"><br></div><br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I would be interestd in what others who have not expressed themselves<br>
have to say on these matters, but I believe my views (and yours) on this<br=
>
topic have been stated clearly. Unless the IESG asks me for more input,<br>
I&#39;ll refrain from further adding to this discussion.<font class=3D"Appl=
e-style-span" color=3D"#888888"><br></font></blockquote><div><br></div><div=
>So you ask a bunch of slanted questions and then retire from the field wit=
h the implication that I should not answer them?=A0</div>
</div><br>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallam=
baker.com/</a><br><br>

--0016363b82769e87820493a2e8a8--

From: David Conrad <[email-masked]>
Date: Wed, 27 Oct 2010 14:39:54 -1000
To: Paul Wouters <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

On Oct 27, 2010, at 2:12 PM, Paul Wouters wrote:
> I would be interestd in what others who have not expressed themselves
> have to say on these matters, but I believe my views (and yours) on =
this
> topic have been stated clearly.

To be blunt, I feel keyassure/kidns is being subject to a DoS attack and =
gave up reading all messages (and most of my hope about timely forward =
progress on this topic within the IETF) some time ago.

Regards,
-drc

Date: Wed, 27 Oct 2010 17:13:45 -0700
To: Warren Kumari <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] DRAFT Agenda for KIDNS BOF.

At 7:29 PM -0400 10/27/10, Warren Kumari wrote:
>o draft-hoffman-keys-linkage-from-dns                  45 minutes
>  Using Secure DNS to Associate Certificates with Domain Names For TLS.
>  Paul Hoffman

Errr, no. There are approximately five drafts that have been discussed on the list so far, and I intend to bring up proposals from all of them. FWIW, Jakob Schlyter and I are working together on this, and he and I have already found things that the other one overlooked.

The talk is currently titled "Some of the Early KIDNS Proposals", and I think that is what should be in the agenda. You can list Jakob and I, although only I will be giving the talk.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 27 Oct 2010 20:12:56 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote:

> I think that this represents a superficial analysis of the problem.

No Philip, you keep trying to drag in the cat's meow. I've already ignored
some claims you made about what I said. We understand you value PKIX. So
we do. We value DNSSEC. So should you.

> This is a rather strange definition of 'separating' DNSSEC key assurance from PKIX. What is being proposed here is that the DNSSEC which
> is not yet deployed is to be promoted above PKIX which we have been working on and with for twenty plus years.

It's your fear this is "above PKIX". If your PKIX system works well
enough, and is better then DNSSEC, why do you have this fear? You are
the one who keeps trying to mix DNSSEC and PKIX. I've made statements
I favour to keep these two separate, so they do not HAVE to interfere
with one another. I never said "above". I said "separate" and "according
to client policy". I'm bending over backwards to not interfere with
any current PKIX deployment, and requested the same in return (eg I'm
opposed to a CAA record).

I would be interestd in what others who have not expressed themselves
have to say on these matters, but I believe my views (and yours) on this
topic have been stated clearly. Unless the IESG asks me for more input,
I'll refrain from further adding to this discussion.

Paul

From: Warren Kumari <[email-masked]>
Date: Wed, 27 Oct 2010 19:29:01 -0400
To: [email-masked]
Subject: [keyassure] DRAFT Agenda for KIDNS BOF.

Hello all,

Here is the draft agenda for the KIDNS BOF on Thursday. As always, =
subject to change, may cause baldness, etc.

W

THURSDAY, November 11, 2010
1520-1720 Afternoon Session II
Garden Ballroom 1
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
=20
CHAIR(s):  Warren Kumari <[email-masked]>
           Ondrej Sury   <[email-masked]>
=20
o Administrivia                                        15 minutes
  Chairs
  =20
  - Note Well
  - Scribe
  - Blue Sheets
  - Document Status

o Working group goals and agenda, charter, etc.
  Ondrej Sury					       30 minutes
=20
o draft-hoffman-keys-linkage-from-dns                  45 minutes
  Using Secure DNS to Associate Certificates with Domain Names For TLS.
  Paul Hoffman

o draft-turner-dnssec-centric-pki-00                   30 minutes
  DNSSEC-centric PKI.
  Sean Turner

o Discussions on what we are trying to accomplish in this group,=20
  charter poking, etc.=

Date: Wed, 27 Oct 2010 15:43:35 -0700
From: =JeffH <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

I support a working group being formed.

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

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

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.

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

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

 > 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
                                      ^^^^^^^^
                                       verify

 > 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.
                   ^^^                ^^^^^^^^^^^^
                   del            it and/or its delegates control.

 > 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
                                                                       ^
                                                                     then

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

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.

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

HTH,

=JeffH

Date: Wed, 27 Oct 2010 17:07:19 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

--001485f6d1ae5c58e004939f9cb9
Content-Type: text/plain; charset=ISO-8859-1

I think that this represents a superficial analysis of the problem. If we
were going to act on this set of concerns we have to start from a far more
precise definition of the problem and a considerably more thorough analysis
of the security considerations.

It is reasonably easy to identify issues with the CA SSL system because it
has been deployed 15 years and we have a lot of experience. At the moment,
DNSSEC is an unknown. And what is worse it is really difficult to have a
public debate about the precise level of security DNSSEC achieves because
there are lots of people involved in deployment of DNSSEC who fear that any
open discussion of the limitations might be used to provide a pretext for
further delay.

This is a rather strange definition of 'separating' DNSSEC key assurance
from PKIX. What is being proposed here is that the DNSSEC which is not yet
deployed is to be promoted above PKIX which we have been working on and with
for twenty plus years.

I am not suggesting that we do not support this type of semantics, merely
that these be kept separated from any new mechanism for signing keys.

The ESRV proposal I have a draft out on is a proposal for an extensible
security policy framework. I think that if there is to be any work on
security policy we have to address the pieces that are easiest to define and
provide the greatest benefit first.

Some parts of the security policy swamp are considered to be inevitable rat
holes. Specification of which trust anchor is allowed to be used for which
purpose is considered the swampiest. So I am not proposing to charge into
that part of the swamp first.

If we have a mechanism that allows a domain to state 'SSL is always offered'
and a mechanism that allows sites to generate domain validated keys at no
additional out of pocket cost beyond that of deploying DNSSEC we are then in
a position to be able to make cryptography the default and retire the
padlock icon and DV certificates completely. The swamp is drained.

On Wed, Oct 27, 2010 at 2:47 PM, Paul Wouters <[email-masked]> wrote:

> On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote:
>
>  We can end this discussion now if the proposers are willing to accept:
>>
>> "If a match between the certificate
>>    association(s) and the server's end entity certificate in TLS is not
>>    found, TLS path processing MUST be performed as if no TLSFP record was
>> published"
>>
>
> I'd rather not see this. If a host is compromised, an attacker can change
> the cert, get it signed by a rogue/sloppy CA, and get it to ignore the
> entire DNSSEC trust chain. In other words, DNSSEC trust is sacrificed
> for another trust hierarchy (The CA one).
>
> I think it makes more sense to say if a DNSSEC protected record is wrong,
> then treat it as a problem, don't ignore it, provided your client policy
> is to use TLSFP/DNSSEC.
>
> Similarly, I don't expect a client with a CA policy to accept an
> invalid/expired CERT based on the fact that the TLSFP record happens
> to match.
>
> It is very important we do not start mixing CA and DNSSEC based trust
> models, or we end up with the worst of both worlds.
>
> Paul
>

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

--001485f6d1ae5c58e004939f9cb9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think that this represents a superficial analysis of the problem. If we w=
ere going to act on this set of concerns we have to start from a far more p=
recise definition of the problem and a considerably more thorough analysis =
of the security considerations.<div>
<br></div><div>It is reasonably easy to identify issues with the CA SSL sys=
tem because it has been deployed 15 years and we have a lot of experience. =
At the moment, DNSSEC is an unknown. And what is worse it is really difficu=
lt to have a public debate about the precise level of security DNSSEC achie=
ves because there are lots of people involved in deployment of DNSSEC who f=
ear that any open discussion of the limitations might be used to provide a =
pretext for further delay.</div>
<div><br></div><div><br></div><div>This is a rather strange definition of &=
#39;separating&#39; DNSSEC key assurance from PKIX. What is being proposed =
here is that the DNSSEC which is not yet deployed is to be promoted above P=
KIX which we have been working on and with for twenty plus years.</div>
<div><br></div><div><br></div><div>I am not suggesting that we do not suppo=
rt this type of semantics, merely that these be kept separated from any new=
 mechanism for signing keys.</div><div><br></div><div>The ESRV proposal I h=
ave a draft out on is a proposal for an extensible security policy framewor=
k. I think that if there is to be any work on security policy we have to ad=
dress the pieces that are easiest to define and provide the greatest benefi=
t first.</div>
<div><br></div><div>Some parts of the security policy swamp are considered =
to be inevitable rat holes. Specification of which trust anchor is allowed =
to be used for which purpose is considered the swampiest. So I am not propo=
sing to charge into that part of the swamp first.</div>
<div><br></div><div>If we have a mechanism that allows a domain to state &#=
39;SSL is always offered&#39; and a mechanism that allows sites to generate=
 domain validated keys at no additional out of pocket cost beyond that of d=
eploying DNSSEC we are then in a position to be able to make cryptography t=
he default and retire the padlock icon and DV certificates completely. The =
swamp is drained.</div>
<div><br></div><div><br><br><div class=3D"gmail_quote">On Wed, Oct 27, 2010=
 at 2:47 PM, Paul Wouters <span dir=3D"ltr">&lt;<a href=3D"mailto:paul@xele=
rance.com">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex;">
<div class=3D"im">On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
We can end this discussion now if the proposers are willing to accept:<br>
<br>
&quot;If a match between the certificate<br>
=A0=A0 association(s) and the server&#39;s end entity certificate in TLS is=
 not<br>
=A0=A0 found,=A0TLS path processing MUST be performed as if no TLSFP record=
 was published&quot;<br>
</blockquote>
<br></div>
I&#39;d rather not see this. If a host is compromised, an attacker can chan=
ge<br>
the cert, get it signed by a rogue/sloppy CA, and get it to ignore the<br>
entire DNSSEC trust chain. In other words, DNSSEC trust is sacrificed<br>
for another trust hierarchy (The CA one).<br>
<br>
I think it makes more sense to say if a DNSSEC protected record is wrong,<b=
r>
then treat it as a problem, don&#39;t ignore it, provided your client polic=
y<br>
is to use TLSFP/DNSSEC.<br>
<br>
Similarly, I don&#39;t expect a client with a CA policy to accept an<br>
invalid/expired CERT based on the fact that the TLSFP record happens<br>
to match.<br>
<br>
It is very important we do not start mixing CA and DNSSEC based trust<br>
models, or we end up with the worst of both worlds.<br><font color=3D"#8888=
88">
<br>
Paul<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--001485f6d1ae5c58e004939f9cb9--

Date: Wed, 27 Oct 2010 14:51:14 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>, Andrew Sullivan <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)
Reply-To: "Jeffrey A. Williams" <[email-masked]>

<HEAD>
<STYLE>body{font-size:10pt;font-family:arial,sans-serif;background-color:#f=
fffff;color:black;}p{margin:0px;}</STYLE>

<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18975"></HEAD>
<BODY id=3DcompText>
<P>Phillip and all,</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<BLOCKQUOTE style=3D"BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MAR=
GIN-LEFT: 0px">-----Original Message----- <BR>From: Phillip Hallam-Baker <H=
[email-masked]><BR>Sent: Oct 27, 2010 12:39 PM <BR>To: Andrew Sullivan <AJ=
[email-masked]><BR>Cc: [email-masked], [email-masked] <BR>Subject: Re: [=
keyassure] WG Review: Keys In DNS (kidns) <BR><BR>This is a charter discuss=
ion.=20
<DIV><BR></DIV>
<DIV>The question of Security Policy is a scope issue for the charter.</DIV=
>
<DIV>&nbsp;</DIV>
<DIV>Agreed.</DIV>
<DIV><BR></DIV>
<DIV>Thus the fact that we have proposals that attempt to address that scop=
e is entirely relevant to this discussion.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Logically correct, so agreed.</DIV>
<DIV><BR></DIV>
<DIV>I do not understand why you would think otherwise.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I do I think.&nbsp; There seems to be a reluctance to recognize or acc=
ept that for some WG security issues are</DIV>
<DIV>intertwined with policy decisions and vise versa.&nbsp; </DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV>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 t=
o approve the WG charter and then reject the WG document proposals as out o=
f scope because they thought that they were agreeing to something else.</DI=
V>
<DIV>&nbsp;</DIV>
<DIV>Maybe not the worst outcome, but certainly not a good one IMO.</DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV>I am finding the rules of engagement here to be rather peculiar. It se=
ems that it is unacceptable for me to suggest that what is being proposed i=
s what the documents and the authors say that they are proposing while it i=
s fine for Richard to make insulting accusations.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp; FWIW, seems that there is some Fear, uncertainty, and doubt , &=
lt; FUD&nbsp;&gt; as there is with almost any security</DIV>
<DIV>related protocol consideration.&nbsp; That FUD, which is not one of an=
 insulting nature, but one borne of the very</DIV>
<DIV>nature of what any WG on such considerations may have in respect to po=
licy and politics &lt; yuk &gt; that are</DIV>
<DIV>unfortunately intertwined accordingly.&nbsp; Of course the rodent-hole=
s and fire pits that all too often unfortunately</DIV>
<DIV>come along with same, sometimes get deep/wide/politically-vemin infest=
ed/hot accordingly and leaving</DIV>
<DIV>uncertainty in the wake.&nbsp;&nbsp; So I wonder if this sort of FUD w=
as not the FUD Richard was referring to? I'll</DIV>
<DIV>assume it was for now or until Richard confers otherwise.</DIV>
<DIV><BR><BR>
<DIV class=3Dgmail_quote>On Wed, Oct 27, 2010 at 12:57 PM, Andrew Sullivan =
<SPAN dir=3Dltr>&lt;<A href=3D"mailto:[email-masked]" target=3D_blank>ajs=
@shinkuro.com</A>&gt;</SPAN> wrote:<BR>
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV class=3Dim>On Wed, Oct 27, 2010 at 12:41:28PM -0400, Phillip Hallam-Ba=
ker wrote:<BR>&gt; I was responding to an unfair and untrue attack that ass=
erted that I was<BR>&gt; spreading FUD.<BR><BR></DIV>I don't care about tha=
t issue. &nbsp;It's irrelevant to this discussion, I<BR>think, which is sup=
posed to be about whether it's right to form a WG<BR>now. &nbsp;Since you s=
eem to be responding to substantive issues in<BR>possible WG work, that is =
evidence that there's work to be done and<BR>even a community to do it. &nb=
sp;Right?<BR>
<DIV class=3Dim><BR>&gt; I was not spreading FUD, as you admit<BR><BR></DIV=
>No, I didn't. &nbsp;I merely observed that I thought I understood why you<=
BR>seemed to want to explore the details of of a particular proposal, and<B=
R>I was trying to say that I didn't think it mattered _why_, because<BR>tha=
t you were doing it was useful information.<BR>
<DIV class=3Dim><BR>A<BR><BR>--<BR>Andrew Sullivan<BR><A href=3D"mailto:ajs=
@shinkuro.com" target=3D_blank>[email-masked]</A><BR>Shinkuro, Inc.<BR></=
DIV>
<DIV>
<DIV></DIV>
<DIV class=3Dh5>_______________________________________________<BR>keyassur=
e mailing list<BR><A href=3D"mailto:[email-masked]" target=3D_blank>key=
[email-masked]</A><BR><A href=3D"https://www.ietf.org/mailman/listinfo/key=
assure" target=3D_blank>https://www.ietf.org/mailman/listinfo/keyassure</A>=
<BR></DIV></DIV></BLOCKQUOTE></DIV><BR><BR clear=3Dall><BR>-- <BR>Website: =
<A href=3D"http://hallambaker.com/" target=3D_blank>http://hallambaker.com/=
</A><BR><BR>Regards,<BR>Jeffrey A. Williams<BR>"Obedience of the law is the=
 greatest freedom" -<BR>&nbsp;&nbsp; Abraham Lincoln<BR><BR>"Credit should =
go with the performance of duty and not with what is very<BR>often the acci=
dent of glory" - Theodore Roosevelt<BR><BR>"If the probability be called P;=
 the injury, L; and the burden, B; liability<BR>depends upon whether B is l=
ess than L multiplied by<BR>P: i.e., whether B is less than PL."<BR>United =
States v. Carroll Towing&nbsp; (159 F.2d 169 [2d Cir. 1947]<BR>=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>Updated 1/26/04<BR>CSO/DIR. Internet Network=
 Eng. SR. Eng. Network data security IDNS. div. of<BR>Information Network E=
ng.&nbsp; INEG. INC.<BR>ABA member in good standing member ID 01257402 E-Ma=
il [email-masked]<BR>Phone: 214-244-4827<BR><BR></DIV></BLOCKQUOTE>=
</BODY>

Date: Wed, 27 Oct 2010 14:47:22 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote:

> We can end this discussion now if the proposers are willing to accept:
> 
> "If a match between the certificate
> �� association(s) and the server's end entity certificate in TLS is not
> �� found,�TLS path processing MUST be performed as if no TLSFP record was published"

I'd rather not see this. If a host is compromised, an attacker can change
the cert, get it signed by a rogue/sloppy CA, and get it to ignore the
entire DNSSEC trust chain. In other words, DNSSEC trust is sacrificed
for another trust hierarchy (The CA one).

I think it makes more sense to say if a DNSSEC protected record is wrong,
then treat it as a problem, don't ignore it, provided your client policy
is to use TLSFP/DNSSEC.

Similarly, I don't expect a client with a CA policy to accept an
invalid/expired CERT based on the fact that the TLSFP record happens
to match.

It is very important we do not start mixing CA and DNSSEC based trust
models, or we end up with the worst of both worlds.

Paul

From: "Steingruebl, Andy" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>, Andrew Sullivan <[email-masked]>
Date: Wed, 27 Oct 2010 11:51:50 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

> From: [email-masked] [mailto:[email-masked]] On B=
ehalf Of Phillip Hallam-Baker

> The question of Security Policy is a scope issue for the charter.
> Thus the fact that we have proposals that attempt to address that scope i=
s entirely relevant to this discussion.

> The objective of this exercise is for both sides to clearly understand wh=
at is being to agreed to. The worst case outcome=20
> would be for the IESG to approve the WG charter and then reject the WG do=
cument proposals as out of scope because=20
> they thought that they were agreeing to something else.

OK.  If we store keys in DNS, we aren't doing it as just an FYI.  We're sto=
ring them there with the expectation that some bit of "client" software pay=
 attention to them, and consequently make a "policy" decision on what the p=
resence of those keys mean.  I'm fine with calling that a "security policy"=
.  And I'm fine with including it here.

Are we all settled on whether PKIX validation should happen and keys in DNS=
 get us exclusion, or whether keys in dns automatically preclude PKIX valid=
ation?  No.  In any case proposing a new way to pass around key information=
 is going to involve some policy choices unless all we define is a way to p=
ass that data, and say absolutely nothing about how a client can tell wheth=
er that data is valid.  And frankly, since we are saying that the DNS respo=
nses should be using DNSSEC, we *already* are making security policy decisi=
ons here.=20

Oh, and I'm with Phillip on being civil.  :)

- Andy

Date: Wed, 27 Oct 2010 13:39:31 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

--001636e1f34d37da7904939cb50b
Content-Type: text/plain; charset=ISO-8859-1

This is a charter discussion.

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

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

I do not understand why you would think otherwise.

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.

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.

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

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

--001636e1f34d37da7904939cb50b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This is a charter discussion.<div><br></div><div>The question of Security P=
olicy is a scope issue for the charter.</div><div><br></div><div>Thus the f=
act that we have proposals that attempt to address that scope is entirely r=
elevant to this discussion.</div>
<div><br></div><div>I do not understand why you would think otherwise.</div=
><div><br></div><div><br></div><div>The objective of this exercise is for b=
oth 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.</div>
<div><br></div><div><br></div><div>I am finding the rules of engagement her=
e 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 accusati=
ons.</div>
<div><br><br><div class=3D"gmail_quote">On Wed, Oct 27, 2010 at 12:57 PM, A=
ndrew Sullivan <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">aj=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Wed, Oct 27, 2010 at 12:41:28PM -0400, Phillip Hallam-=
Baker wrote:<br>
&gt; I was responding to an unfair and untrue attack that asserted that I w=
as<br>
&gt; spreading FUD.<br>
<br>
</div>I don&#39;t care about that issue. =A0It&#39;s irrelevant to this dis=
cussion, I<br>
think, which is supposed to be about whether it&#39;s right to form a WG<br=
>
now. =A0Since you seem to be responding to substantive issues in<br>
possible WG work, that is evidence that there&#39;s work to be done and<br>
even a community to do it. =A0Right?<br>
<div class=3D"im"><br>
&gt; I was not spreading FUD, as you admit<br>
<br>
</div>No, I didn&#39;t. =A0I merely observed that I thought I understood wh=
y you<br>
seemed to want to explore the details of of a particular proposal, and<br>
I was trying to say that I didn&#39;t think it mattered _why_, because<br>
that you were doing it was useful information.<br>
<div class=3D"im"><br>
A<br>
<br>
--<br>
Andrew Sullivan<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
Shinkuro, Inc.<br>
</div><div><div></div><div class=3D"h5">___________________________________=
____________<br>
keyassure mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--001636e1f34d37da7904939cb50b--

Date: Wed, 27 Oct 2010 12:02:04 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Paul Hoffman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Paul and all,

-----Original Message-----
>From: Paul Hoffman <[email-masked]>
>Sent: Oct 27, 2010 11:46 AM
>To: [email-masked], [email-masked]
>Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)
>
>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
"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

Content-class: urn:content-classes:message
Date: Wed, 27 Oct 2010 13:01:33 -0400
From: "Carl Wallace" <[email-masked]>
To: "Phillip Hallam-Baker" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Phillip Hallam-Baker
Sent: Wednesday, October 27, 2010 12:11 PM
To: Richard L. Barnes
Cc: [email-masked]; [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

The point at issue here is the following text in Hoffman-03:

=A0=A0 If a match between one of the certificate association(s) and the
=A0=A0 server's end entity certificate in TLS is found, the TLS client
=A0=A0 continues the TLS handshake. =A0If a match between the =
certificate
=A0=A0 association(s) and the server's end entity certificate in TLS is =
not
=A0=A0 found, the TLS client MUST abort the handshake with an
=A0=A0 "access_denied" error.

Now I have discussed this with the authors on several occasions and at =
least some of them intend this as a mechanism to guard against what they =
see as the risk of unauthorized certificate issue by a CA.

This text is buried in section 3. It comes after a pre-amble that gives =
no justification for this behavior and no hint that this is a primary =
purpose of the specification.

We can end this discussion now if the proposers are willing to accept:

"If a match between the certificate
=A0=A0 association(s) and the server's end entity certificate in TLS is =
not
=A0=A0 found,=A0TLS path processing MUST be performed as if no TLSFP =
record was published"

[CW] Assuming your aim is not to render mismatches meaningless, there =
are words similar enough to yours in the paragraph before the one you =
referenced to handle the case where no match is found.

Date: Wed, 27 Oct 2010 12:57:46 -0400
From: Andrew Sullivan <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

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.

Date: Wed, 27 Oct 2010 12:57:02 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

--000e0cd4d7824bc28604939c1d70
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Oct 27, 2010 at 12:34 PM, Paul Hoffman <[email-masked]>wrote:

> At 8:53 AM -0400 10/27/10, Andrew Sullivan wrote:
>
> >> If this is really a happy group of like-minded people, it should be easy
> >> to cut-and-paste the charter, as well as your and Stephane's
> >> clarifications into a Problem Statement I-D, and get it published soon
> >> after the working group is formed. It need not block the work on the
> >> technical solution.
> >
> >That sounds like a fine approach to me.  The charter could be amended
> >to require a problem statement I-D at the beginning.
>
> Another option is to include this in the first deliverable protocol
> document. That saves both the WG and the IESG process time for something
> that started as a copy-and-paste.

That risks a very long and drawn out conversation between those of us who
are convinced that security policy can be solved very easily and those of us
who think it is difficult but tractable. And that conversation does nothing
to get us any further with the IESG where the problem has been considered a
very hard one for over a decade.

I suggest that we instead follow the precedent of DKIM which was required to
deliver the key publication and message signature draft before working on
policy proposals. I seem to recall that DKIM was however allowed to work on
the problem statement for the policy record at the same time as the key
publication and message format work.

Under this scheme the WG would have two phases, the initial phase being to
produce a key publication mechanism and a problem statement for policy, the
second phase being to work on the policy mechanism itself.

This approach would not in any way delay deployment of DNSSEC published keys
or prevent the group deciding to use a CERT certificate type as the only
means of publishing certificate policy. The only long term consequence would
be that we would end up with four new certificate types instead of just two
and that people who do not want security policy with their key assurance
would be assured of getting it.

The second stage need not be gated on publication as an RFC. It could be
sufficient to have the Security AD's permission to forward the proposal to
the IESG.

The key signing/publication problem is something that I think we can
honestly say is understood really, really well. The number of degrees of
freedom in the problem is really very small and so the only thing left to do
is to write out the path processing semantics and a clear set of security
requirements.

The only real room for argument in the specification is on tagging and
bagging issues. And none of that should affect the semantics.

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

--000e0cd4d7824bc28604939c1d70
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, Oct 27, 2010 at 12:34 PM, Paul H=
offman <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul.=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">At 8:53 AM -0400 10/27/10, Andrew Sullivan wrote:<br><br>
&gt;&gt; If this is really a happy group of like-minded people, it should b=
e easy<br>
&gt;&gt; to cut-and-paste the charter, as well as your and Stephane&#39;s<b=
r>
&gt;&gt; clarifications into a Problem Statement I-D, and get it published =
soon<br>
&gt;&gt; after the working group is formed. It need not block the work on t=
he<br>
&gt;&gt; technical solution.<br>
&gt;<br>
&gt;That sounds like a fine approach to me. =A0The charter could be amended=
<br>
&gt;to require a problem statement I-D at the beginning.<br>
<br>
</div>Another option is to include this in the first deliverable protocol d=
ocument. That saves both the WG and the IESG process time for something tha=
t started as a copy-and-paste.</blockquote><div><br></div><div>That risks a=
 very long and drawn out conversation between those of us who are convinced=
 that security policy can be solved very easily and those of us who think i=
t is difficult but tractable. And that conversation does nothing to get us =
any further with the IESG where the problem has been considered a very hard=
 one for over a decade.</div>
<div><br></div><div>I suggest that we instead follow the precedent of DKIM =
which was required to deliver the key publication and message signature dra=
ft before working on policy proposals. I seem to recall that DKIM was howev=
er allowed to work on the problem statement for the policy record at the sa=
me time as the key publication and message format work.</div>
<div><br></div><div><br></div><div>Under this scheme the WG would have two =
phases, the initial phase being to produce a key publication mechanism and =
a problem statement for policy, the second phase being to work on the polic=
y mechanism itself.</div>
<div><br></div><div>This approach would not in any way delay deployment of =
DNSSEC published keys or prevent the group deciding to use a CERT certifica=
te type as the only means of publishing certificate policy. The only long t=
erm consequence would be that we would end up with four new certificate typ=
es instead of just two and that people who do not want security policy with=
 their key assurance would be assured of getting it.</div>
<div><br></div><div>The second stage need not be gated on publication as an=
 RFC. It could be sufficient to have the Security AD&#39;s permission to fo=
rward the proposal to the IESG.</div><div><br></div><div><br></div><div>
The key signing/publication problem is something that I think we can honest=
ly say is understood really, really well. The number of degrees of freedom =
in the problem is really very small and so the only thing left to do is to =
write out the path processing semantics and a clear set of security require=
ments.</div>
<div><br></div><div>The only real room for argument in the specification is=
 on tagging and bagging issues. And none of that should affect the semantic=
s.</div><div><br></div></div><br>-- <br>Website: <a href=3D"http://hallamba=
ker.com/">http://hallambaker.com/</a><br>
<br>

--000e0cd4d7824bc28604939c1d70--

Date: Wed, 27 Oct 2010 10:51:19 -0600
From: Peter Saint-Andre <[email-masked]>
To: Paul Hoffman <[email-masked]>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

This is a cryptographically signed message in MIME format.

--------------ms040904090603060204060407
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 10/27/10 10:46 AM, Paul Hoffman wrote:

> If the IESG wants the KIDNS WG to deal with defining "policy", it
> should let us know sooner rather than later.

If anything, this IESG member at least will request that the KIDNS WG
rule out any work on defining "policy", which IMHO will lead to a
rodent-hole of unusual size and perhaps even a fire swamp or two.

Peter

--=20
Peter Saint-Andre
https://stpeter.im/

--------------ms040904090603060204060407
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

AAAA
--------------ms040904090603060204060407--

Date: Wed, 27 Oct 2010 09:46:04 -0700
To: [email-masked], [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

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.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 27 Oct 2010 12:41:28 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

--001485f89bd4a78f0704939be521
Content-Type: text/plain; charset=ISO-8859-1

I was responding to an unfair and untrue attack that asserted that I was
spreading FUD.

I was not spreading FUD, as you admit, my statement was fully justified by
the proposal in question. I therefore believe that Richard should apologize
for the implication that I was misrepresenting anyone's position.

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

> On Wed, Oct 27, 2010 at 12:10:32PM -0400, Phillip Hallam-Baker wrote:
> > The point at issue here is the following text in Hoffman-03:
>
> You seem to be taking issue with particular proposals that the
> proposed WG might work on _rather than_ the setting up of the WG in
> order to work on these proposals.  Doesn't that seem to you to be
> _prima facie_ evidence that the WG in fact has work to do, and can
> therefore be chartered to work on it?  (Yes, I know what you were
> responding to.  I'm trying to bring the conversation back on the track
> of what we were supposed to be talking about.)
>
> A
>
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
>

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

--001485f89bd4a78f0704939be521
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I was responding to an unfair and untrue attack that asserted that I was sp=
reading FUD.<div><br></div><div>I was not spreading FUD, as you admit, my s=
tatement was fully justified by the proposal in question. I therefore belie=
ve that Richard should=A0apologize for the implication that I was misrepres=
enting anyone&#39;s position.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Wed, Oct 27, 2010 at =
12:16 PM, Andrew Sullivan <span dir=3D"ltr">&lt;<a href=3D"mailto:ajs@shink=
uro.com">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
<div class=3D"im">On Wed, Oct 27, 2010 at 12:10:32PM -0400, Phillip Hallam-=
Baker wrote:<br>
&gt; The point at issue here is the following text in Hoffman-03:<br>
<br>
</div>You seem to be taking issue with particular proposals that the<br>
proposed WG might work on _rather than_ the setting up of the WG in<br>
order to work on these proposals. =A0Doesn&#39;t that seem to you to be<br>
_prima facie_ evidence that the WG in fact has work to do, and can<br>
therefore be chartered to work on it? =A0(Yes, I know what you were<br>
responding to. =A0I&#39;m trying to bring the conversation back on the trac=
k<br>
of what we were supposed to be talking about.)<br>
<div><div></div><div class=3D"h5"><br>
A<br>
<br>
--<br>
Andrew Sullivan<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
Shinkuro, Inc.<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--001485f89bd4a78f0704939be521--

Date: Wed, 27 Oct 2010 11:40:45 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Stephane Bortzmeyer <[email-masked]>,  Yaron Sheffer <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Stephane and all,

-----Original Message-----
>From: Stephane Bortzmeyer <[email-masked]>
>Sent: Oct 27, 2010 3:03 AM
>To: Yaron Sheffer <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)
>
>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.
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure
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

"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

Date: Wed, 27 Oct 2010 09:34:39 -0700
To: Andrew Sullivan <[email-masked]>, Yaron Sheffer <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

At 8:53 AM -0400 10/27/10, Andrew Sullivan wrote:
>On Wed, Oct 27, 2010 at 02:29:36PM +0200, Yaron Sheffer wrote:
>>
>> My intention is not to add bureaucratic hurdles. It is to ensure that 
>> the group has reasonable consensus about its goals. I get worried when I 
>> see indecision about requirements/goals trickle into the technical spec, 
>
>Yes, on this we fully agree.
>
>> If this is really a happy group of like-minded people, it should be easy 
>> to cut-and-paste the charter, as well as your and Stephane's 
>> clarifications into a Problem Statement I-D, and get it published soon 
>> after the working group is formed. It need not block the work on the 
>> technical solution.
>
>That sounds like a fine approach to me.  The charter could be amended
>to require a problem statement I-D at the beginning.

Another option is to include this in the first deliverable protocol document. That saves both the WG and the IESG process time for something that started as a copy-and-paste.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 27 Oct 2010 12:16:34 -0400
From: Andrew Sullivan <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

On Wed, Oct 27, 2010 at 12:10:32PM -0400, Phillip Hallam-Baker wrote:
> The point at issue here is the following text in Hoffman-03:

You seem to be taking issue with particular proposals that the
proposed WG might work on _rather than_ the setting up of the WG in
order to work on these proposals.  Doesn't that seem to you to be
_prima facie_ evidence that the WG in fact has work to do, and can
therefore be chartered to work on it?  (Yes, I know what you were
responding to.  I'm trying to bring the conversation back on the track
of what we were supposed to be talking about.)

A

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

Date: Wed, 27 Oct 2010 12:10:32 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

--0016e644d6d007118404939b7792
Content-Type: text/plain; charset=ISO-8859-1

The point at issue here is the following text in Hoffman-03:

   If a match between one of the certificate association(s) and the
   server's end entity certificate in TLS is found, the TLS client
   continues the TLS handshake.  If a match between the certificate
   association(s) and the server's end entity certificate in TLS is not
   found, the TLS client MUST abort the handshake with an
   "access_denied" error.

Now I have discussed this with the authors on several occasions and at least
some of them intend this as a mechanism to guard against what they see as
the risk of unauthorized certificate issue by a CA.

This text is buried in section 3. It comes after a pre-amble that gives no
justification for this behavior and no hint that this is a primary purpose
of the specification.

We can end this discussion now if the proposers are willing to accept:

"If a match between the certificate
   association(s) and the server's end entity certificate in TLS is not
   found, TLS path processing MUST be performed as if no TLSFP record was
published"

At the very minimum, this type of behavior has to be optional.

I am quite happy for the IETF to specify a mechanism to address this
particular use case but it is an aspect of security policy, it is the most
difficult aspect of security policy and I do not want to have it conflated
with a new mechanism for key validation.

At the very least, any mechanism that has this intent should be clearly
and unambiguously specified in the problem statement of the RFC. And there
has to be a very compelling reason given for addressing the two issues
together. Saving a DNS round trip is not a compelling reason in my view.

There is a great tendency for IETF working groups to think about the
difficulty of implementation and efficiency as the most important issues. My
view is that the most important issue is functionality and the next most
important is usability for the system administrator.

We have a whole lot of security infrastructure that remains as shelfware
because the typical administrator is not confident that they understand how
to configure it correctly. Network admins are busy people. Their networks
break for all sorts of reasons that are outside their control. Not deploying
bad ideas is something that is within their control. And if they cannot get
comfortable with an idea quickly their reaction is much more likely to be
that the designer should get a clue rather than that they should get a clue.

If you want them to deploy your stuff you have to be prepared to work with
them and provide a mechanism that they can easily understand and be
comfortable with. They are the gatekeepers.

On Wed, Oct 27, 2010 at 9:40 AM, Phillip Hallam-Baker <[email-masked]>wrote:

> Richard,
>
> Please keep the conversation civil.
>
> I am not spreading FUD, I am basing my statements on extensive discussions
> with the proposers.
>
> If they wish to state that they don't want to address security policy then
> there is no need for this discussion at all. The charter will simply say
> that all the WG does in the first phase is to describe a certificate type
> that provides one additional means of validating keys and has no side
> effects.
>
> The only reason for a discussion is that some people want to override the
> PKIX semantics and use this to edit the set of trusted CA roots for a zone.
>
>
>
> On Wed, Oct 27, 2010 at 9:33 AM, Richard L. Barnes <[email-masked]>wrote:
>
>>  What Paul is saying is that the proposal does not override PKIX semantics
>>> based on CA issuing in a world in which there are no CAs. In the world in
>>> which we currently live TLSFP overrides PKIX semantics. If a TLSFP record
>>> exists then a client that supports TLSFP is required to ignore the PKIX
>>> certificate chain entirely.
>>>
>>
>> The only instance in which TLSFP "overrides" anything about a PKIX cert is
>> the following sentence:
>> "
>> If a TLS client fully trusts the association between a domain name and the
>> certificate that was provided by the DNS, then that client MUST ignore the
>> domain name that is given in the certificate.
>> "
>>
>> In fact, the draft goes into some detail about the interaction between
>> PKIX validation and the assertions that TLSFP provides.
>>
>> Unless you can point to text in a document that supports what you're
>> saying about that document, quit spreading FUD.
>>
>> --Richard
>>
>
>
>
> --
> Website: http://hallambaker.com/
>
>

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

--0016e644d6d007118404939b7792
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The point at issue here is the following text in Hoffman-03:<div><br></div>=
<div><div>=A0=A0 If a match between one of the certificate association(s) a=
nd the</div><div>=A0=A0 server&#39;s end entity certificate in TLS is found=
, the TLS client</div>
<div>=A0=A0 continues the TLS handshake. =A0If a match between the certific=
ate</div><div>=A0=A0 association(s) and the server&#39;s end entity certifi=
cate in TLS is not</div><div>=A0=A0 found, the TLS client MUST abort the ha=
ndshake with an</div>
<div>=A0=A0 &quot;access_denied&quot; error.</div><div><br></div><div>Now I=
 have discussed this with the authors on several occasions and at least som=
e of them intend this as a mechanism to guard against what they see as the =
risk of unauthorized certificate issue by a CA.</div>
<div><br></div><div>This text is buried in section 3. It comes after a pre-=
amble that gives no justification for this behavior and no hint that this i=
s a primary purpose of the specification.</div><div><br></div><div>We can e=
nd this discussion now if the proposers are willing to accept:</div>
<div><br></div><div>&quot;If a match between the certificate</div><meta cha=
rset=3D"utf-8"><div>=A0=A0 association(s) and the server&#39;s end entity c=
ertificate in TLS is not</div><div>=A0=A0 found,=A0TLS path processing MUST=
 be performed as if no TLSFP record was published&quot;</div>
<div><br></div><div>At the very minimum, this type of behavior has to be op=
tional.=A0</div><div><br></div><div><br></div><div>I am quite happy for the=
 IETF to specify a mechanism to address this particular use case but it is =
an aspect of security policy, it is the most difficult aspect of security p=
olicy and I do not want to have it conflated with a new mechanism for key v=
alidation.=A0</div>
<div><br></div><div>At the very least, any mechanism that has this intent s=
hould be clearly and=A0unambiguously=A0specified in the problem statement o=
f the RFC. And there has to be a very compelling reason given for addressin=
g the two issues together. Saving a DNS round trip is not a compelling reas=
on in my view.</div>
<div><br></div><div><br></div><div>There is a great tendency for IETF worki=
ng groups to think about the difficulty of implementation and efficiency as=
 the most important issues. My view is that the most important issue is fun=
ctionality and the next most important is usability for the system administ=
rator.</div>
<div><br></div><div>We have a whole lot of security infrastructure that rem=
ains as shelfware because the typical administrator is not confident that t=
hey understand how to configure it correctly. Network admins are busy peopl=
e. Their networks break for all sorts of reasons that are outside their con=
trol. Not deploying bad ideas is something that is within their control. An=
d if they cannot get comfortable with an idea quickly their reaction is muc=
h more likely to be that the designer should get a clue rather than that th=
ey should get a clue.</div>
<div><br></div><div>If you want them to deploy your stuff you have to be pr=
epared to work with them and provide a mechanism that they can easily under=
stand and be comfortable with. They are the gatekeepers.</div><div><br>
</div><br><div class=3D"gmail_quote">On Wed, Oct 27, 2010 at 9:40 AM, Phill=
ip Hallam-Baker <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">h=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Richard,<div><br></div><div>Please keep the conversation civil.</div><div><=
br></div><div>I am not spreading FUD, I am basing my statements on extensiv=
e discussions with the proposers.=A0</div><div><br></div><div>If they wish =
to state that they don&#39;t want to address security policy then there is =
no need for this discussion at all. The charter will simply say that all th=
e WG does in the first phase is to describe a certificate type that provide=
s one additional means of validating keys and has no side effects.</div>

<div><br></div><div>The only reason for a discussion is that some people wa=
nt to override the PKIX semantics and use this to edit the set of trusted C=
A roots for a zone.</div><div><br><br></div><div><br></div><div><div><div>
</div><div class=3D"h5"><div class=3D"gmail_quote">
On Wed, Oct 27, 2010 at 9:33 AM, Richard L. Barnes <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">

<div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
What Paul is saying is that the proposal does not override PKIX semantics b=
ased on CA issuing in a world in which there are no CAs. In the world in wh=
ich we currently live TLSFP overrides PKIX semantics. If a TLSFP record exi=
sts then a client that supports TLSFP is required to ignore the PKIX certif=
icate chain entirely.<br>

</blockquote>
<br></div>
The only instance in which TLSFP &quot;overrides&quot; anything about a PKI=
X cert is the following sentence:<br>
&quot;<br>
If a TLS client fully trusts the association between a domain name and the =
certificate that was provided by the DNS, then that client MUST ignore the =
domain name that is given in the certificate.<br>
&quot;<br>
<br>
In fact, the draft goes into some detail about the interaction between PKIX=
 validation and the assertions that TLSFP provides.<br>
<br>
Unless you can point to text in a document that supports what you&#39;re sa=
ying about that document, quit spreading FUD.<br><font color=3D"#888888">
<br>
--Richard<br>
</font></blockquote></div><br><br clear=3D"all"><br></div></div>-- <br>Webs=
ite: <a href=3D"http://hallambaker.com/" target=3D"_blank">http://hallambak=
er.com/</a><br><br>
</div>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--0016e644d6d007118404939b7792--

Date: Wed, 27 Oct 2010 09:40:27 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

--001636c92c424041b10493995ed7
Content-Type: text/plain; charset=ISO-8859-1

Richard,

Please keep the conversation civil.

I am not spreading FUD, I am basing my statements on extensive discussions
with the proposers.

If they wish to state that they don't want to address security policy then
there is no need for this discussion at all. The charter will simply say
that all the WG does in the first phase is to describe a certificate type
that provides one additional means of validating keys and has no side
effects.

The only reason for a discussion is that some people want to override the
PKIX semantics and use this to edit the set of trusted CA roots for a zone.

On Wed, Oct 27, 2010 at 9:33 AM, Richard L. Barnes <[email-masked]> wrote:

> What Paul is saying is that the proposal does not override PKIX semantics
>> based on CA issuing in a world in which there are no CAs. In the world in
>> which we currently live TLSFP overrides PKIX semantics. If a TLSFP record
>> exists then a client that supports TLSFP is required to ignore the PKIX
>> certificate chain entirely.
>>
>
> The only instance in which TLSFP "overrides" anything about a PKIX cert is
> the following sentence:
> "
> If a TLS client fully trusts the association between a domain name and the
> certificate that was provided by the DNS, then that client MUST ignore the
> domain name that is given in the certificate.
> "
>
> In fact, the draft goes into some detail about the interaction between PKIX
> validation and the assertions that TLSFP provides.
>
> Unless you can point to text in a document that supports what you're saying
> about that document, quit spreading FUD.
>
> --Richard
>

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

--001636c92c424041b10493995ed7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Richard,<div><br></div><div>Please keep the conversation civil.</div><div><=
br></div><div>I am not spreading FUD, I am basing my statements on extensiv=
e discussions with the proposers.=A0</div><div><br></div><div>If they wish =
to state that they don&#39;t want to address security policy then there is =
no need for this discussion at all. The charter will simply say that all th=
e WG does in the first phase is to describe a certificate type that provide=
s one additional means of validating keys and has no side effects.</div>
<div><br></div><div>The only reason for a discussion is that some people wa=
nt to override the PKIX semantics and use this to edit the set of trusted C=
A roots for a zone.</div><div><br><br></div><div><br></div><div><div class=
=3D"gmail_quote">
On Wed, Oct 27, 2010 at 9:33 AM, Richard L. Barnes <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex;">
<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
What Paul is saying is that the proposal does not override PKIX semantics b=
ased on CA issuing in a world in which there are no CAs. In the world in wh=
ich we currently live TLSFP overrides PKIX semantics. If a TLSFP record exi=
sts then a client that supports TLSFP is required to ignore the PKIX certif=
icate chain entirely.<br>

</blockquote>
<br></div>
The only instance in which TLSFP &quot;overrides&quot; anything about a PKI=
X cert is the following sentence:<br>
&quot;<br>
If a TLS client fully trusts the association between a domain name and the =
certificate that was provided by the DNS, then that client MUST ignore the =
domain name that is given in the certificate.<br>
&quot;<br>
<br>
In fact, the draft goes into some detail about the interaction between PKIX=
 validation and the assertions that TLSFP provides.<br>
<br>
Unless you can point to text in a document that supports what you&#39;re sa=
ying about that document, quit spreading FUD.<br><font color=3D"#888888">
<br>
--Richard<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--001636c92c424041b10493995ed7--

From: "Richard L. Barnes" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Oct 2010 09:33:35 -0400
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

> What Paul is saying is that the proposal does not override PKIX  
> semantics based on CA issuing in a world in which there are no CAs.  
> In the world in which we currently live TLSFP overrides PKIX  
> semantics. If a TLSFP record exists then a client that supports  
> TLSFP is required to ignore the PKIX certificate chain entirely.

The only instance in which TLSFP "overrides" anything about a PKIX  
cert is the following sentence:
"
If a TLS client fully trusts the association between a domain name and  
the certificate that was provided by the DNS, then that client MUST  
ignore the domain name that is given in the certificate.
"

In fact, the draft goes into some detail about the interaction between  
PKIX validation and the assertions that TLSFP provides.

Unless you can point to text in a document that supports what you're  
saying about that document, quit spreading FUD.

--Richard

Date: Wed, 27 Oct 2010 09:24:16 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

--0016e647132a68c76604939924a2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 27, 2010 at 4:25 AM, Ond=C5=99ej Sur=C3=BD <[email-masked]>=
 wrote:

> [Replying to Phillip and Paul simultaneously]
>
>
> On 27.10.2010 02:06, Paul Wouters wrote:
>
>> On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote:
>>
>>> In particular the TLSFP scheme defines a path validation algorithm
>>>  that overrides the standard PKIX processing mechanism in two
>>> ways.
>>>
>>
>> Not override, alternative. Depending on client policy. Image systems
>>  with no CA's.
>>
>
> True.

Not true at all.

What Paul is saying is that the proposal does not override PKIX semantics
based on CA issuing in a world in which there are no CAs. In the world in
which we currently live TLSFP overrides PKIX semantics. If a TLSFP record
exists then a client that supports TLSFP is required to ignore the PKIX
certificate chain entirely.

>  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.
>>>
>>
> Just a note:  There is no such assumption in the charter.  This is just
> one particular I-D.

Which is precisely the sort of issue that is relevant to a charter
discussion with the IESG.

This is security policy by side effect. I think that is the worst possible
way to go about the security policy problem. I think we can develop a
practical security policy scheme based on direct security policy assertions
'SMTP at example.com always uses TLS'. But doing this through side effects
is looking for trouble.

>  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 don't see that. The browser and its CA policy installation can
>> still ignore TLSFP. In fact, I strongly suspect they will in at least
>> the near future.
>>
>
The publishers of a TLSFP record cannot assume that the security policy sid=
e
effects are going to be ignored.

Presenting this as a client side choice is nonsense.

I want to be able to publish TLSFP records for my mail server on
example.comwithout affecting the operation of my web server on
example.com in any way whatsoever.

I want to have a means of publishing keys using the DNSSEC that is side
effect free.

>  And I don't see that as a problem anyway.  The scope of this proposed WG
> is to link domain names to certificates.  As stated by Stephane in other
> thread in keyassure list, newer protocols generally use (or can use) SRV
> record to distinguish between different services.  It will take some
> effort on the sysadmin side to make the TLSFP work as intended, but
> setting up security was never painless.

This is not a responsible approach to security configuration.

The reason I want to have side effect free specifications is that I want to
be able to automate these processes. A specification that makes automated
systems management should be rejected out of hand at this point.

This is what architecture is all about.

There is no necessity for conjoining these two features other than that the
proposers think that they would like to avoid some DNS round trips and are
not prepared to use a completely new DNS RR.

>  I find this proposal troubling for several reasons. 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.
>>>
>>
> I don't understand why it should?  You can decide if you want to use DNSS=
EC
> or not.  You can decide if you want to use TLSFP or not.  It's up to each
> domain holder if he will use this mechanism or not.

Because scripts are stupider than rocks.

Separation of concerns is essential if these processes are going to be
automated.

The number of competent systems managers who can deploy DNSSEC is not very
large. Training is hugely expensive. It is going to take a significant
amount of time to do the job right. I can't see how it is going to be
possible for the typical enterprise to deploy DNSSEC in house and those tha=
t
do should probably expect to spend $100K+.

The only way any of this makes sense to me from a cost point of view is if
the process is outsourced and those costs are amortized over a huge number
of instances.

>> The existence of a TLSFP record could mean "always use TLS". The WG
>> is going to discuss whether or not to use bits for these things in
>> the coming months. I would also like to see more policy options
>> there, such as "only connect anonymous", or a policy where it is
>> clear if the server does any kind of authentication, or whether it
>> will allow a BTNS type security policy without client
>> authentication.
>>
>
> Yes, I think our proposed charter allows that.

That is precisely the question the IESG needs to decide.

I want to do security policy. I think that DNSSEC only makes sense if it ca=
n
be used for security policy. But any security policy mechanism that is done
has to be a first order feature and not implemented by diddling with a few
bits buried in a subfield encoding of a BASE64 encoded blob.

My understanding is that this was discussed in the keyassure before and the
> charter was built upon rough consensus.  I don't think it's necessary to
> reiterate through all this again on IESG list.

As you said in your previous message, shouldn't you let the IESG speak for
itself here?

This type of issue is precisely what the IESG needs to be considering.
Because if they do not discuss it now they are going to DISCUSS the drafts
later and there is a serious risk that we waste several years work.

The current IESG is not necessarily going to be the one that reviews the
specifications. Absent a clear and unambiguous statement from the IESG that
security policy work is in scope of the charter there is a risk that a
future IESG is going to kick back.

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

--0016e647132a68c76604939924a2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, Oct 27, 2010 at 4:25 AM, Ond=C5=
=99ej Sur=C3=BD <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]"=
>[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;=
">
[Replying to Phillip and Paul simultaneously]<div class=3D"im"><br>
<br>
On 27.10.2010 02:06, Paul Wouters wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"im">
On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote:<br>
</div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In particular the TLSFP scheme defines a path validation algorithm<br>
=C2=A0that overrides the standard PKIX processing mechanism in two<br>
ways.<br>
</blockquote>
<br>
Not override, alternative. Depending on client policy. Image systems<br>
=C2=A0with no CA&#39;s.<br>
</div></blockquote>
<br>
True.</blockquote><div class=3D"gmail_quote"><br></div><div class=3D"gmail_=
quote">Not true at all.=C2=A0</div><div class=3D"gmail_quote"><br></div><di=
v class=3D"gmail_quote">What Paul is saying is that the proposal does not o=
verride PKIX semantics based on CA issuing in a world in which there are no=
 CAs. In the world in which we currently live TLSFP overrides PKIX semantic=
s. If a TLSFP record exists then a client that supports TLSFP is required t=
o ignore the PKIX certificate chain entirely.</div>
<div class=3D"gmail_quote"><br></div><br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><d=
iv class=3D"im">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Secondly, there is an assumption in TLSFP that any domain that<br>
publishes CERT records of TLSFP certificate type will publish TLSFP<br>
records for ALL valid SSL certs in use for the domain.<br>
</blockquote></blockquote>
<br></div>
Just a note: =C2=A0There is no such assumption in the charter. =C2=A0This i=
s just<br>
one particular I-D.</blockquote><div class=3D"gmail_quote"><br></div><div c=
lass=3D"gmail_quote">Which is precisely the sort of issue that is relevant =
to a charter discussion with the IESG.=C2=A0</div><div class=3D"gmail_quote=
"><br>
</div><div class=3D"gmail_quote">This is security policy by side effect. I =
think that is the worst possible way to go about the security policy proble=
m. I think we can develop a practical security policy scheme based on direc=
t security policy assertions &#39;SMTP at <a href=3D"http://example.com">ex=
ample.com</a> always uses TLS&#39;. But doing this through side effects is =
looking for trouble.</div>
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex;"></blockquote><br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex;">
<div class=3D"im">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So the publication of a TLSFP record to enable secure<br>
communication on the mail server will cause the SSL certificate on<br>
the Web server to be considered invalid.<br>
</blockquote>
<br>
I don&#39;t see that. The browser and its CA policy installation can<br>
still ignore TLSFP. In fact, I strongly suspect they will in at least<br>
the near future.<br></blockquote></div></blockquote><div><br></div><div>The=
 publishers of a TLSFP record cannot assume that the security policy side e=
ffects are going to be ignored.=C2=A0</div><div><br></div><div>Presenting t=
his as a client side choice is nonsense.</div>
<div><br></div><div>I want to be able to publish TLSFP records for my mail =
server on <a href=3D"http://example.com">example.com</a> without affecting =
the operation of my web server on <a href=3D"http://example.com">example.co=
m</a> in any way whatsoever.</div>
<div><br></div><div>I want to have a means of publishing keys using the DNS=
SEC that is side effect free.</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex;">
<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>
</div>
And I don&#39;t see that as a problem anyway. =C2=A0The scope of this propo=
sed WG<br>
is to link domain names to certificates. =C2=A0As stated by Stephane in oth=
er<br>
thread in keyassure list, newer protocols generally use (or can use) SRV<br=
>
record to distinguish between different services. =C2=A0It will take some<b=
r>
effort on the sysadmin side to make the TLSFP work as intended, but<br>
setting up security was never painless. =C2=A0</blockquote><div><br></div><=
div>This is not a responsible approach to security configuration.</div><div=
><br></div><div>The reason I want to have side effect free specifications i=
s that I want to be able to automate these processes. A specification that =
makes automated systems management should be rejected out of hand at this p=
oint.</div>
<div><br></div><div>This is what architecture is all about.=C2=A0</div><div=
><br></div><div>There is no necessity for conjoining these two features oth=
er than that the proposers think that they would like to avoid some DNS rou=
nd trips and are not prepared to use a completely new DNS RR.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;"><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I find this proposal troubling for several reasons. First it lacks<div clas=
s=3D"im"><br>
orthogonality. It should be able to use the DNSSEC to establish<br>
additional keys without affecting existing trust systems in any way<br>
whatsoever.<br>
</div></blockquote></blockquote>
<br>
I don&#39;t understand why it should? =C2=A0You can decide if you want to u=
se DNSSEC or not. =C2=A0You can decide if you want to use TLSFP or not. =C2=
=A0It&#39;s up to each domain holder if he will use this mechanism or not.<=
/blockquote>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Because scr=
ipts are stupider than rocks.</div><div class=3D"gmail_quote"><br></div><di=
v class=3D"gmail_quote">Separation of concerns is essential if these proces=
ses are going to be automated.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">The number =
of competent systems managers who can deploy DNSSEC is not very large. Trai=
ning is hugely expensive. It is going to take a significant amount of time =
to do the job right. I can&#39;t see how it is going to be possible for the=
 typical enterprise to deploy DNSSEC in house and those that do should prob=
ably expect to spend $100K+.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">The only wa=
y any of this makes sense to me from a cost point of view is if the process=
 is outsourced and those costs are amortized over a huge number of instance=
s.=C2=A0</div>
<div class=3D"gmail_quote"><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div c=
lass=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<br>
The existence of a TLSFP record could mean &quot;always use TLS&quot;. The =
WG<br>
is going to discuss whether or not to use bits for these things in<br>
the coming months. I would also like to see more policy options<br>
there, such as &quot;only connect anonymous&quot;, or a policy where it is<=
br>
clear if the server does any kind of authentication, or whether it<br>
will allow a BTNS type security policy without client<br>
authentication.<br>
</blockquote>
<br></div>
Yes, I think our proposed charter allows that.</blockquote><div class=3D"gm=
ail_quote"><br></div><div class=3D"gmail_quote">That is precisely the quest=
ion the IESG needs to decide.</div><div class=3D"gmail_quote"><br></div><di=
v class=3D"gmail_quote">
I want to do security policy. I think that DNSSEC only makes sense if it ca=
n be used for security policy. But any security policy mechanism that is do=
ne has to be a first order feature and not implemented by diddling with a f=
ew bits buried in a subfield encoding of a BASE64 encoded blob.</div>
<div class=3D"gmail_quote"><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
My understanding is that this was discussed in the keyassure before and the=
 charter was built upon rough consensus. =C2=A0I don&#39;t think it&#39;s n=
ecessary to reiterate through all this again on IESG list.</blockquote></di=
v>
<div><br></div><div>As you said in your previous message, shouldn&#39;t you=
 let the IESG speak for itself here?</div><br>This type of issue is precise=
ly what the IESG needs to be considering. Because if they do not discuss it=
 now they are going to DISCUSS the drafts later and there is a serious risk=
 that we waste several years work.<div>
<br></div><div>The current IESG is not necessarily going to be the one that=
 reviews the specifications. Absent a clear and unambiguous statement from =
the IESG that security policy work is in scope of the charter there is a ri=
sk that a future IESG is going to kick back.=C2=A0<br clear=3D"all">
<br>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallambaker.=
com/</a><br><br>
</div>

--0016e647132a68c76604939924a2--

From: "Richard L. Barnes" <[email-masked]>
To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= <[email-masked]>
Date: Wed, 27 Oct 2010 09:22:14 -0400
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

>>> If this is really a happy group of like-minded people, it should  
>>> be easy
>>> to cut-and-paste the charter, as well as your and Stephane's
>>> clarifications into a Problem Statement I-D, and get it published  
>>> soon
>>> after the working group is formed. It need not block the work on the
>>> technical solution.
>>
>> That sounds like a fine approach to me.  The charter could be amended
>> to require a problem statement I-D at the beginning.
>
> Sounds fine to me.  Any other comments from other interested people?

I won't object very strongly to a problem statement I-D, but I don't  
think one is really necessary.

--Richard

Date: Wed, 27 Oct 2010 15:00:37 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked], [email-masked], Warren Kumari <[email-masked]>
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

On 27.10.2010 14:53, Andrew Sullivan wrote:
> On Wed, Oct 27, 2010 at 02:29:36PM +0200, Yaron Sheffer wrote:
>>
>> My intention is not to add bureaucratic hurdles. It is to ensure that
>> the group has reasonable consensus about its goals. I get worried when I
>> see indecision about requirements/goals trickle into the technical spec,
>
> Yes, on this we fully agree.
>
>> If this is really a happy group of like-minded people, it should be easy
>> to cut-and-paste the charter, as well as your and Stephane's
>> clarifications into a Problem Statement I-D, and get it published soon
>> after the working group is formed. It need not block the work on the
>> technical solution.
>
> That sounds like a fine approach to me.  The charter could be amended
> to require a problem statement I-D at the beginning.

Sounds fine to me.  Any other comments from other interested people?

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

Date: Wed, 27 Oct 2010 08:53:44 -0400
From: Andrew Sullivan <[email-masked]>
To: Yaron Sheffer <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

On Wed, Oct 27, 2010 at 02:29:36PM +0200, Yaron Sheffer wrote:
>
> My intention is not to add bureaucratic hurdles. It is to ensure that  
> the group has reasonable consensus about its goals. I get worried when I  
> see indecision about requirements/goals trickle into the technical spec,  

Yes, on this we fully agree.

> If this is really a happy group of like-minded people, it should be easy  
> to cut-and-paste the charter, as well as your and Stephane's  
> clarifications into a Problem Statement I-D, and get it published soon  
> after the working group is formed. It need not block the work on the  
> technical solution.

That sounds like a fine approach to me.  The charter could be amended
to require a problem statement I-D at the beginning.

A

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

Date: Wed, 27 Oct 2010 08:36:10 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

--0016e644cf6c6506a504939878e7
Content-Type: text/plain; charset=ISO-8859-1

Security policy is generally understood to mean anything that was addressed
in Matt Blaze's PolicyMaker scheme. 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.

But whatever they are called, the problem is considered to be very
difficult. In particular the problem of telling relying parties that they
should only trust specific roots or certs for a domain is considered very
difficult.

What is being proposed here is not simply a matter of 'client choice'.

If there are any clients out there that make security policy decisions based
on the existence of TLSFP records then these must be explicit to the domains
publishing the records. Otherwise we end up with a massive interoperability
failure.

I want to be able to publish a TLSFP certificate for my mail server (SMTP
and IMAP) without affecting my Web server.

That is not going to be possible if there is even one client out there that
sees a TLSFP record and decides to reject a perfectly good certificate path
as a result or worse decides that it is not going to connect to my Web
server that does not have TLS and was never intended to.

As for the idea that 'nobody is proposing this'. Paul Wooters just suggested
doing exactly that and the TLSFP code does exactly that.

On Wed, Oct 27, 2010 at 7:45 AM, Richard L. Barnes <[email-masked]> wrote:

> Phillip,
>
> Nothing in this proposal creates security policy.  It creates inputs for
> things that go into security policy.  All that the proposed records do is
> provide another input into the client's *internal* process for deciding
> whether a credential is tied to a particular domain.  Clients are free to
> validate or not validate certificates as they choose.  Please stop trying to
> reinforce the misconception that the proposed mechanism overrides PKIX
> validation in any way.
>
> --Richard
>
>
>
> On Oct 26, 2010, at 9:03 PM, Phillip Hallam-Baker wrote:
>
> Since this is a charter discussion, it goes to the IESG.
>
> My point is not that the IETF should not address Security Policy, it is
> that any security mechanism should be completely independent of defining a
> new and additional mechanism to sign public keys.
>
> It should be able for a domain to publish public keys in the DNS without
> impact on existing deployed SSL certificates and it should be possible for a
> domain to publish security policy constraining trusted keys without having
> to do so by publishing their keys in the DNS.
>
> If the policy of a site is that every certificate is issued off a local CA
> root that is cross certified to a public root, it should suffice to state
> that every valid cert is issued of the local CA root.
>
>
> My reason for wanting this distinction is twofold. First I believe it is a
> matter of sound architectural practice to separate the two issued, Secondly
> I believe that the IAB and IESG are going to insist on this distinction.
>
> The worst outcome here would be for the WG to be chartered with an
> ambiguous remit, spend a year or two working on the issue and then produce a
> proposal that is thrown out by the IESG because they insist that the two
> issues be kept separate.
>
> The second worse outcome is to be kicked back with a request to define the
> problem we are trying to solve. I think that process is going to take longer
> than solving the key signing problem. We really do understand the key
> signing problem very well.
>
>
> We have done mechanisms for signing keys before. It is a well constrained
> problem. I think that having a mechanism for signing keys on the basis of
> DNSSEC is a worthwhile achievement on its own. We should be able to knock
> that one off in about six months. Then we can approach the IESG and invoke
> the pinball rule under RFC 2418 sec 4: If you win you get to play again.
>
> By that time, I hope that we have some results to show with CAA which
> addresses a very limited aspect of security policy that does not affect the
> client. Based on the feedback I have had so far from targeted domains and
> from CAs, that looks like a win-win.
>
> So at that time I think we can expect to be able to go back to the IESG and
> tell them that we want to do security policy and that we are pretty sure
> that we understand the issues involved and can produce a nicely abstracted
> platform that has strong separation of concerns and reduces the entropy in
> the Internet architecture rather than further increasing it..
>
>
>
> On Tue, Oct 26, 2010 at 8:06 PM, Paul Wouters <[email-masked]> wrote:
>
>> On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote:
>>
>> [not sure if such a broad CC: is warranted]
>>
>>
>>  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.
>>>
>>
>> the first is a security policy as well.
>>
>>
>>  In particular the TLSFP scheme defines a path validation
>>> algorithm that overrides the standard PKIX processing mechanism in two
>>> ways.
>>>
>>
>> Not override, alternative. Depending on client policy. Image systems with
>> no CA's.
>>
>>
>>  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 don't see that. The browser and its CA policy installation can still
>> ignore TLSFP. In fact, I strongly
>> suspect they will in at least the near future.
>>
>>
>>  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.
>>>
>>
>> It does. Its an addon a client can decide to use or not use.
>>
>>
>>  I dislike
>>> any mechanism that requires the administrator to perform configuration in
>>> the DNS for each and every SSL certificate as
>>> it is issued.
>>>
>>
>> I dislike needing to delete so many untrusted omnipotent CA's from my
>> browser. But our personal dislikes are irrelevant to protocol design.
>>
>>
>>  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'.
>>>
>>
>> The existence of a TLSFP record could mean "always use TLS". The WG is
>> going to discuss whether or not to use
>> bits for these things in the coming months. I would also like to see more
>> policy options there, such as "only
>> connect anonymous", or a policy where it is clear if the server does any
>> kind of authentication, or whether it
>> will allow a BTNS type security policy without client authentication.
>>
>>
>>  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.
>>>
>>
>> Let's cut the chase here. It's independant of CA's. Yes. It's an
>> alternative. Yes. Your worry has been noted. Again.
>> You can ensure browser vendors are aware of these limitations in respect
>> to deploying CA's, and recommend
>> what they implement and support. But there is no reason to try and stop a
>> protocol development that does not
>> rely on the currently deployed CA infrastructure - an infrastructure some
>> people have lost faith in, with good
>> reason.
>>
>> Paul
>>
>
>
>
> --
> Website: http://hallambaker.com/
>
>  _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>
>
>

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

--0016e644cf6c6506a504939878e7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Security policy is generally understood to mean anything that was addr=
essed in Matt Blaze&#39;s PolicyMaker scheme. Thus PKI trust chaining is ex=
cluded because it existed prior to PolicyMaker.</div><div><br></div><div>
Statements of the form &#39;always use SSL&#39; or &#39;only trust these ro=
ots&#39; are considered to be security policy statements.</div><div><br></d=
iv><div>But whatever they are called, the problem is considered to be very =
difficult. In particular the problem of telling relying parties that they s=
hould only trust specific roots or certs for a domain is considered very di=
fficult.</div>
<div><br></div><div><br></div><div>What is being proposed here is not simpl=
y a matter of &#39;client choice&#39;.</div><div><br></div><div>If there ar=
e any clients out there that make security policy decisions based on the ex=
istence of TLSFP records then these must be explicit to the domains publish=
ing the records. Otherwise we end up with a massive interoperability failur=
e.</div>
<div><br></div><div>I want to be able to publish a TLSFP certificate for my=
 mail server (SMTP and IMAP) without affecting my Web server.</div><div><br=
></div><div>That is not going to be possible if there is even one client ou=
t there that sees a TLSFP record and decides to reject a perfectly good cer=
tificate path as a result or worse decides that it is not going to connect =
to my Web server that does not have TLS and was never intended to.</div>
<div><br></div><div><br></div><div>As for the idea that &#39;nobody is prop=
osing this&#39;. Paul Wooters just suggested doing exactly that and the TLS=
FP code does exactly that.</div><div><br><br><div class=3D"gmail_quote">On =
Wed, Oct 27, 2010 at 7:45 AM, Richard L. Barnes <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div style=3D"word-wrap:break-word">Phillip=
,<div><br></div><div>Nothing in this proposal creates security policy. =A0I=
t creates inputs for things that go into security policy. =A0All that the p=
roposed records do is provide another input into the client&#39;s *internal=
* process for deciding whether a credential is tied to a particular domain.=
 =A0Clients are free to validate or not validate certificates as they choos=
e. =A0Please stop trying to reinforce the misconception that the proposed m=
echanism overrides PKIX validation in any way. =A0</div>
<div><br></div><div>--Richard</div><div><br></div><div><br></div><div><br><=
div><div><div></div><div class=3D"h5"><div>On Oct 26, 2010, at 9:03 PM, Phi=
llip Hallam-Baker wrote:</div><br></div></div><blockquote type=3D"cite"><di=
v>
<div></div><div class=3D"h5">Since this is a charter discussion, it goes to=
 the IESG.<div><br></div><div>My point is not that the IETF should not addr=
ess Security Policy, it is that any security mechanism should be completely=
 independent of defining a new and additional mechanism to sign public keys=
.</div>
 <div><br></div><div>It should be able for a domain to publish public keys =
in the DNS without impact on existing deployed SSL certificates and it shou=
ld be possible for a domain to publish security policy constraining trusted=
 keys without having to do so by publishing their keys in the DNS.</div>
 <div><br></div><div>If the policy of a site is that every certificate is i=
ssued off a local CA root that is cross certified to a public root, it shou=
ld suffice to state that every valid cert is issued of the local CA root.</=
div>
 <div><br></div><div><br></div><div>My reason for wanting this distinction =
is twofold. First I believe it is a matter of sound architectural practice =
to separate the two issued, Secondly I believe that the IAB and IESG are go=
ing to insist on this distinction.</div>
 <div><br></div><div>The worst outcome here would be for the WG to be chart=
ered with an ambiguous remit, spend a year or two working on the issue and =
then produce a proposal that is thrown out by the IESG because they insist =
that the two issues be kept separate.</div>
 <div><br></div><div>The second worse outcome is to be kicked back with a r=
equest to define the problem we are trying to solve. I think that process i=
s going to take longer than solving the key signing problem. We really do u=
nderstand the key signing problem very well.</div>
 <div><br></div><div><br></div><div>We have done mechanisms for signing key=
s before. It is a well constrained problem. I think that having a mechanism=
 for signing keys on the basis of DNSSEC is a worthwhile achievement on its=
 own. We should be able to knock that one off in about six months. Then we =
can approach the IESG and invoke the pinball rule under RFC 2418 sec 4: If =
you win you get to play again.<br>
 <br></div><div>By that time, I hope that we have some results to show with=
 CAA which addresses a very limited aspect of security policy that does not=
 affect the client. Based on the feedback I have had so far from targeted d=
omains and from CAs, that looks like a win-win.</div>
 <div><br></div><div>So at that time I think we can expect to be able to go=
 back to the IESG and tell them that we want to do security policy and that=
 we are pretty sure that we understand the issues involved and can produce =
a nicely abstracted platform that has strong separation of concerns and red=
uces the entropy in the Internet architecture rather than further increasin=
g it..</div>
 <div><br></div><div><br></div><div><br><div class=3D"gmail_quote">On Tue, =
Oct 26, 2010 at 8:06 PM, Paul Wouters <span dir=3D"ltr">&lt;<a href=3D"mail=
to:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"> On Tue, 26 Oct 2010, Phillip Hallam-Baker w=
rote:<br> <br> [not sure if such a broad CC: is warranted]<div><br> <br> <b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
 I think that this mechanism is entirely logical and useful. DNSSEC is enti=
rely adequate for the purpose of establishing<br> a key as being sufficient=
 to enable use of encryption.=A0<br> <br> The second set of proposals relat=
es to security policy.<br>
 </blockquote> <br></div> the first is a security policy as well.<div><br> =
<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"> In particular the TLSFP scheme defines=
 a path validation<br>
 algorithm that overrides the standard PKIX processing mechanism in two way=
s.<br> </blockquote> <br></div> Not override, alternative. Depending on cli=
ent policy. Image systems with no CA&#39;s.<div><br> <br> <blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
 Secondly, there is an assumption in TLSFP that any domain that publishes C=
ERT records of TLSFP certificate type will<br> publish TLSFP records for AL=
L valid SSL certs in use for the domain. So the publication of a TLSFP reco=
rd to enable<br>
 secure communication on the mail server will cause the SSL certificate on =
the Web server to be considered invalid.<br> </blockquote> <br></div> I don=
&#39;t see that. The browser and its CA policy installation can still ignor=
e TLSFP. In fact, I strongly<br>
 suspect they will in at least the near future.<div><br> <br> <blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"> I find this proposal troubling for severalreasons. First=
 it lacks orthogonality. It should be able to use the DNSSEC to<br>
 establish additional keys without affecting existing trust systems in any =
way whatsoever.<br> </blockquote> <br></div> It does. Its an addon a client=
 can decide to use or not use.<div><br> <br> <blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
 I dislike<br> any mechanism that requires the administrator to perform con=
figuration in the DNS for each and every SSL certificate as<br> it is issue=
d.<br> </blockquote> <br></div> I dislike needing to delete so many untrust=
ed omnipotent CA&#39;s from my<br>
 browser. But our personal dislikes are irrelevant to protocol design.<div>=
<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"> Thirdly, the percentage of Intern=
et traffic that is encrypted today is negligible. I think that we should ma=
ke<br>
 encouraging the use of encryption a higher priority than correcting what s=
ome people see as flaws in the trust provision<br> for existing sites. The =
security policy that has the highest leverage is statements of the form &#3=
9;always use TLS&#39;.<br>
 </blockquote> <br></div> The existence of a TLSFP record could mean &quot;=
always use TLS&quot;. The WG is going to discuss whether or not to use<br> =
bits for these things in the coming months. I would also like to see more p=
olicy options there, such as &quot;only<br>
 connect anonymous&quot;, or a policy where it is clear if the server does =
any kind of authentication, or whether it<br> will allow a BTNS type securi=
ty policy without client authentication.<div><br> <br> <blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
 What worries me here is the that the WG should decide to address a single =
aspect of security policy, address that aspect<br> from a single point of v=
iew and then optimize for that single scope.<br> </blockquote> <br></div>
 Let&#39;s cut the chase here. It&#39;s independant of CA&#39;s. Yes. It&#3=
9;s an alternative. Yes. Your worry has been noted. Again.<br> You can ensu=
re browser vendors are aware of these limitations in respect to deploying C=
A&#39;s, and recommend<br>
 what they implement and support. But there is no reason to try and stop a =
protocol development that does not<br> rely on the currently deployed CA in=
frastructure - an infrastructure some people have lost faith in, with good<=
br>
 reason.<br><font color=3D"#888888"> <br> Paul<br> </font></blockquote></di=
v><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"http://hallambaker.c=
om/" target=3D"_blank">http://hallambaker.com/</a><br><br> </div></div></di=
v><div class=3D"im">
 _______________________________________________<br>keyassure mailing list<=
br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=
rg</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" targe=
t=3D"_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</div></blockquote></div><br></div></div></blockquote></div><br><br clear=
=3D"all"><br>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hal=
lambaker.com/</a><br><br>
</div>

--0016e644cf6c6506a504939878e7--

Date: Wed, 27 Oct 2010 14:29:36 +0200
From: Yaron Sheffer <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

Hi Andrew,

I must be doing something right, if I'm coming out on the side of the 
bad guys :-)

My intention is not to add bureaucratic hurdles. It is to ensure that 
the group has reasonable consensus about its goals. I get worried when I 
see indecision about requirements/goals trickle into the technical spec, 
as I demonstrated in my earlier mail.

If this is really a happy group of like-minded people, it should be easy 
to cut-and-paste the charter, as well as your and Stephane's 
clarifications into a Problem Statement I-D, and get it published soon 
after the working group is formed. It need not block the work on the 
technical solution.

Thanks,
	Yaron

On 10/27/2010 01:41 PM, Andrew Sullivan wrote:
> On Tue, Oct 26, 2010 at 10:44:23PM +0200, 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, it seems to me that such a reaction is exactly why
> people give up on doing work at the IETF: the bureaucratic hurdles to
> completing the job that get thrown up make people go away in
> frustration.
>
> We have a community of interested people.  We have a reasonably clear
> idea of the initial goal of the work.  We have different and competing
> proposals for how to get that work done.  We also have some sceptics
> who want to take a completely different approach.  We have people
> committed to doing review.  We have a proposed charter with measurable
> deliverables.  This sounds to me like a community that has coalesced
> around a problem and is ready to do the work.  To me, that means we
> already _have_ a working group (i.e. a group of people doing work),
> and the question is merely whether the IETF machinery acknowledges it.
>
> I'm not opposed to altering the charter to say, "This work allows
> sites to publish keys in the DNS and for clients to use those key
> securely without any validation infrastructure apart from DNSSEC," or
> something like that.  But I don't believe we need to discuss more
> whether there is work to do, whether it can be done in a reasonable
> time, or whether there is a community to do that work (all the things
> a BOF would determine).  We have ample demonstration, I think.
>
> A
>
>

From: "Richard L. Barnes" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Oct 2010 07:45:01 -0400
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

--Apple-Mail-2-635056657
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Phillip,

Nothing in this proposal creates security policy.  It creates inputs  
for things that go into security policy.  All that the proposed  
records do is provide another input into the client's *internal*  
process for deciding whether a credential is tied to a particular  
domain.  Clients are free to validate or not validate certificates as  
they choose.  Please stop trying to reinforce the misconception that  
the proposed mechanism overrides PKIX validation in any way.

--Richard

On Oct 26, 2010, at 9:03 PM, Phillip Hallam-Baker wrote:

> Since this is a charter discussion, it goes to the IESG.
>
> My point is not that the IETF should not address Security Policy, it  
> is that any security mechanism should be completely independent of  
> defining a new and additional mechanism to sign public keys.
>
> It should be able for a domain to publish public keys in the DNS  
> without impact on existing deployed SSL certificates and it should  
> be possible for a domain to publish security policy constraining  
> trusted keys without having to do so by publishing their keys in the  
> DNS.
>
> If the policy of a site is that every certificate is issued off a  
> local CA root that is cross certified to a public root, it should  
> suffice to state that every valid cert is issued of the local CA root.
>
>
> My reason for wanting this distinction is twofold. First I believe  
> it is a matter of sound architectural practice to separate the two  
> issued, Secondly I believe that the IAB and IESG are going to insist  
> on this distinction.
>
> The worst outcome here would be for the WG to be chartered with an  
> ambiguous remit, spend a year or two working on the issue and then  
> produce a proposal that is thrown out by the IESG because they  
> insist that the two issues be kept separate.
>
> The second worse outcome is to be kicked back with a request to  
> define the problem we are trying to solve. I think that process is  
> going to take longer than solving the key signing problem. We really  
> do understand the key signing problem very well.
>
>
> We have done mechanisms for signing keys before. It is a well  
> constrained problem. I think that having a mechanism for signing  
> keys on the basis of DNSSEC is a worthwhile achievement on its own.  
> We should be able to knock that one off in about six months. Then we  
> can approach the IESG and invoke the pinball rule under RFC 2418 sec  
> 4: If you win you get to play again.
>
> By that time, I hope that we have some results to show with CAA  
> which addresses a very limited aspect of security policy that does  
> not affect the client. Based on the feedback I have had so far from  
> targeted domains and from CAs, that looks like a win-win.
>
> So at that time I think we can expect to be able to go back to the  
> IESG and tell them that we want to do security policy and that we  
> are pretty sure that we understand the issues involved and can  
> produce a nicely abstracted platform that has strong separation of  
> concerns and reduces the entropy in the Internet architecture rather  
> than further increasing it..
>
>
>
> On Tue, Oct 26, 2010 at 8:06 PM, Paul Wouters <[email-masked]>  
> wrote:
> On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote:
>
> [not sure if such a broad CC: is warranted]
>
>
> 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.
>
> the first is a security policy as well.
>
>
> In particular the TLSFP scheme defines a path validation
> algorithm that overrides the standard PKIX processing mechanism in  
> two ways.
>
> Not override, alternative. Depending on client policy. Image systems  
> with no CA's.
>
>
> 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 don't see that. The browser and its CA policy installation can  
> still ignore TLSFP. In fact, I strongly
> suspect they will in at least the near future.
>
>
> 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.
>
> It does. Its an addon a client can decide to use or not use.
>
>
> I dislike
> any mechanism that requires the administrator to perform  
> configuration in the DNS for each and every SSL certificate as
> it is issued.
>
> I dislike needing to delete so many untrusted omnipotent CA's from my
> browser. But our personal dislikes are irrelevant to protocol design.
>
>
> 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'.
>
> The existence of a TLSFP record could mean "always use TLS". The WG  
> is going to discuss whether or not to use
> bits for these things in the coming months. I would also like to see  
> more policy options there, such as "only
> connect anonymous", or a policy where it is clear if the server does  
> any kind of authentication, or whether it
> will allow a BTNS type security policy without client authentication.
>
>
> 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.
>
> Let's cut the chase here. It's independant of CA's. Yes. It's an  
> alternative. Yes. Your worry has been noted. Again.
> You can ensure browser vendors are aware of these limitations in  
> respect to deploying CA's, and recommend
> what they implement and support. But there is no reason to try and  
> stop a protocol development that does not
> rely on the currently deployed CA infrastructure - an infrastructure  
> some people have lost faith in, with good
> reason.
>
> Paul
>
>
>
> -- 
> Website: http://hallambaker.com/
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

--Apple-Mail-2-635056657
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; =
">Phillip,<div><br></div><div>Nothing in this proposal creates security =
policy. &nbsp;It creates inputs for things that go into security policy. =
&nbsp;All that the proposed records do is provide another input into the =
client's *internal* process for deciding whether a credential is tied to =
a particular domain. &nbsp;Clients are free to validate or not validate =
certificates as they choose. &nbsp;Please stop trying to reinforce the =
misconception that the proposed mechanism overrides PKIX validation in =
any way. =
&nbsp;</div><div><br></div><div>--Richard</div><div><br></div><div><br></d=
iv><div><br><div><div>On Oct 26, 2010, at 9:03 PM, Phillip Hallam-Baker =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">Since this is a charter discussion, it goes to the =
IESG.<div><br></div><div>My point is not that the IETF should not =
address Security Policy, it is that any security mechanism should be =
completely independent of defining a new and additional mechanism to =
sign public keys.</div> <div><br></div><div>It should be able for a =
domain to publish public keys in the DNS without impact on existing =
deployed SSL certificates and it should be possible for a domain to =
publish security policy constraining trusted keys without having to do =
so by publishing their keys in the DNS.</div> <div><br></div><div>If the =
policy of a site is that every certificate is issued off a local CA root =
that is cross certified to a public root, it should suffice to state =
that every valid cert is issued of the local CA root.</div> =
<div><br></div><div><br></div><div>My reason for wanting this =
distinction is twofold. First I believe it is a matter of sound =
architectural practice to separate the two issued, Secondly I believe =
that the IAB and IESG are going to insist on this distinction.</div> =
<div><br></div><div>The worst outcome here would be for the WG to be =
chartered with an ambiguous remit, spend a year or two working on the =
issue and then produce a proposal that is thrown out by the IESG because =
they insist that the two issues be kept separate.</div> =
<div><br></div><div>The second worse outcome is to be kicked back with a =
request to define the problem we are trying to solve. I think that =
process is going to take longer than solving the key signing problem. We =
really do understand the key signing problem very well.</div> =
<div><br></div><div><br></div><div>We have done mechanisms for signing =
keys before. It is a well constrained problem. I think that having a =
mechanism for signing keys on the basis of DNSSEC is a worthwhile =
achievement on its own. We should be able to knock that one off in about =
six months. Then we can approach the IESG and invoke the pinball rule =
under RFC 2418 sec 4: If you win you get to play again.<br> =
<br></div><div>By that time, I hope that we have some results to show =
with CAA which addresses a very limited aspect of security policy that =
does not affect the client. Based on the feedback I have had so far from =
targeted domains and from CAs, that looks like a win-win.</div> =
<div><br></div><div>So at that time I think we can expect to be able to =
go back to the IESG and tell them that we want to do security policy and =
that we are pretty sure that we understand the issues involved and can =
produce a nicely abstracted platform that has strong separation of =
concerns and reduces the entropy in the Internet architecture rather =
than further increasing it..</div> =
<div><br></div><div><br></div><div><br><div class=3D"gmail_quote">On =
Tue, Oct 26, 2010 at 8:06 PM, Paul Wouters <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;"> On Tue, 26 Oct 2010, =
Phillip Hallam-Baker wrote:<br> <br> [not sure if such a broad CC: is =
warranted]<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> =
I think that this mechanism is entirely logical and useful. DNSSEC is =
entirely adequate for the purpose of establishing<br> a key as being =
sufficient to enable use of encryption.&nbsp;<br> <br> The second set of =
proposals relates to security policy.<br> </blockquote> <br></div> the =
first is a security policy as well.<div class=3D"im"><br> <br> =
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"> In particular the =
TLSFP scheme defines a path validation<br> algorithm that overrides the =
standard PKIX processing mechanism in two ways.<br> </blockquote> =
<br></div> Not override, alternative. Depending on client policy. Image =
systems with no CA's.<div class=3D"im"><br> <br> <blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"> Secondly, there is an assumption in TLSFP that =
any domain that publishes CERT records of TLSFP certificate type =
will<br> publish TLSFP records for ALL valid SSL certs in use for the =
domain. So the publication of a TLSFP record to enable<br> secure =
communication on the mail server will cause the SSL certificate on the =
Web server to be considered invalid.<br> </blockquote> <br></div> I =
don't see that. The browser and its CA policy installation can still =
ignore TLSFP. In fact, I strongly<br> suspect they will in at least the =
near future.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> =
I find this proposal troubling for severalreasons. First it lacks =
orthogonality. It should be able to use the DNSSEC to<br> establish =
additional keys without affecting existing trust systems in any way =
whatsoever.<br> </blockquote> <br></div> It does. Its an addon a client =
can decide to use or not use.<div class=3D"im"><br> <br> <blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"> I dislike<br> any mechanism that requires the =
administrator to perform configuration in the DNS for each and every SSL =
certificate as<br> it is issued.<br> </blockquote> <br></div> I dislike =
needing to delete so many untrusted omnipotent CA's from my<br> browser. =
But our personal dislikes are irrelevant to protocol design.<div =
class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Thirdly, the =
percentage of Internet traffic that is encrypted today is negligible. I =
think that we should make<br> encouraging the use of encryption a higher =
priority than correcting what some people see as flaws in the trust =
provision<br> for existing sites. The security policy that has the =
highest leverage is statements of the form 'always use TLS'.<br> =
</blockquote> <br></div> The existence of a TLSFP record could mean =
"always use TLS". The WG is going to discuss whether or not to use<br> =
bits for these things in the coming months. I would also like to see =
more policy options there, such as "only<br> connect anonymous", or a =
policy where it is clear if the server does any kind of authentication, =
or whether it<br> will allow a BTNS type security policy without client =
authentication.<div class=3D"im"><br> <br> <blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"> What worries me here is the that the WG should =
decide to address a single aspect of security policy, address that =
aspect<br> from a single point of view and then optimize for that single =
scope.<br> </blockquote> <br></div> Let's cut the chase here. It's =
independant of CA's. Yes. It's an alternative. Yes. Your worry has been =
noted. Again.<br> You can ensure browser vendors are aware of these =
limitations in respect to deploying CA's, and recommend<br> what they =
implement and support. But there is no reason to try and stop a protocol =
development that does not<br> rely on the currently deployed CA =
infrastructure - an infrastructure some people have lost faith in, with =
good<br> reason.<br><font color=3D"#888888"> <br> Paul<br> =
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a =
href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br> =
</div> _______________________________________________<br>keyassure =
mailing list<br><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br><a =
href=3D"https://www.ietf.org/mailman/listinfo/keyassure">https://www.ietf.=
org/mailman/listinfo/keyassure</a><br></blockquote></div><br></div></body>=
</html>=

--Apple-Mail-2-635056657--

Date: Wed, 27 Oct 2010 07:41:25 -0400
From: Andrew Sullivan <[email-masked]>
To: Yaron Sheffer <[email-masked]>
Cc: IESG Secretary <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

On Tue, Oct 26, 2010 at 10:44:23PM +0200, 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, it seems to me that such a reaction is exactly why
people give up on doing work at the IETF: the bureaucratic hurdles to
completing the job that get thrown up make people go away in
frustration.

We have a community of interested people.  We have a reasonably clear
idea of the initial goal of the work.  We have different and competing
proposals for how to get that work done.  We also have some sceptics
who want to take a completely different approach.  We have people
committed to doing review.  We have a proposed charter with measurable
deliverables.  This sounds to me like a community that has coalesced
around a problem and is ready to do the work.  To me, that means we
already _have_ a working group (i.e. a group of people doing work),
and the question is merely whether the IETF machinery acknowledges it.

I'm not opposed to altering the charter to say, "This work allows
sites to publish keys in the DNS and for clients to use those key
securely without any validation infrastructure apart from DNSSEC," or
something like that.  But I don't believe we need to discuss more
whether there is work to do, whether it can be done in a reasonable
time, or whether there is a community to do that work (all the things
a BOF would determine).  We have ample demonstration, I think.

A

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

Date: Wed, 27 Oct 2010 13:07:07 +0200
From: Yaron Sheffer <[email-masked]>
To: Stephane Bortzmeyer <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

Hi Stephane,

please see my comments below.

Thanks,
	Yaron

On 10/27/2010 10:03 AM, Stephane Bortzmeyer wrote:
> 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.
>
I'm glad to hear that. Thanks.

>> The group has not produced a problem statement,
>
> It is in the charter.

A charter is not an RFC. An RFC undergoes a different process, and is a 
permanent record of IETF consensus (but I don't have to tell you that). 
I think this group is badly in need of a PS document. If the group 
decides to publish one, I would be happy to participate.

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

The parenthetical remark at the end is incorrect: in a perfect world, I 
only have to trust the DNS manager (I assume you mean the operator) for 
*unprotected* communication, which is not our subject here.

Date: Wed, 27 Oct 2010 10:05:01 +0100
From: Ben Laurie <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Certification Authority Authorization Draft.

On 25 October 2010 18:36, Phillip Hallam-Baker <[email-masked]> wrote:
> On Mon, Oct 25, 2010 at 12:47 PM, Ben Laurie <[email-masked]> wrote:
>>
>> Sorry for the delay..
>>
>> Looking at the -01 version...
>>
>> "The authorizations specified in the dauth and pauth properties are
>> =A0 additive."
>>
>> I'm not sure "additive" is the right word - certainly it leaves me
>> wondering "does that mean 'and' or 'or'?". Later text confirms "or",
>> which was not my guess.
>
> I had difficulty drafting that. I think that the problem is that I should=
 be
> using the term 'permission' or 'authorization entry'.
>
>>
>> Why restrict tag length in the CAA RR?
>
> The tags are from an assigned space. The only protocol constraint I would
> really insist on is that the tag length needs to be expressible in a sing=
le
> byte.
> Do we really think we will need more than 2^16 different tags in a data
> record that has to fit into a 65535 byte space?

No, I just wondered what the point of the restriction was. Perhaps you
want to reserve the other 4 bits for flags (e.g. it occurred to me
that marking permissions as critical might serve some purpose)?

>
>>
>> "An ASN.1 DER encoded data field containing the digest value of the
>> =A0 =A0 =A0referenced object processed using the specified digest algori=
thm."
>>
>> I don't think this is an unambiguous specification - you have to
>> specify the ASN.1...
>
> I am not sure what point you were going to make here.

I mean you should say how it is encoded (that is, as an OCTET STRING).

> I am sure that there can be some byte sex issues that enter into things
> here.

I hope not!

> Some digest algorithms have more than one OID assigned. But the ones we
> currently recommend in IETF specs have exactly one OID assignment across =
all
> specifications, the one assigned by NIST. And this should be the same for
> the SHA-3 algorithms as well.

I'm talking about the digest itself, not the OID.

> One other point that was raised was that some people would like to have t=
he
> ODI data wrapped in an ASN.1 tag, length container as well.

Seems not unreasonable - in which case the tag would be OBJECT IDENTIFIER.

>
>>
>> " =A0 Use of DNSSEC to authenticate CAA RRs is strongly recommended but =
not
>> =A0 required. =A0A CA MUST observe a CAA RR that is returned whether it =
is
>> =A0 signed using DNSSEC or not."
>>
>> Fine - but I think it should say that applications MUST NOT observe a
>> CAA RR that is not signed.
>
> OK, that is fair enough.
> I am thinking that we may want to differentiate between authority to issu=
e
> and authority for relying parties.
> The issue authority statements refer to what an issuer is authorized to d=
o
> during the validity interval for the record.
> But the fact that an issuer is no longer authorized to issue new
> certificates does not invalidate the certificates they have already issue=
d.
> So the statement for relying parties may well contain more entries.

Excellent point.

>
>>
>> 4.2 should note that DNSSEC effectively prevents either suppression or
>> spoofing.
>>
>> Other than that, looks good to me
>
> That must have got lost in the editing.
>
>>
>> On 19 October 2010 03:17, Phillip Hallam-Baker <[email-masked]> wrote:
>> > Adam L. pointed out some typos and so on. I had to get it in today and=
 I
>> > am
>> > fighting off a cold.
>> >
>> > As we discussed in the call, we are very interested in having Google
>> > co-author if you are interested.
>> >
>> > CA buy-in is not so much of a worry for me. Comodo will deploy for
>> > certain
>> > and Symantec/VeriSignCA is pretty likely to follow.
>> > Assume for a moment that other CAs don't follow our lead and end up
>> > mis-issuing against a domain that has a CAA record. What do you think
>> > their
>> > liability is in that case? They certainly have a major PR issue at tha=
t
>> > point and their only realistic chance of surviving it without too much
>> > damage is going to be to deploy CAA.
>> >
>> > So all in all, I think that the chances are pretty good that we can
>> > present
>> > this as a win for all concerned.
>> >
>> > You may also be interested in my DPLS draft:
>> > http://www.ietf.org/id/draft-hallambaker-dpls-00.txt
>> > A lot of the DNS performance issues go away if the DNS client can ask
>> > its
>> > resolver 'hey give me all the info I need to do this with that'.
>> >
>> > On Mon, Oct 18, 2010 at 9:51 PM, Warren Kumari <[email-masked]>
>> > wrote:
>> >>
>> >> I have not yet read the whole draft, but so far I really like it.
>> >>
>> >> While (as you already pointed out) it doesn't solve all of the issues=
,
>> >> it
>> >> does go a long way towards improving matters, assuming of course the
>> >> CAs buy
>> >> in...
>> >>
>> >> W
>> >> On Oct 18, 2010, at 5:32 PM, Phillip Hallam-Baker wrote:
>> >>
>> >> > This is a draft that I submitted this morning. The main proposal
>> >> > being
>> >> > made here is to enable Certification Authorities to avoid mis-issue=
.
>> >> >
>> >> > As such I believe that it is complimentary to mechanisms that enabl=
e
>> >> > client side enforcement but has the considerable advantage of
>> >> > offering
>> >> > immediate protection to every Internet user regardless of whether
>> >> > they have
>> >> > an updated browser. It is also much less strongly dependent on
>> >> > deployment of
>> >> > DNSSEC.
>> >> > http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt
>> >> >
>> >> >
>> >> > Given the nature of the proposal, it is probably better suited to
>> >> > having
>> >> > the bulk of the legal-technical work considered in CABForum rather
>> >> > than
>> >> > IETF. Accordingly the proposal is designed to allow the technical
>> >> > infrastructure to be agreed in IETF and then the practices and lega=
l
>> >> > work
>> >> > done in CABForum.
>> >> >
>> >> > Clearly a record of this type could be used to effect client policy
>> >> > enforcement mechanisms. But this is a rather more complex issue and
>> >> > there
>> >> > are going to be a lot of people with views on the best way forward.
>> >> >
>> >> > The mechanism as specified is sufficient for allowing client side
>> >> > enforcement as it stands if the site is using a public CA, running =
a
>> >> > local
>> >> > CA cross certified into a public hierarchy or using a standalone
>> >> > private CA.
>> >> > But only if those infrastructures are supporting all their
>> >> > applications
>> >> > without exception.
>> >> >
>> >> >
>> >> > --
>> >> > Website: http://hallambaker.com/
>> >> >
>> >> > _______________________________________________
>> >> > keyassure mailing list
>> >> > [email-masked]
>> >> > https://www.ietf.org/mailman/listinfo/keyassure
>> >>
>> >
>> >
>> >
>> > --
>> > Website: http://hallambaker.com/
>> >
>> >
>> > _______________________________________________
>> > keyassure mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/keyassure
>> >
>> >
>
>
>
> --
> Website: http://hallambaker.com/
>
>

Date: Wed, 27 Oct 2010 10:47:44 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

On 27.10.2010 10:03, Stephane Bortzmeyer wrote:
> 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.

I could also add that this work was presented on at least two Centr[1] 
meetings and I just asked dns-wg@ripe chairs to present the work on RIPE 
61 in Rome.  But I think it was very well communicated to the TLD 
community through the various interest mailing lists.

1. CENTR is an association of Internet Country Code Top Level Domain 
Registries (www.centr.org)

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

Date: Wed, 27 Oct 2010 10:34:40 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Certification Authority Authorization Draft.

On 25.10.2010 11:36, Jakob Schlyter wrote:
> On 24 okt 2010, at 23.48, Phillip Hallam-Baker wrote:
>
>> There is no magic in the choice of bits on the wire. DNSSEC suffers
>> from exactly the same set of issuing chain difficulties as PKI
>> does. The number of DNS registrars is actually considerably larger
>> than the number of SSL validation authorities.
>
> Except that it is apparent for the victim when a DNS registrar goes
> rogue (as the result is published in the DNS), whereas a trusted CA
> can issue bad certificates without detection.

And many registries implement lock-down function, where you can tie your 
domain name to current registrar and prevent all transfers.  Some 
registries do it on the registry level[*] and I know I could lock at 
least some gTLDs via my registrar.  If there is need on higher 
protection from rogue registrars then more registries could implement 
lock-down function.

So your current sponsoring registrar would have to go wild.  But you are 
not protected in that case even nowadays.  (Issuing DV certs on 
whois/DNS data...)  (And some registrars have even direct channel with 
some CAs.)

Ondrej
* - http://www.nic.cz/whois/publicrequest/
-- 
  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
  -------------------------------------------

Date: Wed, 27 Oct 2010 10:25:27 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

[Replying to Phillip and Paul simultaneously]

On 27.10.2010 02:06, Paul Wouters wrote:
> On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote:
>> In particular the TLSFP scheme defines a path validation algorithm
>>  that overrides the standard PKIX processing mechanism in two
>> ways.
>
> Not override, alternative. Depending on client policy. Image systems
>  with no CA's.

True.

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

Just a note:  There is no such assumption in the charter.  This is just
one particular I-D.

>> 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 don't see that. The browser and its CA policy installation can
> still ignore TLSFP. In fact, I strongly suspect they will in at least
> the near future.

And I don't see that as a problem anyway.  The scope of this proposed WG
is to link domain names to certificates.  As stated by Stephane in other
thread in keyassure list, newer protocols generally use (or can use) SRV
record to distinguish between different services.  It will take some
effort on the sysadmin side to make the TLSFP work as intended, but
setting up security was never painless.  And people who will find this
too difficult can still use old CA scheme.  But it will give a people
with a skill the tool to make things more secure than now.

>> I find this proposal troubling for several reasons. 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.

I don't understand why it should?  You can decide if you want to use 
DNSSEC or not.  You can decide if you want to use TLSFP or not.  It's up 
to each domain holder if he will use this mechanism or not.

>> 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'.
>
> The existence of a TLSFP record could mean "always use TLS". The WG
> is going to discuss whether or not to use bits for these things in
> the coming months. I would also like to see more policy options
> there, such as "only connect anonymous", or a policy where it is
> clear if the server does any kind of authentication, or whether it
> will allow a BTNS type security policy without client
> authentication.

Yes, I think our proposed charter allows that.

>> 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.
>
> Let's cut the chase here. It's independant of CA's. Yes. It's an
> alternative. Yes. Your worry has been noted. Again. You can ensure
> browser vendors are aware of these limitations in respect to
> deploying CA's, and recommend what they implement and support. But
> there is no reason to try and stop a protocol development that does
> not rely on the currently deployed CA infrastructure - an
> infrastructure some people have lost faith in, with good reason.

My understanding is that this was discussed in the keyassure before and 
the charter was built upon rough consensus.  I don't think it's 
necessary to reiterate through all this again on IESG list.

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

Date: Wed, 27 Oct 2010 10:06:48 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

On 27.10.2010 03:03, Phillip Hallam-Baker wrote:
> The worst outcome here would be for the WG to be chartered with an
> ambiguous remit, spend a year or two working on the issue and then
> produce a proposal that is thrown out by the IESG because they insist
> that the two issues be kept separate.
 >
> The second worse outcome is to be kicked back with a request to define
> the problem we are trying to solve. I think that process is going to
> take longer than solving the key signing problem. We really do
> understand the key signing problem very well.

I would say that IESG could speak for themselves...  Aftera all, we are 
discussing this on the IESG list.  I think it's futile to discuss what 
other parties may or may not do and not to ask them.

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

Date: Wed, 27 Oct 2010 10:03:35 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: Yaron Sheffer <[email-masked]>
Organization: NIC France
Cc: [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

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

Date: Wed, 27 Oct 2010 09:45:31 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: Paul Wouters <[email-masked]>
Organization: NIC France
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt

On Mon, Oct 25, 2010 at 12:26:27PM -0400,
 Paul Wouters <[email-masked]> wrote 
 a message of 18 lines which said:

> I would say the world is moving in the other direction. You use
> "cnn.com" and "twitter.com", not www.cnn.com or www.twitter.com.  I
> am [email-masked], not [email-masked].

HTTP is very specific in that respect. It is the only major protocol
(I do not consider RFC 1288 as "major") which do not use SRV (or a
similar solution, such as MX). Hence the trick of an address record on
the delegated domain.

For your second example, the name to lookup in the DNS is
hermes.jabber.org, target of the SRV, not jabber.org.

Date: Tue, 26 Oct 2010 21:03:23 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

--00163698968fc57a6c04938ecaea
Content-Type: text/plain; charset=ISO-8859-1

Since this is a charter discussion, it goes to the IESG.

My point is not that the IETF should not address Security Policy, it is that
any security mechanism should be completely independent of defining a new
and additional mechanism to sign public keys.

It should be able for a domain to publish public keys in the DNS without
impact on existing deployed SSL certificates and it should be possible for a
domain to publish security policy constraining trusted keys without having
to do so by publishing their keys in the DNS.

If the policy of a site is that every certificate is issued off a local CA
root that is cross certified to a public root, it should suffice to state
that every valid cert is issued of the local CA root.

My reason for wanting this distinction is twofold. First I believe it is a
matter of sound architectural practice to separate the two issued, Secondly
I believe that the IAB and IESG are going to insist on this distinction.

The worst outcome here would be for the WG to be chartered with an ambiguous
remit, spend a year or two working on the issue and then produce a proposal
that is thrown out by the IESG because they insist that the two issues be
kept separate.

The second worse outcome is to be kicked back with a request to define the
problem we are trying to solve. I think that process is going to take longer
than solving the key signing problem. We really do understand the key
signing problem very well.

We have done mechanisms for signing keys before. It is a well constrained
problem. I think that having a mechanism for signing keys on the basis of
DNSSEC is a worthwhile achievement on its own. We should be able to knock
that one off in about six months. Then we can approach the IESG and invoke
the pinball rule under RFC 2418 sec 4: If you win you get to play again.

By that time, I hope that we have some results to show with CAA which
addresses a very limited aspect of security policy that does not affect the
client. Based on the feedback I have had so far from targeted domains and
from CAs, that looks like a win-win.

So at that time I think we can expect to be able to go back to the IESG and
tell them that we want to do security policy and that we are pretty sure
that we understand the issues involved and can produce a nicely abstracted
platform that has strong separation of concerns and reduces the entropy in
the Internet architecture rather than further increasing it..

On Tue, Oct 26, 2010 at 8:06 PM, Paul Wouters <[email-masked]> wrote:

> On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote:
>
> [not sure if such a broad CC: is warranted]
>
>
>  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.
>>
>
> the first is a security policy as well.
>
>
>  In particular the TLSFP scheme defines a path validation
>> algorithm that overrides the standard PKIX processing mechanism in two
>> ways.
>>
>
> Not override, alternative. Depending on client policy. Image systems with
> no CA's.
>
>
>  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 don't see that. The browser and its CA policy installation can still
> ignore TLSFP. In fact, I strongly
> suspect they will in at least the near future.
>
>
>  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.
>>
>
> It does. Its an addon a client can decide to use or not use.
>
>
>  I dislike
>> any mechanism that requires the administrator to perform configuration in
>> the DNS for each and every SSL certificate as
>> it is issued.
>>
>
> I dislike needing to delete so many untrusted omnipotent CA's from my
> browser. But our personal dislikes are irrelevant to protocol design.
>
>
>  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'.
>>
>
> The existence of a TLSFP record could mean "always use TLS". The WG is
> going to discuss whether or not to use
> bits for these things in the coming months. I would also like to see more
> policy options there, such as "only
> connect anonymous", or a policy where it is clear if the server does any
> kind of authentication, or whether it
> will allow a BTNS type security policy without client authentication.
>
>
>  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.
>>
>
> Let's cut the chase here. It's independant of CA's. Yes. It's an
> alternative. Yes. Your worry has been noted. Again.
> You can ensure browser vendors are aware of these limitations in respect to
> deploying CA's, and recommend
> what they implement and support. But there is no reason to try and stop a
> protocol development that does not
> rely on the currently deployed CA infrastructure - an infrastructure some
> people have lost faith in, with good
> reason.
>
> Paul
>

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

--00163698968fc57a6c04938ecaea
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Since this is a charter discussion, it goes to the IESG.<div><br></div><div=
>My point is not that the IETF should not address Security Policy, it is th=
at any security mechanism should be completely independent of defining a ne=
w and additional mechanism to sign public keys.</div>
<div><br></div><div>It should be able for a domain to publish public keys i=
n the DNS without impact on existing deployed SSL certificates and it shoul=
d be possible for a domain to publish security policy constraining trusted =
keys without having to do so by publishing their keys in the DNS.</div>
<div><br></div><div>If the policy of a site is that every certificate is is=
sued off a local CA root that is cross certified to a public root, it shoul=
d suffice to state that every valid cert is issued of the local CA root.</d=
iv>
<div><br></div><div><br></div><div>My reason for wanting this distinction i=
s twofold. First I believe it is a matter of sound architectural practice t=
o separate the two issued, Secondly I believe that the IAB and IESG are goi=
ng to insist on this distinction.</div>
<div><br></div><div>The worst outcome here would be for the WG to be charte=
red with an ambiguous remit, spend a year or two working on the issue and t=
hen produce a proposal that is thrown out by the IESG because they insist t=
hat the two issues be kept separate.</div>
<div><br></div><div>The second worse outcome is to be kicked back with a re=
quest to define the problem we are trying to solve. I think that process is=
 going to take longer than solving the key signing problem. We really do un=
derstand the key signing problem very well.</div>
<div><br></div><div><br></div><div>We have done mechanisms for signing keys=
 before. It is a well constrained problem. I think that having a mechanism =
for signing keys on the basis of DNSSEC is a worthwhile achievement on its =
own. We should be able to knock that one off in about six months. Then we c=
an approach the IESG and invoke the pinball rule under RFC 2418 sec 4: If y=
ou win you get to play again.<br>
<br></div><div>By that time, I hope that we have some results to show with =
CAA which addresses a very limited aspect of security policy that does not =
affect the client. Based on the feedback I have had so far from targeted do=
mains and from CAs, that looks like a win-win.</div>
<div><br></div><div>So at that time I think we can expect to be able to go =
back to the IESG and tell them that we want to do security policy and that =
we are pretty sure that we understand the issues involved and can produce a=
 nicely abstracted platform that has strong separation of concerns and redu=
ces the entropy in the Internet architecture rather than further increasing=
 it..</div>
<div><br></div><div><br></div><div><br><div class=3D"gmail_quote">On Tue, O=
ct 26, 2010 at 8:06 PM, Paul Wouters <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex;">
On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote:<br>
<br>
[not sure if such a broad CC: is warranted]<div class=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I think that this mechanism is entirely logical and useful. DNSSEC is entir=
ely adequate for the purpose of establishing<br>
a key as being sufficient to enable use of encryption.=A0<br>
<br>
The second set of proposals relates to security policy.<br>
</blockquote>
<br></div>
the first is a security policy as well.<div class=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
In particular the TLSFP scheme defines a path validation<br>
algorithm that overrides the standard PKIX processing mechanism in two ways=
.<br>
</blockquote>
<br></div>
Not override, alternative. Depending on client policy. Image systems with n=
o CA&#39;s.<div class=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Secondly, there is an assumption in TLSFP that any domain that publishes CE=
RT records of TLSFP certificate type will<br>
publish TLSFP records for ALL valid SSL certs in use for the domain. So the=
 publication of a TLSFP record to enable<br>
secure communication on the mail server will cause the SSL certificate on t=
he Web server to be considered invalid.<br>
</blockquote>
<br></div>
I don&#39;t see that. The browser and its CA policy installation can still =
ignore TLSFP. In fact, I strongly<br>
suspect they will in at least the near future.<div class=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I find this proposal troubling for severalreasons. First it lacks orthogona=
lity. It should be able to use the DNSSEC to<br>
establish additional keys without affecting existing trust systems in any w=
ay whatsoever.<br>
</blockquote>
<br></div>
It does. Its an addon a client can decide to use or not use.<div class=3D"i=
m"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I dislike<br>
any mechanism that requires the administrator to perform configuration in t=
he DNS for each and every SSL certificate as<br>
it is issued.<br>
</blockquote>
<br></div>
I dislike needing to delete so many untrusted omnipotent CA&#39;s from my<b=
r>
browser. But our personal dislikes are irrelevant to protocol design.<div c=
lass=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Thirdly, the percentage of Internet traffic that is encrypted today is negl=
igible. I think that we should make<br>
encouraging the use of encryption a higher priority than correcting what so=
me people see as flaws in the trust provision<br>
for existing sites. The security policy that has the highest leverage is st=
atements of the form &#39;always use TLS&#39;.<br>
</blockquote>
<br></div>
The existence of a TLSFP record could mean &quot;always use TLS&quot;. The =
WG is going to discuss whether or not to use<br>
bits for these things in the coming months. I would also like to see more p=
olicy options there, such as &quot;only<br>
connect anonymous&quot;, or a policy where it is clear if the server does a=
ny kind of authentication, or whether it<br>
will allow a BTNS type security policy without client authentication.<div c=
lass=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
What worries me here is the that the WG should decide to address a single a=
spect of security policy, address that aspect<br>
from a single point of view and then optimize for that single scope.<br>
</blockquote>
<br></div>
Let&#39;s cut the chase here. It&#39;s independant of CA&#39;s. Yes. It&#39=
;s an alternative. Yes. Your worry has been noted. Again.<br>
You can ensure browser vendors are aware of these limitations in respect to=
 deploying CA&#39;s, and recommend<br>
what they implement and support. But there is no reason to try and stop a p=
rotocol development that does not<br>
rely on the currently deployed CA infrastructure - an infrastructure some p=
eople have lost faith in, with good<br>
reason.<br><font color=3D"#888888">
<br>
Paul<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--00163698968fc57a6c04938ecaea--

Date: Tue, 26 Oct 2010 20:06:51 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote:

[not sure if such a broad CC: is warranted]

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

the first is a security policy as well.

> In particular the TLSFP scheme defines a path validation
> algorithm that overrides the standard PKIX processing mechanism in two ways.

Not override, alternative. Depending on client policy. Image systems with no CA's.

> 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 don't see that. The browser and its CA policy installation can still ignore TLSFP. In fact, I strongly
suspect they will in at least the near future.

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

It does. Its an addon a client can decide to use or not use.

> I dislike
> any mechanism that requires the administrator to perform configuration in the DNS for each and every SSL certificate as
> it is issued.

I dislike needing to delete so many untrusted omnipotent CA's from my
browser. But our personal dislikes are irrelevant to protocol design.

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

The existence of a TLSFP record could mean "always use TLS". The WG is going to discuss whether or not to use
bits for these things in the coming months. I would also like to see more policy options there, such as "only
connect anonymous", or a policy where it is clear if the server does any kind of authentication, or whether it
will allow a BTNS type security policy without client authentication.

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

Let's cut the chase here. It's independant of CA's. Yes. It's an alternative. Yes. Your worry has been noted. Again.
You can ensure browser vendors are aware of these limitations in respect to deploying CA's, and recommend
what they implement and support. But there is no reason to try and stop a protocol development that does not
rely on the currently deployed CA infrastructure - an infrastructure some people have lost faith in, with good
reason.

Paul

Date: Tue, 26 Oct 2010 16:56:23 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Ted Hardie <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)
Reply-To: "Jeffrey A. Williams" <[email-masked]>

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]
>Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)
>
>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 ent=
ities"
>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=20
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:
>> A new IETF working group has been proposed in the Security Area. =C2=A0T=
he 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:
>> =C2=A0 =C2=A0Warren Kumari <[email-masked]>
>> =C2=A0 =C2=A0Ondrej Sury <[email-masked]>
>>
>> Security Area Directors:
>> =C2=A0 =C2=A0Sean Turner <[email-masked]>
>> =C2=A0 =C2=A0Tim Polk <[email-masked]>
>>
>> Security Area Advisor:
>> =C2=A0 =C2=A0Tim Polk <[email-masked]>
>>
>> Mailing Lists:
>> =C2=A0 =C2=A0General Discussion: [email-masked]
>> =C2=A0 =C2=A0To Subscribe: =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mai=
lman/listinfo/keyassure
>> =C2=A0 =C2=A0Archive:
>> 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 =C2=A0First WG draft of standards-track protocol for using DNS =
to
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associate hosts with keys for TLS and =
DTLS
>> Jan 2011 =C2=A0First WG draft of standards-track protocols for using DNS=
 to
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associate hosts with IPsec
>> Jun 2011 =C2=A0Protocol for using DNS to associate domain names with key=
s
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for TLS and DTLS to IESG
>> Aug 2011 =C2=A0Protocols for using DNS to associate domain names with ke=
ys
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for IPsec to IESG
>> Aug 2011 =C2=A0Recharter

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; liabilit=
y
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]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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]=
m
Phone: 214-244-4827

Date: Tue, 26 Oct 2010 16:49:55 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)
Reply-To: "Jeffrey A. Williams" <[email-masked]>

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]
>Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)
>
>Hi folks,
> I entirely disagree with this suggestion to delay protocol work until aft=
er
>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 i=
s
>needed to roll out this scheme should be entirely unsurprising. It's surel=
y
>not a reason to stop ANY work (apart from deep thought on the problem spac=
e).
>I trust we don't require a PS-level fully worked system before a WG can be=
gin.
>
>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 t=
o
>work on its charter tasks.
>I believe that the WG should begin now, and I would trust that there can b=
e
>implementations to test out the initial proposals soon. Running code is go=
od.
>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 th=
e
>ITU =C2=A7-) 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 ch=
oose
>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 ha=
nd
>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 wh=
at
>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.
>>=20
>> The group has not produced a problem statement, nor is one proposed in t=
he draft charter. While in most cases you can hide a problem statement in t=
he first section or two of an RFC, in this case it is essential that the us=
age scenarios be hashed out before the technical solutions are discussed.
>>=20
>> With respect, the technical solution from what I've seen doesn't look te=
rribly difficult, though we can argue forever about the details. But the ev=
entual goal of this work for some of the participants (and one which I pers=
onally support) is to provide an alternative to PKI. And the goal of this w=
ork 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 v=
alidation replaces or not the regular PKIX validation, with wording such as=
 "a client MAY choose to trust a DNSSEC-secured certificate association".
>>=20
>> Lastly, the group includes contributors from the CA industry, which is v=
ery good. But given that we're putting all our trust in the DNS infrastruct=
ure and procedures, I would hope to see some domain operators in the loop.
>>=20
>> 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.
>>=20
>> Thanks,
>> =09Yaron
>>=20
>> On 10/26/2010 07:00 PM, IESG Secretary wrote:
>>> A new IETF working group has been proposed in the Security Area.  The I=
ESG
>>> 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
>>>=20
>>> Keys In DNS (kidns)
>>> -----------------------
>>> Last modified: 2010-10-25
>>> Current status: Proposed Working Group
>>>=20
>>> Chairs:
>>>     Warren Kumari<[email-masked]>
>>>     Ondrej Sury<[email-masked]>
>>>=20
>>> Security Area Directors:
>>>     Sean Turner<[email-masked]>
>>>     Tim Polk<[email-masked]>
>>>=20
>>> Security Area Advisor:
>>>     Tim Polk<[email-masked]>
>>>=20
>>> 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
>>>=20
>>> 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.
>>>=20
>>> Problem Statement:
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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 a=
s
>>> identifiers. Possible starting points for these deliverables include
>>> draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and
>>> draft-josefsson-keyassure-tls.
>>>=20
>>> 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).
>>>=20
>>> 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.
>>>=20
>>> 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
>>> _______________________________________________

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; liabilit=
y
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]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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]=
m
Phone: 214-244-4827

From: Lawrence Conroy <[email-masked]>
Date: Tue, 26 Oct 2010 22:38:14 +0100
To: Yaron Sheffer <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

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 =A7-) 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.
>=20
> 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.
>=20
> 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".
>=20
> 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.
>=20
> 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.
>=20
> Thanks,
> 	Yaron
>=20
> On 10/26/2010 07:00 PM, IESG Secretary 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
>>=20
>> Keys In DNS (kidns)
>> -----------------------
>> Last modified: 2010-10-25
>> Current status: Proposed Working Group
>>=20
>> Chairs:
>>     Warren Kumari<[email-masked]>
>>     Ondrej Sury<[email-masked]>
>>=20
>> Security Area Directors:
>>     Sean Turner<[email-masked]>
>>     Tim Polk<[email-masked]>
>>=20
>> Security Area Advisor:
>>     Tim Polk<[email-masked]>
>>=20
>> 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
>>=20
>> 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.
>>=20
>> Problem Statement:
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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).
>>=20
>> 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.
>>=20
>> 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
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Tue, 26 Oct 2010 22:44:23 +0200
From: Yaron Sheffer <[email-masked]>
To: [email-masked]
Cc: [email-masked], IESG Secretary <[email-masked]>
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

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:
> 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

Date: Tue, 26 Oct 2010 15:30:55 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)
Reply-To: "Jeffrey A. Williams" <[email-masked]>

<HEAD>
<STYLE>body{font-size:10pt;font-family:arial,sans-serif;background-color:#f=
fffff;color:black;}p{margin:0px;}</STYLE>

<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18975"></HEAD>
<BODY>
<P>Phillip and all,</P>
<P>&nbsp;</P>
<P>&nbsp; I fully agree with this approach.&nbsp;<BR><BR><BR></P>
<BLOCKQUOTE style=3D"BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MAR=
GIN-LEFT: 0px">-----Original Message----- <BR>From: Phillip Hallam-Baker <H=
[email-masked]><BR>Sent: Oct 26, 2010 3:10 PM <BR>To: [email-masked] <BR>Cc=
: [email-masked], [email-masked] <BR>Subject: Re: [keyassure] W=
G Review: Keys In DNS (kidns) <BR><BR>There are two sets of work items bein=
g proposed for this group.
<DIV><BR></DIV>
<DIV>The first set of work describes mechanisms that allow a domain name ow=
ner to use the DNS to establish the validity of a key.</DIV>
<DIV><BR></DIV>
<DIV>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.&nbsp;</DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV>The second set of proposals relates to security policy. In particular =
the TLSFP scheme defines a path validation algorithm that overrides the sta=
ndard PKIX processing mechanism in two ways.</DIV>
<DIV><BR></DIV>
<DIV>First a certificate that has a valid TLSFP validation path is to be co=
nsidered valid even if it is a PKIX end entity cert and is invalid under PK=
IX path math. This may be acceptable but needs to be carefully considered.<=
/DIV>
<DIV><BR></DIV>
<DIV>Secondly, there is an assumption in TLSFP that any domain that publish=
es CERT records of TLSFP certificate type will publish TLSFP records for AL=
L valid SSL certs in use for the domain. So the publication of a TLSFP reco=
rd to enable secure communication on the mail server will cause the SSL cer=
tificate on the Web server to be considered invalid.</DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV>I find this proposal troubling for severalreasons. First it lacks orth=
ogonality. It should be able to use the DNSSEC to establish additional keys=
 without affecting existing trust systems in any way whatsoever. At the ver=
y least this behavior should be optional.&nbsp;</DIV>
<DIV><BR></DIV>
<DIV>Secondly, I am not at all convinced that enumeration of valid certific=
ates is a practical method of declaring security policy with respect to TLS=
 trust anchors. PKIX provides a rich set of semantics for validating certif=
icates. 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 woul=
d be if the CA took over maintenance of the DNS for the zone as well as the=
 PKI.&nbsp;</DIV>
<DIV><BR></DIV>
<DIV>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 trus=
t provision for existing sites. The security policy that has the highest le=
verage is statements of the form 'always use TLS'.</DIV>
<DIV><BR></DIV>
<DIV>What worries me here is the that the WG should decide to address a sin=
gle aspect of security policy, address that aspect from a single point of v=
iew and then optimize for that single scope.</DIV>
<DIV><BR></DIV>
<DIV>Specification of trust anchors and trust criteria is by far the most c=
omplex and difficult part of security policy in my view. I do not see the l=
ogic of punting on the high leverage aspects of security policy that are fa=
irly well constrained (always use TLS) and then deciding to address the har=
dest aspect of security policy in a fashion that is likely to raise severe =
scaling issues.</DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV>I think we need to look at security policy separately from the problem=
 of providing new ways to establish keys.</DIV>
<DIV><BR></DIV>
<DIV>I think we need to look at the whole problem of security policy togeth=
er and not just one aspect of security policy. If we are going to address s=
ecurity policy in stages we should start from the well defined problem of p=
rotocol security policy and punt on the difficult issue of trust configurat=
ion.</DIV>
<DIV><BR></DIV>
<DIV><BR>
<DIV class=3Dgmail_quote>On Tue, Oct 26, 2010 at 1:00 PM, IESG Secretary <S=
PAN dir=3Dltr>&lt;<A href=3D"mailto:[email-masked]" target=3D_blan=
k>[email-masked]</A>&gt;</SPAN> wrote:<BR>
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>A new IETF working group has been =
proposed in the Security Area. &nbsp;The IESG<BR>has not made any determina=
tion as yet. The following draft charter was<BR>submitted, and is provided =
for informational purposes only. Please send<BR>your comments to the IESG m=
ailing list (<A href=3D"mailto:[email-masked]" target=3D_blank>[email-masked]=
</A>) by Tuesday,<BR>November 7, 2010<BR><BR>Keys In DNS (kidns)<BR>-------=
----------------<BR>Last modified: 2010-10-25<BR>Current status: Proposed W=
orking Group<BR><BR>Chairs:<BR>&nbsp; &nbsp;Warren Kumari &lt;<A href=3D"ma=
ilto:[email-masked]" target=3D_blank>[email-masked]</A>&gt;<BR>&nbsp;=
 &nbsp;Ondrej Sury &lt;<A href=3D"mailto:[email-masked]" target=3D_blan=
k>[email-masked]</A>&gt;<BR><BR>Security Area Directors:<BR>&nbsp; &nbs=
p;Sean Turner &lt;<A href=3D"mailto:[email-masked]" target=3D_blank>turne=
[email-masked]</A>&gt;<BR>&nbsp; &nbsp;Tim Polk &lt;<A href=3D"mailto:tim.polk=
@nist.gov" target=3D_blank>[email-masked]</A>&gt;<BR><BR>Security Area A=
dvisor:<BR>&nbsp; &nbsp;Tim Polk &lt;<A href=3D"mailto:[email-masked]" t=
arget=3D_blank>[email-masked]</A>&gt;<BR><BR>Mailing Lists:<BR>&nbsp; &n=
bsp;General Discussion: <A href=3D"mailto:[email-masked]" target=3D_bla=
nk>[email-masked]</A><BR>&nbsp; &nbsp;To Subscribe: &nbsp; &nbsp; &nbsp=
; <A href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D_bla=
nk>https://www.ietf.org/mailman/listinfo/keyassure</A><BR>&nbsp; &nbsp;Arch=
ive:<BR><A href=3D"http://www.ietf.org/mail-archive/web/keyassure/current/m=
aillist.html" target=3D_blank>http://www.ietf.org/mail-archive/web/keyassur=
e/current/maillist.html</A><BR><BR>Objective:<BR>Specify mechanisms and tec=
hniques that allow Internet applications to<BR>establish cryptographically =
secured communications by using information<BR>distributed through the DNS =
and authenticated using DNSSEC to obtain<BR>public keys which are associate=
d with a service located at a<BR>domain name.<BR><BR>Problem Statement:<BR>=
<BR>Entities on the Internet are usually identified using domain names and<=
BR>forming a cryptographically secured connection to the entity requires<BR=
>the entity to authenticate its name. For instance, in HTTPS, a server<BR>r=
esponding to a query for &lt;<A href=3D"https://www.example.com" target=3D_=
blank>https://www.example.com</A>&gt; is expected to<BR>authenticate as "<A=
 href=3D"http://www.example.com" target=3D_blank>www.example.com</A>". Secu=
rity protocols such as TLS and<BR>IPsec accomplish this authentication by a=
llowing an endpoint to prove<BR>ownership of a private key whose correspond=
ing public key is somehow<BR>bound to the name being authenticated. As a pr=
e-requisite for<BR>authentication, then, these protocols require a mechanis=
m for bindings<BR>to be asserted between public keys and domain names.<BR><=
BR>DNSSEC provides a mechanism for a domain operator to sign DNS<BR>informa=
tion directly, using keys that are bound to the domain by the<BR>parent dom=
ain; relying parties can continue this chain up to any trust<BR>anchor that=
 they accept. In this way, bindings of keys to domains are<BR>asserted not =
by external entities, but by the entities that operate the<BR>DNS. In addit=
ion, this technique inherently limits the scope of any<BR>given entity to t=
he names in zones he controls.<BR><BR>This working group will develop mecha=
nisms for domain operators to<BR>present bindings between names within thei=
r control and public keys, in<BR>such a way that these bindings can be inte=
grity-protected (and thus<BR>shown to be authentically from the domain oper=
ator) using DNSSEC and<BR>used as a basis for authentication in protocols t=
hat use domain names as<BR>identifiers. Possible starting points for these =
deliverables include<BR>draft-hallambaker-certhash, draft-hoffman-keys-link=
age-from-dns, and<BR>draft-josefsson-keyassure-tls.<BR><BR>The mechanisms d=
eveloped by this group will address bindings between<BR>domain names and ke=
ys, allowing flexibility for all key-transport<BR>mechanisms supported by t=
he application protocols addressed (e.g., both<BR>self-signed and CA-issued=
 certificates for use in TLS).<BR><BR>The group may also create documents t=
hat describe how protocol entities<BR>can discover and validate these bindi=
ngs in the execution of specific<BR>applications. This work would be done i=
n coordination with the IETF<BR>Working Groups responsible for the protocol=
s.<BR><BR>Milestones:<BR>Dec 2010 &nbsp;First WG draft of standards-track p=
rotocol for using DNS to<BR>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;associate hos=
ts with keys for TLS and DTLS<BR>Jan 2011 &nbsp;First WG draft of standards=
-track protocols for using DNS to<BR>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;asso=
ciate hosts with IPsec<BR>Jun 2011 &nbsp;Protocol for using DNS to associat=
e domain names with keys<BR>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;for TLS and D=
TLS to IESG<BR>Aug 2011 &nbsp;Protocols for using DNS to associate domain n=
ames with keys<BR>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;for IPsec to IESG<BR>Au=
g 2011 &nbsp;Recharter<BR>_______________________________________________<B=
R>keyassure mailing list<BR><A href=3D"mailto:[email-masked]" target=3D=
_blank>[email-masked]</A><BR><A href=3D"https://www.ietf.org/mailman/li=
stinfo/keyassure" target=3D_blank>https://www.ietf.org/mailman/listinfo/key=
assure</A><BR></BLOCKQUOTE></DIV><BR><BR clear=3Dall><BR>-- <BR>Website: <A=
 href=3D"http://hallambaker.com/" target=3D_blank>http://hallambaker.com/</=
A><BR><BR>Regards,<BR>Jeffrey A. Williams<BR>"Obedience of the law is the g=
reatest freedom" -<BR>&nbsp;&nbsp; Abraham Lincoln<BR><BR>"Credit should go=
 with the performance of duty and not with what is very<BR>often the accide=
nt of glory" - Theodore Roosevelt<BR><BR>"If the probability be called P; t=
he injury, L; and the burden, B; liability<BR>depends upon whether B is les=
s than L multiplied by<BR>P: i.e., whether B is less than PL."<BR>United St=
ates v. Carroll Towing&nbsp; (159 F.2d 169 [2d Cir. 1947]<BR>=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>Updated 1/26/04<BR>CSO/DIR. Internet Network=
 Eng. SR. Eng. Network data security IDNS. div. of<BR>Information Network E=
ng.&nbsp; INEG. INC.<BR>ABA member in good standing member ID 01257402 E-Ma=
il [email-masked]<BR>Phone: 214-244-4827<BR><BR></DIV></BLOCKQUOTE>=
</BODY>

Date: Tue, 26 Oct 2010 16:10:34 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

--00151750eb3e8f401204938ab31a
Content-Type: text/plain; charset=ISO-8859-1

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/

--00151750eb3e8f401204938ab31a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

There are two sets of work items being proposed for this group.<div><br></d=
iv><div>The first set of work describes mechanisms that allow a domain name=
 owner to use the DNS to establish the validity of a key.</div><div><br>
</div><div>I think that this mechanism is entirely logical and useful. DNSS=
EC is entirely adequate for the purpose of establishing a key as being suff=
icient to enable use of encryption.=A0</div><div><br></div><div><br></div>
<div>The second set of proposals relates to security policy. In particular =
the TLSFP scheme defines a path validation algorithm that overrides the sta=
ndard PKIX processing mechanism in two ways.</div><div><br></div><div>First=
 a certificate that has a valid TLSFP validation path is to be considered v=
alid even if it is a PKIX end entity cert and is invalid under PKIX path ma=
th. This may be acceptable but needs to be carefully considered.</div>
<div><br></div><div>Secondly, there is an assumption in TLSFP that any doma=
in 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 ca=
use the SSL certificate on the Web server to be considered invalid.</div>
<div><br></div><div><br></div><div>I find this proposal troubling for sever=
alreasons. First it lacks orthogonality. It should be able to use the DNSSE=
C to establish additional keys without affecting existing trust systems in =
any way whatsoever. At the very least this behavior should be optional.=A0<=
/div>
<div><br></div><div>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 va=
lidating certificates. I dislike any mechanism that requires the administra=
tor 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.=A0</div>
<div><br></div><div>Thirdly, the percentage of Internet traffic that is enc=
rypted today is negligible. I think that we should make encouraging the use=
 of encryption a higher priority than correcting what some people see as fl=
aws in the trust provision for existing sites. The security policy that has=
 the highest leverage is statements of the form &#39;always use TLS&#39;.</=
div>
<div><br></div><div>What worries me here is the that the WG should decide t=
o address a single aspect of security policy, address that aspect from a si=
ngle point of view and then optimize for that single scope.</div><div><br>
</div><div>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 t=
he hardest aspect of security policy in a fashion that is likely to raise s=
evere scaling issues.</div>
<div><br></div><div><br></div><div>I think we need to look at security poli=
cy separately from the problem of providing new ways to establish keys.</di=
v><div><br></div><div>I think we need to look at the whole problem of secur=
ity policy together and not just one aspect of security policy. If we are g=
oing to address security policy in stages we should start from the well def=
ined problem of protocol security policy and punt on the difficult issue of=
 trust configuration.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Tue, Oct 26, 2010 at =
1:00 PM, IESG Secretary <span dir=3D"ltr">&lt;<a href=3D"mailto:iesg-secret=
[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex;">
A new IETF working group has been proposed in the Security Area. =A0The IES=
G<br>
has not made any determination as yet. The following draft charter was<br>
submitted, and is provided for informational purposes only. Please send<br>
your comments to the IESG mailing list (<a href=3D"mailto:[email-masked]">ie=
[email-masked]</a>) by Tuesday,<br>
November 7, 2010<br>
<br>
Keys In DNS (kidns)<br>
-----------------------<br>
Last modified: 2010-10-25<br>
Current status: Proposed Working Group<br>
<br>
Chairs:<br>
 =A0 =A0Warren Kumari &lt;<a href=3D"mailto:[email-masked]">warren@kumar=
i.net</a>&gt;<br>
 =A0 =A0Ondrej Sury &lt;<a href=3D"mailto:[email-masked]">ondrej.sury@n=
ic.cz</a>&gt;<br>
<br>
Security Area Directors:<br>
 =A0 =A0Sean Turner &lt;<a href=3D"mailto:[email-masked]">[email-masked]=
m</a>&gt;<br>
 =A0 =A0Tim Polk &lt;<a href=3D"mailto:[email-masked]">[email-masked]=
</a>&gt;<br>
<br>
Security Area Advisor:<br>
 =A0 =A0Tim Polk &lt;<a href=3D"mailto:[email-masked]">[email-masked]=
</a>&gt;<br>
<br>
Mailing Lists:<br>
 =A0 =A0General Discussion: <a href=3D"mailto:[email-masked]">keyassure=
@ietf.org</a><br>
 =A0 =A0To Subscribe: =A0 =A0 =A0 <a href=3D"https://www.ietf.org/mailman/l=
istinfo/keyassure" target=3D"_blank">https://www.ietf.org/mailman/listinfo/=
keyassure</a><br>
 =A0 =A0Archive:<br>
<a href=3D"http://www.ietf.org/mail-archive/web/keyassure/current/maillist.=
html" target=3D"_blank">http://www.ietf.org/mail-archive/web/keyassure/curr=
ent/maillist.html</a><br>
<br>
Objective:<br>
Specify mechanisms and techniques that allow Internet applications to<br>
establish cryptographically secured communications by using information<br>
distributed through the DNS and authenticated using DNSSEC to obtain<br>
public keys which are associated with a service located at a<br>
domain name.<br>
<br>
Problem Statement:<br>
<br>
Entities on the Internet are usually identified using domain names and<br>
forming a cryptographically secured connection to the entity requires<br>
the entity to authenticate its name. For instance, in HTTPS, a server<br>
responding to a query for &lt;<a href=3D"https://www.example.com" target=3D=
"_blank">https://www.example.com</a>&gt; is expected to<br>
authenticate as &quot;<a href=3D"http://www.example.com" target=3D"_blank">=
www.example.com</a>&quot;. Security protocols such as TLS and<br>
IPsec accomplish this authentication by allowing an endpoint to prove<br>
ownership of a private key whose corresponding public key is somehow<br>
bound to the name being authenticated. As a pre-requisite for<br>
authentication, then, these protocols require a mechanism for bindings<br>
to be asserted between public keys and domain names.<br>
<br>
DNSSEC provides a mechanism for a domain operator to sign DNS<br>
information directly, using keys that are bound to the domain by the<br>
parent domain; relying parties can continue this chain up to any trust<br>
anchor that they accept. In this way, bindings of keys to domains are<br>
asserted not by external entities, but by the entities that operate the<br>
DNS. In addition, this technique inherently limits the scope of any<br>
given entity to the names in zones he controls.<br>
<br>
This working group will develop mechanisms for domain operators to<br>
present bindings between names within their control and public keys, in<br>
such a way that these bindings can be integrity-protected (and thus<br>
shown to be authentically from the domain operator) using DNSSEC and<br>
used as a basis for authentication in protocols that use domain names as<br=
>
identifiers. Possible starting points for these deliverables include<br>
draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and<br>
draft-josefsson-keyassure-tls.<br>
<br>
The mechanisms developed by this group will address bindings between<br>
domain names and keys, allowing flexibility for all key-transport<br>
mechanisms supported by the application protocols addressed (e.g., both<br>
self-signed and CA-issued certificates for use in TLS).<br>
<br>
The group may also create documents that describe how protocol entities<br>
can discover and validate these bindings in the execution of specific<br>
applications. This work would be done in coordination with the IETF<br>
Working Groups responsible for the protocols.<br>
<br>
Milestones:<br>
Dec 2010 =A0First WG draft of standards-track protocol for using DNS to<br>
 =A0 =A0 =A0 =A0 =A0associate hosts with keys for TLS and DTLS<br>
Jan 2011 =A0First WG draft of standards-track protocols for using DNS to<br=
>
 =A0 =A0 =A0 =A0 =A0associate hosts with IPsec<br>
Jun 2011 =A0Protocol for using DNS to associate domain names with keys<br>
 =A0 =A0 =A0 =A0 =A0for TLS and DTLS to IESG<br>
Aug 2011 =A0Protocols for using DNS to associate domain names with keys<br>
 =A0 =A0 =A0 =A0 =A0for IPsec to IESG<br>
Aug 2011 =A0Recharter<br>
_______________________________________________<br>
keyassure mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--00151750eb3e8f401204938ab31a--

From: Simon Josefsson <[email-masked]>
To: "Jeffrey A. Williams" <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 26 Oct 2010 22:05:03 +0200
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

"Jeffrey A. Williams" <[email-masked]> writes:

>>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.
>
>   Whynot have both.  One being a shared cert as acceptable and the
> option of one for each?
>>
>>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!
>
>   i see nothing wrong with this and conversly nothing wrong with both
> using a shared cert for each.

Good point -- let me clarify that I believe it should be up to each
administrator to decide whether to use one certificate for multiple
services or use one certificate per service.  A standard in this area
should not rule out one alternative.  Both alternatives are too common
for that.

/Simon

Date: Tue, 26 Oct 2010 14:53:29 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Simon Josefsson <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Simon and all,

-----Original Message-----
>From: Simon Josefsson <[email-masked]>
>Sent: Oct 26, 2010 2:46 PM
>To: [email-masked], [email-masked]
>Cc: [email-masked]
>Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)
>
>I believe the KIDNS charter is generally good and I support forming this
>WG to work on this topic, however I have one important concern:
>
>> 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.
>
>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.

I share this concern.  The above refrenced wording needs revision.
>
>By only locating services by domain name, the separation between ports
>(e.g., 443 or 587) and transport protocols (UDP vs TCP) are lost.

  not lost really but confused, perhaps...
>
>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.

  Whynot have both.  One being a shared cert as acceptable and the
option of one for each?
>
>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!

  i see nothing wrong with this and conversly nothing wrong with both
using a shared cert for each.
>
>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
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

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: Simon Josefsson <[email-masked]>
To: [email-masked], [email-masked]
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 26 Oct 2010 21:46:19 +0200
Cc: [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

I believe the KIDNS charter is generally good and I support forming this
WG to work on this topic, however I have one important concern:

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

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

Date: Tue, 26 Oct 2010 14:55:04 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>,  =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

On Tue, 26 Oct 2010, Paul Hoffman wrote:

>>
>>> Aug 2011  Protocols for using DNS to associate domain names with keys
>>>         for IPsec to IESG
>>
>> How is this different from http://tools.ietf.org/html/rfc4322 ?
>
> - It might not.

Okay.

> - It probably will, because RFC 4322 (I think) assumes that the relying party never wants to see if a key can be validated against the relying party's trust anchor store.

isn't that local client policy, similar to things like ISAKMP and IPSEC SA lifetime values that are
also not negotiated?

> - RFC 4322 underwent very light review because it was describing an already-defined protocol that was in the process of being deployed, and it was not intended for standards track.

Actually, it was deployed years before. But its deployment never gained traction. One, because we had
no DNSSEC, and two because part of the functionality worked on the reverse zones, which basically no
clients have access to.

> - Implementation experience with RFC 4322 (if there is any outside of the community of its original designers) might bring to light different design choices that can be made by the WG.

Sure. Please keep me in the loop especially about this case, as I have a vested interest in it. If any update to
RFC 4322 will be proposed, I'm more then happy to sheppard it.

Paul

Date: Tue, 26 Oct 2010 11:36:26 -0700
From: Ted Hardie <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

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 enti=
ties"
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. =A0The I=
ESG
> 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:
> =A0 =A0Warren Kumari <[email-masked]>
> =A0 =A0Ondrej Sury <[email-masked]>
>
> Security Area Directors:
> =A0 =A0Sean Turner <[email-masked]>
> =A0 =A0Tim Polk <[email-masked]>
>
> Security Area Advisor:
> =A0 =A0Tim Polk <[email-masked]>
>
> Mailing Lists:
> =A0 =A0General Discussion: [email-masked]
> =A0 =A0To Subscribe: =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/ke=
yassure
> =A0 =A0Archive:
> 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 =A0First WG draft of standards-track protocol for using DNS to
> =A0 =A0 =A0 =A0 =A0associate hosts with keys for TLS and DTLS
> Jan 2011 =A0First WG draft of standards-track protocols for using DNS to
> =A0 =A0 =A0 =A0 =A0associate hosts with IPsec
> Jun 2011 =A0Protocol for using DNS to associate domain names with keys
> =A0 =A0 =A0 =A0 =A0for TLS and DTLS to IESG
> Aug 2011 =A0Protocols for using DNS to associate domain names with keys
> =A0 =A0 =A0 =A0 =A0for IPsec to IESG
> Aug 2011 =A0Recharter
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

Date: Tue, 26 Oct 2010 10:33:57 -0700
To: Paul Wouters <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

At 1:16 PM -0400 10/26/10, Paul Wouters wrote:
>On Tue, 26 Oct 2010, IESG Secretary wrote:
>
>>Aug 2011  Protocols for using DNS to associate domain names with keys
>>         for IPsec to IESG
>
>How is this different from http://tools.ietf.org/html/rfc4322 ?

- It might not.

- It probably will, because RFC 4322 (I think) assumes that the relying party never wants to see if a key can be validated against the relying party's trust anchor store.

- RFC 4322 underwent very light review because it was describing an already-defined protocol that was in the process of being deployed, and it was not intended for standards track.

- Implementation experience with RFC 4322 (if there is any outside of the community of its original designers) might bring to light different design choices that can be made by the WG.

--Paul Hoffman, Director
--VPN Consortium

Date: Tue, 26 Oct 2010 13:16:55 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

On Tue, 26 Oct 2010, IESG Secretary wrote:

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

How is this different from http://tools.ietf.org/html/rfc4322 ?

Paul

From: IESG Secretary <[email-masked]>
To: [email-masked]
Date: Tue, 26 Oct 2010 10:00:01 -0700 (PDT)
Cc: [email-masked]
Subject: [keyassure] WG Review: Keys In DNS (kidns)
Reply-To: [email-masked]

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

Date: Mon, 25 Oct 2010 13:44:08 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt

--0016e6464da60c6d8f0493748a56
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Oct 25, 2010 at 12:26 PM, Paul Wouters <[email-masked]> wrote:

> On Mon, 25 Oct 2010, Paul Hoffman wrote:
>
>  The common practice is to give each server application its own domain
>> name. This is not the only practice, but it is common. You want to not
>> require that practice, at a cost of the DNS administrator needing to add
>> some extra information in the DNS, and the client app needed to request that
>> information. The question is whether the cost to everyone of those additions
>> to the protocol are worth the benefit for the few who do not have unique
>> domain names for each server application. I claim the cost to everyone is
>> not worth the benefit to the few, but others may disagree.
>>
>
> I would say the world is moving in the other direction. You use "cnn.com"
> and "twitter.com", not www.cnn.com or www.twitter.com.
> I am [email-masked], not [email-masked].
>
> If anything, we are trying to reduce the combinations of http/https/www/
> methods of reaching a website into one.
>
> Using a port specifier would in my opinion be very useful. It will also
> reduce the number of records returned that have
> to be checked by the client that is only interested in one particular
> service/port. But we have to be careful not to
> increase the amount of queries by missing the right port.

At one point I had the following scheme:

_80._http._tcp.example.com

That runs into corner cases with CNAME. In particular:

_80._http._tcp.www.example.com XXX "blah...."
www.example.com CNAME example.com

Trying to write discovery rules that are consistent and efficient and work
with both CNAME and wildcards tend to fail round prefixes unless you can
write the rules in such a way that the first lookup you do is always for an
unprefixed record. Once past your first lookup you can use prefixes without
issue.

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

--0016e6464da60c6d8f0493748a56
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Oct 25, 2010 at 12:26 PM, Paul W=
outers <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul@xel=
erance.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Mon, 25 Oct 2010, Paul Hoffman wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The common practice is to give each server application its own domain name.=
 This is not the only practice, but it is common. You want to not require t=
hat practice, at a cost of the DNS administrator needing to add some extra =
information in the DNS, and the client app needed to request that informati=
on. The question is whether the cost to everyone of those additions to the =
protocol are worth the benefit for the few who do not have unique domain na=
mes for each server application. I claim the cost to everyone is not worth =
the benefit to the few, but others may disagree.<br>

</blockquote>
<br></div>
I would say the world is moving in the other direction. You use &quot;<a hr=
ef=3D"http://cnn.com" target=3D"_blank">cnn.com</a>&quot; and &quot;<a href=
=3D"http://twitter.com" target=3D"_blank">twitter.com</a>&quot;, not <a hre=
f=3D"http://www.cnn.com" target=3D"_blank">www.cnn.com</a> or <a href=3D"ht=
tp://www.twitter.com" target=3D"_blank">www.twitter.com</a>.<br>

I am <a href=3D"mailto:[email-masked]" target=3D"_blank">PaulWouter=
[email-masked]</a>, not <a href=3D"mailto:[email-masked]" targ=
et=3D"_blank">[email-masked]</a>.<br>
<br>
If anything, we are trying to reduce the combinations of http/https/www/ me=
thods of reaching a website into one.<br>
<br>
Using a port specifier would in my opinion be very useful. It will also red=
uce the number of records returned that have<br>
to be checked by the client that is only interested in one particular servi=
ce/port. But we have to be careful not to<br>
increase the amount of queries by missing the right port.</blockquote><div>=
<br></div><div><br></div><div>At one point I had the following scheme:</div=
><div><br></div><div>_80._http._<a href=3D"http://tcp.example.com">tcp.exam=
ple.com</a></div>
<div><br></div><div>That runs into corner cases with CNAME. In particular:<=
/div><div><br></div><div><meta charset=3D"utf-8">_80._http._<a href=3D"http=
://tcp.www.example.com">tcp.www.example.com</a> XXX &quot;blah....&quot;</d=
iv>
<div><a href=3D"http://www.example.com">www.example.com</a> CNAME <a href=
=3D"http://example.com">example.com</a></div><div><br></div><div><br></div>=
<div>Trying to write discovery rules that are consistent and efficient and =
work with both CNAME and wildcards tend to fail round prefixes unless you c=
an write the rules in such a way that the first lookup you do is always for=
 an unprefixed record. Once past your first lookup you can use prefixes wit=
hout issue.</div>
<div><br></div><div><br></div></div>-- <br>Website: <a href=3D"http://halla=
mbaker.com/">http://hallambaker.com/</a><br><br>

--0016e6464da60c6d8f0493748a56--

Date: Mon, 25 Oct 2010 13:36:49 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Certification Authority Authorization Draft.

--0016e6434aeee472440493746f60
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Oct 25, 2010 at 12:47 PM, Ben Laurie <[email-masked]> wrote:

> Sorry for the delay..
>
> Looking at the -01 version...
>
> "The authorizations specified in the dauth and pauth properties are
>   additive."
>
> I'm not sure "additive" is the right word - certainly it leaves me
> wondering "does that mean 'and' or 'or'?". Later text confirms "or",
> which was not my guess.
>

I had difficulty drafting that. I think that the problem is that I should be
using the term 'permission' or 'authorization entry'.

> Why restrict tag length in the CAA RR?
>

The tags are from an assigned space. The only protocol constraint I would
really insist on is that the tag length needs to be expressible in a single
byte.

Do we really think we will need more than 2^16 different tags in a data
record that has to fit into a 65535 byte space?

> "An ASN.1 DER encoded data field containing the digest value of the
>      referenced object processed using the specified digest algorithm."
>
> I don't think this is an unambiguous specification - you have to
> specify the ASN.1...
>

I am not sure what point you were going to make here.

I am sure that there can be some byte sex issues that enter into things
here.

Some digest algorithms have more than one OID assigned. But the ones we
currently recommend in IETF specs have exactly one OID assignment across all
specifications, the one assigned by NIST. And this should be the same for
the SHA-3 algorithms as well.

One other point that was raised was that some people would like to have the
ODI data wrapped in an ASN.1 tag, length container as well.

> "   Use of DNSSEC to authenticate CAA RRs is strongly recommended but not
>   required.  A CA MUST observe a CAA RR that is returned whether it is
>   signed using DNSSEC or not."
>
> Fine - but I think it should say that applications MUST NOT observe a
> CAA RR that is not signed.
>

OK, that is fair enough.

I am thinking that we may want to differentiate between authority to issue
and authority for relying parties.

The issue authority statements refer to what an issuer is authorized to do
during the validity interval for the record.

But the fact that an issuer is no longer authorized to issue new
certificates does not invalidate the certificates they have already issued.
So the statement for relying parties may well contain more entries.

> 4.2 should note that DNSSEC effectively prevents either suppression or
> spoofing.
>
> Other than that, looks good to me

That must have got lost in the editing.

> On 19 October 2010 03:17, Phillip Hallam-Baker <[email-masked]> wrote:
> > Adam L. pointed out some typos and so on. I had to get it in today and I
> am
> > fighting off a cold.
> >
> > As we discussed in the call, we are very interested in having Google
> > co-author if you are interested.
> >
> > CA buy-in is not so much of a worry for me. Comodo will deploy for
> certain
> > and Symantec/VeriSignCA is pretty likely to follow.
> > Assume for a moment that other CAs don't follow our lead and end up
> > mis-issuing against a domain that has a CAA record. What do you think
> their
> > liability is in that case? They certainly have a major PR issue at that
> > point and their only realistic chance of surviving it without too much
> > damage is going to be to deploy CAA.
> >
> > So all in all, I think that the chances are pretty good that we can
> present
> > this as a win for all concerned.
> >
> > You may also be interested in my DPLS draft:
> > http://www.ietf.org/id/draft-hallambaker-dpls-00.txt
> > A lot of the DNS performance issues go away if the DNS client can ask its
> > resolver 'hey give me all the info I need to do this with that'.
> >
> > On Mon, Oct 18, 2010 at 9:51 PM, Warren Kumari <[email-masked]>
> wrote:
> >>
> >> I have not yet read the whole draft, but so far I really like it.
> >>
> >> While (as you already pointed out) it doesn't solve all of the issues,
> it
> >> does go a long way towards improving matters, assuming of course the CAs
> buy
> >> in...
> >>
> >> W
> >> On Oct 18, 2010, at 5:32 PM, Phillip Hallam-Baker wrote:
> >>
> >> > This is a draft that I submitted this morning. The main proposal being
> >> > made here is to enable Certification Authorities to avoid mis-issue.
> >> >
> >> > As such I believe that it is complimentary to mechanisms that enable
> >> > client side enforcement but has the considerable advantage of offering
> >> > immediate protection to every Internet user regardless of whether they
> have
> >> > an updated browser. It is also much less strongly dependent on
> deployment of
> >> > DNSSEC.
> >> > http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt
> >> >
> >> >
> >> > Given the nature of the proposal, it is probably better suited to
> having
> >> > the bulk of the legal-technical work considered in CABForum rather
> than
> >> > IETF. Accordingly the proposal is designed to allow the technical
> >> > infrastructure to be agreed in IETF and then the practices and legal
> work
> >> > done in CABForum.
> >> >
> >> > Clearly a record of this type could be used to effect client policy
> >> > enforcement mechanisms. But this is a rather more complex issue and
> there
> >> > are going to be a lot of people with views on the best way forward.
> >> >
> >> > The mechanism as specified is sufficient for allowing client side
> >> > enforcement as it stands if the site is using a public CA, running a
> local
> >> > CA cross certified into a public hierarchy or using a standalone
> private CA.
> >> > But only if those infrastructures are supporting all their
> applications
> >> > without exception.
> >> >
> >> >
> >> > --
> >> > Website: http://hallambaker.com/
> >> >
> >> > _______________________________________________
> >> > keyassure mailing list
> >> > [email-masked]
> >> > https://www.ietf.org/mailman/listinfo/keyassure
> >>
> >
> >
> >
> > --
> > Website: http://hallambaker.com/
> >
> >
> > _______________________________________________
> > keyassure mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/keyassure
> >
> >
>

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

--0016e6434aeee472440493746f60
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 25, 2010 at 12:47 PM, Ben Laurie <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Sorry for the delay..<br>
<br>
Looking at the -01 version...<br>
<br>
&quot;The authorizations specified in the dauth and pauth properties are<br=
>
 =A0 additive.&quot;<br>
<br>
I&#39;m not sure &quot;additive&quot; is the right word - certainly it leav=
es me<br>
wondering &quot;does that mean &#39;and&#39; or &#39;or&#39;?&quot;. Later =
text confirms &quot;or&quot;,<br>
which was not my guess.<br></blockquote><div><br></div><div>I had difficult=
y drafting that. I think that the problem is that I should be using the ter=
m &#39;permission&#39; or &#39;authorization entry&#39;.</div><div><br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Why restrict tag length in the CAA RR?<br></blockquote><div><br></div><div>=
The tags are from an assigned space. The only protocol constraint I would r=
eally insist on is that the tag length needs to be expressible in a single =
byte.</div>
<div><br></div><div>Do we really think we will need more than 2^16 differen=
t tags in a data record that has to fit into a 65535 byte space?</div><div>=
<br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

&quot;An ASN.1 DER encoded data field containing the digest value of the<br=
>
 =A0 =A0 =A0referenced object processed using the specified digest algorith=
m.&quot;<br>
<br>
I don&#39;t think this is an unambiguous specification - you have to<br>
specify the ASN.1...<br></blockquote><div><br></div><div>I am not sure what=
 point you were going to make here.</div><div><br></div><div>I am sure that=
 there can be some byte sex issues that enter into things here.</div><div>
<br></div><div>Some digest algorithms have more than one OID assigned. But =
the ones we currently recommend in IETF specs have exactly one OID assignme=
nt across all specifications, the one assigned by NIST. And this should be =
the same for the SHA-3 algorithms as well.</div>
<div><br></div><div>One other point that was raised was that some people wo=
uld like to have the ODI data wrapped in an ASN.1 tag, length container as =
well.</div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

&quot; =A0 Use of DNSSEC to authenticate CAA RRs is strongly recommended bu=
t not<br>
 =A0 required. =A0A CA MUST observe a CAA RR that is returned whether it is=
<br>
 =A0 signed using DNSSEC or not.&quot;<br>
<br>
Fine - but I think it should say that applications MUST NOT observe a<br>
CAA RR that is not signed.<br></blockquote><div><br></div><div>OK, that is =
fair enough.</div><div><br></div><div>I am thinking that we may want to dif=
ferentiate between authority to issue and authority for relying parties.</d=
iv>
<div><br></div><div>The issue authority statements refer to what an issuer =
is authorized to do during the validity interval for the record.=A0</div><d=
iv><br></div><div>But the fact that an issuer is no longer authorized to is=
sue new certificates does not invalidate the certificates they have already=
 issued. So the statement for relying parties may well contain more entries=
.</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
4.2 should note that DNSSEC effectively prevents either suppression or spoo=
fing.<br>
<br>
Other than that, looks good to me</blockquote><div><br></div><div>That must=
 have got lost in the editing.=A0</div><div><br></div><div>=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex;">
<div><div class=3D"h5">
On 19 October 2010 03:17, Phillip Hallam-Baker &lt;<a href=3D"mailto:hallam=
@gmail.com">[email-masked]</a>&gt; wrote:<br>
&gt; Adam L. pointed out some typos and so on. I had to get it in today and=
 I am<br>
&gt; fighting off a cold.<br>
&gt;<br>
&gt; As we discussed in the call, we are very interested in having Google<b=
r>
&gt; co-author if you are interested.<br>
&gt;<br>
&gt; CA buy-in is not so much of a worry for me. Comodo will deploy for cer=
tain<br>
&gt; and Symantec/VeriSignCA is pretty likely to follow.<br>
&gt; Assume for a moment that other CAs don&#39;t follow our lead and end u=
p<br>
&gt; mis-issuing against a domain that has a CAA record. What do you think =
their<br>
&gt; liability is in that case? They certainly have a major PR issue at tha=
t<br>
&gt; point and their only realistic chance of surviving it without too much=
<br>
&gt; damage is going to be to deploy CAA.<br>
&gt;<br>
&gt; So all in all, I think that the chances are pretty good that we can pr=
esent<br>
&gt; this as a win for all concerned.<br>
&gt;<br>
&gt; You may also be interested in my DPLS draft:<br>
&gt; <a href=3D"http://www.ietf.org/id/draft-hallambaker-dpls-00.txt" targe=
t=3D"_blank">http://www.ietf.org/id/draft-hallambaker-dpls-00.txt</a><br>
&gt; A lot of the DNS performance issues go away if the DNS client can ask =
its<br>
&gt; resolver &#39;hey give me all the info I need to do this with that&#39=
;.<br>
&gt;<br>
&gt; On Mon, Oct 18, 2010 at 9:51 PM, Warren Kumari &lt;<a href=3D"mailto:w=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I have not yet read the whole draft, but so far I really like it.<=
br>
&gt;&gt;<br>
&gt;&gt; While (as you already pointed out) it doesn&#39;t solve all of the=
 issues, it<br>
&gt;&gt; does go a long way towards improving matters, assuming of course t=
he CAs buy<br>
&gt;&gt; in...<br>
&gt;&gt;<br>
&gt;&gt; W<br>
&gt;&gt; On Oct 18, 2010, at 5:32 PM, Phillip Hallam-Baker wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; This is a draft that I submitted this morning. The main propo=
sal being<br>
&gt;&gt; &gt; made here is to enable Certification Authorities to avoid mis=
-issue.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; As such I believe that it is complimentary to mechanisms that=
 enable<br>
&gt;&gt; &gt; client side enforcement but has the considerable advantage of=
 offering<br>
&gt;&gt; &gt; immediate protection to every Internet user regardless of whe=
ther they have<br>
&gt;&gt; &gt; an updated browser. It is also much less strongly dependent o=
n deployment of<br>
&gt;&gt; &gt; DNSSEC.<br>
&gt;&gt; &gt; <a href=3D"http://www.ietf.org/id/draft-hallambaker-donotissu=
e-00.txt" target=3D"_blank">http://www.ietf.org/id/draft-hallambaker-donoti=
ssue-00.txt</a><br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Given the nature of the proposal, it is probably better suite=
d to having<br>
&gt;&gt; &gt; the bulk of the legal-technical work considered in CABForum r=
ather than<br>
&gt;&gt; &gt; IETF. Accordingly the proposal is designed to allow the techn=
ical<br>
&gt;&gt; &gt; infrastructure to be agreed in IETF and then the practices an=
d legal work<br>
&gt;&gt; &gt; done in CABForum.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Clearly a record of this type could be used to effect client =
policy<br>
&gt;&gt; &gt; enforcement mechanisms. But this is a rather more complex iss=
ue and there<br>
&gt;&gt; &gt; are going to be a lot of people with views on the best way fo=
rward.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; The mechanism as specified is sufficient for allowing client =
side<br>
&gt;&gt; &gt; enforcement as it stands if the site is using a public CA, ru=
nning a local<br>
&gt;&gt; &gt; CA cross certified into a public hierarchy or using a standal=
one private CA.<br>
&gt;&gt; &gt; But only if those infrastructures are supporting all their ap=
plications<br>
&gt;&gt; &gt; without exception.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; --<br>
&gt;&gt; &gt; Website: <a href=3D"http://hallambaker.com/" target=3D"_blank=
">http://hallambaker.com/</a><br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; keyassure mailing list<br>
&gt;&gt; &gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><=
br>
&gt;&gt; &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" t=
arget=3D"_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Website: <a href=3D"http://hallambaker.com/" target=3D"_blank">http://=
hallambaker.com/</a><br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; keyassure mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D"=
_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>

--0016e6434aeee472440493746f60--

Date: Mon, 25 Oct 2010 13:12:03 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt

--0016e64652fa4e3d9104937417e0
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Oct 25, 2010 at 10:51 AM, Paul Hoffman <[email-masked]>wrote:
>
> The common practice is to give each server application its own domain name.
> This is not the only practice, but it is common. You want to not require
> that practice, at a cost of the DNS administrator needing to add some extra
> information in the DNS, and the client app needed to request that
> information. The question is whether the cost to everyone of those additions
> to the protocol are worth the benefit for the few who do not have unique
> domain names for each server application. I claim the cost to everyone is
> not worth the benefit to the few, but others may disagree.

I don't think that this group is going to be allowed to make that decision.
The reason that we have an IESG and an IAB is to prevent WGs introducing
additional assumptions into the architecture that hobble other groups in the
future.

That said, I think it is the wrong approach because it will stop
applications being written to automatically produce the appropriate DNS
records. [see later]

> At 10:02 AM -0400 10/25/10, Phillip Hallam-Baker wrote:
> >Whether this is an issue or not depends on whether the semantics are "here
> is a key you can use" or "here are the only keys you can use"
>
> Correct.

And the very strong impression I was left with after my discussion with Tim
was that we would have to solve #1 before being allowed to go to #2.

> >It has to be possible to use dnssec to establish a key for a mail server
> that lives on the same dns node as a Web server without affecting operation
> of the Web server in any way.
>
> Can you say more about why you have this requirement? When the DNS protocol
> prevents you from doing something at one level but completely allows you do
> do something by creating another name within a subordinate namespace, what
> makes it so required that you only do things at the top-level name? There
> are lots of other examples of such requirements in the DNS protocol; why is
> this one so important?

For example, Alice installs sendmail on example.com. There is no way for a
script to determine that there is a HTTP server on example.com. It might be
a completely fresh install of the OS and the admin installed sendmail before
apache.

It would be really nice if sendmail could just spin up a self signed keypair
and propose a DNS CERT record. But it isn't going to be able to do that if
there is any risk of affecting the Web service. Using CERT records that
establish keys and restrict at the same time means that the sendmail script
would likely disable more than a few Web servers.

Now we could address SMTP by insisting on a different name for the hosts
declared in the MX record. But we can't do that for IMAP or any other
protocol which does not have SRV discovery as a requirement.

[We do in any case have to consider and describe what is done to handle
CNAMEs, DNAMEs, SRV records and any other record that causes name
substitution to take place.]

I think that we can square this circle, but we will need another RR to do
so. or rather, we could try to cram the information into the CERT record but
I think that would get a lot of pushback.

Since one of the base assumptions here is that we are going to be using
DNSSEC, we should expect that the infrastructure that will allow that data
through will have support for using unknown RRs.

So lets imagine we introduce one new RR 'Server Security Policy'.

The SSP record may be used in either a prefixed form or an unprefixed form.
The rules for using SSP is that a client attempting to connect to a service
at x.example.com will always query for the SSP record for x.example.com.

If the SSP record exists, it MAY apply to every service at example.com or it
MAY have a flag that says 'lookup protocol prefixed SSP' or it may have a
flag that says 'lookup SRV and then lookup SSP' (etc.)

In either case the SSP record MAY specify security policies such as 'always
use SSL' or 'valid certs MUST conform to specification Y'.

This approach allows for root restriction to be by requiring there to be a
companion CERT record or by inclusion of a specific policy OID or existence
of a trust chain to a specific certificate signing certificate.

That is what I would anticipate as a requirement since using the DNS to
distribute certificate assurance data is going to be considered 'research'
and there is a longstanding resistance to building research on research.

Looking through the decision tree, the overhead is one additional DNS lookup
that is made in parallel with the A and AAAA lookup for the case that no SSP
record exists.

In the case that there is an SSP record, the overhead depends on how the DNS
resolver is tuned. If the resolver is tuned to optimize SSP lookup (e.g.
using DPLS) the entire lookup can be performed in one round trip in every
single case.

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

--0016e64652fa4e3d9104937417e0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Oct 25, 2010 at 10:51 AM, Paul H=
offman <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul.=
[email-masked]</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The common practice is to give each server application its own domain name.=
 This is not the only practice, but it is common. You want to not require t=
hat practice, at a cost of the DNS administrator needing to add some extra =
information in the DNS, and the client app needed to request that informati=
on. The question is whether the cost to everyone of those additions to the =
protocol are worth the benefit for the few who do not have unique domain na=
mes for each server application. I claim the cost to everyone is not worth =
the benefit to the few, but others may disagree.</blockquote>
<div><br></div><div>I don&#39;t think that this group is going to be allowe=
d to make that decision. The reason that we have an IESG and an IAB is to p=
revent WGs introducing additional assumptions into the architecture that ho=
bble other groups in the future.</div>
<div><br></div><div>That said, I think it is the wrong approach because it =
will stop applications being written to automatically produce the appropria=
te DNS records. [see later]</div><div><br></div><div>=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex;">
<div class=3D"im">
At 10:02 AM -0400 10/25/10, Phillip Hallam-Baker wrote:<br>
&gt;Whether this is an issue or not depends on whether the semantics are &q=
uot;here is a key you can use&quot; or &quot;here are the only keys you can=
 use&quot;<br>
<br>
</div>Correct.</blockquote><div><br></div><div>And the very strong impressi=
on I was left with after my discussion with Tim was that we would have to s=
olve #1 before being allowed to go to #2.</div><div><br></div><div>=A0</div=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">
&gt;It has to be possible to use dnssec to establish a key for a mail serve=
r that lives on the same dns node as a Web server without affecting operati=
on of the Web server in any way.<br>
<br>
</div>Can you say more about why you have this requirement? When the DNS pr=
otocol prevents you from doing something at one level but completely allows=
 you do do something by creating another name within a subordinate namespac=
e, what makes it so required that you only do things at the top-level name?=
 There are lots of other examples of such requirements in the DNS protocol;=
 why is this one so important?</blockquote>
<div><br></div><meta charset=3D"utf-8"><div>For example, Alice installs sen=
dmail on <a href=3D"http://example.com">example.com</a>. There is no way fo=
r a script to determine that there is a HTTP server on <a href=3D"http://ex=
ample.com">example.com</a>. It might be a completely fresh install of the O=
S and the admin installed sendmail before apache.=A0</div>
<div><br></div><div>It would be really nice if sendmail could just spin up =
a self signed keypair and propose a DNS CERT record. But it isn&#39;t going=
 to be able to do that if there is any risk of affecting the Web service. U=
sing CERT records that establish keys and restrict at the same time means t=
hat the sendmail script would likely disable more than a few Web servers.</=
div>
<div><br></div><div>Now we could address SMTP by insisting on a different n=
ame for the hosts declared in the MX record. But we can&#39;t do that for I=
MAP or any other protocol which does not have SRV discovery as a requiremen=
t.</div>
<div><br></div><div>[We do in any case have to consider and describe what i=
s done to handle CNAMEs, DNAMEs, SRV records and any other record that caus=
es name substitution to take place.]</div><div><br></div><div><br></div>
<div>I think that we can square this circle, but we will need another RR to=
 do so. or rather, we could try to cram the information into the CERT recor=
d but I think that would get a lot of pushback.</div><div><br></div><div>
Since one of the base assumptions here is that we are going to be using DNS=
SEC, we should expect that the infrastructure that will allow that data thr=
ough will have support for using unknown RRs.</div><div><br></div><div>
<br></div><div>So lets imagine we introduce one new RR &#39;Server Security=
 Policy&#39;.</div><div><br></div><div>The SSP record may be used in either=
 a prefixed form or an unprefixed form. The rules for using SSP is that a c=
lient attempting to connect to a service at <a href=3D"http://x.example.com=
">x.example.com</a> will always query for the SSP record for <a href=3D"htt=
p://x.example.com">x.example.com</a>.=A0</div>
<div><br></div><div>If the SSP record exists, it MAY apply to every service=
 at <a href=3D"http://example.com">example.com</a> or it MAY have a flag th=
at says &#39;lookup protocol prefixed SSP&#39; or it may have a flag that s=
ays &#39;lookup SRV and then lookup SSP&#39; (etc.)</div>
<div><br></div><div>In either case the SSP record MAY specify security poli=
cies such as &#39;always use SSL&#39; or &#39;valid certs MUST conform to s=
pecification Y&#39;.</div><div><br></div><div><br></div><div>This approach =
allows for root restriction to be by requiring there to be a companion CERT=
 record or by inclusion of a specific policy OID or existence of a trust ch=
ain to a specific certificate signing certificate.</div>
<div><br></div><div>That is what I would anticipate as a requirement since =
using the DNS to distribute certificate assurance data is going to be consi=
dered &#39;research&#39; and there is a longstanding resistance to building=
 research on research.</div>
<div><br></div><div><br></div><div>Looking through the decision tree, the o=
verhead is one additional DNS lookup that is made in parallel with the A an=
d AAAA lookup for the case that no SSP record exists.</div><div><br></div>
<div>In the case that there is an SSP record, the overhead depends on how t=
he DNS resolver is tuned. If the resolver is tuned to optimize SSP lookup (=
e.g. using DPLS) the entire lookup can be performed in one round trip in ev=
ery single case.</div>
<div><br></div><div><br></div></div>-- <br>Website: <a href=3D"http://halla=
mbaker.com/">http://hallambaker.com/</a><br><br>

--0016e64652fa4e3d9104937417e0--

Date: Mon, 25 Oct 2010 17:47:51 +0100
From: Ben Laurie <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Certification Authority Authorization Draft.

Sorry for the delay..

Looking at the -01 version...

"The authorizations specified in the dauth and pauth properties are
   additive."

I'm not sure "additive" is the right word - certainly it leaves me
wondering "does that mean 'and' or 'or'?". Later text confirms "or",
which was not my guess.

Why restrict tag length in the CAA RR?

"An ASN.1 DER encoded data field containing the digest value of the
      referenced object processed using the specified digest algorithm."

I don't think this is an unambiguous specification - you have to
specify the ASN.1...

"   Use of DNSSEC to authenticate CAA RRs is strongly recommended but not
   required.  A CA MUST observe a CAA RR that is returned whether it is
   signed using DNSSEC or not."

Fine - but I think it should say that applications MUST NOT observe a
CAA RR that is not signed.

4.2 should note that DNSSEC effectively prevents either suppression or spoofing.

Other than that, looks good to me.

On 19 October 2010 03:17, Phillip Hallam-Baker <[email-masked]> wrote:
> Adam L. pointed out some typos and so on. I had to get it in today and I am
> fighting off a cold.
>
> As we discussed in the call, we are very interested in having Google
> co-author if you are interested.
>
> CA buy-in is not so much of a worry for me. Comodo will deploy for certain
> and Symantec/VeriSignCA is pretty likely to follow.
> Assume for a moment that other CAs don't follow our lead and end up
> mis-issuing against a domain that has a CAA record. What do you think their
> liability is in that case? They certainly have a major PR issue at that
> point and their only realistic chance of surviving it without too much
> damage is going to be to deploy CAA.
>
> So all in all, I think that the chances are pretty good that we can present
> this as a win for all concerned.
>
> You may also be interested in my DPLS draft:
> http://www.ietf.org/id/draft-hallambaker-dpls-00.txt
> A lot of the DNS performance issues go away if the DNS client can ask its
> resolver 'hey give me all the info I need to do this with that'.
>
> On Mon, Oct 18, 2010 at 9:51 PM, Warren Kumari <[email-masked]> wrote:
>>
>> I have not yet read the whole draft, but so far I really like it.
>>
>> While (as you already pointed out) it doesn't solve all of the issues, it
>> does go a long way towards improving matters, assuming of course the CAs buy
>> in...
>>
>> W
>> On Oct 18, 2010, at 5:32 PM, Phillip Hallam-Baker wrote:
>>
>> > This is a draft that I submitted this morning. The main proposal being
>> > made here is to enable Certification Authorities to avoid mis-issue.
>> >
>> > As such I believe that it is complimentary to mechanisms that enable
>> > client side enforcement but has the considerable advantage of offering
>> > immediate protection to every Internet user regardless of whether they have
>> > an updated browser. It is also much less strongly dependent on deployment of
>> > DNSSEC.
>> > http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt
>> >
>> >
>> > Given the nature of the proposal, it is probably better suited to having
>> > the bulk of the legal-technical work considered in CABForum rather than
>> > IETF. Accordingly the proposal is designed to allow the technical
>> > infrastructure to be agreed in IETF and then the practices and legal work
>> > done in CABForum.
>> >
>> > Clearly a record of this type could be used to effect client policy
>> > enforcement mechanisms. But this is a rather more complex issue and there
>> > are going to be a lot of people with views on the best way forward.
>> >
>> > The mechanism as specified is sufficient for allowing client side
>> > enforcement as it stands if the site is using a public CA, running a local
>> > CA cross certified into a public hierarchy or using a standalone private CA.
>> > But only if those infrastructures are supporting all their applications
>> > without exception.
>> >
>> >
>> > --
>> > Website: http://hallambaker.com/
>> >
>> > _______________________________________________
>> > keyassure mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/keyassure
>>
>
>
>
> --
> Website: http://hallambaker.com/
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>
>

Date: Mon, 25 Oct 2010 12:36:31 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Certification Authority Authorization Draft.

On Mon, 25 Oct 2010, Phillip Hallam-Baker wrote:

> In theory that should be the case. In practice the transfer of dns names is rather more complex. I have been trying to find documentation on the controls. They may not be public or they may not exist.
>
> If you want to demonstrate that one system is more secure than the other you have to apply the same standard of scruitiny to both systems.

The same applies for chaining security systems (DNSSEC and CA's).

I remember when crpytophone people did not trust one cipher, and Rudi
Weiss had to prove that (AES->3DES->blowfish) was at least as secure as
the weakest component in that list. Which he did in a paper that went
beyond my math skills.

Entangling CA's and DNSSEC would need some proof that it is more secure
then its individual components. With some strong weaknesses in the CA
deployments and omnipotent trust wielders, I am extremely skeptical
this can be done. And the price to pay is to deal with many corner
cases because unlike chained chiphers, this entangled system would not
have a clear serial flow through it. Contradictions would be possible,
and then we run into many interpretations and implementations as to how
to address these.

The reason (IMHO) that we are doing anything in the ASN.1 space at all
for DNSSEC is that we have to deal with X.509 in SSL/TLS.

But I think this discussion has already been seen on this list various
times, so I'll refrain from further firing up this discussion *again*

Paul

Date: Mon, 25 Oct 2010 12:26:27 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt

On Mon, 25 Oct 2010, Paul Hoffman wrote:

> The common practice is to give each server application its own domain name. This is not the only practice, but it is common. You want to not require that practice, at a cost of the DNS administrator needing to add some extra information in the DNS, and the client app needed to request that information. The question is whether the cost to everyone of those additions to the protocol are worth the benefit for the few who do not have unique domain names for each server application. I claim the cost to everyone is not worth the benefit to the few, but others may disagree.

I would say the world is moving in the other direction. You use "cnn.com" and "twitter.com", not www.cnn.com or www.twitter.com.
I am [email-masked], not [email-masked].

If anything, we are trying to reduce the combinations of http/https/www/ methods of reaching a website into one.

Using a port specifier would in my opinion be very useful. It will also reduce the number of records returned that have
to be checked by the client that is only interested in one particular service/port. But we have to be careful not to
increase the amount of queries by missing the right port.

Paul

Date: Mon, 25 Oct 2010 07:51:45 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt

At 3:09 PM +0200 10/25/10, Simon Josefsson wrote:
>Paul Hoffman <[email-masked]> writes:
>
>>>For instance, example.com might have a TLS cert for SMTP, but not for
>>>HTTPS. Querying the DNS for a cert record will not tell me I can connect
>>>on HTTPS to that server.
>>
>> That is correct. It is not correct, however, if you query for
>> www.example.com and mail.example.com: then you do know that the
>> services at each of those two hosts (which might reside on the same
>> box) use TLS.
>
>One part that I disliked was that you don't separate on port.  So it is
>not possible to query for a TLS fingerprint for certificate used on port
>X and do the same for port Y without having to match them all.  I
>believe this primarily makes it difficult to deploy, because it is
>difficult to separate DNS privileges between the people responsible for
>the different services.

The common practice is to give each server application its own domain name. This is not the only practice, but it is common. You want to not require that practice, at a cost of the DNS administrator needing to add some extra information in the DNS, and the client app needed to request that information. The question is whether the cost to everyone of those additions to the protocol are worth the benefit for the few who do not have unique domain names for each server application. I claim the cost to everyone is not worth the benefit to the few, but others may disagree.

At 10:02 AM -0400 10/25/10, Phillip Hallam-Baker wrote:
>Whether this is an issue or not depends on whether the semantics are "here is a key you can use" or "here are the only keys you can use"

Correct.

>It has to be possible to use dnssec to establish a key for a mail server that lives on the same dns node as a Web server without affecting operation of the Web server in any way.

Can you say more about why you have this requirement? When the DNS protocol prevents you from doing something at one level but completely allows you do do something by creating another name within a subordinate namespace, what makes it so required that you only do things at the top-level name? There are lots of other examples of such requirements in the DNS protocol; why is this one so important?

--Paul Hoffman, Director
--VPN Consortium

From: Phillip Hallam-Baker <[email-masked]>
To: Simon Josefsson <[email-masked]>
Date: Mon, 25 Oct 2010 10:02:25 -0400
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt

Whether this is an issue or not depends on whether the semantics are =
"here is a key you can use" or "here are the only keys you can use"

I have also had discussions with the AD. My expectation was that the =
group will be required to produce a means of establishing keys as being =
valid before it would be allowed to address any aspect of security =
policy. I also anticipated being required to produce experimental drafts =
for any security policy mechanism. This is what I believe will be =
required of the group.

It has to be possible to use dnssec to establish a key for a mail server =
that lives on the same dns node as a Web server without affecting =
operation of the Web server in any way.

Those requirements cannot and should not be ignored for the sake of =
saving a few DNS round trips.

Reuse of the CERT record to establish a key as being valid goes beyond =
the original semantics of the record but is something i think we can =
justify. But using it to communicate security policy goes too far in my =
view.

Sent from my iPad

On Oct 25, 2010, at 9:09 AM, Simon Josefsson <[email-masked]> =
wrote:

> Paul Hoffman <[email-masked]> writes:
>=20
>>> For instance, example.com might have a TLS cert for SMTP, but not =
for
>>> HTTPS. Querying the DNS for a cert record will not tell me I can =
connect
>>> on HTTPS to that server.
>>=20
>> That is correct. It is not correct, however, if you query for
>> www.example.com and mail.example.com: then you do know that the
>> services at each of those two hosts (which might reside on the same
>> box) use TLS.
>=20
> One part that I disliked was that you don't separate on port.  So it =
is
> not possible to query for a TLS fingerprint for certificate used on =
port
> X and do the same for port Y without having to match them all.  I
> believe this primarily makes it difficult to deploy, because it is
> difficult to separate DNS privileges between the people responsible =
for
> the different services.
>=20
> /Simon
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Phillip Hallam-Baker <[email-masked]>
To: Jakob Schlyter <[email-masked]>
Date: Mon, 25 Oct 2010 09:31:55 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Certification Authority Authorization Draft.

That has yet to be established.

In theory that should be the case. In practice the transfer of dns names =
is rather more complex. I have been trying to find documentation on the =
controls. They may not be public or they may not exist.=20

If you want to demonstrate that one system is more secure than the other =
you have to apply the same standard of scruitiny to both systems.=20

Sent from my iPad

On Oct 25, 2010, at 8:33 AM, Jakob Schlyter <[email-masked]> wrote:

> On 25 okt 2010, at 14.01, Phillip Hallam-Baker wrote:
>=20
>> If the registrar is defecting they can change the DNS, look for the =
update, ping the resolver whose cache they want to poison and then =
reverse out the changes once the cache is poisoned.
>=20
> Only the registrar you have chosen can go rogue. If you don't trust =
your registrar, chose another one. Compared to legacy PKI, where you can =
cannot choose as all CA:s are trusted without constraints, this is a =
huge win.
>=20
> I do agree that combining DNSSEC and EV is even better. However, =
combining DNSSEC and DV to order to increase security is IMHO close to =
useless.
>=20
> 	jakob
>=20
> --=20
> Jakob Schlyter
> Kirei AB - www.kirei.se
>=20
>=20
>=20

From: Simon Josefsson <[email-masked]>
To: Paul Hoffman <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 25 Oct 2010 15:09:43 +0200
Cc: [email-masked]
Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt

Paul Hoffman <[email-masked]> writes:

>>For instance, example.com might have a TLS cert for SMTP, but not for
>>HTTPS. Querying the DNS for a cert record will not tell me I can connect
>>on HTTPS to that server.
>
> That is correct. It is not correct, however, if you query for
> www.example.com and mail.example.com: then you do know that the
> services at each of those two hosts (which might reside on the same
> box) use TLS.

One part that I disliked was that you don't separate on port.  So it is
not possible to query for a TLS fingerprint for certificate used on port
X and do the same for port Y without having to match them all.  I
believe this primarily makes it difficult to deploy, because it is
difficult to separate DNS privileges between the people responsible for
the different services.

/Simon

From: Jakob Schlyter <[email-masked]>
Date: Mon, 25 Oct 2010 14:33:14 +0200
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Certification Authority Authorization Draft.

On 25 okt 2010, at 14.01, Phillip Hallam-Baker wrote:

> If the registrar is defecting they can change the DNS, look for the =
update, ping the resolver whose cache they want to poison and then =
reverse out the changes once the cache is poisoned.

Only the registrar you have chosen can go rogue. If you don't trust your =
registrar, chose another one. Compared to legacy PKI, where you can =
cannot choose as all CA:s are trusted without constraints, this is a =
huge win.

I do agree that combining DNSSEC and EV is even better. However, =
combining DNSSEC and DV to order to increase security is IMHO close to =
useless.

	jakob

--=20
Jakob Schlyter
Kirei AB - www.kirei.se

Date: Mon, 25 Oct 2010 08:01:29 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Jakob Schlyter <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Certification Authority Authorization Draft.

--0015174ff446a9c7cd04936fc04c
Content-Type: text/plain; charset=ISO-8859-1

Not necessarily.

If the registrar is defecting they can change the DNS, look for the update,
ping the resolver whose cache they want to poison and then reverse out the
changes once the cache is poisoned.

If you make equivalent assumptions, both systems are vulnerable to
compromise. The only way you can do better is if you use both systems and
check both paths so that you get some degree of separation of duties.

On Mon, Oct 25, 2010 at 5:36 AM, Jakob Schlyter <[email-masked]> wrote:

> On 24 okt 2010, at 23.48, Phillip Hallam-Baker wrote:
>
> > There is no magic in the choice of bits on the wire. DNSSEC suffers from
> exactly the same set of issuing chain difficulties as PKI does. The number
> of DNS registrars is actually considerably larger than the number of SSL
> validation authorities.
>
> Except that it is apparent for the victim when a DNS registrar goes rogue
> (as the result is published in the DNS), whereas a trusted CA can issue bad
> certificates without detection.
>
>        jakob
>
> --
> Jakob Schlyter
> Kirei AB - www.kirei.se
>
>

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

--0015174ff446a9c7cd04936fc04c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Not necessarily.<div><br></div><div>If the registrar is defecting they can =
change the DNS, look for the update, ping the resolver whose cache they wan=
t to poison and then reverse out the changes once the cache is poisoned.</d=
iv>
<div><br></div><div><br></div><div>If you make equivalent assumptions, both=
 systems are vulnerable to compromise. The only way you can do better is if=
 you use both systems and check both paths so that you get some degree of s=
eparation of duties.=A0</div>
<div><br><br><div class=3D"gmail_quote">On Mon, Oct 25, 2010 at 5:36 AM, Ja=
kob Schlyter <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">jakob@=
kirei.se</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 24 okt 2010, at 23.48, Phillip Hallam-Baker wrote:<br>
<br>
&gt; There is no magic in the choice of bits on the wire. DNSSEC suffers fr=
om exactly the same set of issuing chain difficulties as PKI does. The numb=
er of DNS registrars is actually considerably larger than the number of SSL=
 validation authorities.<br>

<br>
</div>Except that it is apparent for the victim when a DNS registrar goes r=
ogue (as the result is published in the DNS), whereas a trusted CA can issu=
e bad certificates without detection.<br>
<br>
 =A0 =A0 =A0 =A0jakob<br>
<font color=3D"#888888"><br>
--<br>
Jakob Schlyter<br>
Kirei AB - <a href=3D"http://www.kirei.se" target=3D"_blank">www.kirei.se</=
a><br>
<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--0015174ff446a9c7cd04936fc04c--

From: Jakob Schlyter <[email-masked]>
Date: Mon, 25 Oct 2010 11:36:59 +0200
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Certification Authority Authorization Draft.

On 24 okt 2010, at 23.48, Phillip Hallam-Baker wrote:

> There is no magic in the choice of bits on the wire. DNSSEC suffers =
from exactly the same set of issuing chain difficulties as PKI does. The =
number of DNS registrars is actually considerably larger than the number =
of SSL validation authorities.=20

Except that it is apparent for the victim when a DNS registrar goes =
rogue (as the result is published in the DNS), whereas a trusted CA can =
issue bad certificates without detection.

	jakob

--=20
Jakob Schlyter
Kirei AB - www.kirei.se

Date: Sun, 24 Oct 2010 18:03:28 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt

--0016e644cf8ad25a8e0493640c13
Content-Type: text/plain; charset=ISO-8859-1

That is an example of security policy. That is exactly what I propose in
ESRV and what CAA is a form of.

I discussed this issue with Tim Polk last Friday and as I expected, he
thinks that there is a significant risk that a group that tries to do
security policy will never terminate. So he would like to see experimental
proposals being made before the WG looks at them.

Specification of trust anchors is the hardest aspect of security policy to
get right.

If we have a statement in the DNS/DNSSEC that says 'always use SSL' for a
given protocol, we can then ensure that every communication uses the highest
degree of security supported by both the client and server.

In that world we do not require the padlock icon at all. The only
communication to the user that is worth communicating to the user is 'we
think you are safe'. A DV cert only allows encryption to be established and
that is a fairly low level of risk control. The probability that an end
point is malicious is far greater than the probability that the
infrastructure has been compromised for most Internet use cases. So securing
the network connection alone is only giving a very weak form of protection.

I would like to see the padlock icon retired and to only use user
notification when an EV certificate is in use and we have a demonstration of
accountability for the end point.

On Sun, Oct 24, 2010 at 5:01 PM, Paul Wouters <[email-masked]> wrote:

> On Mon, 4 Oct 2010, Paul Hoffman wrote:
>
>  A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>        Title           : Using Secure DNS to Associate Certificates with
>>> Domain Names For TLS
>>>        Author(s)       : P. Hoffman, et al.
>>>        Filename        : draft-hoffman-keys-linkage-from-dns-03.txt
>>>        Pages           : 13
>>>        Date            : 2010-10-04
>>>
>>
> I like this draft. I have only one concern. This method does not allow
> one to query the DNS in an opportunistic matter, and based upon CERT/TLSFP
> records received back, decide on a different course of action.
>
> For instance, example.com might have a TLS cert for SMTP, but not for
> HTTPS. Querying the DNS for a cert record will not tell me I can connect
> on HTTPS to that server.
>
> It would be nice if we could do this, so we have some method of migrating
> the masses of the web servers to use HTTPS without having to go through
> an HTTP redirect (which way too often, will leak cookies, Etags or other
> information that could be used to later take over the HTTPS connection.
>
> A next logical step would be to try and phase out HTTP for HTTPS. If
> possible,
> this standard should take that signalling into consideration. The less
> redirects and DNS queries we need to do, the better.
>
> Paul
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

--0016e644cf8ad25a8e0493640c13
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

That is an example of security policy. That is exactly what I propose in ES=
RV and what CAA is a form of.<div><br></div><div>I discussed this issue wit=
h Tim Polk last Friday and as I expected, he thinks that there is a signifi=
cant risk that a group that tries to do security policy will never terminat=
e. So he would like to see experimental proposals being made before the WG =
looks at them.</div>
<div><br></div><div>Specification of trust anchors is the hardest aspect of=
 security policy to get right.=A0</div><div><br></div><div><br></div><div>I=
f we have a statement in the DNS/DNSSEC that says &#39;always use SSL&#39; =
for a given protocol, we can then ensure that every communication uses the =
highest degree of security supported by both the client and server.</div>
<div><br></div><div>In that world we do not require the padlock icon at all=
. The only communication to the user that is worth communicating to the use=
r is &#39;we think you are safe&#39;. A DV cert only allows encryption to b=
e established and that is a fairly low level of risk control. The probabili=
ty that an end point is malicious is far greater than the probability that =
the infrastructure has been compromised for most Internet use cases. So sec=
uring the network connection alone is only giving a very weak form of prote=
ction.</div>
<div><br></div><div>I would like to see the padlock icon retired and to onl=
y use user notification when an EV certificate is in use and we have a demo=
nstration of accountability for the end point.</div><div><br></div><div>
<br><div class=3D"gmail_quote">On Sun, Oct 24, 2010 at 5:01 PM, Paul Wouter=
s <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul@xeleranc=
e.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Mon, 4 Oct 2010, Paul Hoffman wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.<br>
<br>
 =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Using Secure DNS to Associate C=
ertificates with Domain Names For TLS<br>
 =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : P. Hoffman, et al.<br>
 =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-hoffman-keys-linkage-from-d=
ns-03.txt<br>
 =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 13<br>
 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-10-04<br>
</blockquote></blockquote>
<br></div>
I like this draft. I have only one concern. This method does not allow<br>
one to query the DNS in an opportunistic matter, and based upon CERT/TLSFP<=
br>
records received back, decide on a different course of action.<br>
<br>
For instance, <a href=3D"http://example.com" target=3D"_blank">example.com<=
/a> might have a TLS cert for SMTP, but not for<br>
HTTPS. Querying the DNS for a cert record will not tell me I can connect<br=
>
on HTTPS to that server.<br>
<br>
It would be nice if we could do this, so we have some method of migrating<b=
r>
the masses of the web servers to use HTTPS without having to go through<br>
an HTTP redirect (which way too often, will leak cookies, Etags or other<br=
>
information that could be used to later take over the HTTPS connection.<br>
<br>
A next logical step would be to try and phase out HTTP for HTTPS. If possib=
le,<br>
this standard should take that signalling into consideration. The less<br>
redirects and DNS queries we need to do, the better.<br><font color=3D"#888=
888">
<br>
Paul</font><div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
keyassure mailing list<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]<=
/a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--0016e644cf8ad25a8e0493640c13--

Date: Sun, 24 Oct 2010 17:48:32 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Certification Authority Authorization Draft.

--000e0cd4cdb6462a4f049363d607
Content-Type: text/plain; charset=ISO-8859-1

CAA only requires deployment by two parties to be useful and provide
coverage, both of which are highly motivated to act.

TLSFP requires the client application to be upgraded before a relying party
has any protection. That means that deployment will take a minimum of ten
years. It also means that it is a good deal harder to get right.

There is a good case to be made for client side enforcement of certificate
issuing policy, but it is not a substitute for better issue controls.

As for reducing the number of CAs, that is rather more difficult than you
might imagine. CAA is designed to set an objective test that gives a browser
provider grounds for withdrawing accreditation.

There is no magic in the choice of bits on the wire. DNSSEC suffers from
exactly the same set of issuing chain difficulties as PKI does. The number
of DNS registrars is actually considerably larger than the number of SSL
validation authorities.

On Sun, Oct 24, 2010 at 4:28 PM, Paul Wouters <[email-masked]> wrote:

> On Mon, 18 Oct 2010, Phillip Hallam-Baker wrote:
>
>  http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt
>>
>
>   The Certification Authority Authorization (CAA) DNS Resource Record
>   allows a DNS domain name holder to specify the certificate signing
>   certificate(s) authorized to issue certificates for that domain.
>
> If you can trust the CAA DNS record, why could you not trust a record
> with SSL/TLS FP from the same administrative source? From a technical
> point of view, this record makes no sense.
>
> This record seems to address practical limitations of the CA trust model,
> whereby one installed omnipotent CA could make a claim contradicting
> another omnipontent CA.
>
>
>  Clearly a record of this type could be used to effect client policy
>> enforcement mechanisms.
>>
>
> A better fix would be to replace/fix the broken bag of omnipotent CA's
> endusers now have to blindly trust. If that solution is sought outside
> the scope of CA's and X.509, CRLs, OCSP's etc, then it makes no sense to
> keep lingering in that space, and instead just move on to DNSSEC based
> trust relationships.
>
>   Before issue of a certificate a compliant CA MUST check for
>   publication of a relevant CAA Resource Record and if a record is
>   published that the certificate requested is consistent with it.  If
>   the certificate requested is not consistent with the CAA RR
>   authorization, the CA MUST NOT issue the certificate.
>
> This basicly mandates DNSSEC to avoid fraud. If mandating DNSSEC, what's
> left of the role of the CA?
>
> If the CAA DNS record would present a migration path from CA's to DNSSEC
> based authentication, I might see a use for it.
>
> Paul
>

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

--000e0cd4cdb6462a4f049363d607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

CAA only requires deployment by two parties to be useful and provide covera=
ge, both of which are highly motivated to act.<div><br></div><div>TLSFP req=
uires the client application to be upgraded before a relying party has any =
protection. That means that deployment will take a minimum of ten years. It=
 also means that it is a good deal harder to get right.</div>
<div><br></div><div><br></div><div>There is a good case to be made for clie=
nt side enforcement of certificate issuing policy, but it is not a substitu=
te for better issue controls.=A0<br><br></div><div>As for reducing the numb=
er of CAs, that is rather more difficult than you might imagine. CAA is des=
igned to set an objective test that gives a browser provider grounds for wi=
thdrawing accreditation.=A0</div>
<div><br></div><div><br></div><div>There is no magic in the choice of bits =
on the wire. DNSSEC suffers from exactly the same set of issuing chain diff=
iculties as PKI does. The number of DNS registrars is actually considerably=
 larger than the number of SSL validation authorities.=A0</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Sun, Oct 24, 2010 at =
4:28 PM, Paul Wouters <span dir=3D"ltr">&lt;<a href=3D"mailto:paul@xeleranc=
e.com">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
<div class=3D"im">On Mon, 18 Oct 2010, Phillip Hallam-Baker wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<a href=3D"http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt" targ=
et=3D"_blank">http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt</a=
><br>
</blockquote>
<br></div>
 =A0 The Certification Authority Authorization (CAA) DNS Resource Record<br=
>
 =A0 allows a DNS domain name holder to specify the certificate signing<br>
 =A0 certificate(s) authorized to issue certificates for that domain.<br>
<br>
If you can trust the CAA DNS record, why could you not trust a record<br>
with SSL/TLS FP from the same administrative source? From a technical<br>
point of view, this record makes no sense.<br>
<br>
This record seems to address practical limitations of the CA trust model,<b=
r>
whereby one installed omnipotent CA could make a claim contradicting<br>
another omnipontent CA.<div class=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Clearly a record of this type could be used to effect client policy enforce=
ment mechanisms.<br>
</blockquote>
<br></div>
A better fix would be to replace/fix the broken bag of omnipotent CA&#39;s<=
br>
endusers now have to blindly trust. If that solution is sought outside<br>
the scope of CA&#39;s and X.509, CRLs, OCSP&#39;s etc, then it makes no sen=
se to<br>
keep lingering in that space, and instead just move on to DNSSEC based<br>
trust relationships.<br>
<br>
 =A0 Before issue of a certificate a compliant CA MUST check for<br>
 =A0 publication of a relevant CAA Resource Record and if a record is<br>
 =A0 published that the certificate requested is consistent with it. =A0If<=
br>
 =A0 the certificate requested is not consistent with the CAA RR<br>
 =A0 authorization, the CA MUST NOT issue the certificate.<br>
<br>
This basicly mandates DNSSEC to avoid fraud. If mandating DNSSEC, what&#39;=
s<br>
left of the role of the CA?<br>
<br>
If the CAA DNS record would present a migration path from CA&#39;s to DNSSE=
C<br>
based authentication, I might see a use for it.<br><font color=3D"#888888">
<br>
Paul<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--000e0cd4cdb6462a4f049363d607--

Date: Sun, 24 Oct 2010 14:45:03 -0700
To: Paul Wouters <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt

At 5:01 PM -0400 10/24/10, Paul Wouters wrote:
>I like this draft. I have only one concern. This method does not allow
>one to query the DNS in an opportunistic matter, and based upon CERT/TLSFP
>records received back, decide on a different course of action.

Actually, it does, if you ask for the specific host. However...

>For instance, example.com might have a TLS cert for SMTP, but not for
>HTTPS. Querying the DNS for a cert record will not tell me I can connect
>on HTTPS to that server.

That is correct. It is not correct, however, if you query for www.example.com and mail.example.com: then you do know that the services at each of those two hosts (which might reside on the same box) use TLS.

The "tell me all the TLS-enhanced services at example.com" issue is still interesting, but it devolves very quickly. You are assuming that "example.com" is the right cutoff without knowing how that zone names the hosts that provide services. You do *not* want .com giving a single answer for all of its subdomains, do you? If not, why do you want example.com?

Our design explicitly chose "give the exact host name, and we'll tell you about it". If folks want something that is along the line of "give a zone name and we'll tell you about the layers one or more levels down", I hope they can also say how to prevent the "VeriSign gets to give this data for all of .com" and "PIR gets to give this data for all of .org" problem.

>It would be nice if we could do this, so we have some method of migrating
>the masses of the web servers to use HTTPS without having to go through
>an HTTP redirect (which way too often, will leak cookies, Etags or other
>information that could be used to later take over the HTTPS connection.

Fully agree. The folks in the websec WG are working on this problem.

>A next logical step would be to try and phase out HTTP for HTTPS. If possible,
>this standard should take that signalling into consideration. The less
>redirects and DNS queries we need to do, the better.

Yep.

--Paul Hoffman, Director
--VPN Consortium

Date: Sun, 24 Oct 2010 17:01:54 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt

On Mon, 4 Oct 2010, Paul Hoffman wrote:

>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>> 	Title           : Using Secure DNS to Associate Certificates with Domain Names For TLS
>> 	Author(s)       : P. Hoffman, et al.
>> 	Filename        : draft-hoffman-keys-linkage-from-dns-03.txt
>> 	Pages           : 13
>> 	Date            : 2010-10-04

I like this draft. I have only one concern. This method does not allow
one to query the DNS in an opportunistic matter, and based upon CERT/TLSFP
records received back, decide on a different course of action.

For instance, example.com might have a TLS cert for SMTP, but not for
HTTPS. Querying the DNS for a cert record will not tell me I can connect
on HTTPS to that server.

It would be nice if we could do this, so we have some method of migrating
the masses of the web servers to use HTTPS without having to go through
an HTTP redirect (which way too often, will leak cookies, Etags or other
information that could be used to later take over the HTTPS connection.

A next logical step would be to try and phase out HTTP for HTTPS. If possible,
this standard should take that signalling into consideration. The less
redirects and DNS queries we need to do, the better.

Paul

Date: Sun, 24 Oct 2010 15:59:36 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Certification Authority Authorization Draft.
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Paul and all,

-----Original Message-----
>From: Paul Wouters <[email-masked]>
>Sent: Oct 24, 2010 3:44 PM
>To: Phillip Hallam-Baker <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] Certification Authority Authorization Draft.
>
>On Mon, 18 Oct 2010, Phillip Hallam-Baker wrote:
>
>> Assume for a moment that other CAs don't follow our lead and end up mis-=
issuing against a domain that has a CAA record. What do you
>> think their liability is in that case? They certainly have a major PR is=
sue at that point and their only realistic chance of
>> surviving it without too much damage is going to be to deploy CAA.
>
>Seeing that rapidssl is still very much alive, I think we can safely say P=
R is not a valid detergend
>against running an uhm, less then optimally secure CA.
>
>> You may also be interested in my DPLS draft:=C2=A0
>>=20
>> http://www.ietf.org/id/draft-hallambaker-dpls-00.txt
>
>A quick peek:
>
>    DPLS allows for more efficient secure DNS resolution by enabling a
>    trusted resolver to efficiently authenticate communiction with a
>    client.
>
>I doubt the impact of running DNSSEC on the enduser is that much
>of an impact these days. Especially because of DNS caching. Plus,
>if efficiency is an issue, configuring the enduser to use a trusted
>validating usptream resolver addresses that problem too (except it would
>not have confidentiality, but see below)

  Confidentiality is a significant issue though...
>
>    A secondary advantage of using DPLS is that it enables traffic
>    between the DNS client and resolver to be encrypted, thus reducing
>    exposure to confidentiality attacks.
>
>It might protect last-mile wifi confidentiality attacks, but nothing
>else. Because it is easy to give unique DNS labels to clients for tracking
>purposes, unless hundreds+ clients are all congregating their traffic
>at a common DNS server (something that TOR tries to do)

  If your correct, and I am not sure you are, still confidentiality attacks
are reduced.  That's an improvement. =20
>
>
>> A lot of the DNS performance issues go away if the DNS client can ask it=
s resolver 'hey give me all the info I need to do this with
>> that'.
>
>Those can be done using EDNS options as well.
>
>the draft discusses a lot of split DNS setups and required confidentiality=
, but
>that all boils down to "enterprises need VPN + company DNS server". I am u=
nclear
>how this draft would change that, except adding some new kind of transport=
 layer
>security. If one would design something like that, the very least I would =
expect
>is a way to return more data to the client in bulk that it will encounter =
when
>doing more queries anyway. Latency is the performance issue here, not band=
width
>or CPU usage.
>
>Paul
>Paul
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

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; liabilit=
y
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]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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]=
m
Phone: 214-244-4827

Date: Sun, 24 Oct 2010 16:44:55 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Certification Authority Authorization Draft.

On Mon, 18 Oct 2010, Phillip Hallam-Baker wrote:

> Assume for a moment that other CAs don't follow our lead and end up mis-issuing against a domain that has a CAA record. What do you
> think their liability is in that case? They certainly have a major PR issue at that point and their only realistic chance of
> surviving it without too much damage is going to be to deploy CAA.

Seeing that rapidssl is still very much alive, I think we can safely say PR is not a valid detergend
against running an uhm, less then optimally secure CA.

> You may also be interested in my DPLS draft:�
> 
> http://www.ietf.org/id/draft-hallambaker-dpls-00.txt

A quick peek:

    DPLS allows for more efficient secure DNS resolution by enabling a
    trusted resolver to efficiently authenticate communiction with a
    client.

I doubt the impact of running DNSSEC on the enduser is that much
of an impact these days. Especially because of DNS caching. Plus,
if efficiency is an issue, configuring the enduser to use a trusted
validating usptream resolver addresses that problem too (except it would
not have confidentiality, but see below)

    A secondary advantage of using DPLS is that it enables traffic
    between the DNS client and resolver to be encrypted, thus reducing
    exposure to confidentiality attacks.

It might protect last-mile wifi confidentiality attacks, but nothing
else. Because it is easy to give unique DNS labels to clients for tracking
purposes, unless hundreds+ clients are all congregating their traffic
at a common DNS server (something that TOR tries to do)

> A lot of the DNS performance issues go away if the DNS client can ask its resolver 'hey give me all the info I need to do this with
> that'.

Those can be done using EDNS options as well.

the draft discusses a lot of split DNS setups and required confidentiality, but
that all boils down to "enterprises need VPN + company DNS server". I am unclear
how this draft would change that, except adding some new kind of transport layer
security. If one would design something like that, the very least I would expect
is a way to return more data to the client in bulk that it will encounter when
doing more queries anyway. Latency is the performance issue here, not bandwidth
or CPU usage.

Paul
Paul

Date: Sun, 24 Oct 2010 16:28:09 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Certification Authority Authorization Draft.

On Mon, 18 Oct 2010, Phillip Hallam-Baker wrote:

> http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt

    The Certification Authority Authorization (CAA) DNS Resource Record
    allows a DNS domain name holder to specify the certificate signing
    certificate(s) authorized to issue certificates for that domain.

If you can trust the CAA DNS record, why could you not trust a record
with SSL/TLS FP from the same administrative source? From a technical
point of view, this record makes no sense.

This record seems to address practical limitations of the CA trust model,
whereby one installed omnipotent CA could make a claim contradicting
another omnipontent CA.

> Clearly a record of this type could be used to effect client policy enforcement mechanisms.

A better fix would be to replace/fix the broken bag of omnipotent CA's
endusers now have to blindly trust. If that solution is sought outside
the scope of CA's and X.509, CRLs, OCSP's etc, then it makes no sense to
keep lingering in that space, and instead just move on to DNSSEC based
trust relationships.

    Before issue of a certificate a compliant CA MUST check for
    publication of a relevant CAA Resource Record and if a record is
    published that the certificate requested is consistent with it.  If
    the certificate requested is not consistent with the CAA RR
    authorization, the CA MUST NOT issue the certificate.

This basicly mandates DNSSEC to avoid fraud. If mandating DNSSEC, what's
left of the role of the CA?

If the CAA DNS record would present a migration path from CA's to DNSSEC
based authentication, I might see a use for it.

Paul

Date: Mon, 18 Oct 2010 22:17:04 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Certification Authority Authorization Draft.

--001485f796328d455e0492eee344
Content-Type: text/plain; charset=ISO-8859-1

Adam L. pointed out some typos and so on. I had to get it in today and I am
fighting off a cold.

As we discussed in the call, we are very interested in having Google
co-author if you are interested.

CA buy-in is not so much of a worry for me. Comodo will deploy for certain
and Symantec/VeriSignCA is pretty likely to follow.

Assume for a moment that other CAs don't follow our lead and end up
mis-issuing against a domain that has a CAA record. What do you think their
liability is in that case? They certainly have a major PR issue at that
point and their only realistic chance of surviving it without too much
damage is going to be to deploy CAA.

So all in all, I think that the chances are pretty good that we can present
this as a win for all concerned.

You may also be interested in my DPLS draft:

http://www.ietf.org/id/draft-hallambaker-dpls-00.txt

A lot of the DNS performance issues go away if the DNS client can ask its
resolver 'hey give me all the info I need to do this with that'.

On Mon, Oct 18, 2010 at 9:51 PM, Warren Kumari <[email-masked]> wrote:

> I have not yet read the whole draft, but so far I really like it.
>
> While (as you already pointed out) it doesn't solve all of the issues, it
> does go a long way towards improving matters, assuming of course the CAs buy
> in...
>
> W
> On Oct 18, 2010, at 5:32 PM, Phillip Hallam-Baker wrote:
>
> > This is a draft that I submitted this morning. The main proposal being
> made here is to enable Certification Authorities to avoid mis-issue.
> >
> > As such I believe that it is complimentary to mechanisms that enable
> client side enforcement but has the considerable advantage of offering
> immediate protection to every Internet user regardless of whether they have
> an updated browser. It is also much less strongly dependent on deployment of
> DNSSEC.
> > http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt
> >
> >
> > Given the nature of the proposal, it is probably better suited to having
> the bulk of the legal-technical work considered in CABForum rather than
> IETF. Accordingly the proposal is designed to allow the technical
> infrastructure to be agreed in IETF and then the practices and legal work
> done in CABForum.
> >
> > Clearly a record of this type could be used to effect client policy
> enforcement mechanisms. But this is a rather more complex issue and there
> are going to be a lot of people with views on the best way forward.
> >
> > The mechanism as specified is sufficient for allowing client side
> enforcement as it stands if the site is using a public CA, running a local
> CA cross certified into a public hierarchy or using a standalone private CA.
> But only if those infrastructures are supporting all their applications
> without exception.
> >
> >
> > --
> > Website: http://hallambaker.com/
> >
> > _______________________________________________
> > keyassure mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/keyassure
>
>

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

--001485f796328d455e0492eee344
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Adam L. pointed out some typos and so on. I had to get it in today and I am=
 fighting off a cold.<div><br></div><div><br></div><div>As we discussed in =
the call, we are very interested in having Google co-author if you are inte=
rested.</div>
<div><br></div><div><br><div>CA buy-in is not so much of a worry for me. Co=
modo will deploy for certain and Symantec/VeriSignCA is pretty likely to fo=
llow.</div><div><br></div><div>Assume for a moment that other CAs don&#39;t=
 follow our lead and end up mis-issuing against a domain that has a CAA rec=
ord. What do you think their liability is in that case? They certainly have=
 a major PR issue at that point and their only realistic chance of survivin=
g it without too much damage is going to be to deploy CAA.</div>
<div><br></div><div><br></div><div>So all in all, I think that the chances =
are pretty good that we can present this as a win for all concerned.=A0</di=
v><div><br></div><div><br></div><div>You may also be interested in my DPLS =
draft:=A0</div>
<div><br></div><div><span class=3D"Apple-style-span" style=3D"font-family: =
arial, sans-serif; font-size: 12.5px; border-collapse: collapse; color: rgb=
(51, 51, 51); "><a href=3D"http://www.ietf.org/id/draft-hallambaker-dpls-00=
.txt" target=3D"_blank" style=3D"color: rgb(54, 68, 82); ">http://www.ietf.=
org/id/draft-hallambaker-dpls-00.txt</a></span></div>
<div><br></div><div>A lot of the DNS performance issues go away if the DNS =
client can ask its resolver &#39;hey give me all the info I need to do this=
 with that&#39;.</div><div><br></div><div><br><div class=3D"gmail_quote">
On Mon, Oct 18, 2010 at 9:51 PM, Warren Kumari <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex;">
I have not yet read the whole draft, but so far I really like it.<br>
<br>
While (as you already pointed out) it doesn&#39;t solve all of the issues, =
it does go a long way towards improving matters, assuming of course the CAs=
 buy in...<br>
<br>
W<br>
<div><div></div><div class=3D"h5">On Oct 18, 2010, at 5:32 PM, Phillip Hall=
am-Baker wrote:<br>
<br>
&gt; This is a draft that I submitted this morning. The main proposal being=
 made here is to enable Certification Authorities to avoid mis-issue.<br>
&gt;<br>
&gt; As such I believe that it is complimentary to mechanisms that enable c=
lient side enforcement but has the considerable advantage of offering immed=
iate protection to every Internet user regardless of whether they have an u=
pdated browser. It is also much less strongly dependent on deployment of DN=
SSEC.<br>

&gt; <a href=3D"http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt"=
 target=3D"_blank">http://www.ietf.org/id/draft-hallambaker-donotissue-00.t=
xt</a><br>
&gt;<br>
&gt;<br>
&gt; Given the nature of the proposal, it is probably better suited to havi=
ng the bulk of the legal-technical work considered in CABForum rather than =
IETF. Accordingly the proposal is designed to allow the technical infrastru=
cture to be agreed in IETF and then the practices and legal work done in CA=
BForum.<br>

&gt;<br>
&gt; Clearly a record of this type could be used to effect client policy en=
forcement mechanisms. But this is a rather more complex issue and there are=
 going to be a lot of people with views on the best way forward.<br>
&gt;<br>
&gt; The mechanism as specified is sufficient for allowing client side enfo=
rcement as it stands if the site is using a public CA, running a local CA c=
ross certified into a public hierarchy or using a standalone private CA. Bu=
t only if those infrastructures are supporting all their applications witho=
ut exception.<br>

&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Website: <a href=3D"http://hallambaker.com/" target=3D"_blank">http://=
hallambaker.com/</a><br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; keyassure mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D"=
_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div></div>

--001485f796328d455e0492eee344--

From: Warren Kumari <[email-masked]>
Date: Mon, 18 Oct 2010 21:51:27 -0400
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Certification Authority Authorization Draft.

I have not yet read the whole draft, but so far I really like it.=20

While (as you already pointed out) it doesn't solve all of the issues, =
it does go a long way towards improving matters, assuming of course the =
CAs buy in...

W
On Oct 18, 2010, at 5:32 PM, Phillip Hallam-Baker wrote:

> This is a draft that I submitted this morning. The main proposal being =
made here is to enable Certification Authorities to avoid mis-issue.=20
>=20
> As such I believe that it is complimentary to mechanisms that enable =
client side enforcement but has the considerable advantage of offering =
immediate protection to every Internet user regardless of whether they =
have an updated browser. It is also much less strongly dependent on =
deployment of DNSSEC.=20
> http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt
>=20
>=20
> Given the nature of the proposal, it is probably better suited to =
having the bulk of the legal-technical work considered in CABForum =
rather than IETF. Accordingly the proposal is designed to allow the =
technical infrastructure to be agreed in IETF and then the practices and =
legal work done in CABForum.
>=20
> Clearly a record of this type could be used to effect client policy =
enforcement mechanisms. But this is a rather more complex issue and =
there are going to be a lot of people with views on the best way =
forward.
>=20
> The mechanism as specified is sufficient for allowing client side =
enforcement as it stands if the site is using a public CA, running a =
local CA cross certified into a public hierarchy or using a standalone =
private CA. But only if those infrastructures are supporting all their =
applications without exception.
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Warren Kumari <[email-masked]>
Date: Mon, 18 Oct 2010 18:08:57 -0400
To: Steve Schultze <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] CA-related event in DC on Friday

On Oct 18, 2010, at 5:30 PM, Steve Schultze <[email-masked]> wrote:

> My apologies for the short notice. Frankly, I wasn't even sure if it was a=
ppropriate to send event info to the list.  I'm glad folks are interested.
>=20

Very interested -- unfortunately I won't be able to make it, but it looks ve=
ry interesting...
Please send a followup letting us know how it went off...

W

> At the event, I will be doing an extended introduction/tutorial along with=
 Ed Felten, and I'd be happy to make sure any input from the list is represe=
nted.  Feel free to email me directly or tweet to #ethreats.  I believe that=
 there will also be a live stream (linked from the New America events page),=
 and the moderator will keep his eye on twitter during the event.
>=20
> I'll also be in Beijing, and I'm looking forward to a more interactive con=
versation there.
>=20
> Steve
>=20
> On Oct 18, 2010, at 12:06 PM, Jeffrey A. Williams wrote:
>> stephen and all,
>>=20
>> Thanks for this information, but the thing is that we are
>> just 4 days before this event getting the information.  That's
>> a bit short of a time lead.  Will this event be taken on the road
>> perhaps in the near future?  The video is fine, but doesn't allow
>> for much interaction...
>>=20
>>=20
>> -----Original Message-----
>>> From: Stephen Schultze <[email-masked]>
>>> Sent: Oct 18, 2010 9:39 AM
>>> To: [email-masked]
>>> Subject: [keyassure] CA-related event in DC on Friday
>>>=20
>>> Hey all, those of you in the DC area you may be interested in an event =20=

>>> my research center is hosting along with New America Foundation.  The =20=

>>> full description is below.  Video will be available after the event.
>>>=20
>>> =3D=3D
>>>=20
>>> Emerging Threats to Online Trust: The Role of Public Policy and =20
>>> Browser Certificates
>>> http://citp.princeton.edu/events/emerging-threats-to-online-trust/
>>>=20
>>> Date: Friday, October 22, 2010
>>> Time: 9:00 AM - 11:00 AM
>>> Location: New America Foundation, 1899 L Street, NW, 4th Floor, =20
>>> Washington DC 20036
>>> Hashtag: #ethreats
>>>=20
>>> Hosted by Princeton's Center for Information Technology Policy and the =20=

>>> New America Foundation
>>>=20
>>> Every day, we rely on our web browsers to keep our communications =20
>>> secure. Whether we are submitting our credit card for purchases, doing =20=

>>> online banking, or sending email, the same fundamental security =20
>>> structure is being used. The lock icon displayed by web browsers might =20=

>>> give users reason to believe that the prevailing "certificate"-based =20=

>>> model is trustworthy, but the reality is that many vulnerabilities =20
>>> exist and the risks are multiplying. Hundreds of different entities =20
>>> located around the world have the ability to issue fraudulent =20
>>> certificates that will nevertheless be trusted by our browsers. =20
>>> Overcoming the shortcomings in the current model and working toward a =20=

>>> better model requires cooperation of corporations, the government, =20
>>> developers, and users. Many of the most difficult challenges are not =20=

>>> technical in nature but rather social or political.
>>>=20
>>> Keynote:
>>> Andrew McLaughlin, White House Deputy CTO, Internet Policy
>>>=20
>>> Panelists:
>>> Peter Eckersley, Senior Staff Technologist, Electronic Frontier =20
>>> Foundation
>>> Adam Langley, Senior Software Engineer, Google
>>> Scott Rea, Senior PKI Architect, DigiCert
>>> Paul Vixie, President, Internet Software Consortium
>>>=20
>>> Respondents:
>>> Ari Schwartz, Senior Internet Policy Advisor, National Institute of =20
>>> Standards and Technology
>>> Andy Steingruebl, Manager, Internet Standards and Governance, PayPal
>>>=20
>>> This event is free and open to the public. Please rsvp at:
>>> http://www.newamerica.net/events/2010/online_trust
>>> _______________________________________________
>>> keyassure mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/keyassure
>>=20
>> Regards,
>> Jeffrey A. Williams
>> "Obedience of the law is the greatest freedom" -
>>  Abraham Lincoln
>>=20
>> "Credit should go with the performance of duty and not with what is very
>> often the accident of glory" - Theodore Roosevelt
>>=20
>> "If the probability be called P; the injury, L; and the burden, B; liabil=
ity
>> 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]
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> Updated 1/26/04
>> CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. o=
f
>> Information Network Eng.  INEG. INC.
>> ABA member in good standing member ID 01257402 E-Mail [email-masked].=
com
>> Phone: 214-244-4827
>>=20
>>=20
>=20
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Mon, 18 Oct 2010 17:32:12 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Subject: [keyassure] Certification Authority Authorization Draft.

--001485f7c3ecd0ff030492eae8ba
Content-Type: text/plain; charset=ISO-8859-1

This is a draft that I submitted this morning. The main proposal being made
here is to enable Certification Authorities to avoid mis-issue.

As such I believe that it is complimentary to mechanisms that enable client
side enforcement but has the considerable advantage of offering immediate
protection to every Internet user regardless of whether they have an updated
browser. It is also much less strongly dependent on deployment of DNSSEC.

http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt

Given the nature of the proposal, it is probably better suited to having the
bulk of the legal-technical work considered in CABForum rather than IETF.
Accordingly the proposal is designed to allow the technical infrastructure
to be agreed in IETF and then the practices and legal work done in CABForum.

Clearly a record of this type could be used to effect client policy
enforcement mechanisms. But this is a rather more complex issue and there
are going to be a lot of people with views on the best way forward.

The mechanism as specified is sufficient for allowing client side
enforcement as it stands if the site is using a public CA, running a local
CA cross certified into a public hierarchy or using a standalone private CA.
But only if those infrastructures are supporting all their applications
without exception.

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

--001485f7c3ecd0ff030492eae8ba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This is a draft that I submitted this morning. The main proposal being made=
 here is to enable Certification Authorities to avoid mis-issue.=A0<div><br=
></div><div>As such I believe that it is complimentary to mechanisms that e=
nable client side enforcement but has the considerable advantage of offerin=
g immediate protection to every Internet user regardless of whether they ha=
ve an updated browser. It is also much less strongly dependent on deploymen=
t of DNSSEC.=A0<div>

<p class=3D"p1"><span class=3D"s1"><a href=3D"http://www.ietf.org/id/draft-=
hallambaker-donotissue-00.txt">http://www.ietf.org/id/draft-hallambaker-don=
otissue-00.txt</a></span></p></div><div><br></div><div>Given the nature of =
the proposal, it is probably better suited to having the bulk of the legal-=
technical work considered in CABForum rather than IETF. Accordingly the pro=
posal is designed to allow the technical infrastructure to be agreed in IET=
F and then the practices and legal work done in CABForum.<br clear=3D"all">
<br></div><div>Clearly a record of this type could be used to effect client=
 policy enforcement mechanisms. But this is a rather more complex issue and=
 there are going to be a lot of people with views on the best way forward.<=
/div>
<div><br></div><div>The mechanism as specified is sufficient for allowing c=
lient side enforcement as it stands if the site is using a public CA, runni=
ng a local CA cross certified into a public hierarchy or using a standalone=
 private CA. But only if those infrastructures are supporting all their app=
lications without exception.</div>
<div><br></div><div><br>-- <br>Website: <a href=3D"http://hallambaker.com/"=
>http://hallambaker.com/</a><br><br>
</div></div>

--001485f7c3ecd0ff030492eae8ba--

From: Steve Schultze <[email-masked]>
Date: Mon, 18 Oct 2010 17:30:58 -0400
To: [email-masked]
Subject: Re: [keyassure] CA-related event in DC on Friday

My apologies for the short notice. Frankly, I wasn't even sure if it was =
appropriate to send event info to the list.  I'm glad folks are =
interested.

At the event, I will be doing an extended introduction/tutorial along =
with Ed Felten, and I'd be happy to make sure any input from the list is =
represented.  Feel free to email me directly or tweet to #ethreats.  I =
believe that there will also be a live stream (linked from the New =
America events page), and the moderator will keep his eye on twitter =
during the event.

I'll also be in Beijing, and I'm looking forward to a more interactive =
conversation there.

Steve

On Oct 18, 2010, at 12:06 PM, Jeffrey A. Williams wrote:
> stephen and all,
>=20
>  Thanks for this information, but the thing is that we are
> just 4 days before this event getting the information.  That's
> a bit short of a time lead.  Will this event be taken on the road
> perhaps in the near future?  The video is fine, but doesn't allow
> for much interaction...
>=20
>=20
> -----Original Message-----
>> From: Stephen Schultze <[email-masked]>
>> Sent: Oct 18, 2010 9:39 AM
>> To: [email-masked]
>> Subject: [keyassure] CA-related event in DC on Friday
>>=20
>> Hey all, those of you in the DC area you may be interested in an =
event =20
>> my research center is hosting along with New America Foundation.  The =
=20
>> full description is below.  Video will be available after the event.
>>=20
>> =3D=3D
>>=20
>> Emerging Threats to Online Trust: The Role of Public Policy and =20
>> Browser Certificates
>> http://citp.princeton.edu/events/emerging-threats-to-online-trust/
>>=20
>> Date: Friday, October 22, 2010
>> Time: 9:00 AM - 11:00 AM
>> Location: New America Foundation, 1899 L Street, NW, 4th Floor, =20
>> Washington DC 20036
>> Hashtag: #ethreats
>>=20
>> Hosted by Princeton's Center for Information Technology Policy and =
the =20
>> New America Foundation
>>=20
>> Every day, we rely on our web browsers to keep our communications =20
>> secure. Whether we are submitting our credit card for purchases, =
doing =20
>> online banking, or sending email, the same fundamental security =20
>> structure is being used. The lock icon displayed by web browsers =
might =20
>> give users reason to believe that the prevailing "certificate"-based =20=

>> model is trustworthy, but the reality is that many vulnerabilities =20=

>> exist and the risks are multiplying. Hundreds of different entities =20=

>> located around the world have the ability to issue fraudulent =20
>> certificates that will nevertheless be trusted by our browsers. =20
>> Overcoming the shortcomings in the current model and working toward a =
=20
>> better model requires cooperation of corporations, the government, =20=

>> developers, and users. Many of the most difficult challenges are not =20=

>> technical in nature but rather social or political.
>>=20
>> Keynote:
>> Andrew McLaughlin, White House Deputy CTO, Internet Policy
>>=20
>> Panelists:
>> Peter Eckersley, Senior Staff Technologist, Electronic Frontier =20
>> Foundation
>> Adam Langley, Senior Software Engineer, Google
>> Scott Rea, Senior PKI Architect, DigiCert
>> Paul Vixie, President, Internet Software Consortium
>>=20
>> Respondents:
>> Ari Schwartz, Senior Internet Policy Advisor, National Institute of =20=

>> Standards and Technology
>> Andy Steingruebl, Manager, Internet Standards and Governance, PayPal
>>=20
>> This event is free and open to the public. Please rsvp at:
>> http://www.newamerica.net/events/2010/online_trust
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>=20
> Regards,
> Jeffrey A. Williams
> "Obedience of the law is the greatest freedom" -
>   Abraham Lincoln
>=20
> "Credit should go with the performance of duty and not with what is =
very
> often the accident of glory" - Theodore Roosevelt
>=20
> "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]
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 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
>=20
>=20

Date: Mon, 18 Oct 2010 11:06:22 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Stephen Schultze <[email-masked]>, [email-masked]
Subject: Re: [keyassure] CA-related event in DC on Friday
Reply-To: "Jeffrey A. Williams" <[email-masked]>

stephen and all,

  Thanks for this information, but the thing is that we are
just 4 days before this event getting the information.  That's
a bit short of a time lead.  Will this event be taken on the road
perhaps in the near future?  The video is fine, but doesn't allow
for much interaction...

-----Original Message-----
>From: Stephen Schultze <[email-masked]>
>Sent: Oct 18, 2010 9:39 AM
>To: [email-masked]
>Subject: [keyassure] CA-related event in DC on Friday
>
>Hey all, those of you in the DC area you may be interested in an event  
>my research center is hosting along with New America Foundation.  The  
>full description is below.  Video will be available after the event.
>
>==
>
>Emerging Threats to Online Trust: The Role of Public Policy and  
>Browser Certificates
>http://citp.princeton.edu/events/emerging-threats-to-online-trust/
>
>Date: Friday, October 22, 2010
>Time: 9:00 AM - 11:00 AM
>Location: New America Foundation, 1899 L Street, NW, 4th Floor,  
>Washington DC 20036
>Hashtag: #ethreats
>
>Hosted by Princeton's Center for Information Technology Policy and the  
>New America Foundation
>
>Every day, we rely on our web browsers to keep our communications  
>secure. Whether we are submitting our credit card for purchases, doing  
>online banking, or sending email, the same fundamental security  
>structure is being used. The lock icon displayed by web browsers might  
>give users reason to believe that the prevailing "certificate"-based  
>model is trustworthy, but the reality is that many vulnerabilities  
>exist and the risks are multiplying. Hundreds of different entities  
>located around the world have the ability to issue fraudulent  
>certificates that will nevertheless be trusted by our browsers.  
>Overcoming the shortcomings in the current model and working toward a  
>better model requires cooperation of corporations, the government,  
>developers, and users. Many of the most difficult challenges are not  
>technical in nature but rather social or political.
>
>Keynote:
>Andrew McLaughlin, White House Deputy CTO, Internet Policy
>
>Panelists:
>Peter Eckersley, Senior Staff Technologist, Electronic Frontier  
>Foundation
>Adam Langley, Senior Software Engineer, Google
>Scott Rea, Senior PKI Architect, DigiCert
>Paul Vixie, President, Internet Software Consortium
>
>Respondents:
>Ari Schwartz, Senior Internet Policy Advisor, National Institute of  
>Standards and Technology
>Andy Steingruebl, Manager, Internet Standards and Governance, PayPal
>
>This event is free and open to the public. Please rsvp at:
>http://www.newamerica.net/events/2010/online_trust
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

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: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Mon, 18 Oct 2010 10:39:36 -0400
Subject: [keyassure] CA-related event in DC on Friday

Hey all, those of you in the DC area you may be interested in an event  
my research center is hosting along with New America Foundation.  The  
full description is below.  Video will be available after the event.

==

Emerging Threats to Online Trust: The Role of Public Policy and  
Browser Certificates
http://citp.princeton.edu/events/emerging-threats-to-online-trust/

Date: Friday, October 22, 2010
Time: 9:00 AM - 11:00 AM
Location: New America Foundation, 1899 L Street, NW, 4th Floor,  
Washington DC 20036
Hashtag: #ethreats

Hosted by Princeton's Center for Information Technology Policy and the  
New America Foundation

Every day, we rely on our web browsers to keep our communications  
secure. Whether we are submitting our credit card for purchases, doing  
online banking, or sending email, the same fundamental security  
structure is being used. The lock icon displayed by web browsers might  
give users reason to believe that the prevailing "certificate"-based  
model is trustworthy, but the reality is that many vulnerabilities  
exist and the risks are multiplying. Hundreds of different entities  
located around the world have the ability to issue fraudulent  
certificates that will nevertheless be trusted by our browsers.  
Overcoming the shortcomings in the current model and working toward a  
better model requires cooperation of corporations, the government,  
developers, and users. Many of the most difficult challenges are not  
technical in nature but rather social or political.

Keynote:
Andrew McLaughlin, White House Deputy CTO, Internet Policy

Panelists:
Peter Eckersley, Senior Staff Technologist, Electronic Frontier  
Foundation
Adam Langley, Senior Software Engineer, Google
Scott Rea, Senior PKI Architect, DigiCert
Paul Vixie, President, Internet Software Consortium

Respondents:
Ari Schwartz, Senior Internet Policy Advisor, National Institute of  
Standards and Technology
Andy Steingruebl, Manager, Internet Standards and Governance, PayPal

This event is free and open to the public. Please rsvp at:
http://www.newamerica.net/events/2010/online_trust

From: Brian Sniffen <[email-masked]>
To: Tony Finch <[email-masked]>
Date: Tue, 12 Oct 2010 11:23:18 -0400
Cc: "[email-masked]" <[email-masked]>, Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] key per host

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tony Finch <[email-masked]> writes:

>> Say that I am managing 100,000 sites on 100 actual machines. Do I want
>> to have to manage 100,000 keys that are bound to the sites or 100 keys
>> that are bound to machines? Note that the sites float fairly freely
>> from machine to machine and moving crypto on machines that use crypto
>> accelerators is non-trivial.
>
> If the server farm acts as a single service then a single key would seem
> right to me. The crypto accelerator is more likely to live on the load
> balancer than the servers.

We certainly find need to use multiple keys to identify each of several
principals authorized to provide a service.  For example, Example,
Inc. might hold one key & certificate for www.example.com and authorize
a CDN or service provider to also provide service for www.example.com.
Each such service provider commonly generates his own key and requests
his own certificate---it saves arguing about who compromised a key, for
example.

=2D -Brian

=2D --=20
Brian T. Sniffen <[email-masked]>
Information Security
Akamai Technologies, Inc.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)

iEYEARECAAYFAky0fWYACgkQjNCI4p/QmrpD/wCeNIqzxO71CcpHf50WxegKn9Hx
LuUAoJEN9FLUbXiIIaspEylz0tCjUH8j
=3DBasR
=2D----END PGP SIGNATURE-----

Date: Mon, 11 Oct 2010 12:05:45 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Charter sent to ADs

--001485f03cac6d851404925988a2
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Oct 11, 2010 at 9:42 AM, Tony Finch <[email-masked]> wrote:

> On 11 Oct 2010, at 06:14, Ilari Liusvaara <[email-masked]>
> wrote:
> >
> > Also, "do not issue" advisories are not enough against rogue (or just
> plain
> > careless[*]!) CAs. Against those you need genuine chaining restrictions
>
> Phill's proposal includes that.
>
> > or exhaustive end-server cert enumeration.
>
> I think this should not be necessary. If you don't trust your CA to issue
> certs to the right people, why are you buying certs from them?
>
> Also I am worried that this requires too much complexity to deal with the
> many-certs case, and will be bad for performance if the DNS lookup has to
> be delayed until the TLS handshake.
>
>
> I'm inclined to say the client's logic should be to accept the cert if any
> of the certs in the chain (including the server cert itself) match any
> TLSFP record [0] in the DNS. Then you can either enumerate all the server
> certs or rely on CA "do not issue" rules. Sadly you can't have both
> because listing a CA cert implicitly authorizes any subordinate cert,
> which negates the point of server cert enumeration.
>

I agree that there are cases where there is a risk of either a CA default or
a CA being co-erced. But they are rather complex corner cases and require
assumptions that would invalidate any technology.

In the case where an end entity requires local control, the solution in my
view would be for them to either deploy their own cert issuing CA or deploy
a CA that cross certifies the end entity certs.

I cannot really see a commercial need for this approach, but there could be
a need in a government deployment.

So for example, say that you deploy Windows Server CA internally and get a
cross cert that chains your CA root to a public one. In that case you would
put out a policy statement with the FP of the intermediate root that you
control.

That is going to be a lot easier to manage than the enumeration approach
because all the necessary software to run that type of system already exists
and is mature. The enumeration approach would require tight integration
between the PKI and the DNS which is an entirely new approach.

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

--001485f03cac6d851404925988a2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 11, 2010 at 9:42 AM, Tony Finch <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 11 Oct 2010, at 06:14, Ilari Liusvaara &lt;<a href=3D"=
mailto:[email-masked]">[email-masked]</a>&gt; wro=
te:<br>
&gt;<br>
&gt; Also, &quot;do not issue&quot; advisories are not enough against rogue=
 (or just plain<br>
&gt; careless[*]!) CAs. Against those you need genuine chaining restriction=
s<br>
<br>
</div>Phill&#39;s proposal includes that.<br>
<div class=3D"im"><br>
&gt; or exhaustive end-server cert enumeration.<br>
<br>
</div>I think this should not be necessary. If you don&#39;t trust your CA =
to issue<br>
certs to the right people, why are you buying certs from them?<br>
<br>
Also I am worried that this requires too much complexity to deal with the<b=
r>
many-certs case, and will be bad for performance if the DNS lookup has to<b=
r>
be delayed until the TLS handshake.<br>
<br>
<br>
I&#39;m inclined to say the client&#39;s logic should be to accept the cert=
 if any<br>
of the certs in the chain (including the server cert itself) match any<br>
TLSFP record [0] in the DNS. Then you can either enumerate all the server<b=
r>
certs or rely on CA &quot;do not issue&quot; rules. Sadly you can&#39;t hav=
e both<br>
because listing a CA cert implicitly authorizes any subordinate cert,<br>
which negates the point of server cert enumeration.<br></blockquote><div><b=
r></div><div>I agree that there are cases where there is a risk of either a=
 CA default or a CA being co-erced. But they are rather complex corner case=
s and require assumptions that would invalidate any technology.</div>
<div><br></div><div><br></div><div>In the case where an end entity requires=
 local control, the solution in my view would be for them to either deploy =
their own cert issuing CA or deploy a CA that cross certifies the end entit=
y certs.=A0</div>
<div><br></div><div>I cannot really see a commercial need for this approach=
, but there could be a need in a government deployment.</div><div><br></div=
><div><br></div><div>So for example, say that you deploy Windows Server CA =
internally and get a cross cert that chains your CA root to a public one. I=
n that case you would put out a policy statement with the FP of the interme=
diate root that you control.</div>
<div><br></div><div>That is going to be a lot easier to manage than the enu=
meration approach because all the necessary software to run that type of sy=
stem already exists and is mature. The enumeration approach would require t=
ight integration between the PKI and the DNS which is an entirely new appro=
ach.</div>
<div><br></div><div>=A0</div></div>-- <br>Website: <a href=3D"http://hallam=
baker.com/">http://hallambaker.com/</a><br><br>

--001485f03cac6d851404925988a2--

Date: Mon, 11 Oct 2010 11:41:20 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter sent to ADs

--001485f199f01a24dc0492593176
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Ondrej,

I am not trying to 'obstruct' the WG as you claim.

I have been through IETF process many times over the past 18 years. I have
also had a hand in creating many of the alternative standardization routes
so I can tell you those pitfalls as well.

I would have absolutely no problem with a WG that is only going to specify
additional methods of telling a client that it can trust a key. Which is
what you appear to think that the group is limited to.

My problem is with a proposal that has an implicit condition that if there
is one FP specified in the DNS, then a client MUST regard the absence of a
matching FP to invalidate any other certificate regardless of whether there
is a valid PKIX chain or not.

Now you may not be aware that this is what some people are proposing but th=
e
fact is that (1) they are and (2) they believe that it is a rather importan=
t
requirement.

This is precisely the type of thing that it is important to get clear befor=
e
you submit the charter. The fact that the prototype code that has been
deployed already implements these semantics is rather relevant.

As for the milestones, you want to manage expectations and specify the
longest time period the ADs will allow you to get away with. I cannot
possibly imagine them insisting on the milestones being shorter than a year=
.

There are many aspects of IETF process that are completely out of control o=
f
the WG chairs and authors.

On Mon, Oct 11, 2010 at 3:27 AM, Ond=F8ej Sur=FD <[email-masked]> wrote=
:

> Just to clarify.  This group has nothing to do with Dan Kaminsky and it's
> not based on his work.  Neither his name nor his presentation was pointed
> out neither when we did bar-BoF nor when we started mailing list.
>
> This group was started on basis of work of earlier IETF contributors as w=
as
> Simon Josefsson, Jakob Schlyter and others.[1]  It was merely meant as a
> revival of that work after we started having DNSSEC signed root.
>
> I spoke to different parties and everybody seemed to be working on
> "something like this", and because I didn't want to have divergence on th=
e
> market, I tried to concentrate work done into this place.  (Even though I
> was warned that IETF way is painful and we better keep this outside.)
>
> And Phillip, I would really like to see if you can stop obstructing the
> work here by sending tons of emails where you reiterate your ideas again =
and
> again just because you have entirely different idea what this group shoul=
d
> be doing.  Your ideas about the work for this to-be-WG is that much
> different that you should create your own WG.  I wouldn't mind. But don't
> try to change this group into something it isn't and was never meant to b=
e.
>
> O.
> Links:
> 1. http://www.ietf.org/mail-archive/web/keyassure/current/msg00002.html
>
>
> On 8.10.2010 18:53, Phillip Hallam-Baker wrote:
>
>> At BH, Dan Kaminsky presented a paper where he identified the lack of
>> standards for issuing DV certificates as a problem and suggested an
>> alternative scheme based on DNSSEC which would have two purposes:
>>
>> 1) Enable a domain name owner to validate keys at the DV level
>> 2) Enable a domain name owner to prevent clients that support the
>> proposed mechanism from trusting certificates that they did not authoriz=
e.
>>
>>
>> I did not attend BH this year and so when I saw the group formed I
>> assumed that the only requirement it was intended to address was the
>> first one.
>>
>> This week I have spoken to or otherwise communicated to several of the
>> draft authors offlist. I have confirmed with them that the purpose of
>> enabling a domain name owner to prevent use of the certificates is
>> indeed one of their principal objectives.
>>
>>
>> Now if you want to rule the second purpose out of the charter, that is
>> fine with me. But the fact remains that the technical complexity of
>> putting any form of restriction in the client is vastly greater than the
>> complexity of a mandate that is imposed on the issuing CAs.
>>
>> Whether or not this group wishes to be a part of the 'do not issue'
>> approach, it is a simpler approach and one that offers benefits to both
>> CAs and to the users of legacy browsers and browsers that choose not to
>> deploy an enumeration based restriction scheme. And while it can make
>> use of DNSSEC, it is not dependent on DNSSEC deployment.
>>
>> I would see the forum for addressing do-not-issue to be CABForum more
>> than IETF.
>>
>> The reason it is relevant here is because it bears on the same original
>> requirement and may well pre-empt it to an extent. It is not possible to
>> use the enumeration approach as the basis of do-not-issue for obvious
>> reasons (can't take the hash of a cert before it is issued).
>>
>> So there is going to be do-not-issue information in the DNS that can
>> potentially be applied to solve this problem equally well and with a far
>> lower maintenance requirement than this particular scheme.
>>
>> --
>> Website: http://hallambaker.com/
>>
>>
>
> --
>  Ond=F8ej Sur=FD
>  vedouc=ED v=FDzkumu/Head of R&D department
>  -------------------------------------------
>  CZ.NIC, z.s.p.o.    --    Laborato=F8e CZ.NIC
>  Americka 23, 120 00 Praha 2, Czech Republic
>  mailto:[email-masked]    http://nic.cz/
>  tel:+420.222745110       fax:+420.222745112
>  -------------------------------------------
>

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

--001485f199f01a24dc0492593176
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Ondrej,<div><br></div><div>I am not trying to &#39;obstruct&#39; the WG as =
you claim.</div><div><br></div><div>I have been through IETF process many t=
imes over the past 18 years. I have also had a hand in creating many of the=
 alternative standardization routes so I can tell you those pitfalls as wel=
l.</div>
<div><br></div><div><br></div><div>I would have absolutely no problem with =
a WG that is only going to specify additional methods of telling a client t=
hat it can trust a key. Which is what you appear to think that the group is=
 limited to.</div>
<div><br></div><div>My problem is with a proposal that has an implicit cond=
ition that if there is one FP specified in the DNS, then a client MUST rega=
rd the absence of a matching FP to invalidate any other certificate regardl=
ess of whether there is a valid PKIX chain or not.</div>
<div><br></div><div><br></div><div>Now you may not be aware that this is wh=
at some people are proposing but the fact is that (1) they are and (2) they=
 believe that it is a rather important requirement.</div><div><br></div>
<div>This is precisely the type of thing that it is important to get clear =
before you submit the charter. The fact that the prototype code that has be=
en deployed already implements these semantics is rather relevant.</div>
<div><br></div><div><br></div><div>As for the milestones, you want to manag=
e expectations and specify the longest time period the ADs will allow you t=
o get away with. I cannot possibly imagine them insisting on the milestones=
 being shorter than a year.</div>
<div><br></div><div>There are many aspects of IETF process that are complet=
ely out of control of the WG chairs and authors.</div><div><br></div><div><=
br><div class=3D"gmail_quote">On Mon, Oct 11, 2010 at 3:27 AM, Ond=F8ej Sur=
=FD <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">ondrej.sury=
@nic.cz</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">Just to clarify. =A0This group has nothing =
to do with Dan Kaminsky and it&#39;s not based on his work. =A0Neither his =
name nor his presentation was pointed out neither when we did bar-BoF nor w=
hen we started mailing list.<br>

<br>
This group was started on basis of work of earlier IETF contributors as was=
 Simon Josefsson, Jakob Schlyter and others.[1] =A0It was merely meant as a=
 revival of that work after we started having DNSSEC signed root.<br>
<br>
I spoke to different parties and everybody seemed to be working on &quot;so=
mething like this&quot;, and because I didn&#39;t want to have divergence o=
n the market, I tried to concentrate work done into this place. =A0(Even th=
ough I was warned that IETF way is painful and we better keep this outside.=
)<br>

<br>
And Phillip, I would really like to see if you can stop obstructing the wor=
k here by sending tons of emails where you reiterate your ideas again and a=
gain just because you have entirely different idea what this group should b=
e doing. =A0Your ideas about the work for this to-be-WG is that much differ=
ent that you should create your own WG. =A0I wouldn&#39;t mind. But don&#39=
;t try to change this group into something it isn&#39;t and was never meant=
 to be.<br>

<br>
O.<br>
Links:<br>
1. <a href=3D"http://www.ietf.org/mail-archive/web/keyassure/current/msg000=
02.html" target=3D"_blank">http://www.ietf.org/mail-archive/web/keyassure/c=
urrent/msg00002.html</a><div><div></div><div class=3D"h5"><br>
<br>
On 8.10.2010 18:53, Phillip Hallam-Baker wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
At BH, Dan Kaminsky presented a paper where he identified the lack of<br>
standards for issuing DV certificates as a problem and suggested an<br>
alternative scheme based on DNSSEC which would have two purposes:<br>
<br>
1) Enable a domain name owner to validate keys at the DV level<br>
2) Enable a domain name owner to prevent clients that support the<br>
proposed mechanism from trusting certificates that they did not authorize.<=
br>
<br>
<br>
I did not attend BH this year and so when I saw the group formed I<br>
assumed that the only requirement it was intended to address was the<br>
first one.<br>
<br>
This week I have spoken to or otherwise communicated to several of the<br>
draft authors offlist. I have confirmed with them that the purpose of<br>
enabling a domain name owner to prevent use of the certificates is<br>
indeed one of their principal objectives.<br>
<br>
<br>
Now if you want to rule the second purpose out of the charter, that is<br>
fine with me. But the fact remains that the technical complexity of<br>
putting any form of restriction in the client is vastly greater than the<br=
>
complexity of a mandate that is imposed on the issuing CAs.<br>
<br>
Whether or not this group wishes to be a part of the &#39;do not issue&#39;=
<br>
approach, it is a simpler approach and one that offers benefits to both<br>
CAs and to the users of legacy browsers and browsers that choose not to<br>
deploy an enumeration based restriction scheme. And while it can make<br>
use of DNSSEC, it is not dependent on DNSSEC deployment.<br>
<br>
I would see the forum for addressing do-not-issue to be CABForum more<br>
than IETF.<br>
<br>
The reason it is relevant here is because it bears on the same original<br>
requirement and may well pre-empt it to an extent. It is not possible to<br=
>
use the enumeration approach as the basis of do-not-issue for obvious<br>
reasons (can&#39;t take the hash of a cert before it is issued).<br>
<br>
So there is going to be do-not-issue information in the DNS that can<br>
potentially be applied to solve this problem equally well and with a far<br=
>
lower maintenance requirement than this particular scheme.<br>
<br>
--<br>
Website: <a href=3D"http://hallambaker.com/" target=3D"_blank">http://halla=
mbaker.com/</a><br>
<br>
</blockquote>
<br>
<br></div></div><div><div></div><div class=3D"h5">
-- <br>
=A0Ond=F8ej Sur=FD<br>
=A0vedouc=ED v=FDzkumu/Head of R&amp;D department<br>
=A0-------------------------------------------<br>
=A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC<br>
=A0Americka 23, 120 00 Praha 2, Czech Republic<br>
=A0mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">ondrej.su=
[email-masked]</a> =A0 =A0<a href=3D"http://nic.cz/" target=3D"_blank">http://ni=
c.cz/</a><br>
=A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112<br>
=A0-------------------------------------------<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--001485f199f01a24dc0492593176--

Date: Mon, 11 Oct 2010 14:42:27 +0100
From: Tony Finch <[email-masked]>
To: Ilari Liusvaara <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] Charter sent to ADs

On 11 Oct 2010, at 06:14, Ilari Liusvaara <[email-masked]> wrote:
>
> Also, "do not issue" advisories are not enough against rogue (or just plain
> careless[*]!) CAs. Against those you need genuine chaining restrictions

Phill's proposal includes that.

> or exhaustive end-server cert enumeration.

I think this should not be necessary. If you don't trust your CA to issue
certs to the right people, why are you buying certs from them?

Also I am worried that this requires too much complexity to deal with the
many-certs case, and will be bad for performance if the DNS lookup has to
be delayed until the TLS handshake.

I'm inclined to say the client's logic should be to accept the cert if any
of the certs in the chain (including the server cert itself) match any
TLSFP record [0] in the DNS. Then you can either enumerate all the server
certs or rely on CA "do not issue" rules. Sadly you can't have both
because listing a CA cert implicitly authorizes any subordinate cert,
which negates the point of server cert enumeration.

[0] or whatever we settle on

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/

Date: Mon, 11 Oct 2010 09:27:42 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter sent to ADs

Just to clarify.  This group has nothing to do with Dan Kaminsky and 
it's not based on his work.  Neither his name nor his presentation was 
pointed out neither when we did bar-BoF nor when we started mailing list.

This group was started on basis of work of earlier IETF contributors as 
was Simon Josefsson, Jakob Schlyter and others.[1]  It was merely meant 
as a revival of that work after we started having DNSSEC signed root.

I spoke to different parties and everybody seemed to be working on 
"something like this", and because I didn't want to have divergence on 
the market, I tried to concentrate work done into this place.  (Even 
though I was warned that IETF way is painful and we better keep this 
outside.)

And Phillip, I would really like to see if you can stop obstructing the 
work here by sending tons of emails where you reiterate your ideas again 
and again just because you have entirely different idea what this group 
should be doing.  Your ideas about the work for this to-be-WG is that 
much different that you should create your own WG.  I wouldn't mind. 
But don't try to change this group into something it isn't and was never 
meant to be.

O.
Links:
1. http://www.ietf.org/mail-archive/web/keyassure/current/msg00002.html

On 8.10.2010 18:53, Phillip Hallam-Baker wrote:
> At BH, Dan Kaminsky presented a paper where he identified the lack of
> standards for issuing DV certificates as a problem and suggested an
> alternative scheme based on DNSSEC which would have two purposes:
>
> 1) Enable a domain name owner to validate keys at the DV level
> 2) Enable a domain name owner to prevent clients that support the
> proposed mechanism from trusting certificates that they did not authorize.
>
>
> I did not attend BH this year and so when I saw the group formed I
> assumed that the only requirement it was intended to address was the
> first one.
>
> This week I have spoken to or otherwise communicated to several of the
> draft authors offlist. I have confirmed with them that the purpose of
> enabling a domain name owner to prevent use of the certificates is
> indeed one of their principal objectives.
>
>
> Now if you want to rule the second purpose out of the charter, that is
> fine with me. But the fact remains that the technical complexity of
> putting any form of restriction in the client is vastly greater than the
> complexity of a mandate that is imposed on the issuing CAs.
>
> Whether or not this group wishes to be a part of the 'do not issue'
> approach, it is a simpler approach and one that offers benefits to both
> CAs and to the users of legacy browsers and browsers that choose not to
> deploy an enumeration based restriction scheme. And while it can make
> use of DNSSEC, it is not dependent on DNSSEC deployment.
>
> I would see the forum for addressing do-not-issue to be CABForum more
> than IETF.
>
> The reason it is relevant here is because it bears on the same original
> requirement and may well pre-empt it to an extent. It is not possible to
> use the enumeration approach as the basis of do-not-issue for obvious
> reasons (can't take the hash of a cert before it is issued).
>
> So there is going to be do-not-issue information in the DNS that can
> potentially be applied to solve this problem equally well and with a far
> lower maintenance requirement than this particular scheme.
>
> --
> Website: http://hallambaker.com/
>

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

Date: Mon, 11 Oct 2010 09:18:18 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Charter sent to ADs

Phillip,

We spoke to ADs before we sent the charter, and we sent the charter to 
them upon their request (after we ironed out few flaws we had in the 
charter).  And I am quite sure that if such a danger existed, the ADs 
would point that out.

Also we have a recent precedent - the websec WG (former HASMAT) was 
recently approved[1] and it has requested BoF before it was approved for 
Beijing[2].

O.
Links:
1. http://www.ietf.org/mail-archive/web/hasmat/current/msg00123.html
2. http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#Applications

On 8.10.2010 16:26, Phillip Hallam-Baker wrote:
> As I pointed out to Ondrej offlist,
>
> A WG meeting has a minimum notice period that is constrained by legal
> considerations, visa issue requirements and a whole host of travel
> planning issues.
>
> If the group is chartered before Beijing it cannot have a BOF and it
> cannot have a WG meeting either.
>
> So sending the charter to the ADs in advance of the meeting is probably
> a mistake.
>
> The BOF is an opportunity to advertise the work to the wider IETF
> community. It is your single best advertising and marketing opportunity.
>
>
> The charter milestones are completely unrealistic.
>
> Time and again I see WG charters propose unrealistic milestones that are
> then used to constrain the discussion on the basis that there is no time
> to consider other options.
>
> The result is inevitably that the WG takes far longer than it would have
> done had the milestones been realistic.
>
>
> We can come to agreement almost immediately on a proposal to use the DNS
> to validate keys. The tricky part is how to use DNS to constrain key
> validity.
>
> So far the group has only discussed one mechanism that is designed to
> constrain key validity after issue. But that is not the only option, a
> much more powerful and lower impact approach is to provide mechanisms
> that enable domain name owners to avoid mis-issue.
>
> There is really no need or point to scheduling milestones for submission
> of initial drafts. The charter states that there are input drafts, that
> is enough.
>
> As far as work schedules go, I think it is realistic to have a draft
> ready for IESG review that describes a mechanism for key validation and
> for publishing 'do not issue' advice to CAs by March. Describing a
> mechanism for client side enforcement is a lot more involved and
> necessitates consideration of lots of application details. So November
> 2011 is optimistic.
>
> The Shepherding process for turning drafts into standards always takes
> much longer than everyone expects, even people who have done something
> before.
>
> Rushing a proposal through a WG only makes the process take a lot longer
> with much less control.  Issues that could have been disposed of quickly
> end up taking much longer as the IESG raises them and takes much longer
> to dispose of them because they are overloaded.
>
>
> On Fri, Oct 8, 2010 at 4:15 AM, Ondřej Surý <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On 6.10.2010 17:09, Ondřej Surý wrote:
>
>         Hi all,
>
>         since the proposed charter is quite stable for a last week or so
>         with small exceptions of small nits, we (me and Warren) believed
>         that
>         the charter is good to go and that we have a rough consensus on the
>         charter, and so we asked our fellow ADs to process it accordingly to
>         IETF processes, ie. take it to the IESG.
>
>         With some luck that could mean that we can make it to be WG in the
>         time of Beijing meeting.
>
>         I would like to thank all the contributors to the charter, so thank
>         you all.
>
>         Regards, Ondrej
>
>
>     Bill has asked me to post a charter as sent to ADs:
>
>     http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure
>
>     Here's verbatim copy of that page for an evidence:
>
>     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 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 <http://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:
>     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 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
>
>     O.
>
>     --
>       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] <mailto:[email-masked]> http://nic.cz/
>       tel:+420.222745110       fax:+420.222745112
>       -------------------------------------------
>     _______________________________________________
>     keyassure mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/keyassure
>
>
>
>
> --
> Website: http://hallambaker.com/
>

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

Date: Mon, 11 Oct 2010 08:14:56 +0300
From: Ilari Liusvaara <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: Tony Finch <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Charter sent to ADs

On Sun, Oct 10, 2010 at 11:18:51PM -0400, Phillip Hallam-Baker wrote:
> One scheme can certainly do both.
> 
> But changing CA practices when there is a dramatic and immediate advantage
> to the CA is much easier than working out 'fire and forget' rules for client
> side processing and getting them agreed amongst the various IETF groups
> affected.

The only three (present or near term future) ones that spring to mind are:
- HASMAT
- PKIX
- Keyassure (this group)

(I didn't put TLS on that list because authentication issues are AFAIK
outside its scope).

Also, "do not issue" advisories are not enough against rogue (or just plain
careless[*]!) CAs. Against those you need genuine chaining restrictions or
exhaustive end-server cert enumeration.

[*] Remember, X.509 is only as strong as weakest acceptable CA.

-Ilari

Date: Sun, 10 Oct 2010 23:18:51 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Charter sent to ADs

--001485f199f0ce35d704924ed140
Content-Type: text/plain; charset=ISO-8859-1

One scheme can certainly do both.

But changing CA practices when there is a dramatic and immediate advantage
to the CA is much easier than working out 'fire and forget' rules for client
side processing and getting them agreed amongst the various IETF groups
affected.

I tend to think that the proper procedure on this concept would be to have
the IETF assign the RR code but hand as much work as possible on the
practices side to the CABForum where there are lawyers who like writing
rules for that sort of thing.

I certainly want to do client side rules. But realistically we only get one
chance to do those right.

On Sun, Oct 10, 2010 at 6:55 PM, Tony Finch <[email-masked]> wrote:

> On 8 Oct 2010, at 20:32, "Richard L. Barnes" <[email-masked]> wrote:
> >
> > Certainly agree that putting CA certs in the DNS could be a useful
> approach.  It's not the same as a "do not issue" warning.
>
> Phill's proposal said that clients could check the server's cert chain
> against the list of allowed CAs in the DNS. The CA issuing rules help for
> old clients, and provide defence in depth.
>
> Tony.
> --
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
>

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

--001485f199f0ce35d704924ed140
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

One scheme can certainly do both.<div><br></div><div>But changing CA practi=
ces when there is a dramatic and immediate advantage to the CA is much easi=
er than working out &#39;fire and forget&#39; rules for client side process=
ing and getting them agreed amongst the various IETF groups affected.</div>
<div><br></div><div><br></div><div>I tend to think that the proper procedur=
e on this concept would be to have the IETF assign the RR code but hand as =
much work as possible on the practices side to the CABForum where there are=
 lawyers who like writing rules for that sort of thing.</div>
<div><br>I certainly want to do client side rules. But realistically we onl=
y get one chance to do those right.</div><div><br></div><div><br></div><div=
><br><div class=3D"gmail_quote">On Sun, Oct 10, 2010 at 6:55 PM, Tony Finch=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On 8 Oct 2010, at 20:32, =
&quot;Richard L. Barnes&quot; &lt;<a href=3D"mailto:[email-masked]">rbarne=
[email-masked]</a>&gt; wrote:<br>

&gt;<br>
&gt; Certainly agree that putting CA certs in the DNS could be a useful app=
roach. =A0It&#39;s not the same as a &quot;do not issue&quot; warning.<br>
<br>
</div>Phill&#39;s proposal said that clients could check the server&#39;s c=
ert chain against the list of allowed CAs in the DNS. The CA issuing rules =
help for old clients, and provide defence in depth.<br>
<div><div></div><div class=3D"h5"><br>
Tony.<br>
--<br>
f.anthony.n.finch =A0&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&g=
t; =A0<a href=3D"http://dotat.at/" target=3D"_blank">http://dotat.at/</a></=
div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a h=
ref=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
<br>
</div>

--001485f199f0ce35d704924ed140--

From: Tony Finch <[email-masked]>
Date: Sun, 10 Oct 2010 23:55:13 +0100
To: "Richard L. Barnes" <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] Charter sent to ADs

On 8 Oct 2010, at 20:32, "Richard L. Barnes" <[email-masked]> wrote:
>=20
> Certainly agree that putting CA certs in the DNS could be a useful approac=
h.  It's not the same as a "do not issue" warning.

Phill's proposal said that clients could check the server's cert chain again=
st the list of allowed CAs in the DNS. The CA issuing rules help for old cli=
ents, and provide defence in depth.

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/=

Date: Fri, 8 Oct 2010 21:28:50 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Charter sent to ADs

On Fri, 8 Oct 2010, Jeffrey A. Williams wrote:

[Way behind on the list, possible more in-depth message following...]

The goals of the charter seem good in their goals to allow DNSSEC and CA based
authentication systems to coexist.

This is very important. Try to limit the interaction required for either system
so that they work as independantly as possible, without demanding or forbidding each other's
use. Where interaction occurs, try to limit data overlap or data duplication as much
as possible - this points specifically to SSL/TLS.

I should be able to configure my browser with a preference of auth scheme. One over
the other, or both as a minimum.

Bonus points if two machines can do this when connecting offline (eg bluetooth)

Paul

Date: Fri, 8 Oct 2010 16:53:37 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Ilari Liusvaara <[email-masked]>,  "Richard L. Barnes" <[email-masked]>
Cc: Tony Finch <[email-masked]>, "[email-masked]" <[email-masked]>, Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] Charter sent to ADs
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Ilari and all,

-----Original Message-----
>From: Ilari Liusvaara <[email-masked]>
>Sent: Oct 8, 2010 4:20 PM
>To: "Richard L. Barnes" <[email-masked]>
>Cc: Tony Finch <[email-masked]>, Phillip Hallam-Baker <[email-masked]>, "[email-masked]" <[email-masked]>
>Subject: Re: [keyassure] Charter sent to ADs
>
>On Fri, Oct 08, 2010 at 03:32:06PM -0400, Richard L. Barnes wrote:
>> >
>> >The two are not mutually incompatible. The authorized CA
>> >identified in the DNS can be a private CA (which also deals with
>> >the many-certs problem that Phill identified) and in the simplest
>> >case it should also be possible to identify the server's cert
>> >directly.
>> 
>> Certainly agree that putting CA certs in the DNS could be a useful
>> approach.  It's not the same as a "do not issue" warning.
>
>Furthermore, bad enough CAs could just ignore the "do not issue"
>warnings (for instance if coerced). 
>
>Here's (another) way to do that:
>
>TLSCFP (Transport Layer Security Chaining FingerPrint) record.
>
>These come to play if no matching TLSFP record (eithe direct or
>indirect via TLSRQ) is found but usable TLSCFP records are present.
>
>The client will then collect all available (local store and server-
>sent) certificates that match fingerprints in TLSCFP records and
>runs normal PKI validation with collected certificates notionally
>declared to be trust anchors.

  This assumes that the Trust anchor(s) are trustworthy at the time
of this check.
>
>If this check passes, the key is OK from DNS key checking POV. The
>client may or may not trust it at this point (depending on client
>local policy).

Right.  But if the policy is bad at the time given the trustworthyness
of the Trust Anchor(s) relied upon.  Such may not be the case.
>
>If this check fails, the whole DNS key checking fails and client
>SHOULD NOT trust the certificate.

Right again.  However seems to me anyway that this possibility is
minimized by the questionable assumption that at least one Trust
Anchor used for validation is not compermized.  A reasonably good
assumption depending on the before mentioned policy, but not necessarly
an accurate assumption.
>
>
>The reason for excluding certs that match TLSFPs is that one can't
>attack those using bad-CA attacks anyway (since that certificate
>can't be used without server key, legimate server sends good
>certificate chains and compromising the key would compromise
>everything anyway).

Yes but only if the server key is ligitimate or valid which is not
necessarly an assumption that can be made.
>
>-Ilari
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

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

Date: Sat, 9 Oct 2010 00:20:32 +0300
From: Ilari Liusvaara <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: Tony Finch <[email-masked]>, Phillip Hallam-Baker <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Charter sent to ADs

On Fri, Oct 08, 2010 at 03:32:06PM -0400, Richard L. Barnes wrote:
> >
> >The two are not mutually incompatible. The authorized CA
> >identified in the DNS can be a private CA (which also deals with
> >the many-certs problem that Phill identified) and in the simplest
> >case it should also be possible to identify the server's cert
> >directly.
> 
> Certainly agree that putting CA certs in the DNS could be a useful
> approach.  It's not the same as a "do not issue" warning.

Furthermore, bad enough CAs could just ignore the "do not issue"
warnings (for instance if coerced). 

Here's (another) way to do that:

TLSCFP (Transport Layer Security Chaining FingerPrint) record.

These come to play if no matching TLSFP record (eithe direct or
indirect via TLSRQ) is found but usable TLSCFP records are present.

The client will then collect all available (local store and server-
sent) certificates that match fingerprints in TLSCFP records and
runs normal PKI validation with collected certificates notionally
declared to be trust anchors.

If this check passes, the key is OK from DNS key checking POV. The
client may or may not trust it at this point (depending on client
local policy).

If this check fails, the whole DNS key checking fails and client
SHOULD NOT trust the certificate.

The reason for excluding certs that match TLSFPs is that one can't
attack those using bad-CA attacks anyway (since that certificate
can't be used without server key, legimate server sends good
certificate chains and compromising the key would compromise
everything anyway).

-Ilari

From: "Richard L. Barnes" <[email-masked]>
To: Tony Finch <[email-masked]>
Date: Fri, 8 Oct 2010 15:32:06 -0400
Cc: "[email-masked]" <[email-masked]>, Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] Charter sent to ADs

--Apple-Mail-18--978518882
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

>>> Whether or not this group wishes to be a part of the 'do not  
>>> issue' approach, it is a simpler approach and one that offers  
>>> benefits to both CAs and to the users of legacy browsers and  
>>> browsers that choose not to deploy an enumeration based  
>>> restriction scheme. And while it can make use of DNSSEC, it is not  
>>> dependent on DNSSEC deployment.
>>
>> The "do not issue" approach is entirely orthogonal to the point of  
>> this group.  It assumes that commercial CAs are still the entities  
>> asserting the name-key binding.
>>
>> The point of this group is to enable the assertion of name-key  
>> bindings using DNSSEC, so that the domain owner, rather than an  
>> external CA, is the entity asserting the binding.
>
> The two are not mutually incompatible. The authorized CA identified  
> in the DNS can be a private CA (which also deals with the many-certs  
> problem that Phill identified) and in the simplest case it should  
> also be possible to identify the server's cert directly.

Certainly agree that putting CA certs in the DNS could be a useful  
approach.  It's not the same as a "do not issue" warning.

--Richard

--Apple-Mail-18--978518882
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div><blockquote =
type=3D"cite"><div bgcolor=3D"#FFFFFF"><blockquote =
type=3D"cite"><div><blockquote type=3D"cite"><span>Whether or not this =
group wishes to be a part of the 'do not issue' approach, it is a =
simpler approach and one that offers benefits to both CAs and to the =
users of legacy browsers and browsers that choose not to deploy an =
enumeration based restriction scheme. And while it can make use of =
DNSSEC, it is not dependent on DNSSEC =
deployment.</span><br></blockquote><span></span><br><span>The "do not =
issue" approach is entirely orthogonal to the point of this group. =
&nbsp;It assumes that commercial CAs are still the entities asserting =
the name-key binding.</span><br><span></span><br><span>The point of this =
group is to enable the assertion of name-key bindings using DNSSEC, so =
that the domain owner, rather than an external CA, is the entity =
asserting the binding.</span><font class=3D"Apple-style-span" =
color=3D"#000000"><font class=3D"Apple-style-span" =
color=3D"#0023A3"><br></font></font></div></blockquote><span =
class=3D"Apple-style-span" style=3D"-webkit-tap-highlight-color: =
rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, =
192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, =
0.230469); "><br>The two are not mutually incompatible. The authorized =
CA identified in the DNS can be a private CA (which also deals with the =
many-certs problem that Phill identified) and in the simplest case it =
should also be possible to identify the server's cert =
directly.<br></span></div></blockquote><br></div><div>Certainly agree =
that putting CA certs in the DNS could be a useful approach. &nbsp;It's =
not the same as a "do not issue" =
warning.</div><div><br></div><div>--Richard</div><div><br></div><br></body=
></html>=

--Apple-Mail-18--978518882--

From: Tony Finch <[email-masked]>
Date: Fri, 8 Oct 2010 19:41:47 +0100
To: "Richard L. Barnes" <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] Charter sent to ADs

--Apple-Mail-1--981524117
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 8 Oct 2010, at 18:07, "Richard L. Barnes" <[email-masked]> wrote:

>> Whether or not this group wishes to be a part of the 'do not issue' appro=
ach, it is a simpler approach and one that offers benefits to both CAs and t=
o the users of legacy browsers and browsers that choose not to deploy an enu=
meration based restriction scheme. And while it can make use of DNSSEC, it i=
s not dependent on DNSSEC deployment.
>=20
> The "do not issue" approach is entirely orthogonal to the point of this gr=
oup.  It assumes that commercial CAs are still the entities asserting the na=
me-key binding.
>=20
> The point of this group is to enable the assertion of name-key bindings us=
ing DNSSEC, so that the domain owner, rather than an external CA, is the ent=
ity asserting the binding.

The two are not mutually incompatible. The authorized CA identified in the D=
NS can be a private CA (which also deals with the many-certs problem that Ph=
ill identified) and in the simplest case it should also be possible to ident=
ify the server's cert directly.

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/=

--Apple-Mail-1--981524117
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><body bgcolor=3D"#FFFFFF"><div><span class=3D"Apple-style-span" style=3D=
"-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-compositio=
n-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color=
: rgba(77, 128, 180, 0.230469); ">On 8 Oct 2010, at 18:07, "Richard L. Barne=
s" &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:</sp=
an><br></div><div><br></div><div></div><blockquote type=3D"cite"><div><block=
quote type=3D"cite"><span>Whether or not this group wishes to be a part of t=
he 'do not issue' approach, it is a simpler approach and one that offers ben=
efits to both CAs and to the users of legacy browsers and browsers that choo=
se not to deploy an enumeration based restriction scheme. And while it can m=
ake use of DNSSEC, it is not dependent on DNSSEC deployment.</span><br></blo=
ckquote><span></span><br><span>The "do not issue" approach is entirely ortho=
gonal to the point of this group. &nbsp;It assumes that commercial CAs are s=
till the entities asserting the name-key binding.</span><br><span></span><br=
><span>The point of this group is to enable the assertion of name-key bindin=
gs using DNSSEC, so that the domain owner, rather than an external CA, is th=
e entity asserting the binding.</span><font class=3D"Apple-style-span" color=
=3D"#000000"><font class=3D"Apple-style-span" color=3D"#0023A3"><br></font><=
/font></div></blockquote><span class=3D"Apple-style-span" style=3D"-webkit-t=
ap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-col=
or: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77,=
 128, 180, 0.230469); "><br>The two are not mutually incompatible. The autho=
rized CA identified in the DNS can be a private CA (which also deals with th=
e many-certs problem that Phill identified) and in the simplest case it shou=
ld also be possible to identify the server's cert directly.<br></span><div><=
span class=3D"Apple-style-span" style=3D"-webkit-tap-highlight-color: rgba(2=
6, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.=
230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><b=
r><div>Tony.</div>--<div>f.anthony.n.finch &nbsp;&lt;<a href=3D"mailto:dot@d=
otat.at">[email-masked]</a>&gt; &nbsp;<a href=3D"http://dotat.at/"><a href=3D"=
http://dotat.at/">http://dotat.at/</a></a></div></span></div></body></html>=

--Apple-Mail-1--981524117--

From: "Richard L. Barnes" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Oct 2010 13:07:31 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Charter sent to ADs

> Whether or not this group wishes to be a part of the 'do not issue'  
> approach, it is a simpler approach and one that offers benefits to  
> both CAs and to the users of legacy browsers and browsers that  
> choose not to deploy an enumeration based restriction scheme. And  
> while it can make use of DNSSEC, it is not dependent on DNSSEC  
> deployment.

The "do not issue" approach is entirely orthogonal to the point of  
this group.  It assumes that commercial CAs are still the entities  
asserting the name-key binding.

The point of this group is to enable the assertion of name-key  
bindings using DNSSEC, so that the domain owner, rather than an  
external CA, is the entity asserting the binding.

As a side note, objective (2) as you've phrased it is non-sensical.   
Domain owners cannot prevent clients from accepting any certificate.   
The only thing a domain owner can do is make assertions about what  
their servers will do, which the client can use to make validation  
decisions.  Discussion to date has focused on positive assertions like  
"My servers will use this key:...", but one could imagine negative  
assertions as well, of the character "My servers will not use any  
other keys."  As I read it, the current charter allows both of these.   
(And whoever you talked to off-list, I'm imagining that's more like  
what they had in mind than a "do-not-issue" approach.)

--Richard 

Date: Fri, 8 Oct 2010 12:53:24 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter sent to ADs

--0016e65a022254af3804921dd975
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Oct 8, 2010 at 11:58 AM, Richard L. Barnes <[email-masked]> wrote:

> So far the group has only discussed one mechanism that is designed to
>> constrain key validity after issue. But that is not the only option, a much
>> more powerful and lower impact approach is to provide mechanisms that enable
>> domain name owners to avoid mis-issue.
>>
>
>  ...
>
>
>  As far as work schedules go, I think it is realistic to have a draft ready
>> for IESG review that describes a mechanism for key validation and for
>> publishing 'do not issue' advice to CAs by March.
>>
>
> I do not understand what you mean by "avoid mis-issue" or "publishing 'do
> not issue' advice to CAs".  Those phrases doesn't sound like any problem
> that had been discussed previously on this list.

Which is a real problem because that is exactly what the code we are
discussing is designed to prevent.

And I am not at all surprised that you were unaware that this was an
objective as it is not something that I would have expected to be an
objective either and have only discovered gradually.

Let us rewind back to the Black Hat 2010 conference.

At BH, Dan Kaminsky presented a paper where he identified the lack of
standards for issuing DV certificates as a problem and suggested an
alternative scheme based on DNSSEC which would have two purposes:

1) Enable a domain name owner to validate keys at the DV level
2) Enable a domain name owner to prevent clients that support the proposed
mechanism from trusting certificates that they did not authorize.

I did not attend BH this year and so when I saw the group formed I assumed
that the only requirement it was intended to address was the first one.

This week I have spoken to or otherwise communicated to several of the draft
authors offlist. I have confirmed with them that the purpose of enabling a
domain name owner to prevent use of the certificates is indeed one of their
principal objectives.

Now if you want to rule the second purpose out of the charter, that is fine
with me. But the fact remains that the technical complexity of putting any
form of restriction in the client is vastly greater than the complexity of a
mandate that is imposed on the issuing CAs.

Whether or not this group wishes to be a part of the 'do not issue'
approach, it is a simpler approach and one that offers benefits to both CAs
and to the users of legacy browsers and browsers that choose not to deploy
an enumeration based restriction scheme. And while it can make use of
DNSSEC, it is not dependent on DNSSEC deployment.

I would see the forum for addressing do-not-issue to be CABForum more than
IETF.

The reason it is relevant here is because it bears on the same original
requirement and may well pre-empt it to an extent. It is not possible to use
the enumeration approach as the basis of do-not-issue for obvious reasons
(can't take the hash of a cert before it is issued).

So there is going to be do-not-issue information in the DNS that can
potentially be applied to solve this problem equally well and with a far
lower maintenance requirement than this particular scheme.

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

--0016e65a022254af3804921dd975
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 8, 2010 at 11:58 AM, Richard L. Barnes <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
So far the group has only discussed one mechanism that is designed to const=
rain key validity after issue. But that is not the only option, a much more=
 powerful and lower impact approach is to provide mechanisms that enable do=
main name owners to avoid mis-issue.<br>

</blockquote>
<br></div>
=A0...<div class=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
As far as work schedules go, I think it is realistic to have a draft ready =
for IESG review that describes a mechanism for key validation and for publi=
shing &#39;do not issue&#39; advice to CAs by March.<br>
</blockquote>
<br></div>
I do not understand what you mean by &quot;avoid mis-issue&quot; or &quot;p=
ublishing &#39;do not issue&#39; advice to CAs&quot;. =A0Those phrases does=
n&#39;t sound like any problem that had been discussed previously on this l=
ist.</blockquote>
<div><br></div><div>Which is a real problem because that is exactly what th=
e code we are discussing is designed to prevent.</div><div><br></div><div>A=
nd I am not at all surprised that you were unaware that this was an objecti=
ve as it is not something that I would have expected to be an objective eit=
her and have only discovered gradually.=A0</div>
<div><br></div><div>Let us rewind back to the Black Hat 2010 conference.</d=
iv><div><br></div><div><br></div><div>At BH, Dan Kaminsky presented a paper=
 where he identified the lack of standards for issuing DV certificates as a=
 problem and suggested an alternative scheme based on DNSSEC which would ha=
ve two purposes:</div>
<div><br></div><div>1) Enable a domain name owner to validate keys at the D=
V level</div><div>2) Enable a domain name owner to prevent clients that sup=
port the proposed mechanism from trusting certificates that they did not au=
thorize.</div>
<div><br></div><div><br></div><div>I did not attend BH this year and so whe=
n I saw the group formed I assumed that the only requirement it was intende=
d to address was the first one.=A0</div><div><br></div><div>This week I hav=
e spoken to or otherwise communicated to several of the draft authors offli=
st. I have confirmed with them that the purpose of enabling a domain name o=
wner to prevent use of the certificates is indeed one of their principal ob=
jectives.</div>
<div><br></div><div><br></div><div>Now if you want to rule the second purpo=
se out of the charter, that is fine with me. But the fact remains that the =
technical complexity of putting any form of restriction in the client is va=
stly greater than the complexity of a mandate that is imposed on the issuin=
g CAs.</div>
<div><br></div><div>Whether or not this group wishes to be a part of the &#=
39;do not issue&#39; approach, it is a simpler approach and one that offers=
 benefits to both CAs and to the users of legacy browsers and browsers that=
 choose not to deploy an enumeration based restriction scheme. And while it=
 can make use of DNSSEC, it is not dependent on DNSSEC deployment.</div>
<div><br></div><div>I would see the forum for addressing do-not-issue to be=
 CABForum more than IETF.</div><div><br></div><div>The reason it is relevan=
t here is because it bears on the same original requirement and may well pr=
e-empt it to an extent. It is not possible to use the enumeration approach =
as the basis of do-not-issue for obvious reasons (can&#39;t take the hash o=
f a cert before it is issued).</div>
<div><br></div><div>So there is going to be do-not-issue information in the=
 DNS that can potentially be applied to solve this problem equally well and=
 with a far lower maintenance requirement than this particular scheme.=A0</=
div>
</div><br>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallam=
baker.com/</a><br><br>

--0016e65a022254af3804921dd975--

Date: Fri, 8 Oct 2010 17:33:44 +0100
From: Ben Laurie <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter sent to ADs

On 8 October 2010 17:19, Paul Hoffman <[email-masked]> wrote:
> At 11:58 AM -0400 10/8/10, Richard L. Barnes wrote:
>>>So far the group has only discussed one mechanism that is designed to co=
nstrain key validity after issue. But that is not the only option, a much m=
ore powerful and lower impact approach is to provide mechanisms that enable=
 domain name owners to avoid mis-issue.
>>
>> ...
>>
>>>As far as work schedules go, I think it is realistic to have a draft rea=
dy for IESG review that describes a mechanism for key validation and for pu=
blishing 'do not issue' advice to CAs by March.
>>
>>I do not understand what you mean by "avoid mis-issue" or "publishing 'do=
 not issue' advice to CAs". =A0Those phrases doesn't sound like any problem=
 that had been discussed previously on this list.
>
> +1. These sound like topics for a different proposed Working Group, not o=
ne focused on associating a key with a host name.

Agreed.

Date: Fri, 8 Oct 2010 09:19:29 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Charter sent to ADs

At 11:58 AM -0400 10/8/10, Richard L. Barnes wrote:
>>So far the group has only discussed one mechanism that is designed to constrain key validity after issue. But that is not the only option, a much more powerful and lower impact approach is to provide mechanisms that enable domain name owners to avoid mis-issue.
>
> ...
>
>>As far as work schedules go, I think it is realistic to have a draft ready for IESG review that describes a mechanism for key validation and for publishing 'do not issue' advice to CAs by March.
>
>I do not understand what you mean by "avoid mis-issue" or "publishing 'do not issue' advice to CAs".  Those phrases doesn't sound like any problem that had been discussed previously on this list.

+1. These sound like topics for a different proposed Working Group, not one focused on associating a key with a host name.

--Paul Hoffman, Director
--VPN Consortium

From: "Richard L. Barnes" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Oct 2010 11:58:00 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Charter sent to ADs

> So far the group has only discussed one mechanism that is designed  
> to constrain key validity after issue. But that is not the only  
> option, a much more powerful and lower impact approach is to provide  
> mechanisms that enable domain name owners to avoid mis-issue.

  ...

> As far as work schedules go, I think it is realistic to have a draft  
> ready for IESG review that describes a mechanism for key validation  
> and for publishing 'do not issue' advice to CAs by March.

I do not understand what you mean by "avoid mis-issue" or "publishing  
'do not issue' advice to CAs".  Those phrases doesn't sound like any  
problem that had been discussed previously on this list.

--Richard

Date: Fri, 8 Oct 2010 10:26:17 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter sent to ADs

--00163683302a36d07204921bcbc8
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

As I pointed out to Ondrej offlist,

A WG meeting has a minimum notice period that is constrained by legal
considerations, visa issue requirements and a whole host of travel planning
issues.

If the group is chartered before Beijing it cannot have a BOF and it cannot
have a WG meeting either.

So sending the charter to the ADs in advance of the meeting is probably a
mistake.

The BOF is an opportunity to advertise the work to the wider IETF community=
.
It is your single best advertising and marketing opportunity.

The charter milestones are completely unrealistic.

Time and again I see WG charters propose unrealistic milestones that are
then used to constrain the discussion on the basis that there is no time to
consider other options.

The result is inevitably that the WG takes far longer than it would have
done had the milestones been realistic.

We can come to agreement almost immediately on a proposal to use the DNS to
validate keys. The tricky part is how to use DNS to constrain key validity.

So far the group has only discussed one mechanism that is designed to
constrain key validity after issue. But that is not the only option, a much
more powerful and lower impact approach is to provide mechanisms that enabl=
e
domain name owners to avoid mis-issue.

There is really no need or point to scheduling milestones for submission of
initial drafts. The charter states that there are input drafts, that is
enough.

As far as work schedules go, I think it is realistic to have a draft ready
for IESG review that describes a mechanism for key validation and for
publishing 'do not issue' advice to CAs by March. Describing a mechanism fo=
r
client side enforcement is a lot more involved and necessitates
consideration of lots of application details. So November 2011 is
optimistic.

The Shepherding process for turning drafts into standards always takes much
longer than everyone expects, even people who have done something before.

Rushing a proposal through a WG only makes the process take a lot longer
with much less control.  Issues that could have been disposed of quickly en=
d
up taking much longer as the IESG raises them and takes much longer to
dispose of them because they are overloaded.

On Fri, Oct 8, 2010 at 4:15 AM, Ond=F8ej Sur=FD <[email-masked]> wrote:

> On 6.10.2010 17:09, Ond=F8ej Sur=FD wrote:
>
>> Hi all,
>>
>> since the proposed charter is quite stable for a last week or so
>> with small exceptions of small nits, we (me and Warren) believed that
>> the charter is good to go and that we have a rough consensus on the
>> charter, and so we asked our fellow ADs to process it accordingly to
>> IETF processes, ie. take it to the IESG.
>>
>> With some luck that could mean that we can make it to be WG in the
>> time of Beijing meeting.
>>
>> I would like to thank all the contributors to the charter, so thank
>> you all.
>>
>> Regards, Ondrej
>>
>
> Bill has asked me to post a charter as sent to ADs:
>
> http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure
>
> Here's verbatim copy of that page for an evidence:
>
> 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 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:
> 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 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
>
> O.
>
> --
>  Ond=F8ej Sur=FD
>  vedouc=ED v=FDzkumu/Head of R&D department
>  -------------------------------------------
>  CZ.NIC, z.s.p.o.    --    Laborato=F8e 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]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

--00163683302a36d07204921bcbc8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

As I pointed out to Ondrej offlist,<div><br></div><div>A WG meeting has a m=
inimum notice period that is constrained by legal considerations, visa issu=
e requirements and a whole host of travel planning issues.</div><div><br>
</div><div>If the group is chartered before Beijing it cannot have a BOF an=
d it cannot have a WG meeting either.</div><div><br></div><div>So sending t=
he charter to the ADs in advance of the meeting is probably a mistake.</div=
>
<div><br></div><div>The BOF is an opportunity to advertise the work to the =
wider IETF community. It is your single best advertising and marketing oppo=
rtunity.</div><div><br></div><div><br></div><div>The charter milestones are=
 completely unrealistic.=C2=A0</div>
<div><br></div><div>Time and again I see WG charters propose unrealistic mi=
lestones that are then used to constrain the discussion on the basis that t=
here is no time to consider other options.</div><div><br></div><div>The res=
ult is inevitably that the WG takes far longer than it would have done had =
the milestones been realistic.</div>
<div><br></div><div><br></div><div>We can come to agreement almost immediat=
ely on a proposal to use the DNS to validate keys. The tricky part is how t=
o use DNS to constrain key validity.</div><div><br></div><div>So far the gr=
oup has only discussed one mechanism that is designed to constrain key vali=
dity after issue. But that is not the only option, a much more powerful and=
 lower impact approach is to provide mechanisms that enable domain name own=
ers to avoid mis-issue.</div>
<div><br></div><div>There is really no need or point to scheduling mileston=
es for submission of initial drafts. The charter states that there are inpu=
t drafts, that is enough.</div><div><br></div><div>As far as work schedules=
 go, I think it is realistic to have a draft ready for IESG review that des=
cribes a mechanism for key validation and for publishing &#39;do not issue&=
#39; advice to CAs by March. Describing a mechanism for client side enforce=
ment is a lot more involved and necessitates consideration of lots of appli=
cation details. So November 2011 is optimistic.</div>
<div><br></div><div>The Shepherding process for turning drafts into standar=
ds always takes much longer than everyone expects, even people who have don=
e something before.</div><div><br></div><div>Rushing a proposal through a W=
G only makes the process take a lot longer with much less control. =C2=A0Is=
sues that could have been disposed of quickly end up taking much longer as =
the IESG raises them and takes much longer to dispose of them because they =
are overloaded.</div>
<div><br><br><div class=3D"gmail_quote">On Fri, Oct 8, 2010 at 4:15 AM, Ond=
=C5=99ej Sur=C3=BD <span dir=3D"ltr">&lt;<a href=3D"mailto:ondrej.sury@nic.=
cz">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex;">
<div class=3D"im">On 6.10.2010 17:09, Ond=C5=99ej Sur=C3=BD wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
since the proposed charter is quite stable for a last week or so<br>
with small exceptions of small nits, we (me and Warren) believed that<br>
the charter is good to go and that we have a rough consensus on the<br>
charter, and so we asked our fellow ADs to process it accordingly to<br>
IETF processes, ie. take it to the IESG.<br>
<br>
With some luck that could mean that we can make it to be WG in the<br>
time of Beijing meeting.<br>
<br>
I would like to thank all the contributors to the charter, so thank<br>
you all.<br>
<br>
Regards, Ondrej<br>
</blockquote>
<br></div>
Bill has asked me to post a charter as sent to ADs:<br>
<br>
<a href=3D"http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure" target=
=3D"_blank">http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure</a><br>
<br>
Here&#39;s verbatim copy of that page for an evidence:<br>
<br>
Objective:<br>
Specify mechanisms and techniques that allow Internet applications to<br>
establish cryptographically secured communications by using information<br>
distributed through the DNS for discovering and authenticating public<br>
keys which are associated with a service located at a domain name.<br>
<br>
Problem Statement:<br>
Entities on the Internet are usually identified using domain names and<br>
forming a cryptographically secured connection to the entity requires<br>
the entity to authenticate its name. For instance, in HTTPS, a server<br>
responding to a query for &lt;<a href=3D"https://www.example.com" target=3D=
"_blank">https://www.example.com</a>&gt; is expected to<br>
authenticate as &quot;<a href=3D"http://www.example.com" target=3D"_blank">=
www.example.com</a>&quot;. Security protocols such as TLS and<br>
IPsec accomplish this authentication by allowing an endpoint to prove<br>
ownership of a private key whose corresponding public key is somehow<br>
bound to the name being authenticated. As a pre-requisite for<br>
authentication, then, these protocols require a mechanism for bindings<br>
to be asserted between public keys and domain names.<br>
<br>
DNSSEC provides a mechanism for a domain operator to sign DNS<br>
information directly, using keys that are bound to the domain by the<br>
parent domain; relying parties can continue this chain up to any trust<br>
anchor that they accept. In this way, bindings of keys to domains are<br>
asserted not by external entities, but by the entities that operate the<br>
DNS. In addition, this technique inherently limits the scope of any<br>
given entity to the names in zones he controls.<br>
<br>
This working group will develop mechanisms for domain operators to<br>
present bindings between names within their control and public keys, in<br>
such a way that these bindings can be integrity-protected (and thus<br>
shown to be authentically from the domain operator) using DNSSEC and<br>
used as a basis for authentication in protocols that use domain names as<br=
>
identifiers. Possible starting points for these deliverables include<br>
draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and<br>
draft-josefsson-keyassure-tls.<br>
<br>
The mechanisms developed by this group will address bindings between<br>
domain names and keys, allowing flexibility for all key-transport<br>
mechanisms supported by the application protocols addressed (e.g., both<br>
self-signed and CA-issued certificates for use in TLS).<br>
<br>
The group may also create documents that describe how protocol entities<br>
can discover and validate these bindings in the execution of specific<br>
applications. This work would be done in coordination with the IETF<br>
Working Groups responsible for the protocols.<br>
<br>
Milestones:<br>
Nov 2010 =C2=A0 First WG draft of standards-track protocol for using DNS to=
<br>
associate hosts with keys for TLS and DTLS<br>
Jan 2011 =C2=A0 First WG draft of standards-track protocols for using DNS t=
o<br>
associate hosts with IPsec<br>
Jun 2011 =C2=A0 Protocol for using DNS to associate domain names with keys<=
br>
for TLS and DTLS to IESG<br>
Aug 2011 =C2=A0 Protocols for using DNS to associate domain names with keys=
<br>
for IPsec to IESG<br>
Aug 2011 =C2=A0 Recharter<br><font color=3D"#888888">
<br>
O.</font><div><div></div><div class=3D"h5"><br>
-- <br>
=C2=A0Ond=C5=99ej Sur=C3=BD<br>
=C2=A0vedouc=C3=AD v=C3=BDzkumu/Head of R&amp;D department<br>
=C2=A0-------------------------------------------<br>
=C2=A0CZ.NIC, z.s.p.o. =C2=A0 =C2=A0-- =C2=A0 =C2=A0Laborato=C5=99e CZ.NIC<=
br>
=C2=A0Americka 23, 120 00 Praha 2, Czech Republic<br>
=C2=A0mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">ondrej=
[email-masked]</a> =C2=A0 =C2=A0<a href=3D"http://nic.cz/" target=3D"_blank">=
http://nic.cz/</a><br>
=C2=A0tel:+420.222745110 =C2=A0 =C2=A0 =C2=A0 fax:+420.222745112<br>
=C2=A0-------------------------------------------<br>
_______________________________________________<br>
keyassure mailing list<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]<=
/a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--00163683302a36d07204921bcbc8--

Date: Fri, 08 Oct 2010 10:15:12 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Charter sent to ADs

On 6.10.2010 17:09, Ondřej Surý wrote:
> Hi all,
>
> since the proposed charter is quite stable for a last week or so
> with small exceptions of small nits, we (me and Warren) believed that
> the charter is good to go and that we have a rough consensus on the
> charter, and so we asked our fellow ADs to process it accordingly to
> IETF processes, ie. take it to the IESG.
>
> With some luck that could mean that we can make it to be WG in the
> time of Beijing meeting.
>
> I would like to thank all the contributors to the charter, so thank
> you all.
>
> Regards, Ondrej

Bill has asked me to post a charter as sent to ADs:

http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure

Here's verbatim copy of that page for an evidence:

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 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:
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 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

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

Date: Wed, 06 Oct 2010 17:09:58 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: [keyassure] Charter sent to ADs

Hi all,

since the proposed charter is quite stable for a last week or so with 
small exceptions of small nits, we (me and Warren) believed that the 
charter is good to go and that we have a rough consensus on the charter, 
and so we asked our fellow ADs to process it accordingly to IETF 
processes, ie. take it to the IESG.

With some luck that could mean that we can make it to be WG in the time 
of Beijing meeting.

I would like to thank all the contributors to the charter, so thank you all.

Regards,
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
  -------------------------------------------

Date: Tue, 05 Oct 2010 13:36:56 -0500
From: Marsh Ray <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: "Kemp, David P." <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [keyassure] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

On 10/05/2010 11:56 AM, Phillip Hallam-Baker wrote:
>
> Clearly if you have two controls, A and B and BOTH must be compromised,
> the system is less likely to be compromised than either A or B.
>
> But the design approach taken in the Hoffman et. al. proposal is that
> publication of a DNSSEC assurance for a cert disables verification on
> the PKIX chain unless the 'preferences' flag is set. This flag will be
> buried in a base64 encoded sub-field encoding.
>
> In practice only a proportion of clients will deploy this mechanism. So
> if A is PKIX and B is DNSSEC, it will be possible for an attacker to
> succeed if either A or B is compromised in one configuration and if
> either A or A and B is compromised in the other.

+1

In practice, only a proportion of servers will deploy this mechanism 
until such time as Firefox and Chrome are willing to shut them off.

I've read that because DNSSEC records are large, some resolvers cannot 
pass them on. Testing a few months ago indicated that it worked on 
something like 4 out of 5 internet connections I tried it on. But it's 
quite possible that there are little wifi-router-firewall boxes in 
millions of homes that don't expect such large packets on port 53.

So clients will have to continue to operate in the absence of DNSSEC 
information for the forseeable future.

It's also reasonable to suspect that an attacker (who in our analysis is 
already presumed to have a fraudulent server cert and the ability to 
make use of it, i.e., MitM) would also be able to downgrade DNS to strip 
out this "preferences" flag (if some intermediate box isn't doing it 
already).

Therefore the attacker may be able to choose to attack the via a DNSSEC 
problem (e.g., a website vuln at the site's DNS registrar) or via PKI 
(e.g., a rouge sub-CA). So the attack surface is, in fact, increased.

Unless I'm missing something about how DNSSEC prevents downgrade 
attacks, which is quite possible.

> People seem to be confusing the security of the cryptographic protocols
> with the security of the infrastructures that support them. The weakest
> link in any competently designed security scheme is people and
> processes.

Perhaps only because security designers have successfully washed their 
hands of the harder part of the problem?

> The PKIX infrastructure has been operating as a security
> infrastructure for 15 years, its flaws are reasonably well understood at
> this point.

That's a very nice way of saying it.

I would have said it this way:

     IT SUCKS!!!!

The fact that the national telephone company of Qwertystan can delegate 
a sub-CA that can delegate a sub-CA that can issue a certificate which 
enables the MitM of the connection between my notebook and my company's 
VPN server is a scandal. If anyone had ever proposed such a scheme to 
people who weren't already steeped in the status quo, they'd be laughed 
out of their industry.

> DNS on the other hand is a non-security infrastructure that
> people appear to want to immediately co-opt to duplicate functions of PKIX.

Rather than wanting to co-opt or duplicate the current PKI scheme, it 
may be that people are simply eager to rid themselves of it.

Not saying it's perfect, I honestly haven't looked into it very deeply, 
but DNSSEC holds a lot of promise:

1. It builds on top of DNS, which is reasonably mature.

2. It was designed for actual security with knowledge of modern attacks 
and the benefit of hindsight.

3. It was designed at all, rather than simply evolving to enable various 
sets of business deals.

4. It roots to one entity is ostensibly neutral and non-profit. They 
have a track record which can be evaluated. They largely own DNS anyway.

5. Domain holders already understand the need to handle their domain 
name registrations as super-critical assets.

6. It appears to delegate more control to the domain holder to define 
and authenticate his own data. He doesn't have to deal with weird "per 
server licensing" (whatever that means) agreements.

7. It appears to reduce or eliminate some recurring fees associated with 
server authentication.

Of course, this list leaves out anything bad about it. Possibly, it's 
worse on balance.

> "What could possibly go wrong"

Lots, particularly during the transition period when parallel systems 
must be trusted.

Which is why such a proposal needs a lot of thinking and real-world testing.

Which is why it would have been better for it to have been proposed earlier.

> Given that the problem that instigated this proposal is mis-issue of a
> certificate. It would appear to me that we should look at deploying
> controls that reduce the probability of mis-issue of a certificate

It's not a question of probability, it's the option of the attacker. If 
you have something worth protecting, you need to be defending against a 
targeted attack. The attacker may or may not have the capability to 
obtain a usable private key, but if he can, he can be expected to use 
it. So it's not a question of "probability if" but of "who", i.e., who 
are the attackers I wish to defend against.

There are may of users of the technology who do not desire to trust (or 
actively mistrust) many of the entities controlling CAs.

> before we rush to deploy a completely new validation scheme for
> certificates in the six month timescale being proposed in this charter.
 >
> In particular, it would be rather useful to have controls of the form:
>
> * Certificates only valid if issued into a certificate chain with
> specified properties
> * Obtain additional authentication according to protocol X and key Y.

Anything limiting the number and scope of CAs would be an improvement.

But such improvements could have been implemented at any time 
previously, yet they were not. Maybe the prospect of DNSSEC replacing it 
will provide motivation for PKI to improve. But by then the train may 
already be rolling.

- Marsh

Date: Tue, 5 Oct 2010 10:57:18 -0700
To: "Carl Wallace" <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] usable certificate association?

At 1:34 PM -0400 10/5/10, Carl Wallace wrote:
> > >If the client
>> >receives two associations but does not understand the hash algorithm
>> in
>> >either, does it have 0 usable associations and continue, or does it
>> fail
>> >with access denied because it has no match?
>>
>> It has 0 usable associations and continues:
>>    If a certificate association contains a hash type that is not
>>    understood by the TLS client, that certificate association MUST be
>>    completely ignored.
>>
>
>This is what I suspected was meant.  It would be more clear if the
>"completely ignored" phrase was replaced with something like "marked as
>unusable" to tie the two steps together. 

Good suggestion; done.

>Geoff's suggestion regarding
>the hash algorithm to use could make this OBE.

They work together well.

--Paul Hoffman, Director
--VPN Consortium

Date: Tue, 5 Oct 2010 10:42:30 -0700
To: Geoff Beier <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt

At 1:18 PM -0400 10/5/10, Geoff Beier wrote:
>On Mon, Oct 4, 2010 at 19:42, Paul Hoffman <[email-masked]> wrote:
>>>A URL for this Internet-Draft is:
>>>http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-03.txt
>>
> >
>>    If a certificate association contains a hash type that is not
>>   understood by the TLS client, that certificate association MUST be
>>   completely ignored.
>
>This situation could be avoided entirely by requiring that the hash
>type be the same as the hash used to produce the signature over the
>CERT RR in question. Since the signature must be verified before the
>association is processed, no client could get this far without
>supporting the hash type.

Good point. We will suggest this in the next draft.

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Date: Tue, 5 Oct 2010 13:34:11 -0400
From: "Carl Wallace" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>, <[email-masked]>
Subject: Re: [keyassure] usable certificate association?

> >If the client
> >receives two associations but does not understand the hash algorithm
> in
> >either, does it have 0 usable associations and continue, or does it
> fail
> >with access denied because it has no match?
>=20
> It has 0 usable associations and continues:
>    If a certificate association contains a hash type that is not
>    understood by the TLS client, that certificate association MUST be
>    completely ignored.
>=20

This is what I suspected was meant.  It would be more clear if the
"completely ignored" phrase was replaced with something like "marked as
unusable" to tie the two steps together.  Geoff's suggestion regarding
the hash algorithm to use could make this OBE.

Date: Tue, 5 Oct 2010 08:53:11 -0700
To: Ilari Liusvaara <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt

At 4:43 AM +0300 10/5/10, Ilari Liusvaara wrote:
>On Mon, Oct 04, 2010 at 04:42:04PM -0700, Paul Hoffman wrote:
>> >A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> >	Filename        : draft-hoffman-keys-linkage-from-dns-03.txt
>
>> "The TLSRQ certificate type has a certificate body with a single octet
>> of 0.  The TLSFP certificate type is TBD2."
>
>Do you mean "The TLSRQ certificate type is TBD2."?

Yes, thanks!

--Paul Hoffman, Director
--VPN Consortium

Date: Tue, 5 Oct 2010 10:30:45 -0700
To: "Carl Wallace" <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] usable certificate association?

At 7:22 AM -0400 10/5/10, Carl Wallace wrote:
>In section 3, what is a "usable certificate association"? 

On that the TLS client is able to understand.

>If the client
>receives two associations but does not understand the hash algorithm in
>either, does it have 0 usable associations and continue, or does it fail
>with access denied because it has no match?

It has 0 usable associations and continues:
   If a certificate association contains a hash type that is not
   understood by the TLS client, that certificate association MUST be
   completely ignored.

>  I assume that a different
>client that receives the same two associations but does not understand
>one and the other does not match should fail with access denied.

Correct.

>
>A few nits...
>
>In the first paragraph of the Introduction, change "the trust anchor" to
>"a trust anchor" and change "perform correct validation on" to
>"successfully validate".

Yep.

>In section 2, it'd be nice to have an example that enumerates multiple
>certificates to support the new text on exclusion vs. enumeration.

Added.

>Also in section 3, change "it process TLS" to "it processes TLS".

Done.

Thanks!

--Paul Hoffman, Director
--VPN Consortium

From: Geoff Beier <[email-masked]>
Date: Tue, 5 Oct 2010 13:18:33 -0400
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt

On Mon, Oct 4, 2010 at 19:42, Paul Hoffman <[email-masked]> wrote:
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-03.txt
>
>
>    If a certificate association contains a hash type that is not
>   understood by the TLS client, that certificate association MUST be
>   completely ignored.

This situation could be avoided entirely by requiring that the hash
type be the same as the hash used to produce the signature over the
CERT RR in question. Since the signature must be verified before the
association is processed, no client could get this far without
supporting the hash type.

Regards,

Geoff

Sender: [email-masked]
Date: Tue, 5 Oct 2010 10:23:45 -0400
From: Adam Langley <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: [email-masked], Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

On Tue, Oct 5, 2010 at 7:15 AM, Tony Finch <[email-masked]> wrote:
>> Once the necessary record is allocated, a proposal is made to CABForum to
>> require all member CAs to verify every cert against these DNS records before
>> issue. I believe that there should be a very high degree of voluntary
>> compliance since it is a check that can be automated.

Yes, this would be a useful incentive to adoption. However, we're a
ways off having a proposal solid enough for this yet.

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

Content-class: urn:content-classes:message
Date: Tue, 5 Oct 2010 07:22:15 -0400
From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Subject: [keyassure] usable certificate association?

In section 3, what is a "usable certificate association"?  If the client
receives two associations but does not understand the hash algorithm in
either, does it have 0 usable associations and continue, or does it fail
with access denied because it has no match?  I assume that a different
client that receives the same two associations but does not understand
one and the other does not match should fail with access denied.

A few nits...

In the first paragraph of the Introduction, change "the trust anchor" to
"a trust anchor" and change "perform correct validation on" to
"successfully validate".

In section 2, it'd be nice to have an example that enumerates multiple
certificates to support the new text on exclusion vs. enumeration.

Also in section 3, change "it process TLS" to "it processes TLS".

Date: Tue, 5 Oct 2010 12:15:59 +0100
From: Tony Finch <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

Moving this to the keyassure mailing list. It's probably also on topic for
pkix but i'm not subscribed there.

On Mon, 4 Oct 2010, Phillip Hallam-Baker wrote:
>
> The way I see this working is that each CA would publish a record that
> customers could publish in their DNS zone to state that other CAs should not
> issue certs. This would have the Digest of either the root key or an
> intermediate cert.

This could presumably also cover a private CA cert or a self-signed
certificate that is being used without any chain.

> Once the necessary record is allocated, a proposal is made to CABForum to
> require all member CAs to verify every cert against these DNS records before
> issue. I believe that there should be a very high degree of voluntary
> compliance since it is a check that can be automated.
>
> After a short interval the mechanism is made mandatory. The browser and
> platform providers have the necessary tools to achieve this. They can
> require the checks to be specified in the annual WebTrust audit which means
> that every cert would have to be in compliance within a year.
>
> Non compliant certificates would be detected as a matter of course by the
> various companies who have reason to crawl the Web and look at SSL certs.
>
> Note that my approach does not require client implementation to be
> effective, but allows for client implementation if this is considered
> desirable and is equally effective as a means of client side enforcement.

I like this dual approach a lot.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

Date: Tue, 5 Oct 2010 04:43:13 +0300
From: Ilari Liusvaara <[email-masked]>
To: Paul Hoffman <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt

On Mon, Oct 04, 2010 at 04:42:04PM -0700, Paul Hoffman wrote:
> >A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >	Filename        : draft-hoffman-keys-linkage-from-dns-03.txt

> "The TLSRQ certificate type has a certificate body with a single octet
> of 0.  The TLSFP certificate type is TBD2."

Do you mean "The TLSRQ certificate type is TBD2."?

-Ilari

Date: Mon, 4 Oct 2010 16:42:04 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>	Title           : Using Secure DNS to Associate Certificates with Domain Names For TLS
>	Author(s)       : P. Hoffman, et al.
>	Filename        : draft-hoffman-keys-linkage-from-dns-03.txt
>	Pages           : 13
>	Date            : 2010-10-04
>
>TLS and DTLS use certificates for authenticating the server.  Users
>want their applications to verify that the certificate provided by
>the TLS server is in fact associated with the domain name they
>expect.  Instead of trusting a certificate authority to have made
>this association correctly, the user might instead trust the
>authoritative DNS server for the domain name to make that
>association.  This document describes how to use secure DNS to
>associate the TLS server's certificate with the the intended domain
>name.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-03.txt

The new draft has a slew of changes (listed near the end) that were suggested by many people on this list.

Comments are appreciated, but we would prefer that discussion of this group becoming an IETF WG be considered much higher priority, given that we don't know what the first draft of the WG document will be.

--Paul Hoffman, Director
--VPN Consortium

Date: Mon, 4 Oct 2010 15:18:16 -0400
From: Andrew Sullivan <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: Tony Finch <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked], Marsh Ray <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With	DNSSEC
Reply-To: [email-masked]

On Sun, Oct 03, 2010 at 11:14:23AM -0400, Phillip Hallam-Baker wrote:
> What is actually being proposed is to replace the fifteen year established
> system of CAs with a new scheme starting in November.

[. . .]

> I really don't think that we want to replace the existing infrastructure a
> new PKI designed by people who claim not to understand the issues involved.
> As the proposers of this scheme have done repeatedly.

Suppose all of that is true (and I think it's a gross
misrepresentation of the situation, but never mind that), so what?
Presumably, if this new PKI sucks as much as you say it does, nobody
will use it, and no harm will come.  If it's a kind of snake oil that
appeals to the clueless (i.e. it sucks as much as you say it does, but
it's jumped up and marketed in a way that lures people who don't know
any better), then it will have some spectacular failure and everyone
will thenceforth avoid it.  So what's the problem, even if things are
as bad as you say?

Also, why isn't this on the list devoted to this discussion (followup set)?

A

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

Date: Sat, 2 Oct 2010 08:47:20 -0700
To: Scott Schmit <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Latest spin at the chater...

At 11:26 PM -0400 10/1/10, Scott Schmit wrote:
>On Thu, Sep 30, 2010 at 08:06:00PM -0400, Warren Kumari wrote keyassure:
>> So, please have another look at the charter and hopefully you will
> > find it acceptable to you:
> > http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure
>
>Looking at the deliverables, I see an asymmetry:
>> 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 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
>                 ^^^^^
>
>Is this deliberate?

Er, no, it was a mistake. Now fixed.

>If I understand the latter two correctly, the intent
>is that the Jun/Aug deliverables are final RFCs of the drafts put out in
>Nov/Jan.

Correct.

>The other thing is that I'm not a big believer in special cases unless
>they're really necessary, and I don't quite understand why TLS/DTLS
>warrants a special case. I would have thought that we'd explain the
>basic mechanism, and then appropriate protocol WGs (or this WG) would
>explain how to leverage the mechanism in follow-on RFCs. Otherwise
>you're setting yourself up for a maintenance nightmare of
>almost-the-same mechanisms.

Can you explain more? The drafts done so far show that most of the protocol work is in specifying the DNS part. For example, the "change" to TLS is simply "trust this cert without validating, unless you want to validate anyway". It would be similar for IPsec, although IPsec is quite different because of the many different types of authentication mechanisms that need to be shown in and out of scope.

>If the thought is that the TLS/DTLS use cases are somehow more complex
>than average, then maybe we should be laying out the requirements and
>constraints first...

At least for me, I didn't choose it because of its complexity, but in fact the opposite: the new protocol makes almost no changes to TLS processing.

--Paul Hoffman, Director
--VPN Consortium

Date: Sat, 2 Oct 2010 00:07:40 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Latest spin at the chater...

--001485f28010ce279704919a7369
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Oct 1, 2010 at 1:54 PM, Warren Kumari <[email-masked]> wrote:

>
>
>> That is why I do not want the charter to be tied to any specific approach,
>> mine included.
>>
>>
>> The point I was trying to make was that forced to chose between a
>> certificate type that works for TLS+IPSEC+S/MIME+SSH and one that works for
>> X.509+PGP+SPKI, I would choose the first, i.e. we would have:
>>
>> CERT APKIX ....
>> CERT APGP ....
>> CERT ASPKI ....
>>
>> But that is if I am forced to choose. I would prefer
>>
>> CERT ASSERT 0 0 <AlgID> <CertID> <Digest>
>>
>> Which is completely general.
>>
>
> Can you please try draft text that explains that in a short and concise and
> *specific* manner?
>
> We keep coming back to the "security policy" bit, and it seems as though A:
> most of the participant have a different view than yours, B: your definition
> is vague and / or changing and / or  C: poorly defined / overly broad....

Please read your own draft that your name is on before accusing others of
being vague or confusing. You will find that the certificate enumeration
semantics that you claim to be the main point are never actually explained
directly.

Are you honestly confused by my comments on your spec or are you as confused
by the document you put your name on as I was until I spent several weeks
working out what it says?

Where do I mention security policy in the foregoing paragraph you are
commenting on? The answer is that I don't because I am only addressing the
fact that you have a peculiar and unexplained fixation with having a spec
that covers all known certificate types yet arbitrarily separates TLS
protocol handling from all others.

None of the authors of the draft have bothered to explain this rationale.

The fixation with support for multiple cert types is despite the fact that
SPKI concluded in 1999 and has never progressed beyond EXPERIMENTAL and the
only other cert format of relevance is OpenPGP. While support for multiple
certificate types might be arguably 'nice to have' it is hardly as
significant as support for multiple protocols in a consistent fashion.

No other key assurance format I know of has this peculiar distinction that
you are attempting to foist on us and never bother to explain. Instead you
use the tactics of agenda denial against me.

Please explain to us just why you think TLS should be handled as a special
case in the protocol.

Note that it is perfectly OK to have a mechanism that is general and only
give a detailed explanation for TLS. But that is not what is being proposed
here. What you are proposing is to do a one off for using TLS with any
certificate type and then do other protocols.

The CERT slot is for certificate type not protocol type. You do owe us an
explanation for that approach.

So far none of you have ever deigned to justify a single one of your design
decisions. Instead you have attempted to avoid engagement by claiming not to
understand any of the points being made. Then you declare that consensus in
the group is not to make any change and carry on as before.

What I do not want is for these decisions to be made in the charter.
>>
>
> Oh, but what we REALLY don't want is to have a charter that is so broad
> that:
> A: It never gets agreed to (which is what is happening here -- we have been
> trying to limit the scope, but have slowly increased it to try accommodate
> your suggestions and views).
> B: the working group gets bogged down (like the mailing list has been) and
> forward process is thwarted.
>

The question that the IESG is asking is not 'is the charter too broad' it is
'is the WG likely to finish anything worthwhile'.

So responding to every design query by claiming not to understand the
question is not exactly a good tactic if you want to give the ADs confidence
in the WG ability to deliver.

The approach that you appear to have been advised to follow here is to avoid
engagement on the technical issues at all costs and just stick to the party
line.

I think that before you continue much further that you should consult an
alternative expert on IETF WG strategy. I think that the advice you get back
will be surprisingly different to the advice you have been receiving to
date.

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

--001485f28010ce279704919a7369
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Fri, Oct 1, 2010 at 1:54 PM, Warren K=
umari <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">warren@kum=
ari.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im"><br></div><div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
That is why I do not want the charter to be tied to any specific approach, =
mine included.<br>
<br>
<br>
The point I was trying to make was that forced to chose between a certifica=
te type that works for TLS+IPSEC+S/MIME+SSH and one that works for X.509+PG=
P+SPKI, I would choose the first, i.e. we would have:<br>
<br>
CERT APKIX ....<br>
CERT APGP ....<br>
CERT ASPKI ....<br>
<br>
But that is if I am forced to choose. I would prefer<br>
<br>
CERT ASSERT 0 0 &lt;AlgID&gt; &lt;CertID&gt; &lt;Digest&gt;<br>
<br>
Which is completely general.<br>
</blockquote>
<br></div>
Can you please try draft text that explains that in a short and concise and=
 *specific* manner?<br>
<br>
We keep coming back to the &quot;security policy&quot; bit, and it seems as=
 though A: most of the participant have a different view than yours, B: you=
r definition is vague and / or changing and / or =A0C: poorly defined / ove=
rly broad....</blockquote>
<div><br></div><div>Please read your own draft that your name is on before =
accusing others of being vague or confusing. You will find that the certifi=
cate enumeration semantics that you claim to be the main point are never ac=
tually explained directly.=A0</div>
<div><br></div><div>Are you honestly confused by my comments on your spec o=
r are you as confused by the document you put your name on as I was until I=
 spent several weeks working out what it says?</div><div><br></div><div>
<br></div><div>Where do I mention security policy in the foregoing paragrap=
h you are commenting on? The answer is that I don&#39;t because I am only a=
ddressing the fact that you have a peculiar and unexplained fixation with h=
aving a spec that covers all known certificate types yet arbitrarily separa=
tes TLS protocol handling from all others.</div>
<div><br></div><div>None of the authors of the draft have bothered to expla=
in this rationale.=A0</div><div><br></div><div><br></div><div>The fixation =
with support for multiple cert types is=A0despite the fact that SPKI conclu=
ded in 1999 and has never progressed beyond EXPERIMENTAL and the only other=
 cert format of relevance is OpenPGP. While support for multiple certificat=
e types might be arguably &#39;nice to have&#39; it is hardly as significan=
t as support for multiple protocols in a consistent fashion.</div>
<div><br></div><div>No other key assurance format I know of has this peculi=
ar distinction that you are attempting to foist on us and never bother to e=
xplain. Instead you use the tactics of agenda denial against me.</div><div>
<br></div><div><br></div><div>Please explain to us just why you think TLS s=
hould be handled as a special case in the protocol.</div><div><br></div><di=
v>Note that it is perfectly OK to have a mechanism that is general and only=
 give a detailed explanation for TLS. But that is not what is being propose=
d here. What you are proposing is to do a one off for using TLS with any ce=
rtificate type and then do other protocols.</div>
<div><br></div><div>The CERT slot is for certificate type not protocol type=
. You do owe us an explanation for that approach.</div><div><br></div><div>=
<br></div><div>So far none of you have ever deigned to justify a single one=
 of your design decisions. Instead you have attempted to avoid engagement b=
y claiming not to understand any of the points being made. Then you declare=
 that consensus in the group is not to make any change and carry on as befo=
re.</div>
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D=
"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">What I do not want is for these decisions to=
 be made in the charter.<br>
</blockquote>
<br></div>
Oh, but what we REALLY don&#39;t want is to have a charter that is so broad=
 that:<br>
A: It never gets agreed to (which is what is happening here -- we have been=
 trying to limit the scope, but have slowly increased it to try accommodate=
 your suggestions and views).<br>
B: the working group gets bogged down (like the mailing list has been) and =
forward process is thwarted.<br></blockquote><div><br></div><div>The questi=
on that the IESG is asking is not &#39;is the charter too broad&#39; it is =
&#39;is the WG likely to finish anything worthwhile&#39;.=A0</div>
<div><br></div><div>So responding to every design query by claiming not to =
understand the question is not exactly a good tactic if you want to give th=
e ADs confidence in the WG ability to deliver.=A0</div><div><br></div><div>
The approach that you appear to have been advised to follow here is to avoi=
d engagement on the technical issues at all costs and just stick to the par=
ty line.=A0</div><div><br></div><div>I think that before you continue much =
further that you should consult an alternative expert on IETF WG strategy. =
I think that the advice you get back will be surprisingly different to the =
advice you have been receiving to date.</div>
<div><br></div><div><br></div></div>-- <br>Website: <a href=3D"http://halla=
mbaker.com/">http://hallambaker.com/</a><br><br>

--001485f28010ce279704919a7369--

Date: Fri, 1 Oct 2010 23:26:45 -0400
From: Scott Schmit <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [keyassure] Latest spin at the chater...

On Thu, Sep 30, 2010 at 08:06:00PM -0400, Warren Kumari wrote keyassure:
> So, please have another look at the charter and hopefully you will
> find it acceptable to you:
> http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure

Looking at the deliverables, I see an asymmetry:
> 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 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
                 ^^^^^

Is this deliberate? If I understand the latter two correctly, the intent 
is that the Jun/Aug deliverables are final RFCs of the drafts put out in 
Nov/Jan.

The other thing is that I'm not a big believer in special cases unless 
they're really necessary, and I don't quite understand why TLS/DTLS 
warrants a special case. I would have thought that we'd explain the
basic mechanism, and then appropriate protocol WGs (or this WG) would
explain how to leverage the mechanism in follow-on RFCs. Otherwise
you're setting yourself up for a maintenance nightmare of
almost-the-same mechanisms.

If the thought is that the TLS/DTLS use cases are somehow more complex
than average, then maybe we should be laying out the requirements and
constraints first...

Date: Fri, 1 Oct 2010 21:38:50 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Zack Weinberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Potential benefits of keyassure

--0016e6546d9e87a82e0491985f4d
Content-Type: text/plain; charset=ISO-8859-1

I think it good that people are starting to think in terms of the deployment
incentive.

While it is true that yet-another-mechanism for binding keys to domain names
has limited utility by itself, that does not mean that the only use for
binding keys to domain names is the one hidden in in
hoffman-keys-linkage-from-dns or that this is the best way to achieve the
stated goals.

If Google wishes to eliminate weak CAs from their browser then they can do
that tomorrow. They decide who goes on the list, if they are not confident
in the CPS of any of them they should remove the roots.

My preferred approach would be for them to eliminate all user interface
elements for all certs validated at DV or bellow. The browser would accept
self signed, DV and DNSSEC validated keys regardless of source and turn on
TLS without any user notification at all in the primary chrome.

Somehow, I don't think they are going to do that quite yet. But I think they
might if we could get to the position where 90% of Web traffic was encrypted
and insecurity was now the default.

To get to that point, it is necessary to make it possible for any site to
offer an automatic, transparent upgrade to use TLS without additional
out-of-pocket cost.

Just because you can't think of a use for DNSSEC validated keys without the
cert enumeration semantics does not mean that no such uses exist.

--0016e6546d9e87a82e0491985f4d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think it good that people are starting to think in terms of the deploymen=
t incentive.
<div><br></div><div>While it is true that yet-another-mechanism for binding=
 keys to domain names has limited utility by itself, that does not mean tha=
t the only use for binding keys to domain names is the one hidden in in hof=
fman-keys-linkage-from-dns or that this is the best way to achieve the stat=
ed goals.=A0</div>
<div><br></div><div><br></div><div>If Google wishes to eliminate weak CAs f=
rom their browser then they can do that tomorrow. They decide who goes on t=
he list, if they are not confident in the CPS of any of them they should re=
move the roots.</div>
<div><br></div><div>My preferred approach would be for them to eliminate al=
l user interface elements for all certs validated at DV or bellow. The brow=
ser would accept self signed, DV and DNSSEC validated keys regardless of so=
urce and turn on TLS without any user notification at all in the primary ch=
rome.=A0</div>
<div><br></div><div><br></div><div>Somehow, I don&#39;t think they are goin=
g to do that quite yet. But I think they might if we could get to the posit=
ion where 90% of Web traffic was encrypted and insecurity was now the defau=
lt.</div>
<div><br></div><div>To get to that point, it is necessary to make it possib=
le for any site to offer an automatic, transparent upgrade to use TLS witho=
ut additional out-of-pocket cost.</div><div><br></div><div><br></div><div>
Just because you can&#39;t think of a use for DNSSEC validated keys without=
 the cert enumeration semantics does not mean that no such uses exist.</div=
>

--0016e6546d9e87a82e0491985f4d--

Content-class: urn:content-classes:message
Date: Fri, 1 Oct 2010 21:32:30 -0400
From: "Carl Wallace" <[email-masked]>
To: "Zack Weinberg" <[email-masked]>, "Matt McCutchen" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Potential benefits of keyassure

Date: Fri, 1 Oct 2010 17:46:19 -0700
To: Phillip Hallam-Baker <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Moving policy to a different WG

At 8:24 PM -0400 10/1/10, Phillip Hallam-Baker wrote:
>I am agnostic on the question of number of WGs.

Sounds good. I have removed the policy discussion from the proposed charter at <>.

Please get a mailing list for the policy work set up. If the ADs don't mint you one @ietf.org (but they should), I'm happy to host it at VPNC (because there could be some effect on IPsec) or you can host one at Comodo or something. Be sure to tell this list when it is up and happening.

This split should let both sets of work move forwards more expeditiously.

--Paul Hoffman, Director
--VPN Consortium

Sender: [email-masked]
Date: Fri, 1 Oct 2010 17:36:48 -0700
From: Zack Weinberg <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Potential benefits of keyassure

On Fri, Oct 1, 2010 at 4:30 PM, Matt McCutchen <[email-masked]> wro=
te:
> On Fri, 2010-10-01 at 14:33 -0700, Zack Weinberg wrote:
>> This is my personal opinion, and only applies to keys used for HTTPS:
>> I don't think being able to make that positive statement via the DNS
>> is useful by itself. =C2=A0All it does (I think, anyway) is provide an
>> alternative to DV certs.
>
> Right, and one that supports secure delegation. =C2=A0PKIX supports
> delegation via name constraints, but they are unsupported in some
> popular clients and insecure in others that accept the subject common
> name as a DNS name without applying the constraints. =C2=A0One could fix =
the
> PKIX clients, but I suspect that most people who care about secure
> delegation will just switch to DNSSEC where it is already working.

But what good does secure delegation do you in the absence of
exclusivity assertions?  Someone can still come along with a cert they
shouldn't have, courtesy Jim-Bob's Bait Shop and CA, and without an
exclusivity assertion, the browser has no way of knowing it shouldn't
accept it.

(To be honest, though, I'm not sure I know what you mean by secure delegati=
on?)

>> Exclusivity assertions, though, *do* buy you a real security
>> increment: safety against corrupt or coerced CAs issuing rogue
>> certificates,
>
> This is all true. =C2=A0But note that DNSSEC trust anchors are not immune=
 to
> corruption or coercion either, so it may be worth locally configuring
> exclusive trust anchors for high-value zones with which one has a
> relationship.

As a browser vendor (let me be specific: until this past August I
worked for Mozilla Co., and I am still involved in the project) I am
running on the assumption that local configuration of trust anchors
occurs with probability zero.

>> and against blatantly fake certs that users click
>> through anyway. =C2=A0Those (particularly the latter) are real-world
>> problems that browser vendors would love to have immediate-term
>> solutions to.
>
> You're supposing that browsers would not allow users to override an
> exclusive certificate list in DNSSEC, on the grounds that the server is
> broken and accepting another certificate would be by definition
> incorrect behavior.

Yes.  STS (http://tools.ietf.org/html/draft-hodges-strict-transport-sec)
is already going there, and this could follow.

> Why should we believe that such a tough stance will
> be any more viable with DNSSEC than with the current public CA system?
> (This isn't a rhetorical question, I want an answer if there is one.)

As I understand it, a lot of the problems with the current CA system
are consequences of silent acceptance of conditions that *should*
(from an abstract security point or view) shut down a site.  We're
stuck with that in the existing system lest we break sites that aren't
really being maintained.  But the new scheme is opt-in, so we can
declare that by opting in, you take on certain extra administrative
responsibilities, and in exchange you get these additional security
benefits.  Don't like it? Stick with DV certs, we're not taking that
away.

zw

Date: Fri, 1 Oct 2010 20:24:10 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Moving policy to a different WG

--0016e64c19ce829d33049197541a
Content-Type: text/plain; charset=ISO-8859-1

I am agnostic on the question of number of WGs.

I think that getting a spec like ASSURE/DPKIX/DIGEST ready for submission to
the IESG can be done by January next year.

The XDIGEST/TLSFP approach with the enumeration business is going to take
quite a lot longer. It can possibly be done in a year if it is feasible.

As far as ESRV goes, what I want to do at this stage is to get some real
world deployment experience on an experimental basis. I want a RR assignment
as soon as possible but would not want to be starting on a standards track
effort for a year.

So we really don't need to decide whether this is one WG or two at this
stage.

I suggest the following milestones

Jan 2011  Submit DIGEST mechanism draft to IESG
July 2011 Submit DIGESTX mechanism draft to IESG
July 2011 Submit Using CERT records with TLS draft to IESG
Nov 2011 Submit Using CERT records with IPSEC draft to IESG
Recharter

These are actually pretty aggressive milestones. The WG would have to cover
a lot of work in a short space of time. Getting the group chartered by Jan
might well be ambitious.

Even if the draft of DIGESTX with the enumeration/exclusion semantics is
ready in Jan 2011, the charter has to give the TLS, PKIX and other working
groups a sufficient time to review the impact on their specs.

Note also that getting the draft to the IESG is not the end of the process.
There can be a huge amount of work for the shepherd and the authors after
that point.

The WG is going to have to take a very different approach to work if they
want the spec to exit from the IESG.

On Fri, Oct 1, 2010 at 7:33 PM, Paul Hoffman <[email-masked]> wrote:

> At 7:05 PM -0400 10/1/10, Phillip Hallam-Baker wrote:
> >What I am insisting on here is a separation between security policy and
> the key assurance mechanism. It should not be necessary for me to use a
> mechanism that circumvents PKIX path validation for ALL certificates bound
> to that domain name in order to use either DNSSEC key validation or security
> policy.
>
> Well, you didn't say that you agreed with the proposition that the two
> pieces of work be in separate WGs, but it sounds that way from this
> paragraph. Is that true?
>
> --Paul Hoffman, Director
> --VPN Consortium
>

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

--0016e64c19ce829d33049197541a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I am agnostic on the question of number of WGs.<div><br></div><div>I think =
that getting a spec like ASSURE/DPKIX/DIGEST ready for submission to the IE=
SG can be done by January next year.=A0</div><div><br></div><div>The XDIGES=
T/TLSFP approach with the enumeration business is going to take quite a lot=
 longer. It can possibly be done in a year if it is feasible.</div>
<div><br></div><div><br></div><div>As far as ESRV goes, what I want to do a=
t this stage is to get some real world deployment experience on an experime=
ntal basis. I want a RR assignment as soon as possible but would not want t=
o be starting on a standards track effort for a year.</div>
<div><br></div><div>So we really don&#39;t need to decide whether this is o=
ne WG or two at this stage.=A0</div><div><br></div><div><br></div><div>I su=
ggest the following milestones</div><div><br></div><div>Jan 2011 =A0Submit =
DIGEST mechanism draft to IESG</div>
<div>July 2011 Submit DIGESTX mechanism draft to IESG</div><div>July 2011 S=
ubmit Using CERT records with TLS draft to IESG</div><div>Nov 2011 Submit=
=A0Using CERT records with IPSEC draft to IESG</div><meta charset=3D"utf-8"=
><div>
Recharter</div><div><br></div><div>These are actually pretty aggressive mil=
estones. The WG would have to cover a lot of work in a short space of time.=
 Getting the group chartered by Jan might well be ambitious.=A0</div><div>
<br></div><div>Even if the draft of DIGESTX with the enumeration/exclusion =
semantics is ready in Jan 2011, the charter has to give the TLS, PKIX and o=
ther working groups a sufficient time to review the impact on their specs.<=
/div>
<div><br></div><div><br></div><div>Note also that getting the draft to the =
IESG is not the end of the process. There can be a huge amount of work for =
the shepherd and the authors after that point.</div><div><br></div><div>
The WG is going to have to take a very different approach to work if they w=
ant the spec to exit from the IESG.</div><div><br></div><div><br></div><div=
><div class=3D"gmail_quote">On Fri, Oct 1, 2010 at 7:33 PM, Paul Hoffman <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul.hoffman@v=
pnc.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">At 7:05 PM -0400 10/1/10,=
 Phillip Hallam-Baker wrote:<br>
&gt;What I am insisting on here is a separation between security policy and=
 the key assurance mechanism. It should not be necessary for me to use a me=
chanism that circumvents PKIX path validation for ALL certificates bound to=
 that domain name in order to use either DNSSEC key validation or security =
policy.<br>

<br>
</div>Well, you didn&#39;t say that you agreed with the proposition that th=
e two pieces of work be in separate WGs, but it sounds that way from this p=
aragraph. Is that true?<br>
<div><div></div><div class=3D"h5"><br>
--Paul Hoffman, Director<br>
--VPN Consortium<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--0016e64c19ce829d33049197541a--

From: Warren Kumari <[email-masked]>
Date: Fri, 1 Oct 2010 19:45:50 -0400
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Moving policy to a different WG

On Oct 1, 2010, at 4:06 PM, Andrew Sullivan wrote:

> On Fri, Oct 01, 2010 at 01:03:05PM -0700, Paul Hoffman wrote:
>> How do others feel about this removal of policy for *this* WG?
>=20
> It seems to me that if we want to get any work done, it would be a =
good idea.
>=20

Just in case it wasn't obvious from my earlier mails, so do I....=20

W

> A
>=20
> --=20
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Matt McCutchen <[email-masked]>
To: Zack Weinberg <[email-masked]>
Date: Fri, 01 Oct 2010 19:30:27 -0400
Cc: [email-masked]
Subject: [keyassure] Potential benefits of keyassure

On Fri, 2010-10-01 at 14:33 -0700, Zack Weinberg wrote:
> On Fri, Oct 1, 2010 at 2:04 PM, Matt McCutchen <[email-masked]> wrote:
> > On Fri, 2010-10-01 at 13:46 -0700, Zack Weinberg wrote:
> >> Client software has to be able to
> >> do something with that information, after all.  If this WG cannot come
> >> to any consensus on the meaning of a fingerprint record, _in the
> >> absence_ of any explicit policy records, then we're not doing anything
> >> useful.
> >
> > I believe we have consensus that the presence of a DPKIX (or analogous)
> > record at a name is a positive statement that the key is acceptable for
> > that name.  The disagreement is about whether DPKIX records are
> > implicitly exclusive when at least one is present (as in
> > draft-hoffman-keys-linkage-from-dns) or otherwise about how they can be
> > optionally made exclusive (one approach being to add the functionality
> > to draft-hallambaker-esrv).
> 
> This is my personal opinion, and only applies to keys used for HTTPS:
> I don't think being able to make that positive statement via the DNS
> is useful by itself.  All it does (I think, anyway) is provide an
> alternative to DV certs.

Right, and one that supports secure delegation.  PKIX supports
delegation via name constraints, but they are unsupported in some
popular clients and insecure in others that accept the subject common
name as a DNS name without applying the constraints.  One could fix the
PKIX clients, but I suspect that most people who care about secure
delegation will just switch to DNSSEC where it is already working.

> That may be good for the long-run health of
> the net, but it doesn't make any direct improvement to the security of
> the web and therefore it's going to be a hard sell to browser vendors.
> 
> Exclusivity assertions, though, *do* buy you a real security
> increment: safety against corrupt or coerced CAs issuing rogue
> certificates,

This is all true.  But note that DNSSEC trust anchors are not immune to
corruption or coercion either, so it may be worth locally configuring
exclusive trust anchors for high-value zones with which one has a
relationship.

> and against blatantly fake certs that users click
> through anyway.  Those (particularly the latter) are real-world
> problems that browser vendors would love to have immediate-term
> solutions to.

You're supposing that browsers would not allow users to override an
exclusive certificate list in DNSSEC, on the grounds that the server is
broken and accepting another certificate would be by definition
incorrect behavior.  Why should we believe that such a tough stance will
be any more viable with DNSSEC than with the current public CA system?
(This isn't a rhetorical question, I want an answer if there is one.)

-- 
Matt

Date: Fri, 1 Oct 2010 16:33:33 -0700
To: Phillip Hallam-Baker <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Moving policy to a different WG

At 7:05 PM -0400 10/1/10, Phillip Hallam-Baker wrote:
>What I am insisting on here is a separation between security policy and the key assurance mechanism. It should not be necessary for me to use a mechanism that circumvents PKIX path validation for ALL certificates bound to that domain name in order to use either DNSSEC key validation or security policy.

Well, you didn't say that you agreed with the proposition that the two pieces of work be in separate WGs, but it sounds that way from this paragraph. Is that true?

--Paul Hoffman, Director
--VPN Consortium

Date: Fri, 1 Oct 2010 19:05:12 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Moving policy to a different WG

--0016364c7e371a405b0491963abd
Content-Type: text/plain; charset=ISO-8859-1

My only non-negotiable position are

1) that the exclusive cert enumeration semantics have to be a clearly
distinguished option when using DNSSEC to assure keys

2) That this aspect of security policy does not foreclose a comprehensive
solution to the problem.

As far as the mechanism to use the DNS+DNSSEC goes, we are currently very
close. The only outstanding issues are

1) Identifier to be used to identify the cert format to prevent a
substitution attack and the hash algorithm. I am fine with anything that
does not bias the scheme towards one security protocol. So using the DNS
identifiers would be OK and using ASN.1 would be OK.

I don't want to use TLS identifiers even if the cert type is limited to TLS
as that would mean having to specify different identifiers according to the
protocol to be used which would make coding a general API hellish.

2) Whether to tie the record to one protocol (TLS) or make the key assurance
mechanism protocol neutral with the proviso that an RFC is likely to be
necessary to explain exactly how to use the mechanism with each protocol
covered.

Now it may just be me, but I do not regard those as being irreconcilable.

To deal with the cert enumeration exclusion semantics, I propose two
separate certificate Types:

DIGEST    For assuring certs without exclusive semantics
XDIGEST   For assuring certs and asserting exclusive semantics

We have plenty of certificate type codes and can even use OIDs if necessary.

This makes the use of exclusive semantics a clearly defined option. It is
thus practical to use this mechanism to assure mail server certs and the
like without the risk that publishing a mail server cert will break the Web
server.

What I am insisting on here is a separation between security policy and the
key assurance mechanism. It should not be necessary for me to use a
mechanism that circumvents PKIX path validation for ALL certificates bound
to that domain name in order to use either DNSSEC key validation or security
policy.

--0016364c7e371a405b0491963abd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

My only non-negotiable position are=A0<div><br></div><div>1) that the exclu=
sive cert enumeration semantics have to be a clearly distinguished option w=
hen using DNSSEC to assure keys=A0
</div><div><br></div><div>2) That this aspect of security policy does not f=
oreclose a comprehensive solution to the problem.</div><div><br></div><div>=
<br></div><div>As far as the mechanism to use the DNS+DNSSEC goes, we are c=
urrently very close. The only outstanding issues are</div>
<div><br></div><div>1) Identifier to be used to identify the cert format to=
 prevent a substitution attack and the hash algorithm. I am fine with anyth=
ing that does not bias the scheme towards one security protocol. So using t=
he DNS identifiers would be OK and using ASN.1 would be OK.</div>
<div><br></div><div>I don&#39;t want to use TLS identifiers even if the cer=
t type is limited to TLS as that would mean having to specify different ide=
ntifiers according to the protocol to be used which would make coding a gen=
eral API hellish.</div>
<div><br></div><div>2) Whether to tie the record to one protocol (TLS) or m=
ake the key assurance mechanism protocol neutral with the proviso that an R=
FC is likely to be necessary to explain exactly how to use the mechanism wi=
th each protocol covered.</div>
<div><br></div><div><br></div><div>Now it may just be me, but I do not rega=
rd those as being irreconcilable.=A0</div><div><br></div><div><br></div><di=
v>To deal with the cert enumeration exclusion semantics, I propose two sepa=
rate certificate Types:</div>
<div><br></div><div>DIGEST =A0 =A0For assuring certs without exclusive sema=
ntics</div><div>XDIGEST =A0 For assuring certs and asserting exclusive sema=
ntics</div><div><br></div><div>We have plenty of certificate type codes and=
 can even use OIDs if necessary.</div>
<div><br></div><div>This makes the use of exclusive semantics a clearly def=
ined option. It is thus practical to use this mechanism to assure mail serv=
er certs and the like without the risk that publishing a mail server cert w=
ill break the Web server.</div>
<div><br></div><div><br></div><div>What I am insisting on here is a separat=
ion between security policy and the key assurance mechanism. It should not =
be necessary for me to use a mechanism that circumvents PKIX path validatio=
n for ALL certificates bound to that domain name in order to use either DNS=
SEC key validation or security policy.</div>

--0016364c7e371a405b0491963abd--

Date: Fri, 01 Oct 2010 15:54:57 -0700
From: =JeffH <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Moving policy to a different WG

 > [email-masked] said:
 >> -----Original Message-----
 >> From: [email-masked] [mailto:[email-masked]] On
 >> Behalf Of Zack Weinberg
 >>
 >> As a security researcher and Web browser implementor, I'm fine with
 >> splitting out policy assertions of the form "always use TLS for this site"
 >> (which
 >> are not conceptually tied to any given key).

 > Agreed.  I fully support moving this to another WG.  Depending on whether we
 > believe that there should be a all-purpose policy mechanism, or a
 > per-protocol/application one, some of this could take place in WebSec.

 >> But I don't see that it doe anyone any good to define DNS records for key
 >> fingerprints without also defining what it _means_ for a key's fingerprint
 >> to appear in the DNS. Client software has to be able to do something with
 >> that information, after all. If this WG cannot come to any consensus on the
 >> meaning of a fingerprint record, _in the absence_ of any explicit policy
 >> records, then we're not doing anything useful.

 > Agreed.  This specific question belongs here.

+1

=JeffH

Date: Fri, 1 Oct 2010 14:43:19 -0700
To: Zack Weinberg <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Moving policy to a different WG

At 1:46 PM -0700 10/1/10, Zack Weinberg wrote:
>As a security researcher and Web browser implementor, I'm fine with
>splitting out policy assertions of the form "always use TLS for this
>site" (which are not conceptually tied to any given key). 

Good.

>But I don't
>see that it does anyone any good to define DNS records for key
>fingerprints without also defining what it _means_ for a key's
>fingerprint to appear in the DNS. 

Fully agree. We have already moved around on this just within our own draft, and having a WG with a consensus process and people contributing text to the WG's draft(s) would be really useful.

>Client software has to be able to
>do something with that information, after all.  If this WG cannot come
>to any consensus on the meaning of a fingerprint record, _in the
>absence_ of any explicit policy records, then we're not doing anything
>useful.

Yep. Having a security protocol that doesn't explain its semantics is a waste of time.

>I have an opinion about what a fingerprint record should mean, but
>I'll save it for a non-meta thread.

Keep thinking about contributing text to the eventual WG document!

--Paul Hoffman, Director
--VPN Consortium

Sender: [email-masked]
Date: Fri, 1 Oct 2010 14:33:09 -0700
From: Zack Weinberg <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Moving policy to a different WG

On Fri, Oct 1, 2010 at 2:04 PM, Matt McCutchen <[email-masked]> wro=
te:
> On Fri, 2010-10-01 at 13:46 -0700, Zack Weinberg wrote:
>> Client software has to be able to
>> do something with that information, after all. =C2=A0If this WG cannot c=
ome
>> to any consensus on the meaning of a fingerprint record, _in the
>> absence_ of any explicit policy records, then we're not doing anything
>> useful.
>
> I believe we have consensus that the presence of a DPKIX (or analogous)
> record at a name is a positive statement that the key is acceptable for
> that name. =C2=A0The disagreement is about whether DPKIX records are
> implicitly exclusive when at least one is present (as in
> draft-hoffman-keys-linkage-from-dns) or otherwise about how they can be
> optionally made exclusive (one approach being to add the functionality
> to draft-hallambaker-esrv).

This is my personal opinion, and only applies to keys used for HTTPS:
I don't think being able to make that positive statement via the DNS
is useful by itself.  All it does (I think, anyway) is provide an
alternative to DV certs.  That may be good for the long-run health of
the net, but it doesn't make any direct improvement to the security of
the web and therefore it's going to be a hard sell to browser vendors.

Exclusivity assertions, though, *do* buy you a real security
increment: safety against corrupt or coerced CAs issuing rogue
certificates, and against blatantly fake certs that users click
through anyway.  Those (particularly the latter) are real-world
problems that browser vendors would love to have immediate-term
solutions to.

(I wouldn't be surprised if this assessment was true for other
application layer protocols as well, but HTTPS is the only one I know
well enough to opine for.)

zw

Date: Fri, 1 Oct 2010 16:27:37 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Moving policy to a different WG
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Paul and all,

  I disagree that there is a need to remove policy from this
WG discussion as to devise a standard inhearently at some point
requires that a policy be determined or arrived at.

-----Original Message-----
>From: Paul Hoffman <[email-masked]>
>Sent: Oct 1, 2010 3:03 PM
>To: [email-masked]
>Subject: [keyassure] Moving policy to a different WG
>
>Greetings again. The issue of "host security policy" has bedeviled different IETF WGs over the past decade. It means different things to different people, and it has tended to pull WGs into areas where only a few people have strong opinions, although those people also tend to disagree with each other. This is not to say that defining policies is impossible, but it is often time-consuming and the results are not always well-understood even when they work; DKIM is a good example of this.
>
>Phill's responses today to the current charter shows that there is still a fairly wide rift between different people's views of what policy is wanted and how it should be expressed. Much of the interest in forming this WG was for a single issue that is arguably not policy: which keys and certificates, when given in-band in a security protocol, are to be used by the client.
>
>Given this rift, I propose that we change the proposed charter again and remove "policy" altogether, and that those interested in being able to express policy in the DNS, secured by DNSSEC, set up their own WG to do this. I say this as someone who will participate in that other WG because there is a piece of policy that I absolutely care about, namely "This site always uses { TLS | IPsec }, don't fall back to unprotected". I agree with Phill that such a policy should not be tied to the key or cert that is being proffered in the current work.
>
>Splitting key assurance (which most people here seem to understand) from policy (on which there is a lot of disagreement) should allow the two pieces of work to move forwards in different timeframes, with different WG leadership, even though there will be some overlap between participants, just as there is in many Security Area WGs. I assume that it would not be hard to get a "[email-masked]" mailing list to start discussions of a charter.
>
>How do others feel about this removal of policy for *this* WG?
>
>--Paul Hoffman, Director
>--VPN Consortium
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

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

"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: "Richard L. Barnes" <[email-masked]>
To: Jakob Schlyter <[email-masked]>
Date: Fri, 1 Oct 2010 17:19:49 -0400
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Moving policy to a different WG

I agree with this proposal.
--Richard

On Oct 1, 2010, at 4:06 PM, Jakob Schlyter wrote:

> On 1 okt 2010, at 22.03, Paul Hoffman wrote:
>
>> How do others feel about this removal of policy for *this* WG?
>
> I think this would be a reasonable way forward.
>
> 	jakob
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Matt McCutchen <[email-masked]>
To: Zack Weinberg <[email-masked]>
Date: Fri, 01 Oct 2010 17:04:28 -0400
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Moving policy to a different WG

On Fri, 2010-10-01 at 13:46 -0700, Zack Weinberg wrote:
> On Fri, Oct 1, 2010 at 1:03 PM, Paul Hoffman <[email-masked]> wrote:
> [...]
> > Phill's responses today to the current charter shows that there is still a fairly wide
> > rift between different people's views of what policy is wanted and how it should
> > be expressed. Much of the interest in forming this WG was for a single issue that
> > is arguably not policy: which keys and certificates, when given in-band in a
> > security protocol, are to be used by the client.
> 
> As an interested observer, an awful lot of the argument on this list
> seems to be over
> whether or not that is a policy issue.

Right.

> But I don't
> see that it does anyone any good to define DNS records for key
> fingerprints without also defining what it _means_ for a key's
> fingerprint to appear in the DNS.

Indeed, the existing CERT subtypes do just that.

> Client software has to be able to
> do something with that information, after all.  If this WG cannot come
> to any consensus on the meaning of a fingerprint record, _in the
> absence_ of any explicit policy records, then we're not doing anything
> useful.

I believe we have consensus that the presence of a DPKIX (or analogous)
record at a name is a positive statement that the key is acceptable for
that name.  The disagreement is about whether DPKIX records are
implicitly exclusive when at least one is present (as in
draft-hoffman-keys-linkage-from-dns) or otherwise about how they can be
optionally made exclusive (one approach being to add the functionality
to draft-hallambaker-esrv).

-- 
Matt

From: "Steingruebl, Andy" <[email-masked]>
To: Zack Weinberg <[email-masked]>, Paul Hoffman <[email-masked]>
Date: Fri, 1 Oct 2010 15:02:39 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Moving policy to a different WG

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Zack Weinberg
>=20
> As a security researcher and Web browser implementor, I'm fine with
> splitting out policy assertions of the form "always use TLS for this site=
" (which
> are not conceptually tied to any given key). =20

Agreed.  I fully support moving this to another WG.  Depending on whether w=
e believe that there should be a all-purpose policy mechanism, or a per-pro=
tocol/application one, some of this could take place in WebSec.

>But I don't see that it does
> anyone any good to define DNS records for key fingerprints without also
> defining what it _means_ for a key's fingerprint to appear in the DNS.  C=
lient
> software has to be able to do something with that information, after all.=
  If
> this WG cannot come to any consensus on the meaning of a fingerprint
> record, _in the absence_ of any explicit policy records, then we're not d=
oing
> anything useful.

Agreed.  This specific question belongs here.

- Andy

Sender: [email-masked]
Date: Fri, 1 Oct 2010 13:46:57 -0700
From: Zack Weinberg <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Moving policy to a different WG

On Fri, Oct 1, 2010 at 1:03 PM, Paul Hoffman <[email-masked]> wrote:
[...]
> Phill's responses today to the current charter shows that there is still a fairly wide
> rift between different people's views of what policy is wanted and how it should
> be expressed. Much of the interest in forming this WG was for a single issue that
> is arguably not policy: which keys and certificates, when given in-band in a
> security protocol, are to be used by the client.

As an interested observer, an awful lot of the argument on this list
seems to be over
whether or not that is a policy issue.

As a security researcher and Web browser implementor, I'm fine with
splitting out policy assertions of the form "always use TLS for this
site" (which are not conceptually tied to any given key).  But I don't
see that it does anyone any good to define DNS records for key
fingerprints without also defining what it _means_ for a key's
fingerprint to appear in the DNS.  Client software has to be able to
do something with that information, after all.  If this WG cannot come
to any consensus on the meaning of a fingerprint record, _in the
absence_ of any explicit policy records, then we're not doing anything
useful.

I have an opinion about what a fingerprint record should mean, but
I'll save it for a non-meta thread.

zw

From: Matt McCutchen <[email-masked]>
To: Paul Hoffman <[email-masked]>
Date: Fri, 01 Oct 2010 16:36:30 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Moving policy to a different WG

On Fri, 2010-10-01 at 13:03 -0700, Paul Hoffman wrote:
> Phill's responses today to the current charter shows that there is
> still a fairly wide rift between different people's views of what
> policy is wanted and how it should be expressed. Much of the interest
> in forming this WG was for a single issue that is arguably not policy:
> which keys and certificates, when given in-band in a security
> protocol, are to be used by the client.
> 
> Given this rift, I propose that we change the proposed charter again
> and remove "policy" altogether, and that those interested in being
> able to express policy in the DNS, secured by DNSSEC, set up their own
> WG to do this. I say this as someone who will participate in that
> other WG because there is a piece of policy that I absolutely care
> about, namely "This site always uses { TLS | IPsec }, don't fall back
> to unprotected". I agree with Phill that such a policy should not be
> tied to the key or cert that is being proffered in the current work.

It seems clear that mandatory use of TLS/IPSEC is outside the scope of
DNSSEC key assurance per se.  The disagreement is over the possible
exclusivity of DNSSEC key assurance.  IIUC, you are including it in the
"single issue that is arguably not policy: which keys and certificates,
when given in-band in a security protocol, are to be used by the
client", while Phill argues that it constitutes policy and should be
treated along with other policy:

http://www.ietf.org/mail-archive/web/pkix/current/msg28410.html

I am happy either way, as long as the exclusivity gets standardized
without undue delay.  While the improved security of exclusive DNSSEC
key assurance is arguably the most important benefit of what we are
doing, Phill has pointed out that some admins might want to take
advantage of the convenience of DNSSEC key assurance without committing
to using it exclusively, so I think the exclusivity should be optional
(i.e., a flag).

-- 
Matt

Date: Fri, 1 Oct 2010 16:06:27 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Moving policy to a different WG

On Fri, Oct 01, 2010 at 01:03:05PM -0700, Paul Hoffman wrote:
> How do others feel about this removal of policy for *this* WG?

It seems to me that if we want to get any work done, it would be a good idea.

A

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

From: Jakob Schlyter <[email-masked]>
Date: Fri, 1 Oct 2010 22:06:19 +0200
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Moving policy to a different WG

On 1 okt 2010, at 22.03, Paul Hoffman wrote:

> How do others feel about this removal of policy for *this* WG?

I think this would be a reasonable way forward.

	jakob

Date: Fri, 1 Oct 2010 13:03:05 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: [keyassure] Moving policy to a different WG

Greetings again. The issue of "host security policy" has bedeviled different IETF WGs over the past decade. It means different things to different people, and it has tended to pull WGs into areas where only a few people have strong opinions, although those people also tend to disagree with each other. This is not to say that defining policies is impossible, but it is often time-consuming and the results are not always well-understood even when they work; DKIM is a good example of this.

Phill's responses today to the current charter shows that there is still a fairly wide rift between different people's views of what policy is wanted and how it should be expressed. Much of the interest in forming this WG was for a single issue that is arguably not policy: which keys and certificates, when given in-band in a security protocol, are to be used by the client.

Given this rift, I propose that we change the proposed charter again and remove "policy" altogether, and that those interested in being able to express policy in the DNS, secured by DNSSEC, set up their own WG to do this. I say this as someone who will participate in that other WG because there is a piece of policy that I absolutely care about, namely "This site always uses { TLS | IPsec }, don't fall back to unprotected". I agree with Phill that such a policy should not be tied to the key or cert that is being proffered in the current work.

Splitting key assurance (which most people here seem to understand) from policy (on which there is a lot of disagreement) should allow the two pieces of work to move forwards in different timeframes, with different WG leadership, even though there will be some overlap between participants, just as there is in many Security Area WGs. I assume that it would not be hard to get a "[email-masked]" mailing list to start discussions of a charter.

How do others feel about this removal of policy for *this* WG?

--Paul Hoffman, Director
--VPN Consortium

From: Warren Kumari <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Oct 2010 13:54:56 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Latest spin at the chater...

On Oct 1, 2010, at 9:56 AM, Phillip Hallam-Baker wrote:

> Ilari's position is completely reasonable here. We have not yet  
> demonstrated the practicality of any approach to security policy and  
> we are building on an infrastructure (DNSSEC) that is still in  
> deployment phase.

Thats true -- as we have not "demonstrated the practicality of any  
approach to security policy" I am leaning more and more to making the  
charter as specific as possible, and not opening the "security policy"  
door at all...

>
> That is why I do not want the charter to be tied to any specific  
> approach, mine included.
>
>
> The point I was trying to make was that forced to chose between a  
> certificate type that works for TLS+IPSEC+S/MIME+SSH and one that  
> works for X.509+PGP+SPKI, I would choose the first, i.e. we would  
> have:
>
> CERT APKIX ....
> CERT APGP ....
> CERT ASPKI ....
>
> But that is if I am forced to choose. I would prefer
>
> CERT ASSERT 0 0 <AlgID> <CertID> <Digest>
>
> Which is completely general.

Can you please try draft text that explains that in a short and  
concise and *specific* manner?

We keep coming back to the "security policy" bit, and it seems as  
though A: most of the participant have a different view than yours, B:  
your definition is vague and / or changing and / or  C: poorly  
defined / overly broad....

>
>
> What I do not want is for these decisions to be made in the charter.

Oh, but what we REALLY don't want is to have a charter that is so  
broad that:
A: It never gets agreed to (which is what is happening here -- we have  
been trying to limit the scope, but have slowly increased it to try  
accommodate your suggestions and views).
B: the working group gets bogged down (like the mailing list has been)  
and forward process is thwarted.

A tightly bounded and specific charter that allows us to move forward,  
do a bit of work and then A: conclude or B: recharter seems preferable  
-- "launch and iterate" approach vs "extended kvetching".

I really appreciate your experience, insight, passion and knowledge,  
but it seems more and more as though the list's view and your view's  
on what we are trying to accomplish differ and that these may be  
irreconcilable differences.

One possible option is that the security policy parts could be  
included in a different RR and worked on as an individual submission  
and / or in a different group...

W

>
>
> On Fri, Oct 1, 2010 at 8:05 AM, Ilari Liusvaara <[email-masked] 
> > wrote:
> On Fri, Oct 01, 2010 at 01:16:24AM -0400, Phillip Hallam-Baker wrote:
> >
> > The policy mechanism should be orthogonal to the keying mechanism.
> >
> > Existing experience of security policy ties the policy to  
> protocols and not
> > keys. Security policies are of the form 'must use SSL when using  
> HTTP at
> > example.com' and 'must use SSL with key conforming to trust  
> criteria X when
> > using HTTP...'
>
> I'm not a fan of security policies in DNS. I would like more to see  
> facts,
> like:
>
> * Client can upgrade the connection (to this or that) after connecting
> for this service (downgrade-attack-free upgrades)
> * Client can connect securely (using this or that) to this service
> (it will sniff the connection type)
> * Client can obtain equivalent secure service (using this or that)  
> from
> that service (service redirect)
>
> * This service supports security, client MAY use it.
> * This service is sensitive, client SHOULD use security.
> * This service doesn't yield useful nonsecure service, client MUST use
> security.
>
> * The certificate will chain to one of these TAs.
>
> Of course, the client is free to ignore this, but it will do so on  
> peril
> of itself and its user.
>
> This is pretty much everything one needs to have secure connection.  
> One can
> then send actual (protocol dependent) policy (securely) via that.
>
> > I don't see any particular reason to separate TLS and non TLS  
> protocols
> > either. So far the only aspects of the protocol that are tied to  
> TLS are the
> > 'cert enumeration' mechanism and the cert type identifier.
>
> I thought the idea was to form some "core" with some free  
> "parameters" and
> then instantiate that for each protocol.
>
> Anyway, spec for TLS can be transformed into spec for IPSEC with  
> little
> search-and-replace.
>
> > Given the choice, I would much prefer a key assurance mechanism that
> > supports any security protocol but only works with X.509 certs  
> than one the
> > only works with TLS but has the option of using additional cert  
> formats that
> > are either essentially historic or make no real sense in the  
> context of a
> > hierarchical naming structure (PGP).
>
> I think OpenPGP would make great sense here. Its way simpler if you  
> just
> need key container for TLS (since TLS doesn't have "raw key cert"  
> format).
>
> -Ilari
>
>
>
> -- 
> Website: http://hallambaker.com/
>

-- 
Outside of a dog, a book is your best friend, and inside of a dog,  
it's too dark to read

Date: Fri, 1 Oct 2010 10:47:33 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Latest spin at the chater...

--0016e65b54dc60274104918f46a5
Content-Type: text/plain; charset=ISO-8859-1

If you believe that then tie the charter to the proven approach as used in
DKIM and policymaker and every other Security Policy scheme.

If you believe that then tie the charter to the approach that gives the
clean API.

Having recently shepherded three drafts through the IESG to RFC-EDITOR
state, the issues that they have been concerned with are consistency of
architectural approach, separation of concerns and that the group
understands the security considerations and has deployed all relevant
controls.

On that basis, I don't think the IESG is going to be impressed by a charter
that is written to force adoption of the cert enumeration approach.

On Fri, Oct 1, 2010 at 10:23 AM, Andrew Sullivan <[email-masked]> wrote:

> On Fri, Oct 01, 2010 at 09:56:23AM -0400, Phillip Hallam-Baker wrote:
> > That is why I do not want the charter to be tied to any specific
> approach,
> > mine included.
>
> Over on the homegate list, an open-ended, unfocussed charter of that
> type was just rejected on the very grounds that it's too open-ended,
> unfocussed, unclear, and unconstrained.
>
> My lesson from that discussion is that the current IESG wants specific
> deliverables in charters.
>
> Therefore, if we don't tie to specific approaches, we'll get nowhere
> except wandering in the wilderness.
>
> A
>
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

--0016e65b54dc60274104918f46a5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

If you believe that then tie the charter to the proven approach as used in =
DKIM and policymaker and every other Security Policy scheme.<div><br></div>=
<meta charset=3D"utf-8"><div>If you believe that then tie=A0the charter to =
the approach that gives the clean API.</div>
<div><br></div><div><br></div><div>Having recently shepherded three drafts =
through the IESG to RFC-EDITOR state, the issues that they have been concer=
ned with are consistency of architectural approach, separation of concerns =
and that the group understands the security considerations and has deployed=
 all relevant controls.</div>
<div><br></div><div>On that basis, I don&#39;t think the IESG is going to b=
e impressed by a charter that is written to force adoption of the cert enum=
eration approach.</div><div><br></div><div><br></div><div><br><div class=3D=
"gmail_quote">
On Fri, Oct 1, 2010 at 10:23 AM, Andrew Sullivan <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex;">
<div class=3D"im">On Fri, Oct 01, 2010 at 09:56:23AM -0400, Phillip Hallam-=
Baker wrote:<br>
&gt; That is why I do not want the charter to be tied to any specific appro=
ach,<br>
&gt; mine included.<br>
<br>
</div>Over on the homegate list, an open-ended, unfocussed charter of that<=
br>
type was just rejected on the very grounds that it&#39;s too open-ended,<br=
>
unfocussed, unclear, and unconstrained.<br>
<br>
My lesson from that discussion is that the current IESG wants specific<br>
deliverables in charters.<br>
<br>
Therefore, if we don&#39;t tie to specific approaches, we&#39;ll get nowher=
e<br>
except wandering in the wilderness.<br>
<br>
A<br>
<font color=3D"#888888"><br>
--<br>
Andrew Sullivan<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
Shinkuro, Inc.<br>
</font><div><div></div><div class=3D"h5">__________________________________=
_____________<br>
keyassure mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--0016e65b54dc60274104918f46a5--

Date: Fri, 1 Oct 2010 10:23:53 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Latest spin at the chater...

On Fri, Oct 01, 2010 at 09:56:23AM -0400, Phillip Hallam-Baker wrote:
> That is why I do not want the charter to be tied to any specific approach,
> mine included.

Over on the homegate list, an open-ended, unfocussed charter of that
type was just rejected on the very grounds that it's too open-ended,
unfocussed, unclear, and unconstrained.

My lesson from that discussion is that the current IESG wants specific
deliverables in charters.

Therefore, if we don't tie to specific approaches, we'll get nowhere
except wandering in the wilderness.

A

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

Date: Fri, 1 Oct 2010 09:56:23 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Latest spin at the chater...

--001636416b975ca81804918e8f94
Content-Type: text/plain; charset=ISO-8859-1

Ilari's position is completely reasonable here. We have not yet demonstrated
the practicality of any approach to security policy and we are building on
an infrastructure (DNSSEC) that is still in deployment phase.

That is why I do not want the charter to be tied to any specific approach,
mine included.

The point I was trying to make was that forced to chose between a
certificate type that works for TLS+IPSEC+S/MIME+SSH and one that works for
X.509+PGP+SPKI, I would choose the first, i.e. we would have:

CERT APKIX ....
CERT APGP ....
CERT ASPKI ....

But that is if I am forced to choose. I would prefer

CERT ASSERT 0 0 <AlgID> <CertID> <Digest>

Which is completely general.

What I do not want is for these decisions to be made in the charter.

On Fri, Oct 1, 2010 at 8:05 AM, Ilari Liusvaara <[email-masked]
> wrote:

> On Fri, Oct 01, 2010 at 01:16:24AM -0400, Phillip Hallam-Baker wrote:
> >
> > The policy mechanism should be orthogonal to the keying mechanism.
> >
> > Existing experience of security policy ties the policy to protocols and
> not
> > keys. Security policies are of the form 'must use SSL when using HTTP at
> > example.com' and 'must use SSL with key conforming to trust criteria X
> when
> > using HTTP...'
>
> I'm not a fan of security policies in DNS. I would like more to see facts,
> like:
>
> * Client can upgrade the connection (to this or that) after connecting
> for this service (downgrade-attack-free upgrades)
> * Client can connect securely (using this or that) to this service
> (it will sniff the connection type)
> * Client can obtain equivalent secure service (using this or that) from
> that service (service redirect)
>
> * This service supports security, client MAY use it.
> * This service is sensitive, client SHOULD use security.
> * This service doesn't yield useful nonsecure service, client MUST use
> security.
>
> * The certificate will chain to one of these TAs.
>
> Of course, the client is free to ignore this, but it will do so on peril
> of itself and its user.
>
> This is pretty much everything one needs to have secure connection. One can
> then send actual (protocol dependent) policy (securely) via that.
>
> > I don't see any particular reason to separate TLS and non TLS protocols
> > either. So far the only aspects of the protocol that are tied to TLS are
> the
> > 'cert enumeration' mechanism and the cert type identifier.
>
> I thought the idea was to form some "core" with some free "parameters" and
> then instantiate that for each protocol.
>
> Anyway, spec for TLS can be transformed into spec for IPSEC with little
> search-and-replace.
>
> > Given the choice, I would much prefer a key assurance mechanism that
> > supports any security protocol but only works with X.509 certs than one
> the
> > only works with TLS but has the option of using additional cert formats
> that
> > are either essentially historic or make no real sense in the context of a
> > hierarchical naming structure (PGP).
>
> I think OpenPGP would make great sense here. Its way simpler if you just
> need key container for TLS (since TLS doesn't have "raw key cert" format).
>
> -Ilari
>

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

--001636416b975ca81804918e8f94
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ilari&#39;s position is completely reasonable here. We have not yet demonst=
rated the practicality of any approach to security policy and we are buildi=
ng on an infrastructure (DNSSEC) that is still in deployment phase.<br><br>
<div>That is why I do not want the charter to be tied to any specific appro=
ach, mine included.</div><div><br></div><div><br></div><div>The point I was=
 trying to make was that forced to chose between a certificate type that wo=
rks for TLS+IPSEC+S/MIME+SSH and one that works for X.509+PGP+SPKI, I would=
 choose the first, i.e. we would have:</div>
<div><br></div><div>CERT APKIX ....</div><div>CERT APGP ....</div><div>CERT=
 ASPKI ....</div><div><br></div><div>But that is if I am forced to choose. =
I would prefer</div><div><br></div><div>CERT ASSERT 0 0 &lt;AlgID&gt; &lt;C=
ertID&gt; &lt;Digest&gt;</div>
<div><br></div><div>Which is completely general.</div><div><br></div><div><=
br></div><div>What I do not want is for these decisions to be made in the c=
harter.</div><div><br></div><div><br><div class=3D"gmail_quote">On Fri, Oct=
 1, 2010 at 8:05 AM, Ilari Liusvaara <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:[email-masked]">[email-masked]</a>&gt;</span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On Fri, Oct 01, 2010 at 0=
1:16:24AM -0400, Phillip Hallam-Baker wrote:<br>
&gt;<br>
&gt; The policy mechanism should be orthogonal to the keying mechanism.<br>
&gt;<br>
&gt; Existing experience of security policy ties the policy to protocols an=
d not<br>
&gt; keys. Security policies are of the form &#39;must use SSL when using H=
TTP at<br>
&gt; <a href=3D"http://example.com" target=3D"_blank">example.com</a>&#39; =
and &#39;must use SSL with key conforming to trust criteria X when<br>
&gt; using HTTP...&#39;<br>
<br>
</div>I&#39;m not a fan of security policies in DNS. I would like more to s=
ee facts,<br>
like:<br>
<br>
* Client can upgrade the connection (to this or that) after connecting<br>
for this service (downgrade-attack-free upgrades)<br>
* Client can connect securely (using this or that) to this service<br>
(it will sniff the connection type)<br>
* Client can obtain equivalent secure service (using this or that) from<br>
that service (service redirect)<br>
<br>
* This service supports security, client MAY use it.<br>
* This service is sensitive, client SHOULD use security.<br>
* This service doesn&#39;t yield useful nonsecure service, client MUST use<=
br>
security.<br>
<br>
* The certificate will chain to one of these TAs.<br>
<br>
Of course, the client is free to ignore this, but it will do so on peril<br=
>
of itself and its user.<br>
<br>
This is pretty much everything one needs to have secure connection. One can=
<br>
then send actual (protocol dependent) policy (securely) via that.<br>
<div class=3D"im"><br>
&gt; I don&#39;t see any particular reason to separate TLS and non TLS prot=
ocols<br>
&gt; either. So far the only aspects of the protocol that are tied to TLS a=
re the<br>
&gt; &#39;cert enumeration&#39; mechanism and the cert type identifier.<br>
<br>
</div>I thought the idea was to form some &quot;core&quot; with some free &=
quot;parameters&quot; and<br>
then instantiate that for each protocol.<br>
<br>
Anyway, spec for TLS can be transformed into spec for IPSEC with little<br>
search-and-replace.<br>
<div class=3D"im"><br>
&gt; Given the choice, I would much prefer a key assurance mechanism that<b=
r>
&gt; supports any security protocol but only works with X.509 certs than on=
e the<br>
&gt; only works with TLS but has the option of using additional cert format=
s that<br>
&gt; are either essentially historic or make no real sense in the context o=
f a<br>
&gt; hierarchical naming structure (PGP).<br>
<br>
</div>I think OpenPGP would make great sense here. Its way simpler if you j=
ust<br>
need key container for TLS (since TLS doesn&#39;t have &quot;raw key cert&q=
uot; format).<br>
<font color=3D"#888888"><br>
-Ilari<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--001636416b975ca81804918e8f94--

From: Warren Kumari <[email-masked]>
Date: Fri, 1 Oct 2010 09:00:04 -0400
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Latest spin at the chater...

Will respond more fully later, but wanted to at least start responding =
before heading in to office.
On Oct 1, 2010, at 1:16 AM, Phillip Hallam-Baker wrote:

> I have asked on three separate occasions to have the ESRV draft added =
to the list of possible starting points:
>=20
> Possible starting points for these deliverables include =
draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, =
draft-josefsson-keyassure-tls and draft-hallambaker-esrv
>=20
>=20

Apologies, done.

>=20
>=20
> If we are doing security policy we should look at all the proposals.
>=20
>=20
> The charter as written is of the form 'here is a technology, we want a =
WG to turn it into a standard'. While that is the right approach when =
there is significant experience of using actual code, we are not in that =
position here.=20
>=20
> In particular I disagree with the following:
>=20
> The group will also investigate publishing security policies that are =
related to the use of keying material in the DNS, such as whether =
communications must be cryptographically protected.
>=20
> Please remove " that are related to the use of keying material"

Can you please try and limit this a bit? I had initially written it =
without that phrase, but then realized that that also opened the door to =
talking about how high a fence should be around your datacenter and that =
you shouldn't write your password on a sticky on your monitor... One of =
the major sticking points on these discussions has been:
A: if policy should be included at all (and, my reading is that the =
majority of folk think that it shouldn't)
B: if it is, what all should be allowed.

Just saying "publishing security policies in the DNS" is entirely too =
broad...=20

>=20
> The policy mechanism should be orthogonal to the keying mechanism.
>=20
> Existing experience of security policy ties the policy to protocols =
and not keys. Security policies are of the form 'must use SSL when using =
HTTP at example.com' and 'must use SSL with key conforming to trust =
criteria X when using HTTP...'
>=20
> Absent extensive experience of tying policy to keys and a =
demonstration of clear benefits resulting from that approach, the =
charter should leave that choice open.
>=20
> I don't see any particular reason to separate TLS and non TLS =
protocols either. So far the only aspects of the protocol that are tied =
to TLS are the 'cert enumeration' mechanism and the cert type =
identifier.
>=20
> Given the choice, I would much prefer a key assurance mechanism that =
supports any security protocol but only works with X.509 certs than one =
the only works with TLS but has the option of using additional cert =
formats that are either essentially historic or make no real sense in =
the context of a hierarchical naming structure (PGP).
>=20

Yes, you've made that clear --- however, you are not the only person =
participating. Keep in mind that I haven't had my morning coffee yet, =
and so am extra grumpy -- We have been trying really hard to come to a =
compromise on many of these points, but I'm beginning to think that we =
are just not going to be able to make you happy. We have been trying to =
move things forward, but it feels like you are intentionally being =
obstructionistic.

>=20
> I find the milestones to be entirely unrealistic.=20
>=20
> It will take considerably longer than June 2011 to have any draft with =
the cert enumeration semantics contained in it ready for the IESG. It =
would be somewhat optimistic to expect to have a draft with only the key =
assurance semantics ready in that time, and that is work we have twenty =
years experience doing at this point.
>=20
>=20
> The natural place to break the problem is between key assurance and =
security policy. That is, along the major functional lines.
>=20
> I would anticipate the final document set looking something like
>=20
> * Key Assurance Mechanism
> * Use of Key Assurance Cert Type with HTTP/TLS
> * DNS Security Policy Mechanism=20
> * Use of Security Policy with HTTP
> * Use of Security Policy with SMTP, POP3, IMAP

While the final document set may or may not look like that, having a few =
items and then rechartering may allow us to actually get some things =
done...=20
When rechartering we can look at increasing or decreasing the scope --- =
forming while saying "And we'll poke at a whole bunch of other WGs =
space" is yet another obstacle to getting formed...

>=20
> For each of the 'Mechanism' documents I would anticipate an effective =
3 step process of Experimental, Proposed, Standard.
>=20
> For the Use documents I would anticipate a 2 step process starting at =
Proposed and going to Standard.
>=20
> If Russ' 2 step proposal goes through then the final step would be =
'Full Standard' otherwise it will most likely be 'Draft'.
>=20
>=20
> I would also leave open the possibility that there may be multiple =
experimental mechanism documents in the case that there is no agreement =
before test deployments start.=20
>=20

The possibility of multiple experimental mechanism documents is still =
open -- work can happen that isn't listed in the milestones, but I do =
not think that we *need* to do multiple for all docs...

> The reason I propose using the experimental step is that I want to =
start real world trials as soon as possible and want the results of =
those trials to feed into the Proposed Standard. And to do trials, I =
would like to have possible production code points assigned.
>=20
> Based on previous IETF experience, three years for getting the =
documents of this type to Proposed Standard is rather more realistic =
than the schedules proposed.

Yes, the milestones were intended to be aggressive, and I think that we =
could meet them if folk are willing to ignore distraction / disruptions.

W (who still hasn't had his coffee).

From: "Richard L. Barnes" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Oct 2010 08:11:32 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Latest spin at the chater...

--Apple-Mail-2-537730953
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

I would support striking this sentence, which is the only mention of  
the word "privacy":
"The group will also investigate publishing security policies that are  
related to the use of keying material in the DNS, such as whether  
communications must be cryptographically protected."

This is not a policy group, it's a domain-to-key binding group.   
Policy, as I've said before, is the domain of the applications.

--Richard

On Oct 1, 2010, at 1:16 AM, Phillip Hallam-Baker wrote:

> I have asked on three separate occasions to have the ESRV draft  
> added to the list of possible starting points:
>
> Possible starting points for these deliverables include draft- 
> hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, draft- 
> josefsson-keyassure-tls and draft-hallambaker-esrv
>
>
>
>
>
>
>
>  If we are doing security policy we should look at all the proposals.
>
>
> The charter as written is of the form 'here is a technology, we want  
> a WG to turn it into a standard'. While that is the right approach  
> when there is significant experience of using actual code, we are  
> not in that position here.
>
> In particular I disagree with the following:
>
> The group will also investigate publishing security policies that  
> are related to the use of keying material in the DNS, such as  
> whether communications must be cryptographically protected.
>
> Please remove " that are related to the use of keying material"
>
>
> The policy mechanism should be orthogonal to the keying mechanism.
>
> Existing experience of security policy ties the policy to protocols  
> and not keys. Security policies are of the form 'must use SSL when  
> using HTTP at example.com' and 'must use SSL with key conforming to  
> trust criteria X when using HTTP...'
>
> Absent extensive experience of tying policy to keys and a  
> demonstration of clear benefits resulting from that approach, the  
> charter should leave that choice open.
>
> I don't see any particular reason to separate TLS and non TLS  
> protocols either. So far the only aspects of the protocol that are  
> tied to TLS are the 'cert enumeration' mechanism and the cert type  
> identifier.
>
> Given the choice, I would much prefer a key assurance mechanism that  
> supports any security protocol but only works with X.509 certs than  
> one the only works with TLS but has the option of using additional  
> cert formats that are either essentially historic or make no real  
> sense in the context of a hierarchical naming structure (PGP).
>
>
> I find the milestones to be entirely unrealistic.
>
> It will take considerably longer than June 2011 to have any draft  
> with the cert enumeration semantics contained in it ready for the  
> IESG. It would be somewhat optimistic to expect to have a draft with  
> only the key assurance semantics ready in that time, and that is  
> work we have twenty years experience doing at this point.
>
>
> The natural place to break the problem is between key assurance and  
> security policy. That is, along the major functional lines.
>
> I would anticipate the final document set looking something like
>
> * Key Assurance Mechanism
> * Use of Key Assurance Cert Type with HTTP/TLS
> * DNS Security Policy Mechanism
> * Use of Security Policy with HTTP
> * Use of Security Policy with SMTP, POP3, IMAP
>
> For each of the 'Mechanism' documents I would anticipate an  
> effective 3 step process of Experimental, Proposed, Standard.
>
> For the Use documents I would anticipate a 2 step process starting  
> at Proposed and going to Standard.
>
> If Russ' 2 step proposal goes through then the final step would be  
> 'Full Standard' otherwise it will most likely be 'Draft'.
>
>
> I would also leave open the possibility that there may be multiple  
> experimental mechanism documents in the case that there is no  
> agreement before test deployments start.
>
> The reason I propose using the experimental step is that I want to  
> start real world trials as soon as possible and want the results of  
> those trials to feed into the Proposed Standard. And to do trials, I  
> would like to have possible production code points assigned.
>
> Based on previous IETF experience, three years for getting the  
> documents of this type to Proposed Standard is rather more realistic  
> than the schedules proposed.
>
> On Thu, Sep 30, 2010 at 8:06 PM, Warren Kumari <[email-masked]>  
> wrote:
> Hi there all,
>
> I wanted to thank everyone for their hard work and active  
> involvement in the chartering discussions.
>
> I have reread most of the mail on this topic, and have tried to  
> integrate everyones suggestions, and I think that we finally have a  
> version that will be *acceptable* to everyone.
>
> I'd like to especially thank Stephen Farrell for his suggestions  
> (which I somehow filed into a different label and missed) as well as  
> Phillip, Paul, Richard and Jakob for their input and suggested text...
>
> I think that we have been fairly close to an acceptable charter for  
> a long time now, but were getting hung up on misunderstandings and  
> misinterpretations of what others were saying...
>
> So, please have another look at the charter and hopefully you will  
> find it acceptable to you:
> http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure
>
> If parts are not acceptable, please do me 3 favors:
> 1: Reread the unacceptable parts and try figure out if what you are  
> objecting to is what the sentence is trying to say, or it is just a  
> wording issue / differing uses of a term.
>
> 2: If  you are OK with it being in the charter so that we (as a WG)  
> can at least discuss the issue and come to consensus.
>
> and, most importantly:
> 3: send text --- saying "Bah, paragraph X is the devil! eat flaming  
> death, mongrel!" is *not* helpful... "How does the group feel about  
> 'Foo blargh wumblet boop' instead of 'mumble'?" is...
>
> W
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>
>
>
> -- 
> Website: http://hallambaker.com/
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

--Apple-Mail-2-537730953
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">I would support striking this =
sentence, which is the only mention of the word "privacy":<div>"The =
group will also investigate publishing security policies that are=20
related to the use of keying material in the DNS, such as whether=20
communications must be cryptographically =
protected."</div><div><br></div><div>This is not a policy group, it's a =
domain-to-key binding group. &nbsp;Policy, as I've said before, is the =
domain of the =
applications.</div><div><br></div><div>--Richard</div><div><br></div><div>=
<br><div><div>On Oct 1, 2010, at 1:16 AM, Phillip Hallam-Baker =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">I have asked on three separate occasions to have the ESRV =
draft added to the list of possible starting =
points:<div><br></div><div><span class=3D"Apple-style-span" =
style=3D"font-family: 'Times New Roman', times, serif; font-size: =
10.4167px; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px; ">Possible starting points for =
these deliverables include&nbsp;<a =
href=3D"http://tools.ietf.org/html/draft-hallambaker-certhash" =
class=3D"wiki" style=3D"text-decoration: underline; color: rgb(0, 0, =
221); border-bottom-width: 0px; border-bottom-style: initial; =
border-bottom-color: initial; ">draft-hallambaker-certhash</a>,&nbsp;<a =
href=3D"http://tools.ietf.org/html/draft-hoffman-keys-linkage-from-dns" =
class=3D"wiki" style=3D"text-decoration: underline; color: rgb(0, 0, =
221); border-bottom-width: 0px; border-bottom-style: initial; =
border-bottom-color: initial; ">draft-hoffman-keys-linkage-from-dns</a>, =
<a href=3D"http://tools.ietf.org/html/draft-josefsson-keyassure-tls" =
class=3D"wiki" style=3D"text-decoration: underline; color: rgb(0, 0, =
221); border-bottom-width: 0px; border-bottom-style: initial; =
border-bottom-color: initial; =
">draft-josefsson-keyassure-tls</a>&nbsp;and&nbsp;<span =
class=3D"Apple-style-span" style=3D"font-family: monospace; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; font-size: 11.1111px; font-weight: bold; line-height: 0px; =
white-space: pre; ">draft-hallambaker-esrv</span></span></div> =
<div><span class=3D"Apple-style-span" style=3D"font-family: 'Times New =
Roman', times, serif; font-size: 10.4167px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px; "><font class=3D"Apple-style-span" face=3D"monospace" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 16px; =
line-height: 0px; white-space: pre; -webkit-border-horizontal-spacing: =
0px; -webkit-border-vertical-spacing: 0px;"><b><br> =
</b></span></font></span></div><div><span class=3D"Apple-style-span" =
style=3D"font-family: 'Times New Roman', times, serif; font-size: =
10.4167px; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px; "><font class=3D"Apple-style-span" =
face=3D"monospace" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 16px; line-height: 0px; white-space: pre; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px;"><b><br> </b></span></font></span></div><div><span =
class=3D"Apple-style-span" style=3D"font-family: 'Times New Roman', =
times, serif; font-size: 10.4167px; -webkit-border-horizontal-spacing: =
2px; -webkit-border-vertical-spacing: 2px; "><font =
class=3D"Apple-style-span" face=3D"monospace" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 16px; line-height: 0px; =
white-space: pre; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px;"><b><br> =
</b></span></font></span></div><div><span class=3D"Apple-style-span" =
style=3D"font-family: 'Times New Roman', times, serif; font-size: =
10.4167px; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px; "><font class=3D"Apple-style-span" =
face=3D"monospace" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 16px; line-height: 0px; white-space: pre; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px;"><b><br> </b></span></font></span>If we are doing security policy =
we should look at all the =
proposals.</div><div><br></div><div><br></div><div>The charter as =
written is of the form 'here is a technology, we want a WG to turn it =
into a standard'. While that is the right approach when there is =
significant experience of using actual code, we are not in that position =
here.&nbsp;</div> <div><br></div><div>In particular I disagree with the =
following:</div><div><br></div><div><span class=3D"Apple-style-span" =
style=3D"font-family: 'Times New Roman', times, serif; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px; ">The group will also investigate publishing security policies that =
are related to the use of keying material in the DNS, such as whether =
communications must be cryptographically protected.</span></div> =
<div><span class=3D"Apple-style-span" style=3D"font-family: 'Times New =
Roman', times, serif; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px; "><br></span></div><div><span =
class=3D"Apple-style-span" style=3D"font-family: 'Times New Roman', =
times, serif; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px; ">Please remove "</span><span =
class=3D"Apple-style-span" style=3D"font-family: 'Times New Roman', =
times, serif; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px; ">&nbsp;that are related to the =
use of keying material"</span></div> <div><span class=3D"Apple-style-span"=
 style=3D"font-family: 'Times New Roman', times, serif; font-size: =
10.4167px; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px; "><br></span></div><div> <span =
class=3D"Apple-style-span" style=3D"font-family: 'Times New Roman', =
times, serif; font-size: 10.4167px; -webkit-border-horizontal-spacing: =
2px; -webkit-border-vertical-spacing: 2px; "><br></span></div><div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">The policy =
mechanism should be orthogonal to the keying =
mechanism.</span></font></span></font></div> <div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"><br> =
</span></font></span></font></div><div><font class=3D"Apple-style-span" =
face=3D"'Times New Roman', times, serif" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">Existing =
experience of security policy ties the policy to protocols and not keys. =
Security policies are of the form 'must use SSL when using HTTP at <a =
href=3D"http://example.com">example.com</a>' and 'must use SSL with key =
conforming to trust criteria X when using =
HTTP...'</span></font></span></font></div> <div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"><br> =
</span></font></span></font></div><div><font class=3D"Apple-style-span" =
face=3D"'Times New Roman', times, serif" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">Absent extensive =
experience of tying policy to keys and a demonstration of clear benefits =
resulting from that approach, the charter should leave that choice =
open.</span></font></span></font></div> <div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"><br> =
</span></font></span></font></div><div><font class=3D"Apple-style-span" =
face=3D"'Times New Roman', times, serif" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">I don't see any =
particular reason to separate TLS and non TLS protocols either. So far =
the only aspects of the protocol that are tied to TLS are the 'cert =
enumeration' mechanism and the cert type =
identifier.</span></font></span></font></div> <div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"><br> =
</span></font></span></font></div><div><span class=3D"Apple-style-span" =
style=3D"font-family: 'Times New Roman', times, serif; font-size: =
15.2778px; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px; ">Given the choice, I would much =
prefer a key assurance mechanism that supports any security protocol but =
only works with X.509 certs than one the only works with TLS but has the =
option of using additional cert formats that are either essentially =
historic or make no real sense in the context of a hierarchical naming =
structure (PGP).</span></div> <div><font class=3D"Apple-style-span" =
face=3D"'Times New Roman', times, serif" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"><br> =
</span></font></span></font></div><div><font class=3D"Apple-style-span" =
face=3D"'Times New Roman', times, serif" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"><br> =
</span></font></span></font></div><div><font class=3D"Apple-style-span" =
face=3D"'Times New Roman', times, serif" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">I find the =
milestones to be entirely =
unrealistic.&nbsp;</span></font></span></font></div> <div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"><br> =
</span></font></span></font></div><div><font class=3D"Apple-style-span" =
face=3D"'Times New Roman', times, serif" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">It will take =
considerably longer than June 2011 to have any draft with the cert =
enumeration semantics contained in it ready for the IESG. It would be =
somewhat optimistic to expect to have a draft with only the key =
assurance semantics ready in that time, and that is work we have twenty =
years experience doing at this point.</span></font></span></font></div> =
<div><font class=3D"Apple-style-span" face=3D"'Times New Roman', times, =
serif" size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px;"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px;"><br> </span></font></span></font></div><div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"><br> =
</span></font></span></font></div><div><font class=3D"Apple-style-span" =
face=3D"'Times New Roman', times, serif" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">The natural place =
to break the problem is between key assurance and security policy. That =
is, along the major functional lines.</span></font></span></font></div> =
<div><font class=3D"Apple-style-span" face=3D"'Times New Roman', times, =
serif" size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px;"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px;"><br> </span></font></span></font></div><div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">I would anticipate =
the final document set looking something =
like</span></font></span></font></div> <div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"><br> =
</span></font></span></font></div><div><font class=3D"Apple-style-span" =
face=3D"'Times New Roman', times, serif" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">* Key Assurance =
Mechanism</span></font></span></font></div> <div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">* Use of Key =
Assurance Cert Type with HTTP/TLS</span></font></span></font></div> =
<div><font class=3D"Apple-style-span" face=3D"'Times New Roman', times, =
serif" size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px;"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">* =
DNS Security Policy Mechanism&nbsp;</span></font></span></font></div> =
<div><font class=3D"Apple-style-span" face=3D"'Times New Roman', times, =
serif" size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px;"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">* =
Use of Security Policy with HTTP</span></font></span></font></div> =
<div><font class=3D"Apple-style-span" face=3D"'Times New Roman', times, =
serif" size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px;"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">* =
Use of Security Policy with SMTP, POP3, =
IMAP</span></font></span></font></div> <div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"><br> =
</span></font></span></font></div><div><font class=3D"Apple-style-span" =
face=3D"'Times New Roman', times, serif" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">For each of the =
'Mechanism' documents I would anticipate an effective 3 step process of =
Experimental, Proposed, Standard.</span></font></span></font></div> =
<div><font class=3D"Apple-style-span" face=3D"'Times New Roman', times, =
serif" size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px;"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px;"><br> </span></font></span></font></div><div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">For the Use =
documents I would anticipate a 2 step process starting at Proposed and =
going to Standard.</span></font></span></font></div> <div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"><br> =
</span></font></span></font></div><div><font class=3D"Apple-style-span" =
face=3D"'Times New Roman', times, serif" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">If Russ' 2 step =
proposal goes through then the final step would be 'Full Standard' =
otherwise it will most likely be =
'Draft'.</span></font></span></font></div> <div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"><br> =
</span></font></span></font></div><div><font class=3D"Apple-style-span" =
face=3D"'Times New Roman', times, serif" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"><br> =
</span></font></span></font></div><div><font class=3D"Apple-style-span" =
face=3D"'Times New Roman', times, serif" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">I would also leave =
open the possibility that there may be multiple experimental mechanism =
documents in the case that there is no agreement before test deployments =
start.&nbsp;</span></font></span></font></div> <div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"><br> =
</span></font></span></font></div><div><font class=3D"Apple-style-span" =
face=3D"'Times New Roman', times, serif" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">The reason I =
propose using the experimental step is that I want to start real world =
trials as soon as possible and want the results of those trials to feed =
into the Proposed Standard. And to do trials, I would like to have =
possible production code points =
assigned.</span></font></span></font></div> <div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"><br> =
</span></font></span></font></div><div><font class=3D"Apple-style-span" =
face=3D"'Times New Roman', times, serif" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">Based on previous =
IETF experience, three years for getting the documents of this type to =
Proposed Standard is rather more realistic than the schedules =
proposed.</span></font></span></font></div> <div><font =
class=3D"Apple-style-span" face=3D"'Times New Roman', times, serif" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"><br> =
</span></font></span></font></div><div>On Thu, Sep 30, 2010 at 8:06 PM, =
Warren Kumari <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> =
wrote:</div><div><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex;"> Hi there all,<br> <br> I wanted to thank =
everyone for their hard work and active involvement in the chartering =
discussions.<br> <br> I have reread most of the mail on this topic, and =
have tried to integrate everyones suggestions, and I think that we =
finally have a version that will be *acceptable* to everyone.<br> <br> =
I'd like to especially thank Stephen Farrell for his suggestions (which =
I somehow filed into a different label and missed) as well as Phillip, =
Paul, Richard and Jakob for their input and suggested text...<br> <br> I =
think that we have been fairly close to an acceptable charter for a long =
time now, but were getting hung up on misunderstandings and =
misinterpretations of what others were saying...<br> <br> So, please =
have another look at the charter and hopefully you will find it =
acceptable to you:<br> <a =
href=3D"http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure" =
target=3D"_blank">http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure<=
/a><br> <br> If parts are not acceptable, please do me 3 favors:<br> 1: =
Reread the unacceptable parts and try figure out if what you are =
objecting to is what the sentence is trying to say, or it is just a =
wording issue / differing uses of a term.<br> <br> 2: If &nbsp;you are =
OK with it being in the charter so that we (as a WG) can at least =
discuss the issue and come to consensus.<br> <br> and, most =
importantly:<br> 3: send text --- saying "Bah, paragraph X is the devil! =
eat flaming death, mongrel!" is *not* helpful... "How does the group =
feel about 'Foo blargh wumblet boop' instead of 'mumble'?" is...<br> =
<br> W<br> _______________________________________________<br> keyassure =
mailing list<br> <a =
href=3D"mailto:[email-masked]">[email-masked]</a><br> <a =
href=3D"https://www.ietf.org/mailman/listinfo/keyassure" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br> =
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a =
href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br> =
</div> _______________________________________________<br>keyassure =
mailing list<br><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br><a =
href=3D"https://www.ietf.org/mailman/listinfo/keyassure">https://www.ietf.=
org/mailman/listinfo/keyassure</a><br></blockquote></div><br></div></body>=
</html>=

--Apple-Mail-2-537730953--

Date: Fri, 1 Oct 2010 15:05:22 +0300
From: Ilari Liusvaara <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Latest spin at the chater...

On Fri, Oct 01, 2010 at 01:16:24AM -0400, Phillip Hallam-Baker wrote:
> 
> The policy mechanism should be orthogonal to the keying mechanism.
> 
> Existing experience of security policy ties the policy to protocols and not
> keys. Security policies are of the form 'must use SSL when using HTTP at
> example.com' and 'must use SSL with key conforming to trust criteria X when
> using HTTP...'

I'm not a fan of security policies in DNS. I would like more to see facts,
like:

* Client can upgrade the connection (to this or that) after connecting
for this service (downgrade-attack-free upgrades)
* Client can connect securely (using this or that) to this service
(it will sniff the connection type)
* Client can obtain equivalent secure service (using this or that) from
that service (service redirect)

* This service supports security, client MAY use it.
* This service is sensitive, client SHOULD use security.
* This service doesn't yield useful nonsecure service, client MUST use
security.

* The certificate will chain to one of these TAs.

Of course, the client is free to ignore this, but it will do so on peril
of itself and its user.

This is pretty much everything one needs to have secure connection. One can
then send actual (protocol dependent) policy (securely) via that.

> I don't see any particular reason to separate TLS and non TLS protocols
> either. So far the only aspects of the protocol that are tied to TLS are the
> 'cert enumeration' mechanism and the cert type identifier.

I thought the idea was to form some "core" with some free "parameters" and
then instantiate that for each protocol.

Anyway, spec for TLS can be transformed into spec for IPSEC with little
search-and-replace.

> Given the choice, I would much prefer a key assurance mechanism that
> supports any security protocol but only works with X.509 certs than one the
> only works with TLS but has the option of using additional cert formats that
> are either essentially historic or make no real sense in the context of a
> hierarchical naming structure (PGP).

I think OpenPGP would make great sense here. Its way simpler if you just
need key container for TLS (since TLS doesn't have "raw key cert" format).
 
-Ilari