Subject: Re: [keyassure] Question about Keyassure and IPsec
From: Martin Rex <[email-masked]>
To: [email-masked] (Paul Hoffman)
Cc: [email-masked]
Date: Thu, 25 Nov 2010 02:14:35 +0100 (MET)
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>

Paul Hoffman wrote:
> 
> At 5:26 PM +0100 11/24/10, Martin Rex wrote:
> >
> >TLS does not have a trust model.  It is at most a better-than-nothing
> >untrusted key "introduction" scheme.
> 
> This is utter nonsense. There is a completely-defined trust model:
> the TLS server must authenticate itself with a PKIX certificate that
> chains to a trust anchor in the TLS client. The fact that the
> implementation of that trust model has been openly perverted by
> browser and OS vendors who stuff dozens or hundreds of trust anchors
> into the client does not negate the fact that TLS itself has a simple
> and well-defined trust model.

We're fighting about terminology here.

The technology TLS as described in rfc-2246,rfc-4346 and rfc-5246
does not have and does not define _any_ trust model.

The certificate path validation described in rfc-5280 and implemented
in the PKI software part of TLS stacks is an algorithm and not a trust model.

When folks refer to "PKI" when talking about TLS, they normally refer
to the set of 50+ self-signed rootCA certs distributed with every
WebBrowser, preconfigured as trust anchors.

That is no trust model, that is a pretty bold concept of faith. 
There is zero trust involved.  99.999% of the folks using that set
of self-signed rootCAs (plus a bunch of intermediate CA certs)
pre-configured as trusted by software distributors do _NOT_ know
and do _NOT_ care what organizations and what CAs are covered by
und under what terms CAs are issued.  There is actually no known
algorithm to reliably figure out which CAs are valid under that
configuration.

And think of Microsoft Windows 7, where you do not even know any longer
which rootCAs actually exist, because the Browser will automatically
and dynamically download missing rootCA certs.  Deleting such roots
manually doesn't get you anywhere, you will need to manually move
rootCAs that you don't trust over into "Untrusted Certs" to disable it.
But unless you tried to verify a chain to a particular root, it doesn't
exist under trusted roots yet.

The so-called "PKI" that is commonly used with TLS is definitely
not a "model of trust", for any sensible meaning of the word "trust".

>
> >Trust between organization through keyassure?
> >I have strong doubts that this will work.
> 
> Same here, but that doesn't mean that we should not do the work
> for the organizations where it would actually help.

Fair enough.  I didn't mean to preclude this.
I just wanted to point out the the cross-organization
key introduction scheme that Browsers currently use during
server endpoint identification works across HTTP CONNECT proxies
even when organizations use seperate DNS universes throughout
their internal network.

-Martin

Date: Wed, 24 Nov 2010 16:21:47 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Yoav Nir <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Question about Keyassure and IPsec

On Wed, 24 Nov 2010, Yoav Nir wrote:

> I am not in any way suggesting that this is complicated or will take a 20-page RFC to explain. I think the end result would be a 2-page document (plus boilerplate).
>
> For example, we're looking in DNS, so it makes sense that ID Type will be FQDN. Do we also allow IP address and tell people to do a reverse lookup?  I hope not, but can't rule it out before it's discussed. Also, maybe RFC822 addresses for users?
>
> Cert Encoding should be X509, or RAW RSA key, or a new encoding specifically created for this application. We would probably follow the example of TLS.
>
> PAD entries would be of the DNS type, or maybe RFC822 for users. Authentication data would have to hold something new and different to tell the IKE daemon to query the DNS for keys (and what to do if it can't?)
>
> OK, maybe 4 pages plus boilerplate.
>
> Point is, we already have something that works for TLS (or at least HTTPS). There's plenty of things that are wrong with the trust model, but it's generally functional. IKE still doesn't have a universal infrastructure for establishing trust between different organizations. For whatever reason, administrators are not willing to trust Verisign for communications between organizations. Maybe keyassure can fix this.

Look at RFC 4025, IPSECKEY. Other useful fields might be a "gateway"

Paul

From: Yoav Nir <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 24 Nov 2010 22:02:59 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Question about Keyassure and IPsec

On Nov 24, 2010, at 6:26 PM, Martin Rex wrote:

> Yoav Nir wrote:
>>=20
>> Point is, we already have something that works for TLS (or at least HTTP=
S).
>> There's plenty of things that are wrong with the trust model, it's
>> generally functional.
>=20
> TLS does not have a trust model.  It is at most a better-than-nothing
> untrusted key "introduction" scheme

Of course there's a trust model. Even in the context of the browser, I trus=
t a (relatively) small group of CAs to never sign an EE unless that DN or a=
lternate name correctly identifies the owner, and never to sign a CA certif=
icate for anyone who would do otherwise. I might be a little too trusting.

>> IKE still doesn't have a universal infrastructure
>> for establishing trust between different organizations. For whatever
>> reason, administrators are not willing to trust Verisign for
>> communications between organizations. Maybe keyassure can fix this.
>=20
> Trust between organization through keyassure?
> I have strong doubts that this will work.

Actually, I'm not sure what "trust" means in this context. Let's suppose fo=
r a moment that Check Point is a customer of SAP. Relating to this business=
 relationship, some emails are exchanged. Occasionally, we might run into a=
 problem, talk (through VoIP?) to a support engineer, and they might tell u=
p to upload this or that file to your FTP server. All this data going back =
and forth might be sensitive (might contain customer data), so it would be =
good if it was encrypted.  We can do it the hard way, by configuring a mutu=
ally trusted CA, or by distributing shared secrets, or keyassure may give u=
s an easier way.

I don't need to trust SAP. The only trust I need is to know that the gatewa=
y on the other side actually belongs to SAP, and that it's showing me the c=
orrect certificate in IKE. This is just the same as trusting that the addre=
ss I get by typing "nslookup www.sap.com" actually belongs to SAP. Both can=
 be enabled by DNSSEC. No?

>=20
> We're running the entire company in a seperate DNS universe,
> and there is no possibility to obtain DNS records from the
> internet inside the company.  Any communication to other organizations
> is via application level gateways (which are located in the DMZ and
> are the only components that can resolve internet DNS names.
>=20
> For security and robustness, if a company has business- or mission-critic=
al
> internal IT systems, those should not have dependicies of the internet
> connection being up and running, or particular services like DNS being
> fully functional in order for company-internal communication to work.
> Creating any such dependencies would be calling for disaster.
>=20
> -Martin

Date: Wed, 24 Nov 2010 11:36:40 -0600 (GMT-06:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Question about Keyassure and IPsec
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Paul and all,

-----Original Message-----
>From: Paul Hoffman <[email-masked]>
>Sent: Nov 24, 2010 10:59 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: [keyassure] Question about Keyassure and IPsec
>
>At 5:26 PM +0100 11/24/10, Martin Rex wrote:
>>Yoav Nir wrote:
>>>
>>> Point is, we already have something that works for TLS (or at least HTTPS).
>>> There's plenty of things that are wrong with the trust model, it's
>>> generally functional.
>>
>>TLS does not have a trust model.  It is at most a better-than-nothing
>>untrusted key "introduction" scheme.
>
>This is utter nonsense. There is a completely-defined trust model: the TLS server must authenticate itself with a PKIX certificate that chains to a trust anchor in the TLS client. The fact that the implementation of that trust model has been openly perverted by browser and OS vendors who stuff dozens or hundreds of trust anchors into the client does not negate the fact that TLS itself has a simple and well-defined trust model.

  Your right.  The problem is that the Trust model itself is not
trustworthy or at a minimum as it has been perverted as you say
and/or as there is stark COI's built within the 'Simple and well-
defined trust model' demonstrates the at least possibility that
as a useful mechinisim it is lacking accordingly.
>
>> > IKE still doesn't have a universal infrastructure
>>> for establishing trust between different organizations. For whatever
>>> reason, administrators are not willing to trust Verisign for
>>> communications between organizations. Maybe keyassure can fix this.
>>
>>Trust between organization through keyassure?
>>I have strong doubts that this will work.
>
>Same here, but that doesn't mean that we should not do the work for the organizations where it would actually help.

  Completely agreed!  The most in need are those that seemingly 
wish to pervert it.  And that is a difficult task, but worth while.
>
>--Paul Hoffman, Director
>--VPN Consortium
>_______________________________________________
>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: Wed, 24 Nov 2010 08:59:35 -0800
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Question about Keyassure and IPsec

At 5:26 PM +0100 11/24/10, Martin Rex wrote:
>Yoav Nir wrote:
>>
>> Point is, we already have something that works for TLS (or at least HTTPS).
>> There's plenty of things that are wrong with the trust model, it's
>> generally functional.
>
>TLS does not have a trust model.  It is at most a better-than-nothing
>untrusted key "introduction" scheme.

This is utter nonsense. There is a completely-defined trust model: the TLS server must authenticate itself with a PKIX certificate that chains to a trust anchor in the TLS client. The fact that the implementation of that trust model has been openly perverted by browser and OS vendors who stuff dozens or hundreds of trust anchors into the client does not negate the fact that TLS itself has a simple and well-defined trust model.

> > IKE still doesn't have a universal infrastructure
>> for establishing trust between different organizations. For whatever
>> reason, administrators are not willing to trust Verisign for
>> communications between organizations. Maybe keyassure can fix this.
>
>Trust between organization through keyassure?
>I have strong doubts that this will work.

Same here, but that doesn't mean that we should not do the work for the organizations where it would actually help.

--Paul Hoffman, Director
--VPN Consortium

From: Martin Rex <[email-masked]>
To: [email-masked] (Yoav Nir)
Date: Wed, 24 Nov 2010 17:26:57 +0100 (MET)
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Question about Keyassure and IPsec
Reply-To: [email-masked]

Yoav Nir wrote:
> 
> Point is, we already have something that works for TLS (or at least HTTPS).
> There's plenty of things that are wrong with the trust model, it's
> generally functional.

TLS does not have a trust model.  It is at most a better-than-nothing
untrusted key "introduction" scheme.

>
> IKE still doesn't have a universal infrastructure
> for establishing trust between different organizations. For whatever
> reason, administrators are not willing to trust Verisign for
> communications between organizations. Maybe keyassure can fix this.

Trust between organization through keyassure?
I have strong doubts that this will work.

We're running the entire company in a seperate DNS universe,
and there is no possibility to obtain DNS records from the
internet inside the company.  Any communication to other organizations
is via application level gateways (which are located in the DMZ and
are the only components that can resolve internet DNS names.

For security and robustness, if a company has business- or mission-critical
internal IT systems, those should not have dependicies of the internet
connection being up and running, or particular services like DNS being
fully functional in order for company-internal communication to work.
Creating any such dependencies would be calling for disaster.

-Martin

Date: Wed, 24 Nov 2010 09:46:56 -0600 (GMT-06:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Question about Keyassure and IPsec
Reply-To: "Jeffrey A. Williams" <[email-masked]>

All,

-----Original Message-----
>From: Paul Hoffman <[email-masked]>
>Sent: Nov 24, 2010 8:36 AM
>To: Yoav Nir <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [keyassure] Question about Keyassure and IPsec
>
>At 2:30 PM +0200 11/24/10, Yoav Nir wrote:
>> > At 12:24 PM +0200 11/21/10, Yoav Nir wrote:
>>>> I have not yet thought through all the implications for PAD, ID Type, and the cert encoding fields, but I think it should be doable.
>>
>>I am not in any way suggesting that this is complicated or will take a 20-page RFC to explain. I think the end result would be a 2-page document (plus boilerplate).
>
>Hopefully true. And, if we determine that early enough, it could just get folded into the TLS document.
>
>>For example, we're looking in DNS, so it makes sense that ID Type will be FQDN. Do we also allow IP address and tell people to do a reverse lookup?  I hope not, but can't rule it out before it's discussed.
>
>Here, we disagree. Given that many/most common IPsec gateway-to-gateway deployments rely on IP addresses, this WG needs to think about how to deal with them for IPsec (or to punt and say "only works for domain names"). That will be an interesting discussion.
>
>>Also, maybe RFC822 addresses for users?
>
>I don't think this is needed for the use case being dealt with here: in IPsec, those are almost exclusively used for clients, not for gateways.
>
>>Cert Encoding should be X509, or RAW RSA key, or a new encoding specifically created for this application. We would probably follow the example of TLS.
>
>Hopefully true.
>
>>PAD entries would be of the DNS type, or maybe RFC822 for users. Authentication data would have to hold something new and different to tell the IKE daemon to query the DNS for keys (and what to do if it can't?)
>
>And here we go down the rabbit hole, maybe not too far.
>
>>OK, maybe 4 pages plus boilerplate.
>
>That would be OK too.
>
>>Point is, we already have something that works for TLS (or at least HTTPS). There's plenty of things that are wrong with the trust model, but it's generally functional. IKE still doesn't have a universal infrastructure for establishing trust between different organizations. For whatever reason, administrators are not willing to trust Verisign for communications between organizations. Maybe keyassure can fix this.
>
>That's why it is in the charter!

  Right!  Still the trust model is trustworthy if we still have CA's
that are also trust anchors AND have a history of their CERT DB being
breached as well as passing out CERTS under questionable circumstances.
Ergo, a new and better trust model is sorely needed.
>
>--Paul Hoffman, Director
>--VPN Consortium

>_________________________

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

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

Date: Wed, 24 Nov 2010 06:36:49 -0800
To: Yoav Nir <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Question about Keyassure and IPsec

At 2:30 PM +0200 11/24/10, Yoav Nir wrote:
> > At 12:24 PM +0200 11/21/10, Yoav Nir wrote:
>>> I have not yet thought through all the implications for PAD, ID Type, and the cert encoding fields, but I think it should be doable.
>
>I am not in any way suggesting that this is complicated or will take a 20-page RFC to explain. I think the end result would be a 2-page document (plus boilerplate).

Hopefully true. And, if we determine that early enough, it could just get folded into the TLS document.

>For example, we're looking in DNS, so it makes sense that ID Type will be FQDN. Do we also allow IP address and tell people to do a reverse lookup?  I hope not, but can't rule it out before it's discussed.

Here, we disagree. Given that many/most common IPsec gateway-to-gateway deployments rely on IP addresses, this WG needs to think about how to deal with them for IPsec (or to punt and say "only works for domain names"). That will be an interesting discussion.

>Also, maybe RFC822 addresses for users?

I don't think this is needed for the use case being dealt with here: in IPsec, those are almost exclusively used for clients, not for gateways.

>Cert Encoding should be X509, or RAW RSA key, or a new encoding specifically created for this application. We would probably follow the example of TLS.

Hopefully true.

>PAD entries would be of the DNS type, or maybe RFC822 for users. Authentication data would have to hold something new and different to tell the IKE daemon to query the DNS for keys (and what to do if it can't?)

And here we go down the rabbit hole, maybe not too far.

>OK, maybe 4 pages plus boilerplate.

That would be OK too.

>Point is, we already have something that works for TLS (or at least HTTPS). There's plenty of things that are wrong with the trust model, but it's generally functional. IKE still doesn't have a universal infrastructure for establishing trust between different organizations. For whatever reason, administrators are not willing to trust Verisign for communications between organizations. Maybe keyassure can fix this.

That's why it is in the charter!

--Paul Hoffman, Director
--VPN Consortium

From: Yoav Nir <[email-masked]>
To: Paul Hoffman <[email-masked]>
Date: Wed, 24 Nov 2010 14:30:45 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Question about Keyassure and IPsec

On Nov 22, 2010, at 1:48 AM, Paul Hoffman wrote:

> At 6:36 PM -0500 11/21/10, Phillip Hallam-Baker wrote:
>> PKIX has no semantics that are protocol specific.
>=20
> Other than the EKUs, that is correct.
>=20
>> If we think we need protocol specific semantics for key assure, isn't th=
at a sign that we are probably doing something wrong?
>=20
> No, it is a sign that we are not trying to slap a one-size-fits-all set o=
f semantics across dissimilar protocols. As Yoav said in his earlier messag=
e:
>=20
> At 12:24 PM +0200 11/21/10, Yoav Nir wrote:
>> I have not yet thought through all the implications for PAD, ID Type, an=
d the cert encoding fields, but I think it should be doable.

I am not in any way suggesting that this is complicated or will take a 20-p=
age RFC to explain. I think the end result would be a 2-page document (plus=
 boilerplate).

For example, we're looking in DNS, so it makes sense that ID Type will be F=
QDN. Do we also allow IP address and tell people to do a reverse lookup?  I=
 hope not, but can't rule it out before it's discussed. Also, maybe RFC822 =
addresses for users?

Cert Encoding should be X509, or RAW RSA key, or a new encoding specificall=
y created for this application. We would probably follow the example of TLS=
.

PAD entries would be of the DNS type, or maybe RFC822 for users. Authentica=
tion data would have to hold something new and different to tell the IKE da=
emon to query the DNS for keys (and what to do if it can't?)

OK, maybe 4 pages plus boilerplate.

Point is, we already have something that works for TLS (or at least HTTPS).=
 There's plenty of things that are wrong with the trust model, but it's gen=
erally functional. IKE still doesn't have a universal infrastructure for es=
tablishing trust between different organizations. For whatever reason, admi=
nistrators are not willing to trust Verisign for communications between org=
anizations. Maybe keyassure can fix this.

Yoav

Date: Tue, 23 Nov 2010 21:18:22 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Updated Charter (after Beijing)

On Tue, 23 Nov 2010, Paul Hoffman wrote:

>> I am not sure about "require".  This phrasing excludes usage of passive
>> attack protection or leap of faith based. Is that intentional?
>
> It was, yes. We don't care about passive attacks: seeing what is in the certs that will be used poses no threat to either party. We explicitly do not allow "leap of faith", given that a successful active attacker can make TLS weaker after the proposed changes than before.

Understood. Thanks for the explanation.

Paul

From: Warren Kumari <[email-masked]>
Date: Tue, 23 Nov 2010 20:53:10 -0500
To: Stephen Farrell <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Updated Charter (after Beijing)

On Nov 23, 2010, at 6:01 PM, Stephen Farrell wrote:

>=20
>=20
> On 23/11/10 19:37, Paul Hoffman wrote:
>>> (Or have I got my
>>> terminology confused?)
>>=20
>> No, and yes. DNSSEC has nothing to do with registrars: it has to do =
with DNS zone operators. Those might be the same entity, but often is =
not.
>=20
> Ah. So then if the charter talked about zone operators
> rather than domain operators that'd sort that out
> for this terminology-challenged reader at least.

Hmmm, I have done this, and *think* that it still makes sense / flows =
well.

I have also added your (Stephen) suggested text on the "last hop" bit...=20=

I think the we finally have this right, and are getting close to the =
bikeshed point / tweaking bits 'cos we can...

W

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

Date: Tue, 23 Nov 2010 23:01:44 +0000
From: Stephen Farrell <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Updated Charter (after Beijing)

On 23/11/10 19:37, Paul Hoffman wrote:
>> (Or have I got my
>> terminology confused?)
> 
> No, and yes. DNSSEC has nothing to do with registrars: it has to do with DNS zone operators. Those might be the same entity, but often is not.

Ah. So then if the charter talked about zone operators
rather than domain operators that'd sort that out
for this terminology-challenged reader at least.

S.

From: Warren Kumari <[email-masked]>
To: Ben Laurie <[email-masked]>
Date: Tue, 23 Nov 2010 16:45:07 -0500
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Updated Charter (after Beijing)

On Nov 23, 2010, at 2:51 PM, Ben Laurie wrote:

> On 23 November 2010 19:37, Paul Hoffman <[email-masked]> wrote:
>> At 11:25 AM -0500 11/23/10, Paul Wouters wrote:
>>> I like that less actually. Maybe its just me (I don't know the
>>> details of what an implementer would have to do), but shouldn't
>>> the WG say how to secure the "last hop"?
>>
>> That feels a lot like mission creep to me, but it also points out  
>> that the IETF doesn't yet have good advice for doing this. FWIW,  
>> "this" is actually two things:
>> a) Getting the fact that a response was DNSSEC-validated to a host
>> b) Getting that fact to an application
>
> Continuing the existing digression: I've never understood this
> problem: the app does DNSSEC itself. Whatever facts it needs, it gets
> for itself. There is no "last hop". Why complicate matters?

Well, some folk would like to be able to provide DNSSEC validating  
resolver as a service, and then something like an SSL VPN / TSIG /  
SIG(0) / similar magic to provide tamper-resistance and protection of  
the AD bit, and then the belief is that the app can just trust this.
This seems like bad juju to me, but the text was included to allow the  
WG to explore the idea and decided...

My personal view is that the app (or OS on the host) should do the  
validation, but...

>
>>
>>> To be clear: I don't think this WG should define new ways to
>>> secure the "last hop," I just think saying how that works needs
>>> to be part of the spec - hopefully by reference.
>>
>> There is general agreement in the DNS community that we don't have  
>> good references on doing (a) above, and we have none at all on  
>> doing (b).

Yup... it seems surprising to me that this isn't an issue that has  
been addressed more (though, not quite surprising enough that I'm  
willing to tackle it myself :-))

>>
>>> How about:
>>>
>>> "the protocols and mechanisms designed by this working group require
>>> securing the "last hop" by operating a local DNS resolver or  
>>> securing
>>> the connection to remote resolver - this WG will not specify new
>>> mechanisms to secure that hop, but will reference existing
>>> specifications or document existing methods in order to allow
>>> implementations to interoperate securely."
>>
>> That works for me too.

+1

W
>>
>> --Paul Hoffman, Director
>> --VPN Consortium
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

-- 
There are only 10 types of people in this world -- those who  
understand binary arithmetic and those who don't.

From: Steve Schultze <[email-masked]>
Date: Tue, 23 Nov 2010 15:19:06 -0500
To: Ben Laurie <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Updated Charter (after Beijing)

--Apple-Mail-5-851217732
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 23, 2010, at 2:51 PM, Ben Laurie wrote:
> On 23 November 2010 19:37, Paul Hoffman <[email-masked]> wrote:
>> At 11:25 AM -0500 11/23/10, Paul Wouters wrote:
>>> I like that less actually. Maybe its just me (I don't know the
>>> details of what an implementer would have to do), but shouldn't
>>> the WG say how to secure the "last hop"?
>>=20
>> That feels a lot like mission creep to me, but it also points out =
that the IETF doesn't yet have good advice for doing this. FWIW, "this" =
is actually two things:
>> a) Getting the fact that a response was DNSSEC-validated to a host
>> b) Getting that fact to an application
>=20
> Continuing the existing digression: I've never understood this
> problem: the app does DNSSEC itself. Whatever facts it needs, it gets
> for itself. There is no "last hop". Why complicate matters?

I don't think it's a digression, but rather a question in our critical =
path.

I'm not sure what you mean when you say that the app does DNSSEC itself. =
 What is an example?  The reality is that the *most* that most apps do =
is trust the AD bit, which is entirely insufficient.  I believe that =
even the Firefox DNSSEC validator built by Ond=C5=99ej's guys is doing =
this (and they know what they're doing).  The reality is that client =
validation is not built into current clients or the underlying crypto =
libs.  This is why Kaminsky is focusing on several solutions to the =
problem:

http://www.slideshare.net/RecursionVentures/dki-2

Or have I misunderstood your comment?=

--Apple-Mail-5-851217732
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><div>On Nov 23, 2010, at 2:51 PM, Ben Laurie =
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; ">On 23 =
November 2010 19:37, Paul Hoffman &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
wrote:<br><blockquote type=3D"cite">At 11:25 AM -0500 11/23/10, Paul =
Wouters wrote:<br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">I like that less actually. Maybe its just me (I don't know =
the<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">details of what an implementer would have to do), but =
shouldn't<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">the WG say how to secure the =
"last hop"?<br></blockquote></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">That feels a =
lot like mission creep to me, but it also points out that the IETF =
doesn't yet have good advice for doing this. FWIW, "this" is actually =
two things:<br></blockquote><blockquote type=3D"cite">a) Getting the =
fact that a response was DNSSEC-validated to a =
host<br></blockquote><blockquote type=3D"cite">b) Getting that fact to =
an application<br></blockquote><br>Continuing the existing digression: =
I've never understood this<br>problem: the app does DNSSEC itself. =
Whatever facts it needs, it gets<br>for itself. There is no "last hop". =
Why complicate matters?</span></blockquote></div><br><div>I don't think =
it's a digression, but rather a question in our critical =
path.</div><div><br></div><div>I'm not sure what you mean when you say =
that the app does DNSSEC itself. &nbsp;What is an example? &nbsp;The =
reality is that the *most* that most apps do is trust the AD bit, which =
is entirely insufficient. &nbsp;I believe that even the Firefox DNSSEC =
validator built by Ond=C5=99ej's guys is doing this (and they know what =
they're doing). &nbsp;The reality is that client validation is not built =
into current clients or the underlying crypto libs. &nbsp;This is why =
Kaminsky is focusing on several solutions to the =
problem:</div><div><br></div><div><a =
href=3D"http://www.slideshare.net/RecursionVentures/dki-2">http://www.slid=
eshare.net/RecursionVentures/dki-2</a></div><div><br></div><div>Or have =
I misunderstood your comment?</div></body></html>=

--Apple-Mail-5-851217732--

Date: Tue, 23 Nov 2010 15:17:36 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Updated Charter (after Beijing)

On Tue, Nov 23, 2010 at 07:51:19PM +0000, Ben Laurie wrote:
> Continuing the existing digression: I've never understood this
> problem: the app does DNSSEC itself. Whatever facts it needs, it gets
> for itself. There is no "last hop". Why complicate matters?

Doesn't matter why: its None Of Our Business.  I think the idea here
is to specify how to do something given other deployed pieces of
network goodness.  Specifying all that other goodness is not our job.

No?

A

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

Date: Tue, 23 Nov 2010 22:02:45 +0200
From: Yaron Sheffer <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Updated Charter (after Beijing)

Hi,

we had a long discussion before Beijing on the missing problem 
statement. I would expect some of it to find its way into the charter.

Thanks,
	Yaron
>
> Message: 1
> Date: Tue, 23 Nov 2010 09:29:59 +0100
> From: Ond?ej Sur?<[email-masked]>
> Subject: [keyassure] Updated Charter (after Beijing)
> To: [email-masked]
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi there,
>
> We believe we have managed to integrate all the comments, suggestions,
> the latest spin at the charter is:
> http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure
>
> Diffs are:
> http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure?action=diff&version=12
>
> We added:
> - note about need for DNSSEC
> - note about general policy being out of scope
> - moved milestones so we have more time to discuss
>
> All was done with cooperation with ADs.  Many thanks to them.
>
> Ondrej&  Warren

Date: Tue, 23 Nov 2010 19:51:19 +0000
From: Ben Laurie <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Updated Charter (after Beijing)

On 23 November 2010 19:37, Paul Hoffman <[email-masked]> wrote:
> At 11:25 AM -0500 11/23/10, Paul Wouters wrote:
>>I like that less actually. Maybe its just me (I don't know the
>>details of what an implementer would have to do), but shouldn't
>>the WG say how to secure the "last hop"?
>
> That feels a lot like mission creep to me, but it also points out that the IETF doesn't yet have good advice for doing this. FWIW, "this" is actually two things:
> a) Getting the fact that a response was DNSSEC-validated to a host
> b) Getting that fact to an application

Continuing the existing digression: I've never understood this
problem: the app does DNSSEC itself. Whatever facts it needs, it gets
for itself. There is no "last hop". Why complicate matters?

>
>>To be clear: I don't think this WG should define new ways to
>>secure the "last hop," I just think saying how that works needs
>>to be part of the spec - hopefully by reference.
>
> There is general agreement in the DNS community that we don't have good references on doing (a) above, and we have none at all on doing (b).
>
>>How about:
>>
>>"the protocols and mechanisms designed by this working group require
>>securing the "last hop" by operating a local DNS resolver or securing
>>the connection to remote resolver - this WG will not specify new
>>mechanisms to secure that hop, but will reference existing
>>specifications or document existing methods in order to allow
>>implementations to interoperate securely."
>
> That works for me too.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

Date: Tue, 23 Nov 2010 11:37:49 -0800
To: Paul Wouters <[email-masked]>, Stephen Farrell <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Updated Charter (after Beijing)

At 11:25 AM -0500 11/23/10, Paul Wouters wrote:
>On Tue, 23 Nov 2010, Paul Hoffman wrote:
>
>>Current:
>>the protocols and mechanisms designed by this working group require securing the "last hop" by operating a local DNS resolver ...
>>...snip...
>>... by operating a local DNS resolver or securing the connection to remote resolver, neither of which will be specified by this WG.
>
>I am not sure about "require".  This phrasing excludes usage of passive
>attack protection or leap of faith based. Is that intentional?

It was, yes. We don't care about passive attacks: seeing what is in the certs that will be used poses no threat to either party. We explicitly do not allow "leap of faith", given that a successful active attacker can make TLS weaker after the proposed changes than before.

>For instance with an anonsec (ipsec) connection, a non-dnssec secured
>key from dns might still be preferred over using a plaintext connection,
>or an https connection might still be preferred over an http connection
>despite the unverified nature of the (self signed) cert.

Even if the client is using anonsec with its chosen recursive resolver, there is an active attack that makes TLS weaker, so that is not good enough.

This WG is *not* discussing the "HTTPS vs HTTP" issue.

At 4:31 PM +0000 11/23/10, Stephen Farrell wrote:
>On 23/11/10 16:04, Paul Hoffman wrote:
> > At 11:46 AM +0000 11/23/10, Stephen Farrell wrote:
>>> The nit: I assume that "and thus shown to be authentically from the
>...snip...
> > that these bindings can be integrity-protected using DNSSEC, thus showing them to be authentically from the domain operator,
>
>Well....doesn't the DNSSEC signature really show (modulo good
>key mgmt) that the records are from the domain registrar who
>is generally not the domain operator? (Or have I got my
>terminology confused?)

No, and yes. DNSSEC has nothing to do with registrars: it has to do with DNS zone operators. Those might be the same entity, but often is not.

>We do hope that registrars put in the right stuff, but I
>don't believe the DNSSEC signature shows you that.

Correct: it does not. It shows that the DNS zone operator put in the data that you are looking at.

>How about getting rid of the last part:
>
>"that these bindings can be integrity-protected using DNSSEC."

That's OK too, but given that it might clear up some misconceptions that some people have, maybe it is better to leave it in.

> >> The possibly more substantive question: the charter says that "last
>>> hop" security is needed, but its not clear to me whether this WG will
>...snip...
> > the protocols and mechanisms designed by this working group require securing the "last hop" by operating a local DNS resolver or securing the connection to remote resolver, neither of which will be specified by this WG.
>
>I like that less actually. Maybe its just me (I don't know the
>details of what an implementer would have to do), but shouldn't
>the WG say how to secure the "last hop"?

That feels a lot like mission creep to me, but it also points out that the IETF doesn't yet have good advice for doing this. FWIW, "this" is actually two things:
a) Getting the fact that a response was DNSSEC-validated to a host
b) Getting that fact to an application

>To be clear: I don't think this WG should define new ways to
>secure the "last hop," I just think saying how that works needs
>to be part of the spec - hopefully by reference.

There is general agreement in the DNS community that we don't have good references on doing (a) above, and we have none at all on doing (b).

>How about:
>
>"the protocols and mechanisms designed by this working group require
>securing the "last hop" by operating a local DNS resolver or securing
>the connection to remote resolver - this WG will not specify new
>mechanisms to secure that hop, but will reference existing
>specifications or document existing methods in order to allow
>implementations to interoperate securely."

That works for me too.

--Paul Hoffman, Director
--VPN Consortium

Date: Tue, 23 Nov 2010 12:57:16 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Updated Charter (after Beijing)

--0016e6434ae86e9ae40495bc1a12
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Since the milestones have been changed, the fact that they have not been
changed enough is hardly repeating myself.

The charter is an agreement between the WG and the IETF, not just the AD an=
d
the chairs.

I have stated the reason I think the milestones are poorly chosen, you have
not even stated you think they are achievable, still less given a
justification.

On Tue, Nov 23, 2010 at 10:42 AM, Ond=F8ej Sur=FD <[email-masked]> wrot=
e:

> Phillip,
>
> you said it before and we have consulted the milestones with ADs on our
> last confcall and the result of our agreement is in the updated charter.
> So unless you have a specific proposal how we should change the milestone=
s
> and the people here will agree with you, there's no need to repeat what y=
ou
> have already said.
>
> Also please keep on topic.  DNSSEC deployment, SDMI or OpenID is out of
> topic here.
>
> Thank you,
> Ondrej
>
>
> On 23.11.2010 14:09, Phillip Hallam-Baker wrote:
>
>> I agree with Stephen on the goals.
>>
>> Unrealistic goals slow things down. They don't make anything happen
>> faster.
>>
>> What I have seen happen repeatedly in standards processes is groups have
>> adopted goals they can't possibly meet and then the impossible goals
>> become the reason not to look at the real issues.
>>
>> We would have started deployment of DNSSEC in 2002 only some people
>> thought there was no time to consider real world deployment issues. Then
>> when the EU privacy thing came up wit literally spent three years
>> arguing over whether there was time to consider an issue that took 2
>> months to fix once we were allowed to consider it.
>>
>> And don't get me started on SDMI or OpenID.
>>
>>
>> This particular problem cuts across layers 5, 7 and 8. It is a security
>> problem.
>>
>>
>> On Tue, Nov 23, 2010 at 6:46 AM, Stephen Farrell
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>    One hopefully minor nit and one question.
>>
>>    The nit: I assume that "and thus shown to be authentically from the
>>    domain operator" doesn't require e.g. an additional signature other
>>    than that provided by DNSSEC - the "from the domain operator" could
>>    be read to imply that it does require an additional signature. Not
>>    sure how best to re-word that but maybe something like "providing
>>    strong evidence that the public key record has not been tampered
>>    with since being inserted in the DNS" or something. (I'd have no
>>    problem if an additional signature were allowed, e.g. if the record
>>    contained an X.509 cert, but I didn't think we wanted to insist
>>    on that always, at least not in the charter.)
>>
>>    The possibly more substantive question: the charter says that "last
>>    hop" security is needed, but its not clear to me whether this WG will
>>    specify ways to do that for an implementer that doesn't already
>>    know how. (The "or by other means" phrase is pretty vague.) Am I
>>    right in thinking that one of the drafts listed will include that
>>    (by reference is fine if good references exist). If the answer is
>>    yes, then it might be worth saying so, (and maybe get rid of the
>>    "or by other means" phrase). If the answer is no, then I think
>>    that'd be a problem since I'd bet it'd lead to implementers making
>>    the frequently bad assumption that someone else has looked after
>>    the "last hop."
>>
>>    Oh - and I bet a beer the September milestones slip:-)
>>
>>    Ta,
>>    Stephen.
>>
>>    On 23/11/10 08:29, Ond=F8ej Sur=FD wrote:
>>     > Hi there,
>>     >
>>     > We believe we have managed to integrate all the comments,
>>    suggestions,
>>     > the latest spin at the charter is:
>>     > http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure
>>     >
>>     > Diffs are:
>>     >
>>
>> http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure?action=3Ddiff&ve=
rsion=3D12
>>    <
>> http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure?action=3Ddiff&ve=
rsion=3D12
>> >
>>     >
>>     >
>>     > We added:
>>     > - note about need for DNSSEC
>>     > - note about general policy being out of scope
>>     > - moved milestones so we have more time to discuss
>>     >
>>     > All was done with cooperation with ADs.  Many thanks to them.
>>     >
>>     > Ondrej & Warren
>>    _______________________________________________
>>    keyassure mailing list
>>    [email-masked] <mailto:[email-masked]>
>>
>>    https://www.ietf.org/mailman/listinfo/keyassure
>>
>>
>>
>>
>> --
>> 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/

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

Since the milestones have been changed, the fact that they have not been ch=
anged enough is hardly repeating myself.=A0<div><br></div><div>The charter =
is an agreement between the WG and the IETF, not just the AD and the chairs=
.=A0</div>
<div><br></div><div><br></div><div>I have stated the reason I think the mil=
estones are poorly chosen, you have not even stated you think they are achi=
evable, still less given a justification.=A0<br><br></div><div><br><div cla=
ss=3D"gmail_quote">
On Tue, Nov 23, 2010 at 10:42 AM, Ond=F8ej Sur=FD <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-lef=
t:1px #ccc solid;padding-left:1ex;">
Phillip,<br>
<br>
you said it before and we have consulted the milestones with ADs on our las=
t confcall and the result of our agreement is in the updated charter.<br>
So unless you have a specific proposal how we should change the milestones =
and the people here will agree with you, there&#39;s no need to repeat what=
 you have already said.<br>
<br>
Also please keep on topic. =A0DNSSEC deployment, SDMI or OpenID is out of t=
opic here.<br>
<br>
Thank you,<br>
Ondrej<div class=3D"im"><br>
<br>
On 23.11.2010 14:09, Phillip Hallam-Baker 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">
I agree with Stephen on the goals.<br>
<br>
Unrealistic goals slow things down. They don&#39;t make anything happen fas=
ter.<br>
<br>
What I have seen happen repeatedly in standards processes is groups have<br=
>
adopted goals they can&#39;t possibly meet and then the impossible goals<br=
>
become the reason not to look at the real issues.<br>
<br>
We would have started deployment of DNSSEC in 2002 only some people<br>
thought there was no time to consider real world deployment issues. Then<br=
>
when the EU privacy thing came up wit literally spent three years<br>
arguing over whether there was time to consider an issue that took 2<br>
months to fix once we were allowed to consider it.<br>
<br>
And don&#39;t get me started on SDMI or OpenID.<br>
<br>
<br>
This particular problem cuts across layers 5, 7 and 8. It is a security<br>
problem.<br>
<br>
<br>
On Tue, Nov 23, 2010 at 6:46 AM, Stephen Farrell<br></div><div><div></div><=
div class=3D"h5">
&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">stephen.=
[email-masked]</a> &lt;mailto:<a href=3D"mailto:[email-masked]=
e" target=3D"_blank">[email-masked]</a>&gt;&gt; wrote:<br>
<br>
<br>
 =A0 =A0One hopefully minor nit and one question.<br>
<br>
 =A0 =A0The nit: I assume that &quot;and thus shown to be authentically fro=
m the<br>
 =A0 =A0domain operator&quot; doesn&#39;t require e.g. an additional signat=
ure other<br>
 =A0 =A0than that provided by DNSSEC - the &quot;from the domain operator&q=
uot; could<br>
 =A0 =A0be read to imply that it does require an additional signature. Not<=
br>
 =A0 =A0sure how best to re-word that but maybe something like &quot;provid=
ing<br>
 =A0 =A0strong evidence that the public key record has not been tampered<br=
>
 =A0 =A0with since being inserted in the DNS&quot; or something. (I&#39;d h=
ave no<br>
 =A0 =A0problem if an additional signature were allowed, e.g. if the record=
<br>
 =A0 =A0contained an X.509 cert, but I didn&#39;t think we wanted to insist=
<br>
 =A0 =A0on that always, at least not in the charter.)<br>
<br>
 =A0 =A0The possibly more substantive question: the charter says that &quot=
;last<br>
 =A0 =A0hop&quot; security is needed, but its not clear to me whether this =
WG will<br>
 =A0 =A0specify ways to do that for an implementer that doesn&#39;t already=
<br>
 =A0 =A0know how. (The &quot;or by other means&quot; phrase is pretty vague=
.) Am I<br>
 =A0 =A0right in thinking that one of the drafts listed will include that<b=
r>
 =A0 =A0(by reference is fine if good references exist). If the answer is<b=
r>
 =A0 =A0yes, then it might be worth saying so, (and maybe get rid of the<br=
>
 =A0 =A0&quot;or by other means&quot; phrase). If the answer is no, then I =
think<br>
 =A0 =A0that&#39;d be a problem since I&#39;d bet it&#39;d lead to implemen=
ters making<br>
 =A0 =A0the frequently bad assumption that someone else has looked after<br=
>
 =A0 =A0the &quot;last hop.&quot;<br>
<br>
 =A0 =A0Oh - and I bet a beer the September milestones slip:-)<br>
<br>
 =A0 =A0Ta,<br>
 =A0 =A0Stephen.<br>
<br>
 =A0 =A0On 23/11/10 08:29, Ond=F8ej Sur=FD wrote:<br>
 =A0 =A0 &gt; Hi there,<br>
 =A0 =A0 &gt;<br>
 =A0 =A0 &gt; We believe we have managed to integrate all the comments,<br>
 =A0 =A0suggestions,<br>
 =A0 =A0 &gt; the latest spin at the charter is:<br>
 =A0 =A0 &gt; <a href=3D"http://trac.tools.ietf.org/area/sec/trac/wiki/Keya=
ssure" target=3D"_blank">http://trac.tools.ietf.org/area/sec/trac/wiki/Keya=
ssure</a><br>
 =A0 =A0 &gt;<br>
 =A0 =A0 &gt; Diffs are:<br>
 =A0 =A0 &gt;<br>
 =A0 =A0<a href=3D"http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure?=
action=3Ddiff&amp;version=3D12" target=3D"_blank">http://trac.tools.ietf.or=
g/area/sec/trac/wiki/Keyassure?action=3Ddiff&amp;version=3D12</a><br>
 =A0 =A0&lt;<a href=3D"http://trac.tools.ietf.org/area/sec/trac/wiki/Keyass=
ure?action=3Ddiff&amp;version=3D12" target=3D"_blank">http://trac.tools.iet=
f.org/area/sec/trac/wiki/Keyassure?action=3Ddiff&amp;version=3D12</a>&gt;<b=
r>
 =A0 =A0 &gt;<br>
 =A0 =A0 &gt;<br>
 =A0 =A0 &gt; We added:<br>
 =A0 =A0 &gt; - note about need for DNSSEC<br>
 =A0 =A0 &gt; - note about general policy being out of scope<br>
 =A0 =A0 &gt; - moved milestones so we have more time to discuss<br>
 =A0 =A0 &gt;<br>
 =A0 =A0 &gt; All was done with cooperation with ADs. =A0Many thanks to the=
m.<br>
 =A0 =A0 &gt;<br>
 =A0 =A0 &gt; Ondrej &amp; Warren<br>
 =A0 =A0_______________________________________________<br>
 =A0 =A0keyassure mailing list<br></div></div>
 =A0 =A0<a href=3D"mailto:[email-masked]" target=3D"_blank">keyassure@i=
etf.org</a> &lt;mailto:<a href=3D"mailto:[email-masked]" target=3D"_bla=
nk">[email-masked]</a>&gt;<div class=3D"im"><br>
 =A0 =A0<a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=
=3D"_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
<br>
<br>
<br>
<br>
--<br>
Website: <a href=3D"http://hallambaker.com/" target=3D"_blank">http://halla=
mbaker.com/</a><br>
<br>
</div></blockquote>
<br><div><div></div><div class=3D"h5">
<br>
-- <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>

--0016e6434ae86e9ae40495bc1a12--

Date: Tue, 23 Nov 2010 16:31:14 +0000
From: Stephen Farrell <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Updated Charter (after Beijing)

On 23/11/10 16:04, Paul Hoffman wrote:
> At 11:46 AM +0000 11/23/10, Stephen Farrell wrote:
>> The nit: I assume that "and thus shown to be authentically from the
>> domain operator" doesn't require e.g. an additional signature other
>> than that provided by DNSSEC - the "from the domain operator" could
>> be read to imply that it does require an additional signature. Not
>> sure how best to re-word that but maybe something like "providing
>> strong evidence that the public key record has not been tampered
>> with since being inserted in the DNS" or something. (I'd have no
>> problem if an additional signature were allowed, e.g. if the record
>> contained an X.509 cert, but I didn't think we wanted to insist
>> on that always, at least not in the charter.)
> 
> Fully agree about not wanting to suggest that another signature is needed. Would the following change fix this for you:
> 
> Current:
> that these bindings can be integrity-protected (and thus shown to be authentically from the domain operator) using DNSSEC
> 
> Proposed:
> that these bindings can be integrity-protected using DNSSEC, thus showing them to be authentically from the domain operator,

Well....doesn't the DNSSEC signature really show (modulo good
key mgmt) that the records are from the domain registrar who
is generally not the domain operator? (Or have I got my
terminology confused?)

We do hope that registrars put in the right stuff, but I
don't believe the DNSSEC signature shows you that.

How about getting rid of the last part:

"that these bindings can be integrity-protected using DNSSEC."

>> The possibly more substantive question: the charter says that "last
>> hop" security is needed, but its not clear to me whether this WG will
>> specify ways to do that for an implementer that doesn't already
>> know how.
> 
> I'm 99% sure that that it is the latter, from what Tim and Sean said at the Beijing meeting.
> 
>> (The "or by other means" phrase is pretty vague.) Am I
>> right in thinking that one of the drafts listed will include that
>> (by reference is fine if good references exist). If the answer is
>> yes, then it might be worth saying so, (and maybe get rid of the
>> "or by other means" phrase). If the answer is no, then I think
>> that'd be a problem since I'd bet it'd lead to implementers making
>> the frequently bad assumption that someone else has looked after
>> the "last hop."
> 
> Agree.
> 
> Current:
> the protocols and mechanisms designed by this working group require securing the "last hop" by operating a local DNS resolver, securing the connection to remote resolver, or by other means.
> 
> Proposed:
> the protocols and mechanisms designed by this working group require securing the "last hop" by operating a local DNS resolver or securing the connection to remote resolver, neither of which will be specified by this WG.

I like that less actually. Maybe its just me (I don't know the
details of what an implementer would have to do), but shouldn't
the WG say how to secure the "last hop"?

To be clear: I don't think this WG should define new ways to
secure the "last hop," I just think saying how that works needs
to be part of the spec - hopefully by reference.

How about:

"the protocols and mechanisms designed by this working group require
securing the "last hop" by operating a local DNS resolver or securing
the connection to remote resolver - this WG will not specify new
mechanisms to secure that hop, but will reference existing
specifications or document existing methods in order to allow
implementations to interoperate securely."

S.

Date: Tue, 23 Nov 2010 11:25:46 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Updated Charter (after Beijing)

On Tue, 23 Nov 2010, Paul Hoffman wrote:

> Current:
> the protocols and mechanisms designed by this working group require securing the "last hop" by operating a local DNS resolver, securing the connection to remote resolver, or by other means.
>
> Proposed:
> the protocols and mechanisms designed by this working group require securing the "last hop" by operating a local DNS resolver or securing the connection to remote resolver, neither of which will be specified by this WG.

I am not sure about "require".  This phrasing excludes usage of passive
attack protection or leap of faith based. Is that intentional?

For instance with an anonsec (ipsec) connection, a non-dnssec secured
key from dns might still be preferred over using a plaintext connection,
or an https connection might still be preferred over an http connection
despite the unverified nature of the (self signed) cert.

Paul

Date: Tue, 23 Nov 2010 08:04:05 -0800
To: Stephen Farrell <[email-masked]>, OndÞej Sur˜ <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Updated Charter (after Beijing)

At 11:46 AM +0000 11/23/10, Stephen Farrell wrote:
>The nit: I assume that "and thus shown to be authentically from the
>domain operator" doesn't require e.g. an additional signature other
>than that provided by DNSSEC - the "from the domain operator" could
>be read to imply that it does require an additional signature. Not
>sure how best to re-word that but maybe something like "providing
>strong evidence that the public key record has not been tampered
>with since being inserted in the DNS" or something. (I'd have no
>problem if an additional signature were allowed, e.g. if the record
>contained an X.509 cert, but I didn't think we wanted to insist
>on that always, at least not in the charter.)

Fully agree about not wanting to suggest that another signature is needed. Would the following change fix this for you:

Current:
that these bindings can be integrity-protected (and thus shown to be authentically from the domain operator) using DNSSEC

Proposed:
that these bindings can be integrity-protected using DNSSEC, thus showing them to be authentically from the domain operator,

>The possibly more substantive question: the charter says that "last
>hop" security is needed, but its not clear to me whether this WG will
>specify ways to do that for an implementer that doesn't already
>know how.

I'm 99% sure that that it is the latter, from what Tim and Sean said at the Beijing meeting.

>(The "or by other means" phrase is pretty vague.) Am I
>right in thinking that one of the drafts listed will include that
>(by reference is fine if good references exist). If the answer is
>yes, then it might be worth saying so, (and maybe get rid of the
>"or by other means" phrase). If the answer is no, then I think
>that'd be a problem since I'd bet it'd lead to implementers making
>the frequently bad assumption that someone else has looked after
>the "last hop."

Agree.

Current:
the protocols and mechanisms designed by this working group require securing the "last hop" by operating a local DNS resolver, securing the connection to remote resolver, or by other means.

Proposed:
the protocols and mechanisms designed by this working group require securing the "last hop" by operating a local DNS resolver or securing the connection to remote resolver, neither of which will be specified by this WG.

--Paul Hoffman, Director
--VPN Consortium

Date: Tue, 23 Nov 2010 16:42:54 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Updated Charter (after Beijing)

Phillip,

you said it before and we have consulted the milestones with ADs on our 
last confcall and the result of our agreement is in the updated charter.
So unless you have a specific proposal how we should change the 
milestones and the people here will agree with you, there's no need to 
repeat what you have already said.

Also please keep on topic.  DNSSEC deployment, SDMI or OpenID is out of 
topic here.

Thank you,
Ondrej

On 23.11.2010 14:09, Phillip Hallam-Baker wrote:
> I agree with Stephen on the goals.
>
> Unrealistic goals slow things down. They don't make anything happen faster.
>
> What I have seen happen repeatedly in standards processes is groups have
> adopted goals they can't possibly meet and then the impossible goals
> become the reason not to look at the real issues.
>
> We would have started deployment of DNSSEC in 2002 only some people
> thought there was no time to consider real world deployment issues. Then
> when the EU privacy thing came up wit literally spent three years
> arguing over whether there was time to consider an issue that took 2
> months to fix once we were allowed to consider it.
>
> And don't get me started on SDMI or OpenID.
>
>
> This particular problem cuts across layers 5, 7 and 8. It is a security
> problem.
>
>
> On Tue, Nov 23, 2010 at 6:46 AM, Stephen Farrell
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     One hopefully minor nit and one question.
>
>     The nit: I assume that "and thus shown to be authentically from the
>     domain operator" doesn't require e.g. an additional signature other
>     than that provided by DNSSEC - the "from the domain operator" could
>     be read to imply that it does require an additional signature. Not
>     sure how best to re-word that but maybe something like "providing
>     strong evidence that the public key record has not been tampered
>     with since being inserted in the DNS" or something. (I'd have no
>     problem if an additional signature were allowed, e.g. if the record
>     contained an X.509 cert, but I didn't think we wanted to insist
>     on that always, at least not in the charter.)
>
>     The possibly more substantive question: the charter says that "last
>     hop" security is needed, but its not clear to me whether this WG will
>     specify ways to do that for an implementer that doesn't already
>     know how. (The "or by other means" phrase is pretty vague.) Am I
>     right in thinking that one of the drafts listed will include that
>     (by reference is fine if good references exist). If the answer is
>     yes, then it might be worth saying so, (and maybe get rid of the
>     "or by other means" phrase). If the answer is no, then I think
>     that'd be a problem since I'd bet it'd lead to implementers making
>     the frequently bad assumption that someone else has looked after
>     the "last hop."
>
>     Oh - and I bet a beer the September milestones slip:-)
>
>     Ta,
>     Stephen.
>
>     On 23/11/10 08:29, OndÅ™ej SurÃ½ wrote:
>      > Hi there,
>      >
>      > We believe we have managed to integrate all the comments,
>     suggestions,
>      > the latest spin at the charter is:
>      > http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure
>      >
>      > Diffs are:
>      >
>     http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure?action=diff&version=12
>     <http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure?action=diff&version=12>
>      >
>      >
>      > We added:
>      > - note about need for DNSSEC
>      > - note about general policy being out of scope
>      > - moved milestones so we have more time to discuss
>      >
>      > All was done with cooperation with ADs.  Many thanks to them.
>      >
>      > Ondrej & Warren
>     _______________________________________________
>     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: Tue, 23 Nov 2010 09:31:51 -0600 (GMT-06:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Updated Charter (after Beijing)
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 remember and I could not agree more with you here.<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: Nov 23, 2010 7:09 AM <BR>To: Stephen Farrell <STE=
[email-masked]><BR>Cc: [email-masked] <BR>Subject: Re: [keyassu=
re] Updated Charter (after Beijing) <BR><BR>I agree with Stephen on the goa=
ls.
<DIV><BR></DIV>
<DIV>Unrealistic goals slow things down. They don't make anything happen fa=
ster.</DIV>
<DIV><BR></DIV>
<DIV>What I have seen happen repeatedly in standards processes is groups ha=
ve adopted goals they can't possibly meet and then the impossible goals bec=
ome the reason not to look at the real issues.</DIV>
<DIV><BR></DIV>
<DIV>We would have started deployment of DNSSEC in 2002 only some people th=
ought there was no time to consider real world deployment issues. Then when=
 the EU privacy thing came up wit&nbsp;literally spent three years arguing =
over whether there was time to consider an issue that took 2 months to fix =
once we were allowed to consider it.</DIV>
<DIV><BR></DIV>
<DIV>And don't get me started on SDMI or OpenID.</DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV>This particular problem cuts across layers 5, 7 and 8. It is a securit=
y problem. &nbsp;</DIV>
<DIV><BR><BR>
<DIV class=3Dgmail_quote>On Tue, Nov 23, 2010 at 6:46 AM, Stephen Farrell <=
SPAN dir=3Dltr>&lt;<A href=3D"mailto:[email-masked]" target=3D_b=
lank>[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><BR>One hopefully minor nit and on=
e question.<BR><BR>The nit: I assume that "and thus shown to be authentical=
ly from the<BR>domain operator" doesn't require e.g. an additional signatur=
e other<BR>than that provided by DNSSEC - the "from the domain operator" co=
uld<BR>be read to imply that it does require an additional signature. Not<B=
R>sure how best to re-word that but maybe something like "providing<BR>stro=
ng evidence that the public key record has not been tampered<BR>with since =
being inserted in the DNS" or something. (I'd have no<BR>problem if an addi=
tional signature were allowed, e.g. if the record<BR>contained an X.509 cer=
t, but I didn't think we wanted to insist<BR>on that always, at least not i=
n the charter.)<BR><BR>The possibly more substantive question: the charter =
says that "last<BR>hop" security is needed, but its not clear to me whether=
 this WG will<BR>specify ways to do that for an implementer that doesn't al=
ready<BR>know how. (The "or by other means" phrase is pretty vague.) Am I<B=
R>right in thinking that one of the drafts listed will include that<BR>(by =
reference is fine if good references exist). If the answer is<BR>yes, then =
it might be worth saying so, (and maybe get rid of the<BR>"or by other mean=
s" phrase). If the answer is no, then I think<BR>that'd be a problem since =
I'd bet it'd lead to implementers making<BR>the frequently bad assumption t=
hat someone else has looked after<BR>the "last hop."<BR><BR>Oh - and I bet =
a beer the September milestones slip:-)<BR><BR>Ta,<BR><FONT color=3D#888888=
>Stephen.<BR></FONT>
<DIV class=3Dim><BR>On 23/11/10 08:29, Ond=C5=99ej Sur=C3=BD wrote:<BR>&gt;=
 Hi there,<BR>&gt;<BR>&gt; We believe we have managed to integrate all the =
comments, suggestions,<BR>&gt; the latest spin at the charter is:<BR>&gt; <=
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>&g=
t;<BR>&gt; Diffs are:<BR>&gt; <A href=3D"http://trac.tools.ietf.org/area/se=
c/trac/wiki/Keyassure?action=3Ddiff&amp;version=3D12" target=3D_blank>http:=
//trac.tools.ietf.org/area/sec/trac/wiki/Keyassure?action=3Ddiff&amp;versio=
n=3D12</A><BR>&gt;<BR>&gt;<BR>&gt; We added:<BR>&gt; - note about need for =
DNSSEC<BR>&gt; - note about general policy being out of scope<BR>&gt; - mov=
ed milestones so we have more time to discuss<BR>&gt;<BR>&gt; All was done =
with cooperation with ADs. &nbsp;Many thanks to them.<BR>&gt;<BR>&gt; Ondre=
j &amp; Warren<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>Network Eng. SR. Eng. Net=
work data security<BR>ABA member in good standing member ID 01257402 <BR>E-=
Mail [email-masked]<BR>Phone: 214-244-4827<BR><BR></DIV></BLOCKQUOT=
E></BODY>

Date: Tue, 23 Nov 2010 08:09:32 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Updated Charter (after Beijing)

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

I agree with Stephen on the goals.

Unrealistic goals slow things down. They don't make anything happen faster.

What I have seen happen repeatedly in standards processes is groups have
adopted goals they can't possibly meet and then the impossible goals become
the reason not to look at the real issues.

We would have started deployment of DNSSEC in 2002 only some people thought
there was no time to consider real world deployment issues. Then when the E=
U
privacy thing came up wit literally spent three years arguing over whether
there was time to consider an issue that took 2 months to fix once we were
allowed to consider it.

And don't get me started on SDMI or OpenID.

This particular problem cuts across layers 5, 7 and 8. It is a security
problem.

On Tue, Nov 23, 2010 at 6:46 AM, Stephen Farrell
<[email-masked]>wrote:

>
> One hopefully minor nit and one question.
>
> The nit: I assume that "and thus shown to be authentically from the
> domain operator" doesn't require e.g. an additional signature other
> than that provided by DNSSEC - the "from the domain operator" could
> be read to imply that it does require an additional signature. Not
> sure how best to re-word that but maybe something like "providing
> strong evidence that the public key record has not been tampered
> with since being inserted in the DNS" or something. (I'd have no
> problem if an additional signature were allowed, e.g. if the record
> contained an X.509 cert, but I didn't think we wanted to insist
> on that always, at least not in the charter.)
>
> The possibly more substantive question: the charter says that "last
> hop" security is needed, but its not clear to me whether this WG will
> specify ways to do that for an implementer that doesn't already
> know how. (The "or by other means" phrase is pretty vague.) Am I
> right in thinking that one of the drafts listed will include that
> (by reference is fine if good references exist). If the answer is
> yes, then it might be worth saying so, (and maybe get rid of the
> "or by other means" phrase). If the answer is no, then I think
> that'd be a problem since I'd bet it'd lead to implementers making
> the frequently bad assumption that someone else has looked after
> the "last hop."
>
> Oh - and I bet a beer the September milestones slip:-)
>
> Ta,
> Stephen.
>
> On 23/11/10 08:29, Ond=C5=99ej Sur=C3=BD wrote:
> > Hi there,
> >
> > We believe we have managed to integrate all the comments, suggestions,
> > the latest spin at the charter is:
> > http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure
> >
> > Diffs are:
> >
> http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure?action=3Ddiff&ver=
sion=3D12
> >
> >
> > We added:
> > - note about need for DNSSEC
> > - note about general policy being out of scope
> > - moved milestones so we have more time to discuss
> >
> > All was done with cooperation with ADs.  Many thanks to them.
> >
> > Ondrej & Warren
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

I agree with Stephen on the goals.<div><br></div><div>Unrealistic goals slo=
w things down. They don&#39;t make anything happen faster.</div><div><br></=
div><div>What I have seen happen repeatedly in standards processes is group=
s have adopted goals they can&#39;t possibly meet and then the impossible g=
oals become the reason not to look at the real issues.</div>
<div><br></div><div>We would have started deployment of DNSSEC in 2002 only=
 some people thought there was no time to consider real world deployment is=
sues. Then when the EU privacy thing came up wit=C2=A0literally spent three=
 years arguing over whether there was time to consider an issue that took 2=
 months to fix once we were allowed to consider it.</div>
<div><br></div><div>And don&#39;t get me started on SDMI or OpenID.</div><d=
iv><br></div><div><br></div><div>This particular problem cuts across layers=
 5, 7 and 8. It is a security problem. =C2=A0</div><div><br><br><div class=
=3D"gmail_quote">
On Tue, Nov 23, 2010 at 6:46 AM, Stephen Farrell <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 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
One hopefully minor nit and one question.<br>
<br>
The nit: I assume that &quot;and thus shown to be authentically from the<br=
>
domain operator&quot; doesn&#39;t require e.g. an additional signature othe=
r<br>
than that provided by DNSSEC - the &quot;from the domain operator&quot; cou=
ld<br>
be read to imply that it does require an additional signature. Not<br>
sure how best to re-word that but maybe something like &quot;providing<br>
strong evidence that the public key record has not been tampered<br>
with since being inserted in the DNS&quot; or something. (I&#39;d have no<b=
r>
problem if an additional signature were allowed, e.g. if the record<br>
contained an X.509 cert, but I didn&#39;t think we wanted to insist<br>
on that always, at least not in the charter.)<br>
<br>
The possibly more substantive question: the charter says that &quot;last<br=
>
hop&quot; security is needed, but its not clear to me whether this WG will<=
br>
specify ways to do that for an implementer that doesn&#39;t already<br>
know how. (The &quot;or by other means&quot; phrase is pretty vague.) Am I<=
br>
right in thinking that one of the drafts listed will include that<br>
(by reference is fine if good references exist). If the answer is<br>
yes, then it might be worth saying so, (and maybe get rid of the<br>
&quot;or by other means&quot; phrase). If the answer is no, then I think<br=
>
that&#39;d be a problem since I&#39;d bet it&#39;d lead to implementers mak=
ing<br>
the frequently bad assumption that someone else has looked after<br>
the &quot;last hop.&quot;<br>
<br>
Oh - and I bet a beer the September milestones slip:-)<br>
<br>
Ta,<br>
<font color=3D"#888888">Stephen.<br>
</font><div class=3D"im"><br>
On 23/11/10 08:29, Ond=C5=99ej Sur=C3=BD wrote:<br>
&gt; Hi there,<br>
&gt;<br>
&gt; We believe we have managed to integrate all the comments, suggestions,=
<br>
&gt; the latest spin at the charter is:<br>
&gt; <a href=3D"http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure" ta=
rget=3D"_blank">http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure</a>=
<br>
&gt;<br>
&gt; Diffs are:<br>
&gt; <a href=3D"http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure?act=
ion=3Ddiff&amp;version=3D12" target=3D"_blank">http://trac.tools.ietf.org/a=
rea/sec/trac/wiki/Keyassure?action=3Ddiff&amp;version=3D12</a><br>
&gt;<br>
&gt;<br>
&gt; We added:<br>
&gt; - note about need for DNSSEC<br>
&gt; - note about general policy being out of scope<br>
&gt; - moved milestones so we have more time to discuss<br>
&gt;<br>
&gt; All was done with cooperation with ADs. =C2=A0Many thanks to them.<br>
&gt;<br>
&gt; Ondrej &amp; Warren<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>

--0016e645b8e264ec000495b8154a--

Date: Tue, 23 Nov 2010 11:46:23 +0000
From: Stephen Farrell <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Updated Charter (after Beijing)

One hopefully minor nit and one question.

The nit: I assume that "and thus shown to be authentically from the
domain operator" doesn't require e.g. an additional signature other
than that provided by DNSSEC - the "from the domain operator" could
be read to imply that it does require an additional signature. Not
sure how best to re-word that but maybe something like "providing
strong evidence that the public key record has not been tampered
with since being inserted in the DNS" or something. (I'd have no
problem if an additional signature were allowed, e.g. if the record
contained an X.509 cert, but I didn't think we wanted to insist
on that always, at least not in the charter.)

The possibly more substantive question: the charter says that "last
hop" security is needed, but its not clear to me whether this WG will
specify ways to do that for an implementer that doesn't already
know how. (The "or by other means" phrase is pretty vague.) Am I
right in thinking that one of the drafts listed will include that
(by reference is fine if good references exist). If the answer is
yes, then it might be worth saying so, (and maybe get rid of the
"or by other means" phrase). If the answer is no, then I think
that'd be a problem since I'd bet it'd lead to implementers making
the frequently bad assumption that someone else has looked after
the "last hop."

Oh - and I bet a beer the September milestones slip:-)

Ta,
Stephen.

On 23/11/10 08:29, OndÅ™ej SurÃ½ wrote:
> Hi there,
> 
> We believe we have managed to integrate all the comments, suggestions,
> the latest spin at the charter is:
> http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure
> 
> Diffs are:
> http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure?action=diff&version=12
> 
> 
> We added:
> - note about need for DNSSEC
> - note about general policy being out of scope
> - moved milestones so we have more time to discuss
> 
> All was done with cooperation with ADs.  Many thanks to them.
> 
> Ondrej & Warren

Date: Tue, 23 Nov 2010 09:29:59 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: [keyassure] Updated Charter (after Beijing)

Hi there,

We believe we have managed to integrate all the comments, suggestions,
the latest spin at the charter is:
http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure

Diffs are:
http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure?action=diff&version=12

We added:
- note about need for DNSSEC
- note about general policy being out of scope
- moved milestones so we have more time to discuss

All was done with cooperation with ADs.  Many thanks to them.

Ondrej & Warren
-- 
  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: Sun, 21 Nov 2010 15:48:36 -0800
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Question about Keyassure and IPsec

At 6:36 PM -0500 11/21/10, Phillip Hallam-Baker wrote:
>PKIX has no semantics that are protocol specific.

Other than the EKUs, that is correct.

>If we think we need protocol specific semantics for key assure, isn't that a sign that we are probably doing something wrong?

No, it is a sign that we are not trying to slap a one-size-fits-all set of semantics across dissimilar protocols. As Yoav said in his earlier message:

At 12:24 PM +0200 11/21/10, Yoav Nir wrote:
>I have not yet thought through all the implications for PAD, ID Type, and the cert encoding fields, but I think it should be doable.

If you *have* thought about all those and have proposed wording for them, that's great. Given the long, drawn-out history of the pki4ipsec WG, particularly with respect to the second point, having someone who is not part of the IPsec community solve our problems in a way that can be agreed to by that community would be wonderful.

--Paul Hoffman, Director
--VPN Consortium

Date: Sun, 21 Nov 2010 18:36:52 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Question about Keyassure and IPsec

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

PKIX has no semantics that are protocol specific.

If we think we need protocol specific semantics for key assure, isn't that a
sign that we are probably doing something wrong?

On Sun, Nov 21, 2010 at 6:13 PM, Paul Hoffman <[email-masked]> wrote:

> At 12:24 PM +0200 11/21/10, Yoav Nir wrote:
> >Hi all
> >
> >I was not in Beijing, but I did listen to the discussion at the KiDNS BoF.
> >
> >Paul Hoffman talked about the various proposals, and mentioned that IPsec
> (or actually IKE) is not a good candidate, because hardly anyone uses
> certificates in IKE.
> >
> >I don't agree with this. HTTPS uses PKI all the time, because the browser
> vendors pre-package browsers with large trust-anchor stores, so everyone can
> get a certificate from one of those blessed CAs.
> >
> >Most IPsec products do not come with a trust-anchor store, so getting any
> certificate is not helpful in interoperating with anyone outside your small
> domain.
> >
> >Having keys in DNS can change all that. If authentication is based on
> having the same key in the (secure) DNS as you show in the protocol, it
> makes a lot of sense to start authenticating with such public keys, because
> now you don't have to have both sides trust the same CA.
> >
> >I have not yet thought through all the implications for PAD, ID Type, and
> the cert encoding fields, but I think it should be doable.
> >
> >Am I missing something?
>
> Yes. I believe I said (or I certainly hope I said) that IPsec is not a good
> *initial* or *early* candidate. After we get the semantics down for the more
> common candidates (Foo over TLS), then we can work on translating that to
> certificate authentication in IKE.
>
> FWIW, I fully agree with the rest of your logic: having KIDNS functionality
> for IKE can only improve the low current usage of certficates for
> authentication.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

PKIX has no semantics that are protocol specific.<div><br></div><div>If we =
think we need protocol specific semantics for key assure, isn&#39;t that a =
sign that we are probably doing something wrong?</div><div><br></div><div>
<br><div class=3D"gmail_quote">On Sun, Nov 21, 2010 at 6:13 PM, Paul Hoffma=
n <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul.hoffm=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">At 12:24 PM +0200 11/21/10, Yoav Nir wrote:<br>
&gt;Hi all<br>
&gt;<br>
&gt;I was not in Beijing, but I did listen to the discussion at the KiDNS B=
oF.<br>
&gt;<br>
&gt;Paul Hoffman talked about the various proposals, and mentioned that IPs=
ec (or actually IKE) is not a good candidate, because hardly anyone uses ce=
rtificates in IKE.<br>
&gt;<br>
&gt;I don&#39;t agree with this. HTTPS uses PKI all the time, because the b=
rowser vendors pre-package browsers with large trust-anchor stores, so ever=
yone can get a certificate from one of those blessed CAs.<br>
&gt;<br>
&gt;Most IPsec products do not come with a trust-anchor store, so getting a=
ny certificate is not helpful in interoperating with anyone outside your sm=
all domain.<br>
&gt;<br>
&gt;Having keys in DNS can change all that. If authentication is based on h=
aving the same key in the (secure) DNS as you show in the protocol, it make=
s a lot of sense to start authenticating with such public keys, because now=
 you don&#39;t have to have both sides trust the same CA.<br>

&gt;<br>
&gt;I have not yet thought through all the implications for PAD, ID Type, a=
nd the cert encoding fields, but I think it should be doable.<br>
&gt;<br>
&gt;Am I missing something?<br>
<br>
</div>Yes. I believe I said (or I certainly hope I said) that IPsec is not =
a good *initial* or *early* candidate. After we get the semantics down for =
the more common candidates (Foo over TLS), then we can work on translating =
that to certificate authentication in IKE.<br>

<br>
FWIW, I fully agree with the rest of your logic: having KIDNS functionality=
 for IKE can only improve the low current usage of certficates for authenti=
cation.<br>
<font color=3D"#888888"><br>
--Paul Hoffman, Director<br>
--VPN Consortium<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>

--0016e644cf5038fb6b0495989df0--

Date: Sun, 21 Nov 2010 15:13:30 -0800
To: Yoav Nir <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Question about Keyassure and IPsec

At 12:24 PM +0200 11/21/10, Yoav Nir wrote:
>Hi all
>
>I was not in Beijing, but I did listen to the discussion at the KiDNS BoF.
>
>Paul Hoffman talked about the various proposals, and mentioned that IPsec (or actually IKE) is not a good candidate, because hardly anyone uses certificates in IKE.
>
>I don't agree with this. HTTPS uses PKI all the time, because the browser vendors pre-package browsers with large trust-anchor stores, so everyone can get a certificate from one of those blessed CAs.
>
>Most IPsec products do not come with a trust-anchor store, so getting any certificate is not helpful in interoperating with anyone outside your small domain.
>
>Having keys in DNS can change all that. If authentication is based on having the same key in the (secure) DNS as you show in the protocol, it makes a lot of sense to start authenticating with such public keys, because now you don't have to have both sides trust the same CA.
>
>I have not yet thought through all the implications for PAD, ID Type, and the cert encoding fields, but I think it should be doable.
>
>Am I missing something?

Yes. I believe I said (or I certainly hope I said) that IPsec is not a good *initial* or *early* candidate. After we get the semantics down for the more common candidates (Foo over TLS), then we can work on translating that to certificate authentication in IKE.

FWIW, I fully agree with the rest of your logic: having KIDNS functionality for IKE can only improve the low current usage of certficates for authentication.

--Paul Hoffman, Director
--VPN Consortium

Date: Sun, 21 Nov 2010 10:25:04 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Yoav Nir <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Question about Keyassure and IPsec

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

Whether or not Paul was right on the facts, his reasoning was faulty.

The reason for producing a new protocol specification should always be to
make something work that currently does not or to make something that works
poorly work better.

If people were using IPSEC in its original design intent, that is to secure
Internet communications, there would be no need for a DNSSEC keying
approach. The problem would be solved already.

The reason that I think IPSEC needs to be considered here is that currently
IPSEC can only be used for network communications. Most IPSEC use is to
secure remote access to enterprise networks, an application for which it is
rather poorly designed. Tunneling over TLS works far better. It is also
deployed at a few enterprises as a VPN and there are a tiny number of
extranet deployments.

IPSEC is somewhat more successful than S/MIME, but neither has met the
original design goal of ubiquitous deployment. They have had some success in
some niches. The Internet has two billion users. A protocol can have
millions of users and still have underperformed.

If we are going to get to ubiquitous deployment of either, we need to have a
mechanism for ubiquitous keying based on Internet names. So DNSSEC based
approaches are of very real interest to me.

On Sun, Nov 21, 2010 at 5:24 AM, Yoav Nir <[email-masked]> wrote:

> Hi all
>
> I was not in Beijing, but I did listen to the discussion at the KiDNS BoF.
>
> Paul Hoffman talked about the various proposals, and mentioned that IPsec
> (or actually IKE) is not a good candidate, because hardly anyone uses
> certificates in IKE.
>
> I don't agree with this. HTTPS uses PKI all the time, because the browser
> vendors pre-package browsers with large trust-anchor stores, so everyone can
> get a certificate from one of those blessed CAs.
>
> Most IPsec products do not come with a trust-anchor store, so getting any
> certificate is not helpful in interoperating with anyone outside your small
> domain.
>
> Having keys in DNS can change all that. If authentication is based on
> having the same key in the (secure) DNS as you show in the protocol, it
> makes a lot of sense to start authenticating with such public keys, because
> now you don't have to have both sides trust the same CA.
>
> I have not yet thought through all the implications for PAD, ID Type, and
> the cert encoding fields, but I think it should be doable.
>
> Am I missing something?
>
> Yoav
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

<div>Whether or not Paul was right on the facts, his reasoning was faulty.<=
/div><div><br></div><div>The reason for producing a new protocol specificat=
ion should always be to make something work that currently does not or to m=
ake something that works poorly work better.</div>
<div><br></div><div>If people were using IPSEC in its original design inten=
t, that is to secure Internet communications, there would be no need for a =
DNSSEC keying approach. The problem would be solved already.</div><div>
<br></div><div>The reason that I think IPSEC needs to be considered here is=
 that currently IPSEC can only be used for network communications. Most IPS=
EC use is to secure remote access to enterprise networks, an application fo=
r which it is rather poorly designed. Tunneling over TLS works far better. =
It is also deployed at a few enterprises as a VPN and there are a tiny numb=
er of extranet deployments.</div>
<div><br></div><div>IPSEC is somewhat more successful than S/MIME, but neit=
her has met the original design goal of ubiquitous deployment. They have ha=
d some success in some niches. The Internet has two billion users. A protoc=
ol can have millions of users and still have underperformed.</div>
<div><br></div><div><br></div><div>If we are going to get to ubiquitous dep=
loyment of either, we need to have a mechanism for ubiquitous keying based =
on Internet names. So DNSSEC based approaches are of very real interest to =
me.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Sun, Nov 21, 2010 at =
5:24 AM, Yoav Nir <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
om">[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;">
Hi all<br>
<br>
I was not in Beijing, but I did listen to the discussion at the KiDNS BoF.<=
br>
<br>
Paul Hoffman talked about the various proposals, and mentioned that IPsec (=
or actually IKE) is not a good candidate, because hardly anyone uses certif=
icates in IKE.<br>
<br>
I don&#39;t agree with this. HTTPS uses PKI all the time, because the brows=
er vendors pre-package browsers with large trust-anchor stores, so everyone=
 can get a certificate from one of those blessed CAs.<br>
<br>
Most IPsec products do not come with a trust-anchor store, so getting any c=
ertificate is not helpful in interoperating with anyone outside your small =
domain.<br>
<br>
Having keys in DNS can change all that. If authentication is based on havin=
g the same key in the (secure) DNS as you show in the protocol, it makes a =
lot of sense to start authenticating with such public keys, because now you=
 don&#39;t have to have both sides trust the same CA.<br>

<br>
I have not yet thought through all the implications for PAD, ID Type, and t=
he cert encoding fields, but I think it should be doable.<br>
<br>
Am I missing something?<br>
<br>
Yoav<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>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--001485f547ca681a44049591beee--

Date: Sun, 21 Nov 2010 15:23:36 +0200
From: Ilari Liusvaara <[email-masked]>
To: [email-masked]
Sender: Ilari Liusvaara <[email-masked]>
Subject: [keyassure] Commentary about IETF 79 slides

Here's misc. stuff I found from the slides and my own comments to those.

"If you don't have this CA cert in your trust anchor pile, stop: You {SHOULD | MUST} NOT validate my EE cert"

It might be useful not to have that requirement. Like setting private "CA" and chaining certificates to that. Could
make certificate management bit easier.

What attack this is there to defend against?

"In short: does the protocol make things worse if DNSSEC is not used?"

The only scenerios I can come up with:

* Trusting bad authentication data
* Downgrade attacks
* Some extra ways for attacker (that can already DoS) to DoS stuff in new ways.

"Create our own RRType, sub-class CERT, or use TXT with a _prefix"

1) Our own RRType:

+ We can define useful formatting for it.
+ Binary on the wire (efficient in space and time)
- Support for RRType as known type.

2) CERT

- Bad formatting
+ Binary on the wire (efficient in space and time)
- Difficulty of assembling record.

3) TXT with _prefix

+ Well supported RRtype
- Text on the wire (inefficient in space and time)
+ Record is easy to assemble.

"There is discussion of 'I always do Foo over TLS' in DNS"

I still consider this ill-defined.

"The semantics associated with STS-in-DNS should be the same as HSTS; otherwise, the overlap will lead to confusion"

I don't see how DNS version of STS and HSTS could conflict (unless you do something really silly like claiming "I don't support
TLS in DNS and then assering HSTS in HTTP).

But there's more subtle issue. What if you under HSTS rules present self-signed certificate that DNS declares as correct (and
the client security policy trusts DNS)?

The right thing would seem to be to accept it and continue...

"Have to evaluate if the HTTP semantics apply to other application protocols that run under TLS"

My opinion on that: Definitely not! (and that's where that "ill-defined" comes from).

-Ilari

From: Yoav Nir <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Sun, 21 Nov 2010 12:24:03 +0200
Accept-Language: en-US
acceptlanguage: en-US
Subject: [keyassure] Question about Keyassure and IPsec

Hi all

I was not in Beijing, but I did listen to the discussion at the KiDNS BoF.

Paul Hoffman talked about the various proposals, and mentioned that IPsec (=
or actually IKE) is not a good candidate, because hardly anyone uses certif=
icates in IKE.

I don't agree with this. HTTPS uses PKI all the time, because the browser v=
endors pre-package browsers with large trust-anchor stores, so everyone can=
 get a certificate from one of those blessed CAs.

Most IPsec products do not come with a trust-anchor store, so getting any c=
ertificate is not helpful in interoperating with anyone outside your small =
domain.

Having keys in DNS can change all that. If authentication is based on havin=
g the same key in the (secure) DNS as you show in the protocol, it makes a =
lot of sense to start authenticating with such public keys, because now you=
 don't have to have both sides trust the same CA.

I have not yet thought through all the implications for PAD, ID Type, and t=
he cert encoding fields, but I think it should be doable.

Am I missing something?

Yoav

Date: Thu, 11 Nov 2010 03:25:31 -0800
From: =JeffH <[email-masked]>
To: [email-masked]
Subject: [keyassure] fyi: Kaminsky: Phreebird Suite 1.0: Introducing the Domain Key Infrastructure

just announced today..

Phreebird Suite 1.0: Introducing the Domain Key Infrastructure
<http://www.slideshare.net/dakami/phreebird-suite-10-introducing-the-domain-key-infrastructure>

source code
http://j.mp/9kXyd7

=JeffH

From: Warren Kumari <[email-masked]>
Date: Wed, 10 Nov 2010 12:12:18 +0800
To: [email-masked]
Subject: [keyassure] Looking for jabber scribes / note folk.

Hi there all,

I'm looking for volunteers willing to be jabber scribes / willing to =
take some sort of notes in the BOF tomorrow....

Volunteers greatly appreciated,
W=

Date: Mon, 08 Nov 2010 17:47:28 -0500
From: Olafur Gudmundsson <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and	draft-hoffman-keys-linkage-from-dns

On 10/30/2010 09:02 PM, Warren Kumari wrote:
>
> On Oct 30, 2010, at 8:07 PM, James Cloos wrote:

> Another option (which has some (IMO) of the elegance retained, but
> probably has scalability and leakage issues) is
> foo.example.com <http://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
> <http://foo.example.com> (or just exmaple.com <http://exmaple.com>) all
> at the same level, but have the ports included in the response.
>
>>
>> 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....
>
>>
>> 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.
>
> Yes, both are (IMO) sub-optimal -- my *personal* view of the world

Rule #1 in DNS land: Do not optimize until you know exactly what the 
problem is as most "design" optimization have turned out to be bad
for protocol or operations.

> involves having unique names for each service (www.example.com
> <http://www.example.com>, imap.exmaple.com <http://imap.exmaple.com>,
> jabber.example.com <http://jabber.example.com>) which sidesteps this
> issue, but enough folk have raised this issue that it needs to be
> addressed....
>
>

There are multiple ways to address this, in general DNS people recommend 
strongly against "sub-typing" i.e. having multiple different protocols 
share the same RRset.
There are number of issues here to think about:
	size of the RRset
	Number of foot prints per protocol/port
	How is/are the RRsets are maintained, in particular is
		dynamic update used.

Think about operations for a minute, if the 'web' team has write access 
via dynamic update to the web KIDNS rrset then they maintain it without
involving the 'dns' team.
Now having the 'mail', 'web' and other protocols share one set then all 
of them either need write access or to involve the 'dns' team for 
arbitration.

As Chome has demonstrated there it is not that hard to have multiple 
queries in flight at the same time, in general the rule should be
"prefer more specific".

Additionally there may be different ways to reach the same service,
like www.foo.bar and foo.bar. are then two copies of KIDNS records 
stored or does the protocol need KIDNS_ALIAS [<port>] <name> that has
pointer to the real set?

I want to emphasize Jakob's point that it is important to differentiate 
between where service is described (MX) and where it is provided (A 
records).

	Olafur

	Olafur

From: Tony Finch <[email-masked]>
Date: Wed, 3 Nov 2010 23:21:20 +0000
To: Jakob Schlyter <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: Steve Schultze <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On 3 Nov 2010, at 20:32, Jakob Schlyter <[email-masked]> wrote:
>=20
> I most likely do not have the same key material for all SMTP servers.

There's nothing stopping you from having multiple cert records alongside you=
r MX records. It's easy to ensure the DNS is correct if your MXs are managed=
 as a coherent service. Old style secondary MXs cause significant operationa=
l problems and no longer have any advantages.

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/=

From: Jakob Schlyter <[email-masked]>
Date: Wed, 3 Nov 2010 22:39:57 +0100
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and

On 3 nov 2010, at 21.57, Martin Rex wrote:

>> I most likely do not have the same key material for all SMTP servers.
>=20
> Which particular situation do you have in mind.

example.com. IN MX 5 mail.foo.com.
             IN MX 10 mail.bar.com.

where foo.com and bar.com does not share key material (e.g. run by =
different organizations).

in the TLSFP draft, we envision that there will be one TLSFP RR for =
mail.foo.com. and one for mail.bar.com.

In the example (of future) use of SRV for HTTP:

_https._tcp.www.example.com. IN SRV 0 0 443 web1.example.com.
                             IN SRV 0 0 443 web2.example.com.

where there would be TLSFP RRs for web1 and web2.

There is a possibility that someone wants to name all hostnames (as in, =
right hand side of SRV/MX/A/AAA) the very same, but still do not share =
key material. Is this problem large enough that we need to solve that =
scenario, or can we decide this is not a problem we need to address?

	jakob

--=20
Jakob Schlyter
Kirei AB - www.kirei.se

Date: Wed, 3 Nov 2010 17:36:43 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] CNAME, wildcards, SRV and Key binding

If prefixes worked like I would like them to, I would just have
prefixed records.

But the constraints on prefixes means that you either have to accept
some limitations on the use of DNS or start your discovery process
with an unprefixed record.

So its more a case of making a virtue out of an (almost) necessity.

On Wed, Nov 3, 2010 at 1:20 PM, Tony Finch <[email-masked]> wrote:
> On Mon, 1 Nov 2010, Phillip Hallam-Baker wrote:
>>
>> The idea behind ESRV was that the discovery would be a process of gradua=
l
>> refinement, starting with security policy for the site and gradually
>> refining down to very specific policies for specific protocols, hosts an=
d
>> services.
>
> I think this is over-complicated. Each service should be terated
> independently by the protocol. If a site wants to specify policy at a
> coarser level then they will need to repeat the policy for each service
> that the policy applies to.
>
> Tony.
> --
> f.anthony.n.finch =A0<[email-masked]> =A0http://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.
>

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

Date: Wed, 3 Nov 2010 16:25:14 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Martin and all,

-----Original Message-----
>From: Martin Rex <[email-masked]>
>Sent: Nov 3, 2010 3:57 PM
>To: Jakob Schlyter <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] PKIX/KIDNS validation results and
>
>Jakob Schlyter wrote:
>> 
>> On 3 nov 2010, at 17.44, Tony Finch wrote:
>> 
>> > If they are stored at _smtp._tcp.kirei.se then you can use a CNAME to deal
>> > with outsourced service, and support concurrent lookups of target hostname
>> > and cert material.
>> 
>> I most likely do not have the same key material for all SMTP servers.
>
>Which particular situation do you have in mind.
>
>Mutual MX-based backups with other servers is would be a different
>issue with independent hostnames.
>
>If your main SMTP hub uses several servers, sharing of private key
>and certificate usually should be possible, unless there is a pkcs#12 problem
>in the software, or the private key is (marked) non-exporable,
>ultimately because the private key is in hardware.
>
>Precluding multiple servers (redundancy) which cannot share keys
>would not be a good idea for KIDNS.  For key-rollover, you need
>to double that number again...

  I agree with this mainly because of cost, and the significant chance
of key-rollover problems that would be significantly damaging.
>
>
>-Martin
>_______________________________________________
>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

From: Martin Rex <[email-masked]>
To: [email-masked] (Jakob Schlyter)
Date: Wed, 3 Nov 2010 21:57:05 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and
Reply-To: [email-masked]

Jakob Schlyter wrote:
> 
> On 3 nov 2010, at 17.44, Tony Finch wrote:
> 
> > If they are stored at _smtp._tcp.kirei.se then you can use a CNAME to deal
> > with outsourced service, and support concurrent lookups of target hostname
> > and cert material.
> 
> I most likely do not have the same key material for all SMTP servers.

Which particular situation do you have in mind.

Mutual MX-based backups with other servers is would be a different
issue with independent hostnames.

If your main SMTP hub uses several servers, sharing of private key
and certificate usually should be possible, unless there is a pkcs#12 problem
in the software, or the private key is (marked) non-exporable,
ultimately because the private key is in hardware.

Precluding multiple servers (redundancy) which cannot share keys
would not be a good idea for KIDNS.  For key-rollover, you need
to double that number again...

-Martin

From: Jakob Schlyter <[email-masked]>
Date: Wed, 3 Nov 2010 21:32:54 +0100
To: Tony Finch <[email-masked]>
Cc: Steve Schultze <[email-masked]>, [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On 3 nov 2010, at 17.44, Tony Finch wrote:

> If they are stored at _smtp._tcp.kirei.se then you can use a CNAME to deal
> with outsourced service, and support concurrent lookups of target hostname
> and cert material.

I most likely do not have the same key material for all SMTP servers.

	jakob

Date: Wed, 3 Nov 2010 14:15:26 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: "[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]>

Ilari and all,

-----Original Message-----
>From: Ilari Liusvaara <[email-masked]>
>Sent: Nov 3, 2010 1:55 PM
>To: Phillip Hallam-Baker <[email-masked]>
>Cc: Tony Finch <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
>Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns
>
>On Wed, Nov 03, 2010 at 01:14:11PM -0400, Phillip Hallam-Baker wrote:
>> 
>> There are certainly issues that arise with prefixes as I mentioned in
>> my other post. But they are tractable provided that:
>> 
>> 1) You are prepared to allow an additional DNS round trip.
>> 2) You are prepared to introduce a new DNS RR.
>
>Considering the adoption of CERT RR, CERT RR can almost be treated as
>new RR.
>
>And there's a diffrence between having to serialize the query and
>firing off the query in parallel with some other qurey one would have
>to do anyway.
>
>> We have to keep an eye on efficiency, but anything we do here is going
>> to depend on deployment of new DNS support infrastructure and require
>> transport that supports new RRs.
>
>Well, there's RFC 3597. But of course, new RRs (even if RFC 3597-compliant)
>have issues with adminstration.
>
>> Certificates typically bind to an entire domain.
>
>They may, or they may not. Some services use certificates in bizarre
>manner and can't share them with anything.
>
>> Statements concerning configuration of a security policy naturally
>> bind to a specific service at a domain.
>
>If you think HSTS is good example of security policy, consider that
>HSTS is really a special kind of protcol-level redirect and is only
>well-defined because of interactions between HSTS spec and HTTPS
>spec.
>
>That's why I think that records specifying secure equivalent of service
>must specify where to locate the service and how to connect to it
>(there are essentially two ways).
>
>> When we start to look at the consequences of outsourcing, the fact
>> that I have outsourced my Web site to outsource.net does not
>> necessarily mean I want to trust them with my mail service so maybe
>> the assumption that certificates are global to a domain also starts to
>> break down.
>
>Actually, HTTP is just about the worst in this regard since it does
>not support any kind of protocol-specific redirect from DNS. Yes, it
>supports CNAME, but CNAME isn't prtocol-specific.
>
>SMTP has MX records, many protocols have SRV, but HTTP does not have
>anything like that.
> 
>> So I am thinking that we are going to end up with a requirement for
>> protocol specific key assurance.
>
>Actually, at key assurance level, port numbers/services only matter
>if you can partition port numbers/services (which might not be
>possible) or if you have services with different security levels on
>one name (to prevent attacking higher-security services using stolen
>key from lower-security service).

  My take is that this all gets back to getting the CA's cleaned
up if possible AND eliminating the COI in respect to some few CA's
also being trust anchors.  Becaues if a key is presented from a
lower-security service that is a qualified CA and perhaps a Trust
Anchor as well, you end up with a obvious problem that is difficult
to actually solve.  
>
>-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
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402 
E-Mail [email-masked]
Phone: 214-244-4827

Date: Wed, 3 Nov 2010 19:04:23 +0000
From: Tony Finch <[email-masked]>
To: Paul Hoffman <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Wed, 3 Nov 2010, Paul Hoffman wrote:
>
> Can you be specific here? I'm not at all saying you are wrong; I might
> have dropped something in the redirection. My thought (possibly
> incorrect) is that one would only do a KIDNS lookup after they had
> gotten to the terminal end of an SRV chain.

You can save time if you can do them concurrently.

SRV isn't a chain, it's a single layer of indirection.

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: Wed, 3 Nov 2010 20:55:40 +0200
From: Ilari Liusvaara <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: Tony Finch <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Wed, Nov 03, 2010 at 01:14:11PM -0400, Phillip Hallam-Baker wrote:
> 
> There are certainly issues that arise with prefixes as I mentioned in
> my other post. But they are tractable provided that:
> 
> 1) You are prepared to allow an additional DNS round trip.
> 2) You are prepared to introduce a new DNS RR.

Considering the adoption of CERT RR, CERT RR can almost be treated as
new RR.

And there's a diffrence between having to serialize the query and
firing off the query in parallel with some other qurey one would have
to do anyway.

> We have to keep an eye on efficiency, but anything we do here is going
> to depend on deployment of new DNS support infrastructure and require
> transport that supports new RRs.

Well, there's RFC 3597. But of course, new RRs (even if RFC 3597-compliant)
have issues with adminstration.

> Certificates typically bind to an entire domain.

They may, or they may not. Some services use certificates in bizarre
manner and can't share them with anything.

> Statements concerning configuration of a security policy naturally
> bind to a specific service at a domain.

If you think HSTS is good example of security policy, consider that
HSTS is really a special kind of protcol-level redirect and is only
well-defined because of interactions between HSTS spec and HTTPS
spec.

That's why I think that records specifying secure equivalent of service
must specify where to locate the service and how to connect to it
(there are essentially two ways).

> When we start to look at the consequences of outsourcing, the fact
> that I have outsourced my Web site to outsource.net does not
> necessarily mean I want to trust them with my mail service so maybe
> the assumption that certificates are global to a domain also starts to
> break down.

Actually, HTTP is just about the worst in this regard since it does
not support any kind of protocol-specific redirect from DNS. Yes, it
supports CNAME, but CNAME isn't prtocol-specific.

SMTP has MX records, many protocols have SRV, but HTTP does not have
anything like that.
 
> So I am thinking that we are going to end up with a requirement for
> protocol specific key assurance.

Actually, at key assurance level, port numbers/services only matter
if you can partition port numbers/services (which might not be
possible) or if you have services with different security levels on
one name (to prevent attacking higher-security services using stolen
key from lower-security service).

-Ilari

Date: Wed, 3 Nov 2010 10:47:43 -0700
To: Tony Finch <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

At 5:28 PM +0000 11/3/10, Tony Finch wrote:
>On Wed, 3 Nov 2010, Paul Hoffman wrote:
>>
>> It is still far from clear how KIDNS will deal with SRV, so it is
>> premature to say that subdomains will be a problem. If KIDNS records are
>> retrieved for the name gotten from (not given to) the SRV request, there
>> is no issue, is there?
>
>Not from the RRset size point of view, but doing that is bad for
>performance.

Can you be specific here? I'm not at all saying you are wrong; I might have dropped something in the redirection. My thought (possibly incorrect) is that one would only do a KIDNS lookup after they had gotten to the terminal end of an SRV chain.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 3 Nov 2010 17:28:30 +0000
From: Tony Finch <[email-masked]>
To: Paul Hoffman <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Wed, 3 Nov 2010, Paul Hoffman wrote:
>
> It is still far from clear how KIDNS will deal with SRV, so it is
> premature to say that subdomains will be a problem. If KIDNS records are
> retrieved for the name gotten from (not given to) the SRV request, there
> is no issue, is there?

Not from the RRset size point of view, but doing that is bad for
performance.

> >It implies that I should change my email address to [email-masked] and
> >my Jabber ID to [email-masked] etc. etc. so that I can put their
> >certificates in the DNS.
>
> No, it does not imply that at all. The discussion of how to deal with
> end-user certificates in KIDNS has barely begun, and I doubt it will end
> with what you just said was the implication.

I'm not talking about personal certificates, I'm talking about the mail
and jabber services identified by the domain parts of the addresses.

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: Wed, 3 Nov 2010 17:20:53 +0000
From: Tony Finch <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] CNAME, wildcards, SRV and Key binding

On Mon, 1 Nov 2010, Phillip Hallam-Baker wrote:
>
> The idea behind ESRV was that the discovery would be a process of gradual
> refinement, starting with security policy for the site and gradually
> refining down to very specific policies for specific protocols, hosts and
> services.

I think this is over-complicated. Each service should be terated
independently by the protocol. If a site wants to specify policy at a
coarser level then they will need to repeat the policy for each service
that the policy applies to.

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: Wed, 3 Nov 2010 10:14:49 -0700
To: Tony Finch <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

At 4:57 PM +0000 11/3/10, Tony Finch wrote:
>On Wed, 3 Nov 2010, Paul Hoffman wrote:
>>
>> In the case of KIDNS, the solution is simple: don't allow a large number
>> of services to be accessed by that domain name just because they are all
>> running on the same box. That is, if the use of subtyping causes a
>> TCP-fallback problem for the nameserver of a particular domain name, the
>> solution is in the hands of the affected parties: use subdomains (which
>> they probably are already doing anyhow...).
>
>I think this is foolishly short-sighted and it ruins the simplification
>allowed by the SRV record. Just because pre-SRV protocols have to use
>subdomains for scalability doesn't mean that is a good usability idea.

It is still far from clear how KIDNS will deal with SRV, so it is premature to say that subdomains will be a problem. If KIDNS records are retrieved for the name gotten from (not given to) the SRV request, there is no issue, is there?

>It implies that I should change my email address to [email-masked] and
>my Jabber ID to [email-masked] etc. etc. so that I can put their
>certificates in the DNS.

No, it does not imply that at all. The discussion of how to deal with end-user certificates in KIDNS has barely begun, and I doubt it will end with what you just said was the implication.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 3 Nov 2010 13:14:11 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

+1 on the RFC 5507

This was actually a major change that was made to the document.
Originally there was a blanket proscription on prefixes that some of
us spent a lot of time and effort to get changed.

There are certainly issues that arise with prefixes as I mentioned in
my other post. But they are tractable provided that:

1) You are prepared to allow an additional DNS round trip.
2) You are prepared to introduce a new DNS RR.

We have to keep an eye on efficiency, but anything we do here is going
to depend on deployment of new DNS support infrastructure and require
transport that supports new RRs.

I think that we should first decide on all the features we might want
and then look at how we implement.

Certificates typically bind to an entire domain.

Statements concerning configuration of a security policy naturally
bind to a specific service at a domain.

I may use the same certificate for my mail and web servers. But I
almost certainly have not configured them identically.

When we start to look at the consequences of outsourcing, the fact
that I have outsourced my Web site to outsource.net does not
necessarily mean I want to trust them with my mail service so maybe
the assumption that certificates are global to a domain also starts to
break down.

So I am thinking that we are going to end up with a requirement for
protocol specific key assurance.

On Wed, Nov 3, 2010 at 12:36 PM, Paul Hoffman <[email-masked]> wrote=
:
> At 4:03 PM +0000 11/3/10, Tony Finch wrote:
>>On Sat, 30 Oct 2010, Warren Kumari wrote:
>>>
>>> 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
>>> [...], 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 [...] 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.
>>
>>I think both of these are argued against by section 3.1 of RFC 5507.
>>
>>That RFC also argues against a _prefix approach, but it also fails to
>>provide any solution for RRs that can apply to any service and which need
>>to be selected per service.
>
> I read that section (and lots of other sections of 5507) as saying "don't=
 assume one solution fits all". But I also note that the section 3.1 talks =
about the problems of "a large number of services for a single domain name"=
 causing fallback to TCP. In the case of KIDNS, the solution is simple: don=
't allow a large number of services to be accessed by that domain name just=
 because they are all running on the same box. That is, if the use of subty=
ping causes a TCP-fallback problem for the nameserver of a particular domai=
n name, the solution is in the hands of the affected parties: use subdomain=
s (which they probably are already doing anyhow...).
>
>>Another argument against putting all the records at the same domain name
>>is that it couples the policies for the services together. For instance, =
I
>>would want to be able to put certs or fingerprints in the DNS for my
>>secure services without forcing my colleagues to upgrade their services t=
o
>>secure-only. (It's reasonable not to prioritize the deployment of
>>encryption for anonyous services.)
>
> First off, the proposal for "say which services require TLS" is not part =
of KIDNS, despite what it might seem from reading some of the list traffic.=
 When that protocol is specified, it does not (and I think should not) be l=
inked to the KIDNS key association.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Wed, 3 Nov 2010 16:57:47 +0000
From: Tony Finch <[email-masked]>
To: Paul Hoffman <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Wed, 3 Nov 2010, Paul Hoffman wrote:
>
> In the case of KIDNS, the solution is simple: don't allow a large number
> of services to be accessed by that domain name just because they are all
> running on the same box. That is, if the use of subtyping causes a
> TCP-fallback problem for the nameserver of a particular domain name, the
> solution is in the hands of the affected parties: use subdomains (which
> they probably are already doing anyhow...).

I think this is foolishly short-sighted and it ruins the simplification
allowed by the SRV record. Just because pre-SRV protocols have to use
subdomains for scalability doesn't mean that is a good usability idea.

It implies that I should change my email address to [email-masked] and
my Jabber ID to [email-masked] etc. etc. so that I can put their
certificates in the DNS.

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: Wed, 3 Nov 2010 16:44:52 +0000
From: Tony Finch <[email-masked]>
To: Jakob Schlyter <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: Steve Schultze <[email-masked]>, [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Mon, 1 Nov 2010, Jakob Schlyter wrote:
>
> Publishing the key/hash material at the same name as the SRV doesn't
> work that well with managed services, e.g. if I use Google Apps for my
> jabber services, storing the keys at _jabber._tcp.kirei.se will not
> help, as I do not manage the keys - Google does.

Why doesn't CNAME solve this problem?

_jabber._tcp.kirei.se. CNAME _jabber._tcp.whatever.google.com

> In this case, the key material that will be used is better stored at the
> SRV destination (e.g., xmpp-server.l.google.com.).

This forces the two DNS lookups to be sequential which is slow.

> Given this, IMHO, the key material for my mail server should be stored
> at the MX destination mail.kirei.se - not kirei.se nor
> _smtp._tcp.kirei.se.

If they are stored at _smtp._tcp.kirei.se then you can use a CNAME to deal
with outsourced service, and support concurrent lookups of target hostname
and cert material.

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: Wed, 3 Nov 2010 16:38:59 +0000
From: Tony Finch <[email-masked]>
To: Ilari Liusvaara <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: Steve Schultze <[email-masked]>, [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Sun, 31 Oct 2010, Ilari Liusvaara wrote:
>
> 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...).

That would work except for protocols that do not use SRV.

If you publish the cert material attached to the service domain (as
opposed to the service target hostname) then you also get a performance
advantage since you can do the two lookups concurrently, which your
proposal does not permit.

e.g.

_smtp._tcp.example TLSFP ...
_smtp._tcp.example SRV ...

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: Wed, 3 Nov 2010 09:36:38 -0700
To: Tony Finch <[email-masked]>, Warren Kumari <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

At 4:03 PM +0000 11/3/10, Tony Finch wrote:
>On Sat, 30 Oct 2010, Warren Kumari wrote:
>>
>> 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
>> [...], 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 [...] 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.
>
>I think both of these are argued against by section 3.1 of RFC 5507.
>
>That RFC also argues against a _prefix approach, but it also fails to
>provide any solution for RRs that can apply to any service and which need
>to be selected per service.

I read that section (and lots of other sections of 5507) as saying "don't assume one solution fits all". But I also note that the section 3.1 talks about the problems of "a large number of services for a single domain name" causing fallback to TCP. In the case of KIDNS, the solution is simple: don't allow a large number of services to be accessed by that domain name just because they are all running on the same box. That is, if the use of subtyping causes a TCP-fallback problem for the nameserver of a particular domain name, the solution is in the hands of the affected parties: use subdomains (which they probably are already doing anyhow...).

>Another argument against putting all the records at the same domain name
>is that it couples the policies for the services together. For instance, I
>would want to be able to put certs or fingerprints in the DNS for my
>secure services without forcing my colleagues to upgrade their services to
>secure-only. (It's reasonable not to prioritize the deployment of
>encryption for anonyous services.)

First off, the proposal for "say which services require TLS" is not part of KIDNS, despite what it might seem from reading some of the list traffic. When that protocol is specified, it does not (and I think should not) be linked to the KIDNS key association.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 3 Nov 2010 16:03:53 +0000
From: Tony Finch <[email-masked]>
To: Warren Kumari <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Sat, 30 Oct 2010, Warren Kumari wrote:
>
> 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
> [...], 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 [...] 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.

I think both of these are argued against by section 3.1 of RFC 5507.

That RFC also argues against a _prefix approach, but it also fails to
provide any solution for RRs that can apply to any service and which need
to be selected per service.

Another argument against putting all the records at the same domain name
is that it couples the policies for the services together. For instance, I
would want to be able to put certs or fingerprints in the DNS for my
secure services without forcing my colleagues to upgrade their services to
secure-only. (It's reasonable not to prioritize the deployment of
encryption for anonyous services.)

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: Wed, 3 Nov 2010 15:32:25 +0000
From: Tony Finch <[email-masked]>
To: Matt McCutchen <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Sat, 30 Oct 2010, Matt McCutchen wrote:
>
> The flag has a simple and clear semantic, "I authorize this certificate
> and only this certificate for use on my TLS server"

That's too simple. You need to be able to publish multiple certificates
(or fingerprints) and exclude certificates that don't match any of them.
This is necessary for rollover, amongst other things.

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, 2 Nov 2010 11:34:30 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

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

On Tue, Nov 2, 2010 at 10:29 AM, Ond=C5=99ej Sur=C3=BD <[email-masked]>=
 wrote:

> On 2.11.2010 14:49, Warren Kumari wrote:
>
>> A clear (and I do mean painfully clear) requirements document
>>> outlining exactly what functionality is required, however, would go
>>> a long way to making such development possible in DNSEXT.  Note
>>> that I am very keen to avoid a repeat of the current disaster with
>>> respect to "aliases" in the DNS, and I think this community is more
>>> sensitive to details of how DNS works than the community whence
>>> came the alias work.  So if this is something desirable, I would
>>> encourage the development of such a requirements document either in
>>> this proto-group or else independently, by some of the
>>> participants.
>>>
>>
>> I am not convinced that this is path that we want to go down (the
>> idea, not the "write it up if y'all want DNSEXT to even consider
>> it"), I think that, at the moment, we are more rumbling about various
>> blue sky possibilities... If it turns out that we do end up going
>> down this path, it will be after some serious thought -- making
>> changes that affect basic plumbing and require changes in the
>> behavior of resolvers is not to be taken lightly, and will make
>> deployment *really* *really* hard...
>>
>
> I agree with Warren.  Crafting a solution in KIDNS which is based on
> "EDNS1" is a good way how to kill it.  I think we are talking here about
> premature optimizations while we don't have the basic work done.
>

Then isn't it  good thing that nobody actually proposed doing that?

My argument was that it was premature to optimize the protocol.

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

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

<br><br><div class=3D"gmail_quote">On Tue, Nov 2, 2010 at 10:29 AM, Ond=F8e=
j Sur=FD <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">ondrej=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 2.11.2010 14:49, Warren Kumari wrote:<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 clear (and I do mean painfully clear) requirements document<br>
outlining exactly what functionality is required, however, would go<br>
a long way to making such development possible in DNSEXT. =A0Note<br>
that I am very keen to avoid a repeat of the current disaster with<br>
respect to &quot;aliases&quot; in the DNS, and I think this community is mo=
re<br>
sensitive to details of how DNS works than the community whence<br>
came the alias work. =A0So if this is something desirable, I would<br>
encourage the development of such a requirements document either in<br>
this proto-group or else independently, by some of the<br>
participants.<br>
</blockquote>
<br>
I am not convinced that this is path that we want to go down (the<br>
idea, not the &quot;write it up if y&#39;all want DNSEXT to even consider<b=
r>
it&quot;), I think that, at the moment, we are more rumbling about various<=
br>
blue sky possibilities... If it turns out that we do end up going<br>
down this path, it will be after some serious thought -- making<br>
changes that affect basic plumbing and require changes in the<br>
behavior of resolvers is not to be taken lightly, and will make<br>
deployment *really* *really* hard...<br>
</blockquote>
<br></div>
I agree with Warren. =A0Crafting a solution in KIDNS which is based on &quo=
t;EDNS1&quot; is a good way how to kill it. =A0I think we are talking here =
about premature optimizations while we don&#39;t have the basic work done.<=
br>
</blockquote><div><br></div><div>Then isn&#39;t it =A0good thing that nobod=
y actually proposed doing that?</div><div><br></div><div>My argument was th=
at it was premature to optimize the protocol.=A0</div><div><br></div><div>=
=A0</div>
</div>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallambake=
r.com/</a><br><br>

--0016368e1c1033996f049413a94d--

Date: Tue, 02 Nov 2010 16:00:26 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and	draft-hoffman-keys-linkage-from-dns

On 2.11.2010 15:47, Warren Kumari wrote:
>> I think my original point has been lost, what I originally wrote
>> was:
>>
>> "Performance matters here. But we should not allow performance to
>> drive requirements. If we can get all the requirements on the table
>> (performance included) we can then see who can propose the best
>> trade off that gets most support.
>>
>> Remember that in the context of a complete transaction a better
>> discovery mechanism that allows the client to select the nearest
>> service may be better overall than one that minimizes dns round
>> trips. Also there is scope for optimizing the DNS protocol
>> itself."
>>
>>
>> If people care about performance then they should be looking at the
>> whole protocol interaction and not just one module in isolation.
>
> Yup, sorry, point taken -- I am perhaps overly sensitive about
> ratholes and distractions, but realize that you were just kaing a
> general point, not "Let's go down this path...". Apologies...
>
> So, specifically to the 'megaquery' (and similar) suggestions -- one
> (obvious) plan would be to build this all using "current technology"
> and the cool DNS tricks would be a future optimization. I know that I
> have alway wanted to be able to query 'www.foo.com' and get a port in
> addition to an IP (this is less interesting with SNI, but, still...),
> but haven't wanted it enough to bother *doing* anything about it :-)

[moderator hat on]

Could we please stop here.  We are getting off-topic.  So if you 
(generic you, not Warren-you) want to discuss it, please take it to 
DNSEXT.  (And I suggest you go read archives first, I am quite sure this 
has been beaten to the death already when there was A+AAAA.)

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

From: Warren Kumari <[email-masked]>
Date: Tue, 2 Nov 2010 10:56:05 -0400
To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and	draft-hoffman-keys-linkage-from-dns

On Nov 2, 2010, at 10:42 AM, Ond=C5=99ej Sur=C3=BD wrote:

> On 2.11.2010 15:16, Phillip Hallam-Baker wrote:
>> I think my original point has been lost, what I originally wrote was:
>>=20
>> "Performance matters here. But we should not allow performance to =
drive
>> requirements. If we can get all the requirements on the table
>> (performance included) we can then see who can propose the best trade
>> off that gets most support.
>>=20
>> Remember that in the context of a complete transaction a better
>> discovery mechanism that allows the client to select the nearest =
service
>> may be better overall than one that minimizes dns round trips. Also
>> there is scope for optimizing the DNS protocol itself."
>=20
> Changes (optimizations) of DNS protocol affects more parties than just =
creating new RRs and teaching clients to ask for them.  You need support =
for new "option" all along the way (in all resolvers), and it becomes =
even more complicated when there are chained caches (with mixed =
support).

Yes -- look at DNSSEC for an example...

>=20
> Also you will need to support old clients for a long time and the =
percentage of those who will be able to use the optimization will be =
very low (for a long period of time).
>=20
> > If people care about performance then they should be looking at the
> > whole protocol interaction and not just one module in isolation.
>=20
> Well in case of optimizing the DNS protocol you need to think in much =
broader scope because it affects not just our field, but almost =
everybody out there.

Yes, not a job to be undertaken lightly, but, once we have consensus =
(and implementations) of the base work, it MAY be interesting for some =
of us to consider writing up something and pursue it in DNSEXT, as a =
DNSEXT (not KIDNS) item -- please note the liberal use of weasel words.=20=

If all this were to happen, I'd think that the KIDNS "requirements" =
would be a tiny consideration, and the work would be driven by general =
utility...

I guess my summary here is that this idea sounds interesting and useful, =
and that folk should feel free to pursue it if they like, but that =
(IMO), this isn't the place for it...

W

>=20
> Ondrej
> --=20
> Ond=C5=99ej Sur=C3=BD
> vedouc=C3=AD v=C3=BDzkumu/Head of R&D department
> -------------------------------------------
> CZ.NIC, z.s.p.o.    --    Laborato=C5=99e 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

From: Warren Kumari <[email-masked]>
Date: Tue, 2 Nov 2010 10:47:24 -0400
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Nov 2, 2010, at 10:16 AM, Phillip Hallam-Baker wrote:

> I think my original point has been lost, what I originally wrote was:
>=20
> "Performance matters here. But we should not allow performance to =
drive requirements. If we can get all the requirements on the table =
(performance included) we can then see who can propose the best trade =
off that gets most support.
>=20
> Remember that in the context of a complete transaction a better =
discovery mechanism that allows the client to select the nearest service =
may be better overall than one that minimizes dns round trips. Also =
there is scope for optimizing the DNS protocol itself."
>=20
>=20
> If people care about performance then they should be looking at the =
whole protocol interaction and not just one module in isolation.

Yup, sorry, point taken -- I am perhaps overly sensitive about ratholes =
and distractions, but realize that you were just kaing a general point, =
not "Let's go down this path...". Apologies...

So, specifically to the 'megaquery' (and similar) suggestions -- one =
(obvious) plan would be to build this all using "current technology" and =
the cool DNS tricks would be a future optimization. I know that I have =
alway wanted to be able to query 'www.foo.com' and get a port in =
addition to an IP (this is less interesting with SNI, but, still...), =
but haven't wanted it enough to bother *doing* anything about it :-)

W

(Obviously, through DNSEXT, etc...)

>=20
>=20
>=20
> On Tue, Nov 2, 2010 at 9:49 AM, Warren Kumari <[email-masked]> =
wrote:
>=20
> On Nov 2, 2010, at 6:36 AM, Andrew Sullivan wrote:
>=20
> > On Mon, Nov 01, 2010 at 09:46:07AM -0400, Phillip Hallam-Baker =
wrote:
> >>
> >> For example, we could use EDNS to advertise support for a
> >> 'megaquery' which would be a new query format that contains =
separate
> >> slots for the protocol, name, try number. If we have a common
> >> discovery architecture defined the resolver can then ferret out all
> >> the data required and deliver it on a plate.
> >
> > I am not a big fan of turf wars in the IETF, but it seems to me that
> > any development along the lines you are suggesting is pretty clearly
> > going to need to go through DNSEXT.
>=20
> Yes, fully, 100% agree...
>=20
> >  A clear (and I do mean painfully
> > clear) requirements document outlining exactly what functionality is
> > required, however, would go a long way to making such development
> > possible in DNSEXT.  Note that I am very keen to avoid a repeat of =
the
> > current disaster with respect to "aliases" in the DNS, and I think
> > this community is more sensitive to details of how DNS works than =
the
> > community whence came the alias work.  So if this is something
> > desirable, I would encourage the development of such a requirements
> > document either in this proto-group or else independently, by some =
of
> > the participants.
>=20
> I am not convinced that this is path that we want to go down (the =
idea, not the "write it up if y'all want DNSEXT to even consider it"), I =
think that, at the moment, we are more rumbling about various blue sky =
possibilities... If it turns out that we do end up going down this path, =
it will be after some serious thought -- making changes that affect =
basic plumbing and require changes in the behavior of resolvers is not =
to be taken lightly, and will make deployment *really* *really* hard...
>=20
> W
>=20
> >
> > Best,
> >
> > A
> >
> > --
> > Andrew Sullivan
> > [email-masked]
> > Shinkuro, Inc.
> > _______________________________________________
> > 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
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20

Date: Tue, 02 Nov 2010 15:42:52 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and	draft-hoffman-keys-linkage-from-dns

On 2.11.2010 15:16, Phillip Hallam-Baker wrote:
> I think my original point has been lost, what I originally wrote was:
>
> "Performance matters here. But we should not allow performance to drive
> requirements. If we can get all the requirements on the table
> (performance included) we can then see who can propose the best trade
> off that gets most support.
>
> Remember that in the context of a complete transaction a better
> discovery mechanism that allows the client to select the nearest service
> may be better overall than one that minimizes dns round trips. Also
> there is scope for optimizing the DNS protocol itself."

Changes (optimizations) of DNS protocol affects more parties than just 
creating new RRs and teaching clients to ask for them.  You need support 
for new "option" all along the way (in all resolvers), and it becomes 
even more complicated when there are chained caches (with mixed support).

Also you will need to support old clients for a long time and the 
percentage of those who will be able to use the optimization will be 
very low (for a long period of time).

 > If people care about performance then they should be looking at the
 > whole protocol interaction and not just one module in isolation.

Well in case of optimizing the DNS protocol you need to think in much 
broader scope because it affects not just our field, but almost 
everybody out there.

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, 02 Nov 2010 15:29:42 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results	and	draft-hoffman-keys-linkage-from-dns

On 2.11.2010 14:49, Warren Kumari wrote:
>> A clear (and I do mean painfully clear) requirements document
>> outlining exactly what functionality is required, however, would go
>> a long way to making such development possible in DNSEXT.  Note
>> that I am very keen to avoid a repeat of the current disaster with
>> respect to "aliases" in the DNS, and I think this community is more
>> sensitive to details of how DNS works than the community whence
>> came the alias work.  So if this is something desirable, I would
>> encourage the development of such a requirements document either in
>> this proto-group or else independently, by some of the
>> participants.
>
> I am not convinced that this is path that we want to go down (the
> idea, not the "write it up if y'all want DNSEXT to even consider
> it"), I think that, at the moment, we are more rumbling about various
> blue sky possibilities... If it turns out that we do end up going
> down this path, it will be after some serious thought -- making
> changes that affect basic plumbing and require changes in the
> behavior of resolvers is not to be taken lightly, and will make
> deployment *really* *really* hard...

I agree with Warren.  Crafting a solution in KIDNS which is based on 
"EDNS1" is a good way how to kill it.  I think we are talking here about 
premature optimizations while we don't have the basic work done.

There are more interest groups which would benefit from packing multiple 
queries into one packet, but my view is that such a change is even more 
bothersome then "aliasing".

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, 2 Nov 2010 10:16:52 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

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

I think my original point has been lost, what I originally wrote was:

"Performance matters here. But we should not allow performance to drive
requirements. If we can get all the requirements on the table (performance
included) we can then see who can propose the best trade off that gets most
support.

Remember that in the context of a complete transaction a better discovery
mechanism that allows the client to select the nearest service may be better
overall than one that minimizes dns round trips. Also there is scope for
optimizing the DNS protocol itself."

If people care about performance then they should be looking at the whole
protocol interaction and not just one module in isolation.

On Tue, Nov 2, 2010 at 9:49 AM, Warren Kumari <[email-masked]> wrote:

>
> On Nov 2, 2010, at 6:36 AM, Andrew Sullivan wrote:
>
> > On Mon, Nov 01, 2010 at 09:46:07AM -0400, Phillip Hallam-Baker wrote:
> >>
> >> For example, we could use EDNS to advertise support for a
> >> 'megaquery' which would be a new query format that contains separate
> >> slots for the protocol, name, try number. If we have a common
> >> discovery architecture defined the resolver can then ferret out all
> >> the data required and deliver it on a plate.
> >
> > I am not a big fan of turf wars in the IETF, but it seems to me that
> > any development along the lines you are suggesting is pretty clearly
> > going to need to go through DNSEXT.
>
> Yes, fully, 100% agree...
>
> >  A clear (and I do mean painfully
> > clear) requirements document outlining exactly what functionality is
> > required, however, would go a long way to making such development
> > possible in DNSEXT.  Note that I am very keen to avoid a repeat of the
> > current disaster with respect to "aliases" in the DNS, and I think
> > this community is more sensitive to details of how DNS works than the
> > community whence came the alias work.  So if this is something
> > desirable, I would encourage the development of such a requirements
> > document either in this proto-group or else independently, by some of
> > the participants.
>
> I am not convinced that this is path that we want to go down (the idea, not
> the "write it up if y'all want DNSEXT to even consider it"), I think that,
> at the moment, we are more rumbling about various blue sky possibilities...
> If it turns out that we do end up going down this path, it will be after
> some serious thought -- making changes that affect basic plumbing and
> require changes in the behavior of resolvers is not to be taken lightly, and
> will make deployment *really* *really* hard...
>
> W
>
> >
> > Best,
> >
> > A
> >
> > --
> > Andrew Sullivan
> > [email-masked]
> > Shinkuro, Inc.
> > _______________________________________________
> > keyassure mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/keyassure
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

I think my original point has been lost, what I originally wrote was:<div><=
br></div><div>&quot;<meta charset=3D"utf-8"><span class=3D"Apple-style-span=
" style=3D"font-family: arial, sans-serif; font-size: 12.5px; border-collap=
se: collapse; color: rgb(51, 51, 51); ">Performance matters here. But we sh=
ould not allow performance to drive requirements. If we can get all the req=
uirements on the table (performance included) we can then see who can propo=
se the best trade off that gets most support.</span></div>
<div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser=
if; font-size: 12.5px; border-collapse: collapse; color: rgb(51, 51, 51); "=
><br></span></div><meta charset=3D"utf-8"><div><span class=3D"Apple-style-s=
pan" style=3D"font-family: arial, sans-serif; font-size: 12.5px; border-col=
lapse: collapse; color: rgb(51, 51, 51); "><span class=3D"Apple-style-span"=
 style=3D"font-size: 12.5px; ">Remember that in the context of a complete t=
ransaction a better discovery mechanism that allows the client to select th=
e nearest service may be better overall than one that minimizes dns round t=
rips. Also there is scope for optimizing the DNS protocol itself.</span>&qu=
ot;</span></div>
<div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser=
if; font-size: 12.5px; border-collapse: collapse; color: rgb(51, 51, 51); "=
><br></span></div><div><span class=3D"Apple-style-span" style=3D"font-famil=
y: arial, sans-serif; font-size: 12.5px; border-collapse: collapse; color: =
rgb(51, 51, 51); "><br>
</span></div><div><span class=3D"Apple-style-span" style=3D"font-family: ar=
ial, sans-serif; font-size: 12.5px; border-collapse: collapse; color: rgb(5=
1, 51, 51); ">If people care about performance then they should be looking =
at the whole protocol interaction and not just one module in isolation.</sp=
an></div>
<div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser=
if; font-size: 12.5px; border-collapse: collapse; color: rgb(51, 51, 51); "=
><br></span></div><div><span class=3D"Apple-style-span" style=3D"font-famil=
y: arial, sans-serif; font-size: 12.5px; border-collapse: collapse; color: =
rgb(51, 51, 51); "><br>
</span></div><div><span class=3D"Apple-style-span" style=3D"font-family: ar=
ial, sans-serif; font-size: 12.5px; border-collapse: collapse; color: rgb(5=
1, 51, 51); "><br></span></div><div>On Tue, Nov 2, 2010 at 9:49 AM, Warren =
Kumari <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">warren@ku=
mari.net</a>&gt;</span> wrote:</div>
<div><div><div class=3D"gmail_quote"><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"><br>
On Nov 2, 2010, at 6:36 AM, Andrew Sullivan wrote:<br>
<br>
&gt; On Mon, Nov 01, 2010 at 09:46:07AM -0400, Phillip Hallam-Baker wrote:<=
br>
&gt;&gt;<br>
&gt;&gt; For example, we could use EDNS to advertise support for a<br>
&gt;&gt; &#39;megaquery&#39; which would be a new query format that contain=
s separate<br>
&gt;&gt; slots for the protocol, name, try number. If we have a common<br>
&gt;&gt; discovery architecture defined the resolver can then ferret out al=
l<br>
&gt;&gt; the data required and deliver it on a plate.<br>
&gt;<br>
&gt; I am not a big fan of turf wars in the IETF, but it seems to me that<b=
r>
&gt; any development along the lines you are suggesting is pretty clearly<b=
r>
&gt; going to need to go through DNSEXT.<br>
<br>
</div>Yes, fully, 100% agree...<br>
<div class=3D"im"><br>
&gt; =A0A clear (and I do mean painfully<br>
&gt; clear) requirements document outlining exactly what functionality is<b=
r>
&gt; required, however, would go a long way to making such development<br>
&gt; possible in DNSEXT. =A0Note that I am very keen to avoid a repeat of t=
he<br>
&gt; current disaster with respect to &quot;aliases&quot; in the DNS, and I=
 think<br>
&gt; this community is more sensitive to details of how DNS works than the<=
br>
&gt; community whence came the alias work. =A0So if this is something<br>
&gt; desirable, I would encourage the development of such a requirements<br=
>
&gt; document either in this proto-group or else independently, by some of<=
br>
&gt; the participants.<br>
<br>
</div>I am not convinced that this is path that we want to go down (the ide=
a, not the &quot;write it up if y&#39;all want DNSEXT to even consider it&q=
uot;), I think that, at the moment, we are more rumbling about various blue=
 sky possibilities... If it turns out that we do end up going down this pat=
h, it will be after some serious thought -- making changes that affect basi=
c plumbing and require changes in the behavior of resolvers is not to be ta=
ken lightly, and will make deployment *really* *really* hard...<br>

<font color=3D"#888888"><br>
W<br>
</font><div><div></div><div class=3D"h5"><br>
&gt;<br>
&gt; Best,<br>
&gt;<br>
&gt; A<br>
&gt;<br>
&gt; --<br>
&gt; Andrew Sullivan<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; Shinkuro, Inc.<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>
<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></div>

--0016368e1c108f7122049412930f--

From: Warren Kumari <[email-masked]>
Date: Tue, 2 Nov 2010 09:49:36 -0400
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and	draft-hoffman-keys-linkage-from-dns

On Nov 2, 2010, at 6:36 AM, Andrew Sullivan wrote:

> On Mon, Nov 01, 2010 at 09:46:07AM -0400, Phillip Hallam-Baker wrote:
>>=20
>> For example, we could use EDNS to advertise support for a
>> 'megaquery' which would be a new query format that contains separate
>> slots for the protocol, name, try number. If we have a common
>> discovery architecture defined the resolver can then ferret out all
>> the data required and deliver it on a plate.
>=20
> I am not a big fan of turf wars in the IETF, but it seems to me that
> any development along the lines you are suggesting is pretty clearly
> going to need to go through DNSEXT.

Yes, fully, 100% agree...

>  A clear (and I do mean painfully
> clear) requirements document outlining exactly what functionality is
> required, however, would go a long way to making such development
> possible in DNSEXT.  Note that I am very keen to avoid a repeat of the
> current disaster with respect to "aliases" in the DNS, and I think
> this community is more sensitive to details of how DNS works than the
> community whence came the alias work.  So if this is something
> desirable, I would encourage the development of such a requirements
> document either in this proto-group or else independently, by some of
> the participants.

I am not convinced that this is path that we want to go down (the idea, =
not the "write it up if y'all want DNSEXT to even consider it"), I think =
that, at the moment, we are more rumbling about various blue sky =
possibilities... If it turns out that we do end up going down this path, =
it will be after some serious thought -- making changes that affect =
basic plumbing and require changes in the behavior of resolvers is not =
to be taken lightly, and will make deployment *really* *really* hard...

W=20

>=20
> Best,
>=20
> A
>=20
> --=20
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Tue, 2 Nov 2010 08:54:09 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

--00163616446bb349370494116b29
Content-Type: text/plain; charset=ISO-8859-1

Of course any proposal to implement would have to go through DNSEXT.

But the option of optimizing the DNS protocol is relevant to the question of
performance and the number of round trips discovery takes.

Performance and functionality need to be considered differently in this
respect. I don't think we should develop a proposal in one WG that depends
on another WG accepting some structural change to work at all.

So depending on DNSEXT producing a BNAME specification would be a disaster
in my view. There are enough constraints on that problem already without
introducing even more. But proposing to DNSEXT a rather modest performance
improvement that is not essential does not bother me much.

On Tue, Nov 2, 2010 at 6:36 AM, Andrew Sullivan <[email-masked]> wrote:

> On Mon, Nov 01, 2010 at 09:46:07AM -0400, Phillip Hallam-Baker wrote:
> >
> > For example, we could use EDNS to advertise support for a
> > 'megaquery' which would be a new query format that contains separate
> > slots for the protocol, name, try number. If we have a common
> > discovery architecture defined the resolver can then ferret out all
> > the data required and deliver it on a plate.
>
> I am not a big fan of turf wars in the IETF, but it seems to me that
> any development along the lines you are suggesting is pretty clearly
> going to need to go through DNSEXT.  A clear (and I do mean painfully
> clear) requirements document outlining exactly what functionality is
> required, however, would go a long way to making such development
> possible in DNSEXT.  Note that I am very keen to avoid a repeat of the
> current disaster with respect to "aliases" in the DNS, and I think
> this community is more sensitive to details of how DNS works than the
> community whence came the alias work.  So if this is something
> desirable, I would encourage the development of such a requirements
> document either in this proto-group or else independently, by some of
> the participants.
>
> Best,
>
> A
>
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

Of course any proposal to implement would have to go through DNSEXT.<div><b=
r></div><div>But the option of optimizing the DNS protocol is relevant to t=
he question of performance and the number of round trips discovery takes.</=
div>
<div><br></div><div><br></div><div>Performance and functionality need to be=
 considered differently in this respect. I don&#39;t think we should develo=
p a proposal in one WG that depends on another WG accepting some structural=
 change to work at all.</div>
<div><br></div><div>So depending on DNSEXT producing a BNAME specification =
would be a disaster in my view. There are enough constraints on that proble=
m already without introducing even more. But proposing to DNSEXT a rather m=
odest performance improvement that is not essential does not bother me much=
.</div>
<div><br></div><div><br></div><div><div class=3D"gmail_quote">On Tue, Nov 2=
, 2010 at 6:36 AM, Andrew Sullivan <span dir=3D"ltr">&lt;<a href=3D"mailto:=
[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex;">
<div class=3D"im">On Mon, Nov 01, 2010 at 09:46:07AM -0400, Phillip Hallam-=
Baker wrote:<br>
&gt;<br>
&gt; For example, we could use EDNS to advertise support for a<br>
&gt; &#39;megaquery&#39; which would be a new query format that contains se=
parate<br>
&gt; slots for the protocol, name, try number. If we have a common<br>
&gt; discovery architecture defined the resolver can then ferret out all<br=
>
&gt; the data required and deliver it on a plate.<br>
<br>
</div>I am not a big fan of turf wars in the IETF, but it seems to me that<=
br>
any development along the lines you are suggesting is pretty clearly<br>
going to need to go through DNSEXT. =A0A clear (and I do mean painfully<br>
clear) requirements document outlining exactly what functionality is<br>
required, however, would go a long way to making such development<br>
possible in DNSEXT. =A0Note that I am very keen to avoid a repeat of the<br=
>
current disaster with respect to &quot;aliases&quot; in the DNS, and I thin=
k<br>
this community is more sensitive to details of how DNS works than the<br>
community whence came the alias work. =A0So if this is something<br>
desirable, I would encourage the development of such a requirements<br>
document either in this proto-group or else independently, by some of<br>
the participants.<br>
<br>
Best,<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>

--00163616446bb349370494116b29--

Date: Tue, 2 Nov 2010 06:36:40 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and	draft-hoffman-keys-linkage-from-dns

On Mon, Nov 01, 2010 at 09:46:07AM -0400, Phillip Hallam-Baker wrote:
> 
> For example, we could use EDNS to advertise support for a
> 'megaquery' which would be a new query format that contains separate
> slots for the protocol, name, try number. If we have a common
> discovery architecture defined the resolver can then ferret out all
> the data required and deliver it on a plate.

I am not a big fan of turf wars in the IETF, but it seems to me that
any development along the lines you are suggesting is pretty clearly
going to need to go through DNSEXT.  A clear (and I do mean painfully
clear) requirements document outlining exactly what functionality is
required, however, would go a long way to making such development
possible in DNSEXT.  Note that I am very keen to avoid a repeat of the
current disaster with respect to "aliases" in the DNS, and I think
this community is more sensitive to details of how DNS works than the
community whence came the alias work.  So if this is something
desirable, I would encourage the development of such a requirements
document either in this proto-group or else independently, by some of
the participants.

Best,

A

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

From: Jakob Schlyter <[email-masked]>
Date: Tue, 2 Nov 2010 11:30:46 +0100
To: Phillip Hallam-Baker <[email-masked]>
Cc: Steve Schultze <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On 1 nov 2010, at 14.46, Phillip Hallam-Baker wrote:

> For example, we could use EDNS to advertise support for a 'megaquery' =
which would be a new query format that contains separate slots for the =
protocol, name, try number. If we have a common discovery architecture =
defined the resolver can then ferret out all the data required and =
deliver it on a plate.

Although I agree with the usefulness of such an EDNS option, I do not =
think this is within the scope of KIDNS to extend the current DNS =
protocol with such an option.

	jakob

To: Phillip Hallam-Baker <[email-masked]>
From: Mark Andrews <[email-masked]>
Date: Tue, 02 Nov 2010 11:20:44 +1100
Cc: [email-masked]
Subject: Re: [keyassure] CNAME, wildcards, SRV and Key binding

In message <[email-masked]>, Phil
lip Hallam-Baker writes:
> Two of the biggest challenges to work around for KIDNS is the existence of
> CNAMES and wildcards.
> 
> Both suffer from having somewhat soft semantics implementation wise. The
> official semantics are strict enough to get in the way but the diversity of
> implementations means that it is not necessarily possible to benefit from
> that strictness.
> 
> DNSSEC affects wildcards in particular since DNS wildcards were originally
> an issue for the DNS server alone. Before DNSSEC, a server could synthesize
> any record it liked and so a wildcard of the form x.*.y was completely
> feasible. DNSSEC only allows wildcards of the form *.y and that makes use of
> prefixes difficult.
> 
> CNAMES pose a separate problem. According to the rules the only things that
> can exist at a DNS node with a CNAME are the CNAME record and the signature
> records.

Which is not a show stopping issue.  You just replace the CNAME
with the address or other records that are being referenced by the
CNAME records (for legacy clients) and also introduce SRV (or
similar) support so that the indirection has the right sematics.
HTTP has been mis-using CNAME records for a long time now.

> CNAMES do not work well with prefixes. The intention of a CNAME is to say
> 'this name is equivalent to that name'. 

No.  CNAME is "the real name of this object is TARGET".

> That does not work because the CNAME
> only applies to the node and not any prefixes. So one solution is to use a
> DNAME which maps the entire tree. But that also does not work in cases where
> there are names and prefixes involved.

See BNAME proposals.
 
> the reason we have to think about them is that naming affects trust. If we
> have one name aliased to another, where should we be looking for the keys?
> If we have a service provided from multiple hosts should we look for keys at
> the service level or for the individual host?

The target of the CNAME.  If you want the owner of the CNAME record
to be the name found in the cert then you shouldn't be using CNAME
in the first place.  You should be using something SRV/MX like to
find the addresses of the hosting servers.

Once you are using something SRV/MX like you can make the decision
on a per-protocol basis.  Remember the SRV/MX records are signed.

For HTTP you use the original name.  For SMTP you use the targets
of the MX records.  Both could have well known prefixes attached
to allow for service specific certs.

> There are plenty of corner cases and I wrote a very long private message
> setting these out last week, but I think it is possible to address all of
> them if we apply the following rules:
> 
> 1) The first lookup in a discovery chain is for an unprefixed record.
> 
> 2) Subsequent lookups are for prefixed records and the records returned MUST
> be canonical (no CNAME, DNAME, ZNAME...)
> 
> Here the term 'discovery' may be as narrow as security attribute discovery
> or may combine service and security attribute discovery.
> 
> 
> The idea behind ESRV was that the discovery would be a process of gradual
> refinement, starting with security policy for the site and gradually
> refining down to very specific policies for specific protocols, hosts and
> services.
> 
> I think that is still the way to do it, but we need to complete the process
> in fewer steps than are involved in ESRV.
> 
> 
> So imagine we have two new RRs, START and DETAIL. These are just for the
> sake of example of course. It may even be possible to combine both RRs into
> one.
> 
> The discovery process always begins with a request for an unprefixed START
> rr, but may lead to requests for more detail.
> 
> 
> A very simple site might be able to pack its entire policy into one record
> 
> simple.example.com  START "always use TLS, always use the cert
> fingerprint=Y"
> 
> Such a site may have an alias, or even a wildcard record:
> 
> alias.example.com CNAME simple.example.com
> *.wildcard.example.com CNAME "always use TLS, always use the cert
> fingerprint=Y"
> 
> 
> A more complex site might have different policies for different services:
> 
> 
> complex.example.com START "look for detail by protocol"
> _http._tcp.example.com DETAIL "always use TLS"
> _finger._tcp.example.com DETAIL "never use TLS use SRV discovery"
> _finger._tcp.example.com SRV 1 1 9000 finger1.example.com
> _finger._tcp.example.com SRV 1 1 9000 finger1.example.com
> 
> 
> So now if we alias alias.complex.example.com to the above, the discovery
> works exactly as we would like.
> 
> alias.complex.example.com  CNAME complex.example.com
> 
> We can also do wildcards or anything else that we might want to do.
> 
> 
> If we are doing outsourcing, I would think that the way we would want to
> achieve that is by inserting one record that says 'do SRV discovery at the
> outsource provider' So if we have Big URL Resolution Protocol (BURP) I would
> think that we would want to have something like
> 
> 
> complex.example.com START "look for detail by protocol"
> _http._tcp.example.com DETAIL "always use TLS"
> _finger._tcp.example.com DETAIL "never use TLS"
> _burp._tcp.example.com DETAIL "look at trusted.outsource.ly"
> 
> At the outsource:
> _burp._tcp.trusted.outsource.ly DETAIL "never use TLS"
> 
> 
> But I can well see that there would be cases where you would want to have
> detail that applied to specific SRV hosts.
> 
> 
> Granted, this appears to require a lot of round trips. But I think that this
> would not be the case in practice and certainly not if we also extend the
> DNS protocol itself to support this scheme.
> 
> DNS allows for additional records to be packed into each response. So as I
> see it, we should only need two round trips for the general case where the
> resolution does not cross administrative zone boundaries.
> 
> First phase:  Lookup A, AAAA and START RRs for unprefixed record
> Second phase (if needed): Lookup  DETAIL, SRV records
> 
> 
> 
> -- 
> Website: http://hallambaker.com/
> 
> --20cf3043523476ac4c0493ffc8f5
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> Two of the biggest challenges to work around for KIDNS is the existence of =
> CNAMES and wildcards.<div><br></div><div>Both suffer from having somewhat s=
> oft semantics implementation wise. The official semantics are strict enough=
>  to get in the way but the diversity of implementations means that it is no=
> t necessarily possible to benefit from that strictness.</div>
> <div><br></div><div>DNSSEC affects wildcards in particular since DNS wildca=
> rds were originally an issue for the DNS server alone. Before DNSSEC, a ser=
> ver could synthesize any record it liked and so a wildcard of the form x.*.=
> y was completely feasible. DNSSEC only allows wildcards of the form *.y and=
>  that makes use of prefixes difficult.</div>
> <div><br></div><div>CNAMES pose a separate problem. According to the rules =
> the only things that can exist at a DNS node with a CNAME are the CNAME rec=
> ord and the signature records.</div><div><br></div><div>CNAMES do not work =
> well with prefixes. The intention of a CNAME is to say &#39;this name is eq=
> uivalent to that name&#39;. That does not work because the CNAME only appli=
> es to the node and not any prefixes. So one solution is to use a DNAME whic=
> h maps the entire tree. But that also does not work in cases where there ar=
> e names and prefixes involved.</div>
> <div><br></div><div><br></div><div>the reason we have to think about them i=
> s that naming affects trust. If we have one name aliased to another, where =
> should we be looking for the keys? If we have a service provided from multi=
> ple hosts should we look for keys at the service level or for the individua=
> l host?</div>
> <div><br></div><div><br></div><div>There are plenty of corner cases and I w=
> rote a very long private message setting these out last week, but I think i=
> t is possible to address all of them if we apply the following rules:</div>
> <div><br></div><div>1) The first lookup in a discovery chain is for an unpr=
> efixed record.</div><div><br></div><div>2) Subsequent lookups are for prefi=
> xed records and the records returned MUST be canonical (no CNAME, DNAME, ZN=
> AME...)</div>
> <div><br></div><div>Here the term &#39;discovery&#39; may be as narrow as s=
> ecurity attribute discovery or may combine service and security attribute d=
> iscovery.</div><div><br></div><div><br></div><div>The idea behind ESRV was =
> that the discovery would be a process of gradual refinement, starting with =
> security policy for the site and gradually refining down to very specific p=
> olicies for specific protocols, hosts and services.</div>
> <div><br></div><div>I think that is still the way to do it, but we need to =
> complete the process in fewer steps than are involved in ESRV.</div><div><b=
> r></div><div><br></div><div>So imagine we have two new RRs, START and DETAI=
> L. These are just for the sake of example of course. It may even be possibl=
> e to combine both RRs into one.</div>
> <div><br></div><div>The discovery process always begins with a request for =
> an unprefixed START rr, but may lead to requests for more detail.</div><div=
> ><br></div><div><br></div><div>A very simple site might be able to pack its=
>  entire policy into one record</div>
> <div><br></div><div><a href=3D"http://simple.example.com">simple.example.co=
> m</a> =A0START &quot;always use TLS, always use the cert fingerprint=3DY&qu=
> ot;</div><div><br></div><div>Such a site may have an alias, or even a wildc=
> ard record:</div>
> <div><br></div><div><a href=3D"http://alias.example.com">alias.example.com<=
> /a> CNAME <a href=3D"http://simple.example.com">simple.example.com</a></div=
> ><div>*.<a href=3D"http://wildcard.example.com">wildcard.example.com</a> CN=
> AME=A0&quot;always use TLS, always use the cert fingerprint=3DY&quot;</div>
> <meta charset=3D"utf-8"><div><br></div><div><br></div><div>A more complex s=
> ite might have different policies for different services:</div><div><br></d=
> iv><div><br></div><div><a href=3D"http://complex.example.com">complex.examp=
> le.com</a> START &quot;look for detail by protocol&quot;</div>
> <div>_http._<a href=3D"http://tcp.example.com">tcp.example.com</a> DETAIL &=
> quot;always use TLS&quot;</div><div><meta charset=3D"utf-8">_finger._<a hre=
> f=3D"http://tcp.example.com">tcp.example.com</a> DETAIL &quot;never use TLS=
>  use SRV discovery&quot;</div>
> <div><meta charset=3D"utf-8">_finger._<a href=3D"http://tcp.example.com">tc=
> p.example.com</a>=A0SRV 1 1 9000 <a href=3D"http://finger1.example.com">fin=
> ger1.example.com</a>=A0</div><div><meta charset=3D"utf-8">_finger._<a href=
> =3D"http://tcp.example.com">tcp.example.com</a>=A0SRV 1 1 9000 <a href=3D"h=
> ttp://finger1.example.com">finger1.example.com</a>=A0</div>
> <meta charset=3D"utf-8"><div><br></div><div><br></div><div>So now if we ali=
> as <a href=3D"http://alias.complex.example.com">alias.complex.example.com</=
> a> to the above, the discovery works exactly as we would like.</div><div><b=
> r>
> </div><div><meta charset=3D"utf-8"><a href=3D"http://alias.complex.example.=
> com">alias.complex.example.com</a> =A0CNAME=A0<meta charset=3D"utf-8"><a hr=
> ef=3D"http://complex.example.com">complex.example.com</a><br><br></div><div=
> >We can also do wildcards or anything else that we might want to do.</div>
> <div><br></div><div><br></div><div>If we are doing outsourcing, I would thi=
> nk that the way we would want to achieve that is by inserting one record th=
> at says &#39;do SRV discovery at the outsource provider&#39; So if we have =
> Big URL Resolution Protocol (BURP) I would think that we would want to have=
>  something like</div>
> <div><br></div><div><br></div><div><a href=3D"http://complex.example.com">c=
> omplex.example.com</a> START &quot;look for detail by protocol&quot;</div><=
> div><div>_http._<a href=3D"http://tcp.example.com">tcp.example.com</a> DETA=
> IL &quot;always use TLS&quot;</div>
> <div>_finger._<a href=3D"http://tcp.example.com">tcp.example.com</a> DETAIL=
>  &quot;never use TLS&quot;</div></div><div>_burp._<a href=3D"http://tcp.exa=
> mple.com">tcp.example.com</a> DETAIL &quot;look at <a href=3D"http://truste=
> d.outsource.ly">trusted.outsource.ly</a>&quot;</div>
> <div><br></div><div>At the outsource:</div><div><meta charset=3D"utf-8">_bu=
> rp._<a href=3D"http://tcp.trusted.outsource.ly">tcp.trusted.outsource.ly</a=
> >=A0DETAIL &quot;never use TLS&quot;</div><meta charset=3D"utf-8"><meta cha=
> rset=3D"utf-8"><div>
> <br></div><div><br></div><div>But I can well see that there would be cases =
> where you would want to have detail that applied to specific SRV hosts.=A0<=
> /div><div><br></div><div><br></div><div>Granted, this appears to require a =
> lot of round trips. But I think that this would not be the case in practice=
>  and certainly not if we also extend the DNS protocol itself to support thi=
> s scheme.</div>
> <div><br></div><div>DNS allows for additional records to be packed into eac=
> h response. So as I see it, we should only need two round trips for the gen=
> eral case where the resolution does not cross administrative zone boundarie=
> s.</div>
> <div><br></div><div>First phase: =A0Lookup A, AAAA and START RRs for unpref=
> ixed record</div><div>Second phase (if needed): Lookup =A0DETAIL, SRV recor=
> ds</div><div><br></div><div><br></div><div><br></div><div>-- <br>Website: <=
> a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
> <br>
> </div>
> 
> --20cf3043523476ac4c0493ffc8f5--
> 
> --===============1223621894==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
> 
> --===============1223621894==--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

Date: Mon, 1 Nov 2010 17:27:03 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] CNAME, wildcards, SRV and Key binding

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

On Mon, Nov 1, 2010 at 1:58 PM, Ilari Liusvaara <[email-masked]
> wrote:

> On Mon, Nov 01, 2010 at 11:51:35AM -0400, Phillip Hallam-Baker wrote:
> >
> > CNAMES pose a separate problem. According to the rules the only things
> that
> > can exist at a DNS node with a CNAME are the CNAME record and the
> signature
> > records.
> >
> > the reason we have to think about them is that naming affects trust. If
> we
> > have one name aliased to another, where should we be looking for the
> keys?
> > If we have a service provided from multiple hosts should we look for keys
> at
> > the service level or for the individual host?
>
> In my view, all DNS redirect mechanisms (SRV, CNAME, DNAME, etc...) are
> pretty much equivalent when it comes to keys.
>
> For managed services, one pretty much has to have keys on individual host
> level.

Keys at the host level yes.

But other security attributes are likely common to all hosts in the service.

> > The idea behind ESRV was that the discovery would be a process of gradual
> > refinement, starting with security policy for the site and gradually
> > refining down to very specific policies for specific protocols, hosts and
> > services.
>
> Security policy is meaningless if client has no clue how to get secure
> connection. And furthermore, I'm no fan of secuirity policy in DNS.

You certainly don't want to put your policy rules in the DNS. In fact you
probably don't want to have them in any format that is appropriate for a
network protocol.

But security attributes that provide relying parties with additional
information to help them process the security policy may be viable.

> > A very simple site might be able to pack its entire policy into one
> record
> >
> > simple.example.com  START "always use TLS, always use the cert
> > fingerprint=Y"
>
> "Always use TLS" is ill-defined. It may be almost well-defined with HTTP,
> but there are protocols where "use TLS" is just plain ill-defined.
>

The point of the example was to show the DNS discovery process rather than
the details of the security attributes.

Hence the only sites that could use 'always use TLS' at a site level would
be sites that only supported services that can be secured with TLS. such
sites certainly do exist. None of my Web sites has FTP enabled. The only
services provided are Web and Mail.

> In fact, it contains unstated assumptions (that could turn out to be
> false!) even for HTTP.
>

You would of course want to ensure that the version of TLS was sufficiently
advanced for the in-band TLS negotiation to prevent downgrade attack within
the TLS protocol itself. But I am pretty sure that holds from TLS 1.0 on and
may well apply to SSL 3.0 as well (but not 2.0!)

For most protocols, 'always offers' is the interesting one. That enables
promiscuous encryption whereby the client will always use crypto if it is
offered. At the moment only a few percent of Internet traffic is encrypted
and that means that a lot of the traffic that is encrypted is compromised by
the en-clair traffic.

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

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

<br><br><div class=3D"gmail_quote">On Mon, Nov 1, 2010 at 1:58 PM, Ilari Li=
usvaara <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 Mon, Nov 01, 2010 at 11:51:35AM -0400, Phillip Hallam-=
Baker wrote:<br>
&gt;<br>
&gt; CNAMES pose a separate problem. According to the rules the only things=
 that<br>
&gt; can exist at a DNS node with a CNAME are the CNAME record and the sign=
ature<br>
&gt; records.<br>
&gt;<br>
</div><div class=3D"im">&gt; the reason we have to think about them is that=
 naming affects trust. If we<br>
&gt; have one name aliased to another, where should we be looking for the k=
eys?<br>
&gt; If we have a service provided from multiple hosts should we look for k=
eys at<br>
&gt; the service level or for the individual host?<br>
<br>
</div>In my view, all DNS redirect mechanisms (SRV, CNAME, DNAME, etc...) a=
re<br>
pretty much equivalent when it comes to keys.<br>
<br>
For managed services, one pretty much has to have keys on individual host<b=
r>
level.</blockquote><div><br></div><div>Keys at the host level yes.</div><di=
v><br></div><div>But other security attributes are likely common to all hos=
ts in the service.</div><div><br></div><div>=A0</div><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">
&gt; The idea behind ESRV was that the discovery would be a process of grad=
ual<br>
&gt; refinement, starting with security policy for the site and gradually<b=
r>
&gt; refining down to very specific policies for specific protocols, hosts =
and<br>
&gt; services.<br>
<br>
</div>Security policy is meaningless if client has no clue how to get secur=
e<br>
connection. And furthermore, I&#39;m no fan of secuirity policy in DNS.</bl=
ockquote><div><br></div><div>You certainly don&#39;t want to put your polic=
y rules in the DNS. In fact you probably don&#39;t want to have them in any=
 format that is appropriate for a network protocol.=A0</div>
<div><br></div><div>But security attributes that provide relying parties wi=
th additional information to help them process the security policy may be v=
iable.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">
&gt; A very simple site might be able to pack its entire policy into one re=
cord<br>
&gt;<br>
&gt; <a href=3D"http://simple.example.com" target=3D"_blank">simple.example=
.com</a> =A0START &quot;always use TLS, always use the cert<br>
&gt; fingerprint=3DY&quot;<br>
<br>
</div>&quot;Always use TLS&quot; is ill-defined. It may be almost well-defi=
ned with HTTP,<br>
but there are protocols where &quot;use TLS&quot; is just plain ill-defined=
.<br></blockquote><div><br></div><div>The point of the example was to show =
the DNS discovery process rather than the details of the security attribute=
s.</div>
<div><br></div><div>Hence the only sites that could use &#39;always use TLS=
&#39; at a site level would be sites that only supported services that can =
be secured with TLS. such sites certainly do exist. None of my Web sites ha=
s FTP enabled. The only services provided are Web and Mail.</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;">
In fact, it contains unstated assumptions (that could turn out to be<br>
false!) even for HTTP.<font class=3D"Apple-style-span" color=3D"#888888"><b=
r></font></blockquote></div><br clear=3D"all">You would of course want to e=
nsure that the version of TLS was sufficiently advanced for the in-band TLS=
 negotiation to prevent downgrade attack within the TLS protocol itself. Bu=
t I am pretty sure that holds from TLS 1.0 on and may well apply to SSL 3.0=
 as well (but not 2.0!)<br>
<div><br></div><div>For most protocols, &#39;always offers&#39; is the inte=
resting one. That enables promiscuous encryption whereby the client will al=
ways use crypto if it is offered. At the moment only a few percent of Inter=
net traffic is encrypted and that means that a lot of the traffic that is e=
ncrypted is compromised by the en-clair traffic.</div>
<div><br>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallamb=
aker.com/</a><br><br>
</div>

--20cf303dd82c26dc5d049404783e--

Date: Mon, 1 Nov 2010 19:58:21 +0200
From: Ilari Liusvaara <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] CNAME, wildcards, SRV and Key binding

On Mon, Nov 01, 2010 at 11:51:35AM -0400, Phillip Hallam-Baker wrote:
> 
> CNAMES pose a separate problem. According to the rules the only things that
> can exist at a DNS node with a CNAME are the CNAME record and the signature
> records.
> 
> the reason we have to think about them is that naming affects trust. If we
> have one name aliased to another, where should we be looking for the keys?
> If we have a service provided from multiple hosts should we look for keys at
> the service level or for the individual host?

In my view, all DNS redirect mechanisms (SRV, CNAME, DNAME, etc...) are
pretty much equivalent when it comes to keys.

For managed services, one pretty much has to have keys on individual host
level. 

> The idea behind ESRV was that the discovery would be a process of gradual
> refinement, starting with security policy for the site and gradually
> refining down to very specific policies for specific protocols, hosts and
> services.

Security policy is meaningless if client has no clue how to get secure
connection. And furthermore, I'm no fan of secuirity policy in DNS.

> A very simple site might be able to pack its entire policy into one record
> 
> simple.example.com  START "always use TLS, always use the cert
> fingerprint=Y"

"Always use TLS" is ill-defined. It may be almost well-defined with HTTP,
but there are protocols where "use TLS" is just plain ill-defined.

In fact, it contains unstated assumptions (that could turn out to be
false!) even for HTTP.

-Ilari

Date: Mon, 1 Nov 2010 11:51:35 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Subject: [keyassure] CNAME, wildcards, SRV and Key binding

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

Two of the biggest challenges to work around for KIDNS is the existence of
CNAMES and wildcards.

Both suffer from having somewhat soft semantics implementation wise. The
official semantics are strict enough to get in the way but the diversity of
implementations means that it is not necessarily possible to benefit from
that strictness.

DNSSEC affects wildcards in particular since DNS wildcards were originally
an issue for the DNS server alone. Before DNSSEC, a server could synthesize
any record it liked and so a wildcard of the form x.*.y was completely
feasible. DNSSEC only allows wildcards of the form *.y and that makes use of
prefixes difficult.

CNAMES pose a separate problem. According to the rules the only things that
can exist at a DNS node with a CNAME are the CNAME record and the signature
records.

CNAMES do not work well with prefixes. The intention of a CNAME is to say
'this name is equivalent to that name'. That does not work because the CNAME
only applies to the node and not any prefixes. So one solution is to use a
DNAME which maps the entire tree. But that also does not work in cases where
there are names and prefixes involved.

the reason we have to think about them is that naming affects trust. If we
have one name aliased to another, where should we be looking for the keys?
If we have a service provided from multiple hosts should we look for keys at
the service level or for the individual host?

There are plenty of corner cases and I wrote a very long private message
setting these out last week, but I think it is possible to address all of
them if we apply the following rules:

1) The first lookup in a discovery chain is for an unprefixed record.

2) Subsequent lookups are for prefixed records and the records returned MUST
be canonical (no CNAME, DNAME, ZNAME...)

Here the term 'discovery' may be as narrow as security attribute discovery
or may combine service and security attribute discovery.

The idea behind ESRV was that the discovery would be a process of gradual
refinement, starting with security policy for the site and gradually
refining down to very specific policies for specific protocols, hosts and
services.

I think that is still the way to do it, but we need to complete the process
in fewer steps than are involved in ESRV.

So imagine we have two new RRs, START and DETAIL. These are just for the
sake of example of course. It may even be possible to combine both RRs into
one.

The discovery process always begins with a request for an unprefixed START
rr, but may lead to requests for more detail.

A very simple site might be able to pack its entire policy into one record

simple.example.com  START "always use TLS, always use the cert
fingerprint=Y"

Such a site may have an alias, or even a wildcard record:

alias.example.com CNAME simple.example.com
*.wildcard.example.com CNAME "always use TLS, always use the cert
fingerprint=Y"

A more complex site might have different policies for different services:

complex.example.com START "look for detail by protocol"
_http._tcp.example.com DETAIL "always use TLS"
_finger._tcp.example.com DETAIL "never use TLS use SRV discovery"
_finger._tcp.example.com SRV 1 1 9000 finger1.example.com
_finger._tcp.example.com SRV 1 1 9000 finger1.example.com

So now if we alias alias.complex.example.com to the above, the discovery
works exactly as we would like.

alias.complex.example.com  CNAME complex.example.com

We can also do wildcards or anything else that we might want to do.

If we are doing outsourcing, I would think that the way we would want to
achieve that is by inserting one record that says 'do SRV discovery at the
outsource provider' So if we have Big URL Resolution Protocol (BURP) I would
think that we would want to have something like

complex.example.com START "look for detail by protocol"
_http._tcp.example.com DETAIL "always use TLS"
_finger._tcp.example.com DETAIL "never use TLS"
_burp._tcp.example.com DETAIL "look at trusted.outsource.ly"

At the outsource:
_burp._tcp.trusted.outsource.ly DETAIL "never use TLS"

But I can well see that there would be cases where you would want to have
detail that applied to specific SRV hosts.

Granted, this appears to require a lot of round trips. But I think that this
would not be the case in practice and certainly not if we also extend the
DNS protocol itself to support this scheme.

DNS allows for additional records to be packed into each response. So as I
see it, we should only need two round trips for the general case where the
resolution does not cross administrative zone boundaries.

First phase:  Lookup A, AAAA and START RRs for unprefixed record
Second phase (if needed): Lookup  DETAIL, SRV records

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

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

Two of the biggest challenges to work around for KIDNS is the existence of =
CNAMES and wildcards.<div><br></div><div>Both suffer from having somewhat s=
oft semantics implementation wise. The official semantics are strict enough=
 to get in the way but the diversity of implementations means that it is no=
t necessarily possible to benefit from that strictness.</div>
<div><br></div><div>DNSSEC affects wildcards in particular since DNS wildca=
rds were originally an issue for the DNS server alone. Before DNSSEC, a ser=
ver could synthesize any record it liked and so a wildcard of the form x.*.=
y was completely feasible. DNSSEC only allows wildcards of the form *.y and=
 that makes use of prefixes difficult.</div>
<div><br></div><div>CNAMES pose a separate problem. According to the rules =
the only things that can exist at a DNS node with a CNAME are the CNAME rec=
ord and the signature records.</div><div><br></div><div>CNAMES do not work =
well with prefixes. The intention of a CNAME is to say &#39;this name is eq=
uivalent to that name&#39;. That does not work because the CNAME only appli=
es to the node and not any prefixes. So one solution is to use a DNAME whic=
h maps the entire tree. But that also does not work in cases where there ar=
e names and prefixes involved.</div>
<div><br></div><div><br></div><div>the reason we have to think about them i=
s that naming affects trust. If we have one name aliased to another, where =
should we be looking for the keys? If we have a service provided from multi=
ple hosts should we look for keys at the service level or for the individua=
l host?</div>
<div><br></div><div><br></div><div>There are plenty of corner cases and I w=
rote a very long private message setting these out last week, but I think i=
t is possible to address all of them if we apply the following rules:</div>
<div><br></div><div>1) The first lookup in a discovery chain is for an unpr=
efixed record.</div><div><br></div><div>2) Subsequent lookups are for prefi=
xed records and the records returned MUST be canonical (no CNAME, DNAME, ZN=
AME...)</div>
<div><br></div><div>Here the term &#39;discovery&#39; may be as narrow as s=
ecurity attribute discovery or may combine service and security attribute d=
iscovery.</div><div><br></div><div><br></div><div>The idea behind ESRV was =
that the discovery would be a process of gradual refinement, starting with =
security policy for the site and gradually refining down to very specific p=
olicies for specific protocols, hosts and services.</div>
<div><br></div><div>I think that is still the way to do it, but we need to =
complete the process in fewer steps than are involved in ESRV.</div><div><b=
r></div><div><br></div><div>So imagine we have two new RRs, START and DETAI=
L. These are just for the sake of example of course. It may even be possibl=
e to combine both RRs into one.</div>
<div><br></div><div>The discovery process always begins with a request for =
an unprefixed START rr, but may lead to requests for more detail.</div><div=
><br></div><div><br></div><div>A very simple site might be able to pack its=
 entire policy into one record</div>
<div><br></div><div><a href=3D"http://simple.example.com">simple.example.co=
m</a> =A0START &quot;always use TLS, always use the cert fingerprint=3DY&qu=
ot;</div><div><br></div><div>Such a site may have an alias, or even a wildc=
ard record:</div>
<div><br></div><div><a href=3D"http://alias.example.com">alias.example.com<=
/a> CNAME <a href=3D"http://simple.example.com">simple.example.com</a></div=
><div>*.<a href=3D"http://wildcard.example.com">wildcard.example.com</a> CN=
AME=A0&quot;always use TLS, always use the cert fingerprint=3DY&quot;</div>
<meta charset=3D"utf-8"><div><br></div><div><br></div><div>A more complex s=
ite might have different policies for different services:</div><div><br></d=
iv><div><br></div><div><a href=3D"http://complex.example.com">complex.examp=
le.com</a> START &quot;look for detail by protocol&quot;</div>
<div>_http._<a href=3D"http://tcp.example.com">tcp.example.com</a> DETAIL &=
quot;always use TLS&quot;</div><div><meta charset=3D"utf-8">_finger._<a hre=
f=3D"http://tcp.example.com">tcp.example.com</a> DETAIL &quot;never use TLS=
 use SRV discovery&quot;</div>
<div><meta charset=3D"utf-8">_finger._<a href=3D"http://tcp.example.com">tc=
p.example.com</a>=A0SRV 1 1 9000 <a href=3D"http://finger1.example.com">fin=
ger1.example.com</a>=A0</div><div><meta charset=3D"utf-8">_finger._<a href=
=3D"http://tcp.example.com">tcp.example.com</a>=A0SRV 1 1 9000 <a href=3D"h=
ttp://finger1.example.com">finger1.example.com</a>=A0</div>
<meta charset=3D"utf-8"><div><br></div><div><br></div><div>So now if we ali=
as <a href=3D"http://alias.complex.example.com">alias.complex.example.com</=
a> to the above, the discovery works exactly as we would like.</div><div><b=
r>
</div><div><meta charset=3D"utf-8"><a href=3D"http://alias.complex.example.=
com">alias.complex.example.com</a> =A0CNAME=A0<meta charset=3D"utf-8"><a hr=
ef=3D"http://complex.example.com">complex.example.com</a><br><br></div><div=
>We can also do wildcards or anything else that we might want to do.</div>
<div><br></div><div><br></div><div>If we are doing outsourcing, I would thi=
nk that the way we would want to achieve that is by inserting one record th=
at says &#39;do SRV discovery at the outsource provider&#39; So if we have =
Big URL Resolution Protocol (BURP) I would think that we would want to have=
 something like</div>
<div><br></div><div><br></div><div><a href=3D"http://complex.example.com">c=
omplex.example.com</a> START &quot;look for detail by protocol&quot;</div><=
div><div>_http._<a href=3D"http://tcp.example.com">tcp.example.com</a> DETA=
IL &quot;always use TLS&quot;</div>
<div>_finger._<a href=3D"http://tcp.example.com">tcp.example.com</a> DETAIL=
 &quot;never use TLS&quot;</div></div><div>_burp._<a href=3D"http://tcp.exa=
mple.com">tcp.example.com</a> DETAIL &quot;look at <a href=3D"http://truste=
d.outsource.ly">trusted.outsource.ly</a>&quot;</div>
<div><br></div><div>At the outsource:</div><div><meta charset=3D"utf-8">_bu=
rp._<a href=3D"http://tcp.trusted.outsource.ly">tcp.trusted.outsource.ly</a=
>=A0DETAIL &quot;never use TLS&quot;</div><meta charset=3D"utf-8"><meta cha=
rset=3D"utf-8"><div>
<br></div><div><br></div><div>But I can well see that there would be cases =
where you would want to have detail that applied to specific SRV hosts.=A0<=
/div><div><br></div><div><br></div><div>Granted, this appears to require a =
lot of round trips. But I think that this would not be the case in practice=
 and certainly not if we also extend the DNS protocol itself to support thi=
s scheme.</div>
<div><br></div><div>DNS allows for additional records to be packed into eac=
h response. So as I see it, we should only need two round trips for the gen=
eral case where the resolution does not cross administrative zone boundarie=
s.</div>
<div><br></div><div>First phase: =A0Lookup A, AAAA and START RRs for unpref=
ixed record</div><div>Second phase (if needed): Lookup =A0DETAIL, SRV recor=
ds</div><div><br></div><div><br></div><div><br></div><div>-- <br>Website: <=
a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
<br>
</div>

--20cf3043523476ac4c0493ffc8f5--

From: Phillip Hallam-Baker <[email-masked]>
To: Jakob Schlyter <[email-masked]>
Date: Mon, 1 Nov 2010 09:46:07 -0400
Cc: Steve Schultze <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

+1

There are several use cases here. I think they are all manageable but we =
need more than just a single flag.

Performance matters here. But we should not allow performance to drive =
requirements. If we can get all the requirements on the table =
(performance included) we can then see who can propose the best trade =
off that gets most support.

Remember that in the context of a complete transaction a better =
discovery mechanism that allows the client to select the nearest service =
may be better overall than one that minimizes dns round trips. Also =
there is scope for optimizing the DNS protocol itself.

For example, we could use EDNS to advertise support for a 'megaquery' =
which would be a new query format that contains separate slots for the =
protocol, name, try number. If we have a common discovery architecture =
defined the resolver can then ferret out all the data required and =
deliver it on a plate.

A secondary advantage of this approach is that the DNS resolver can =
optimize its cache strategy for protocols where interactive response is =
most important.

Sent from my iPad

On Nov 1, 2010, at 6:14 AM, Jakob Schlyter <[email-masked]> wrote:

> On 31 okt 2010, at 05.51, James Cloos wrote:
>=20
>> 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?)
>=20
> Publishing the key/hash material at the same name as the SRV doesn't =
work that well with managed services, e.g. if I use Google Apps for my =
jabber services, storing the keys at _jabber._tcp.kirei.se will not =
help, as I do not manage the keys - Google does. In this case, the key =
material that will be used is better stored at the SRV destination =
(e.g., xmpp-server.l.google.com.). I believe this is discussed further =
in draft-saintandre-tls-server-id-check. Given this, IMHO, the key =
material for my mail server should be stored at the MX destination =
mail.kirei.se - not kirei.se nor _smtp._tcp.kirei.se.
>=20
> 	jakob
>=20
> --=20
> Jakob Schlyter
> Kirei AB - http://www.kirei.se/
>=20
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Jakob Schlyter <[email-masked]>
Date: Mon, 1 Nov 2010 11:14:09 +0100
To: James Cloos <[email-masked]>
Cc: [email-masked], Steve Schultze <[email-masked]>
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On 31 okt 2010, at 05.51, James Cloos wrote:

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

Publishing the key/hash material at the same name as the SRV doesn't =
work that well with managed services, e.g. if I use Google Apps for my =
jabber services, storing the keys at _jabber._tcp.kirei.se will not =
help, as I do not manage the keys - Google does. In this case, the key =
material that will be used is better stored at the SRV destination =
(e.g., xmpp-server.l.google.com.). I believe this is discussed further =
in draft-saintandre-tls-server-id-check. Given this, IMHO, the key =
material for my mail server should be stored at the MX destination =
mail.kirei.se - not kirei.se nor _smtp._tcp.kirei.se.

	jakob

--=20
Jakob Schlyter
Kirei AB - http://www.kirei.se/

Date: Mon, 01 Nov 2010 08:46:06 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] DRAFT Agenda for KIDNS BOF.

Hi,

here's the updated agenda.

THURSDAY, November 11, 2010
1520-1720 Afternoon Session II
Garden Ballroom 1
=====================================================

CHAIR(s):  Warren Kumari <[email-masked]>
            Ondrej Sury   <[email-masked]>

o Administrivia                                        15 minutes
   Chairs

   - Note Well
   - Scribe
   - Blue Sheets
   - Document Status

o Working group goals and agenda, charter, etc.
   Ondrej Sury					       30 minutes

o Some of the Early KIDNS Proposals                    45 minutes
   Paul Hoffman (presenting) & Jakob Schlyter

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,
   charter poking, etc.

On 28.10.2010 01:29, Warren Kumari wrote:
> 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
> =====================================================
>
> CHAIR(s):  Warren Kumari<[email-masked]>
>             Ondrej Sury<[email-masked]>
>
> o Administrivia                                        15 minutes
>    Chairs
>
>    - Note Well
>    - Scribe
>    - Blue Sheets
>    - Document Status
>
> o Working group goals and agenda, charter, etc.
>    Ondrej Sury					       30 minutes
>
> 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,
>    charter poking, etc.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

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