Subject: Re: [keyassure] SSHFP (is there a work to do) vs. Securing Last Mile
From: Phillip Hallam-Baker <[email-masked]>
To: Nicholas Weaver <[email-masked]>
Cc: [email-masked]
Date: Mon, 30 Aug 2010 18:25:51 -0400
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>

DNSSEC is an internet security scheme not an intranet security scheme.
There is a big difference in the approaches and the constraints that
are relevant.

The objective of DNSSEC is to secure the DNS protocol. As an
enterprise I could not give a hoot for the security of the DNS
protocol unless it negatively impacts my actual security objectives.
In particular DNSSEC is designed to ensure that a client has a
faithful copy of the authoritative DNS, I don't want my machines to
connect to the authoritative DNS and to connect to every Internet site
any more than I would want them to run every program run by every
random bozo I never met.

In short, enterprise security is not the same as what individuals
chose to run for themselves.

What is taken to be a demand for 'security' is more often a regulatory
requirement for compliance. And it is instructive to see how very
subtle changes in a system can create massive compliance issues.

So for example, I move from using SSH with bilateral keys to SSH with
keys stored and distributed via the DNS. It is really easy to show
that this offers the same theoretical degree of control if the
applications are using a trust root that I control or I have a direct
contractual agreement with. What do I tell the auditor if I am
trusting a root I don't control and nor does the party being
authenticated?

It shows up fairly starkly in SSH because we are moving from an
environment with direct key management with an organized hierarchy. It
is much harder to spot this situation where we are talking about
moving from 99% of traffic having no security to having better than
nothing security.

On Mon, Aug 30, 2010 at 2:58 PM, Nicholas Weaver
<[email-masked]> wrote:
>
> On Aug 30, 2010, at 1:57 AM, Ondřej Surý wrote:
>> Bigger:
>> 3) Secure Last Mile: I think it was already stated here (or on other place) that simply trusting AD bit is not sufficient, and there is a strong need for securing last mile.  Could it be a validating resolver on localhost (but it's not secure on multi-user machine).  Could it be IPSec (but this is probably valid only in strictly controlled environment).  Could be SIG(0) to your resolver?
>
> Actually, the resolver on localhost is secure on a multi-user machine, in the sense that any adversary who could corrupt that resolver could corrupt other parts of the victim.
>
> IPSec or others to a "trusted" secondary resolver is, IMO, silly:  DNSSEC is all about not needing to trust the infrastructure, so why change the DNS client model to one that establishes a 'secure' connection to a 'trusted' resolver instead of just having the client validate the information directly and, if it can't validate the information, fetches it for itself if you don't trust the external resolver?
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Mon, 30 Aug 2010 17:23:49 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Trust models (was: Securing Last Mile)
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Paul H., and all,

  Yes, nicely stated.

-----Original Message-----
>From: Paul Hoffman <[email-masked]>
>Sent: Aug 30, 2010 5:14 PM
>To: [email-masked]
>Subject: [keyassure] Trust models (was: Securing Last Mile)
>
>At 11:58 AM -0700 8/30/10, Nicholas Weaver wrote:
>>On Aug 30, 2010, at 1:57 AM, OndÞej Sur wrote:
>>> Bigger:
>>> 3) Secure Last Mile: I think it was already stated here (or on other place) that simply trusting AD bit is not sufficient, and there is a strong need for securing last mile.  Could it be a validating resolver on localhost (but it's not secure on multi-user machine).  Could it be IPSec (but this is probably valid only in strictly controlled environment).  Could be SIG(0) to your resolver?
>>
>>Actually, the resolver on localhost is secure on a multi-user machine, in the sense that any adversary who could corrupt that resolver could corrupt other parts of the victim.
>>
>>IPSec or others to a "trusted" secondary resolver is, IMO, silly:  DNSSEC is all about not needing to trust the infrastructure, so why change the DNS client model to one that establishes a 'secure' connection to a 'trusted' resolver instead of just having the client validate the information directly and, if it can't validate the information, fetches it for itself if you don't trust the external resolver?
>
>This exposes something that people in the security community constantly grapple with / trip over: who is the trust anchor? In the "localhost" scenario above, it is the DNSSEC root or whichever lower DNSSEC trust anchors you have manually installed. In the "IPsec or others" scenario, it is a trusted third party who is doing resolution for you, such as "your ISP" or "your corporation".
>
>Those are radically different models that are desired by different types of people with different needs. You can't say one is more important than the other because you are making a value judgement for people with whom you disagree.
>
>The "localhost" solution is defined today. The "IPsec or others" is too, but in a zillion different ways. If there is interest in making the latter more focused, that's great, but such work is for the DNSEXT WG, not here.
>
>--Paul Hoffman, Director
>--VPN Consortium
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

Date: Mon, 30 Aug 2010 15:14:02 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: [keyassure] Trust models (was: Securing Last Mile)

At 11:58 AM -0700 8/30/10, Nicholas Weaver wrote:
>On Aug 30, 2010, at 1:57 AM, Ond�ej Sur� wrote:
>> Bigger:
>> 3) Secure Last Mile: I think it was already stated here (or on other place) that simply trusting AD bit is not sufficient, and there is a strong need for securing last mile.  Could it be a validating resolver on localhost (but it's not secure on multi-user machine).  Could it be IPSec (but this is probably valid only in strictly controlled environment).  Could be SIG(0) to your resolver?
>
>Actually, the resolver on localhost is secure on a multi-user machine, in the sense that any adversary who could corrupt that resolver could corrupt other parts of the victim.
>
>IPSec or others to a "trusted" secondary resolver is, IMO, silly:  DNSSEC is all about not needing to trust the infrastructure, so why change the DNS client model to one that establishes a 'secure' connection to a 'trusted' resolver instead of just having the client validate the information directly and, if it can't validate the information, fetches it for itself if you don't trust the external resolver?

This exposes something that people in the security community constantly grapple with / trip over: who is the trust anchor? In the "localhost" scenario above, it is the DNSSEC root or whichever lower DNSSEC trust anchors you have manually installed. In the "IPsec or others" scenario, it is a trusted third party who is doing resolution for you, such as "your ISP" or "your corporation".

Those are radically different models that are desired by different types of people with different needs. You can't say one is more important than the other because you are making a value judgement for people with whom you disagree.

The "localhost" solution is defined today. The "IPsec or others" is too, but in a zillion different ways. If there is interest in making the latter more focused, that's great, but such work is for the DNSEXT WG, not here.

--Paul Hoffman, Director
--VPN Consortium

Date: Mon, 30 Aug 2010 21:55:41 +0000
From: [email-masked]
To: [email-masked]
Subject: [keyassure] rapid conclusion or pandoras box

a quick review of the recent thread on SSHFP led me to go look at the repository, here:

http://www.iana.org/assignments/dns-parameters

and there seem to be a number of potentially applicable RR types.  I've extracted the
following list:

SIG          24 for security signature                      [RFC4034][RFC3755][RFC2535]
KEY          25 for security key                            [RFC4034][RFC3755][RFC2535]
GPOS         27 Geographical Position                       [RFC1712]
LOC          29 Location Information                        [RFC1876]
EID          31 Endpoint Identifier                         [Patton]
NIMLOC       32 Nimrod Locator                              [Patton]
KX           36 Key Exchanger                               [RFC2230]
CERT         37 CERT                                        [RFC4398]
DS           43 Delegation Signer                           [RFC4034][RFC3658]
SSHFP        44 SSH Key Fingerprint                         [RFC4255]
IPSECKEY     45 IPSECKEY                                    [RFC4025]
DNSKEY       48 DNSKEY                                      [RFC4034][RFC3755]
NSEC3PARAM   51 NSEC3PARAM                                  [RFC5155]
HIP          55 Host Identity Protocol                      [RFC5205]
RKEY         57 RKEY                                        [Reid]
TALINK       58 Trust Anchor LINK                           [Wijngaards]

at one point or another, all of these either have delt with certs/naked keys.

so how specific is this work going to be?  just SSHFP <-> openssh or as DRC seems to
suggest, are more careful review of an API method?

--bill

From: David Conrad <[email-masked]>
Date: Mon, 30 Aug 2010 12:35:50 -0700
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] SSHFP (is there a work to do) vs. Securing Last Mile

On Aug 30, 2010, at 11:52 AM, Warren Kumari wrote:
>> There's TSIG too.
> No, no there isn't. Here is where I go into my standard rant about the fact that standard stub resolvers don't support either of these

Implementation detail (half :-)). I'm sure the fine folks at ISC and/or NLNetLabs would be more than happy to implement the appropriate hacks to resolv.conf and stub resolvers if you wave money at them.  I suspect the reason TSIG/SIG(0) protected channel between validating resolvers and stub resolvers hasn't been implemented to date is (a) no point given DNSSEC hadn't been deployed, (b) IPSec does the same thing and already exists and/or (c) running a local validating resolver is easier.

Regards,
-drc

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Mon, 30 Aug 2010 11:58:41 -0700
To: =?utf-8?Q?Ondřej_Surý?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] SSHFP (is there a work to do) vs. Securing Last Mile

On Aug 30, 2010, at 1:57 AM, Ondřej Surý wrote:
> Bigger:
> 3) Secure Last Mile: I think it was already stated here (or on other place) that simply trusting AD bit is not sufficient, and there is a strong need for securing last mile.  Could it be a validating resolver on localhost (but it's not secure on multi-user machine).  Could it be IPSec (but this is probably valid only in strictly controlled environment).  Could be SIG(0) to your resolver?

Actually, the resolver on localhost is secure on a multi-user machine, in the sense that any adversary who could corrupt that resolver could corrupt other parts of the victim.

IPSec or others to a "trusted" secondary resolver is, IMO, silly:  DNSSEC is all about not needing to trust the infrastructure, so why change the DNS client model to one that establishes a 'secure' connection to a 'trusted' resolver instead of just having the client validate the information directly and, if it can't validate the information, fetches it for itself if you don't trust the external resolver?

From: Warren Kumari <[email-masked]>
To: David Conrad <[email-masked]>
Date: Mon, 30 Aug 2010 14:52:46 -0400
Cc: [email-masked]
Subject: Re: [keyassure] SSHFP (is there a work to do) vs. Securing Last Mile

On Aug 30, 2010, at 2:44 PM, David Conrad wrote:

> On Aug 30, 2010, at 1:57 AM, Ondřej Surý wrote:
>> 3) Secure Last Mile: I think it was already stated here (or on  
>> other place) that simply trusting AD bit is not sufficient, and  
>> there is a strong need for securing last mile.  Could it be a  
>> validating resolver on localhost (but it's not secure on multi-user  
>> machine).
>
> I'd imagine that if you can't trust your resolver on your local  
> machine (multi-user or not), you have bigger problems than the risks  
> associated with DNS response corruption.
>
>> Could it be IPSec (but this is probably valid only in strictly  
>> controlled environment).  Could be SIG(0) to your resolver?
>
> There's TSIG too.

No, no there isn't. Here is where I go into my standard rant about the  
fact that standard stub resolvers don't support either of these:
Standard stub resolvers don't support SIG(0) / TSIG. Every time I want  
to do this, someone says "Yeah, it's super easy, you setup the server  
like <blargh> then, on the client, you edit /etc/resolv.conf and  
enter.... erm.... weeeeellll.... gimma a sec... bugger..."
Sorry, but yes, I *do* feel better now....

W

> Basically, it is any way you can establish a secure channel to the  
> trusted resolver.  Since establishing a secure channel over the  
> Internet is generally harder than doing so on the local machine,  
> I've argued that the right place for a validating resolver is on the  
> local host (and you also have a better chance of getting access to  
> logs to figure out why stuff fails when those logs are on the local  
> machine).
>
>> Hence I don't think that there is a much work to do for SSH since  
>> the work there is finished (maybe couple of BCP with  
>> recommendations how to use it),
>
> I'd agree.
>
>> but there is a big piece of work on securing the last mile, which  
>> will probably need a changed APIs in the system libraries in the  
>> long run, and application stub resolvers in the short run.
>
> Personally, I've felt pretty much all of the current APIs are  
> fundamentally broken, e.g., encouraging folks to make assumptions  
> like data associated with names never change (or IP addresses  
> associated with end points never change or IP addresses have  
> particular structure, etc.) for the lifetime of the application. We  
> could probably come up with some hacks to bandaid over the sucking  
> chest wound that is the current API model, but it is a big swamp to  
> drain and I suspect doing it right would be a bit beyond the scope  
> of the potential working group being discussed here.
>
> Regards,
> -drc
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Credo quia absurdum est.

From: David Conrad <[email-masked]>
Date: Mon, 30 Aug 2010 11:44:15 -0700
To: =?utf-8?Q?Ondřej_Surý?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] SSHFP (is there a work to do) vs. Securing Last Mile

On Aug 30, 2010, at 1:57 AM, Ondřej Surý wrote:
> 3) Secure Last Mile: I think it was already stated here (or on other place) that simply trusting AD bit is not sufficient, and there is a strong need for securing last mile.  Could it be a validating resolver on localhost (but it's not secure on multi-user machine).  

I'd imagine that if you can't trust your resolver on your local machine (multi-user or not), you have bigger problems than the risks associated with DNS response corruption.

> Could it be IPSec (but this is probably valid only in strictly controlled environment).  Could be SIG(0) to your resolver?

There's TSIG too. Basically, it is any way you can establish a secure channel to the trusted resolver.  Since establishing a secure channel over the Internet is generally harder than doing so on the local machine, I've argued that the right place for a validating resolver is on the local host (and you also have a better chance of getting access to logs to figure out why stuff fails when those logs are on the local machine). 

> Hence I don't think that there is a much work to do for SSH since the work there is finished (maybe couple of BCP with recommendations how to use it),

I'd agree.

> but there is a big piece of work on securing the last mile, which will probably need a changed APIs in the system libraries in the long run, and application stub resolvers in the short run.

Personally, I've felt pretty much all of the current APIs are fundamentally broken, e.g., encouraging folks to make assumptions like data associated with names never change (or IP addresses associated with end points never change or IP addresses have particular structure, etc.) for the lifetime of the application. We could probably come up with some hacks to bandaid over the sucking chest wound that is the current API model, but it is a big swamp to drain and I suspect doing it right would be a bit beyond the scope of the potential working group being discussed here.

Regards,
-drc

Date: Mon, 30 Aug 2010 10:57:25 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: [keyassure] SSHFP (is there a work to do) vs. Securing Last Mile

Hi,

I was convinced by Phillip that the charter should be as open-minded as 
possible, even though the original idea was to include just TLS.  Anyway
I would like to ask you, if you think about adding SSH(FP) to our 
charter to do a little homework and try using SSHFP with OpenSSH and 
then write down what's missing from SSHFP.  Ie. what will the future 
work of this group look like on that field.

I have used SSHFP in the past and there are two minor and one bigger 
problem:

Minor:

1) openssh server: the setup - you need to run sshfp utility and put the 
result into the DNS -> some kind of help from OpenSSH would be great - 
at least print the SSHFP records by default

2) openssh client: you have to enable SSHFP validation by hand, because 
default value of VerifyHostKeyDNS is "no".

Bigger:
3) Secure Last Mile: I think it was already stated here (or on other 
place) that simply trusting AD bit is not sufficient, and there is a 
strong need for securing last mile.  Could it be a validating resolver 
on localhost (but it's not secure on multi-user machine).  Could it be 
IPSec (but this is probably valid only in strictly controlled 
environment).  Could be SIG(0) to your resolver?

Hence I don't think that there is a much work to do for SSH since the 
work there is finished (maybe couple of BCP with recommendations how to 
use it), but there is a big piece of work on securing the last mile, 
which will probably need a changed APIs in the system libraries in the 
long run, and application stub resolvers in the short run.

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: Sun, 29 Aug 2010 13:30:54 -0700
From: Douglas Otis <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

  On 8/27/10 7:25 AM, Andrew Sullivan wrote:
> On Thu, Aug 26, 2010 at 03:43:16PM -0700, Douglas Otis wrote:
>> For cases where clients do not exchange domain names, reverse DNS could
>> be utilized to authenticate clients.
> Except, of course, that you can't really rely on the reverse tree
> being managed.
This was not expressing any optimism for reverse DNS, especially with 
IPv6. Nor for that matter, that IPv6 addresses offer suitable 
identifiers for clients either.  However, a transition toward the use of 
domains can avoid some of the complexities imposed by an IPv6 
environment.  Providing conventions that enable opportunistic use of 
reverse DNS with IPv4 addresses might help to accelerate this transition.

-Doug

Date: Fri, 27 Aug 2010 17:54:04 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] two vs multi

At 5:34 PM +0000 8/27/10, [email-masked] wrote:
>One presumes that (a) validating the DNS delegation chain, and then finding at
>the end of that validation, (b) a crypto-bundle of goodness is the functional
>equivalent of what is known as "two-factor" authentication.
>
>
>So if One validates (a) the forward delegation chain, (b) the 
>reverse delegation
>chain, and finds (c) the _same_ crypto-bundle of goodness at the end of each
>validation chain, would this be the functional equivalent of "Multi-factor"
>authentication?

not based on the common uses of this term. Usually multi-factor 
implies use of different technologies to authenticate (a person), not 
multiple uses of the same technology managed by different entities.

Steve

Date: Fri, 27 Aug 2010 15:32:05 -0700
From: =JeffH <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki

 > I think there's still legitimate debate over whether certs or keys are
 > ideal, and at this stage I'd rather leave it open-ended.

+1 (at least ;)

=JeffH

From: "Richard L. Barnes" <[email-masked]>
To: Warren Kumari <[email-masked]>
Date: Fri, 27 Aug 2010 18:13:29 -0400
Cc: Stephen Schultze <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki

+3.25

On Aug 27, 2010, at 4:08 PM, Warren Kumari wrote:

>
> On Aug 27, 2010, at 3:49 PM, Stephen Schultze wrote:
>
>> I think there's still legitimate debate over whether certs or keys  
>> are ideal, and at this stage I'd rather leave it open-ended.
>>
>
>
> +11 3/4
>
> W
>
>> On Aug 27, 2010, at 2:11 PM, Simon Josefsson wrote:
>>> For example, I propose that we qualify the "cryptographic  
>>> material" to
>>> be authenticated to be PKIX certificates and OpenPGP keys.  Are  
>>> there
>>> other formats that are an active use?  There is SPKI, but we need  
>>> some
>>> SPKI experts to participate in the discussion to make sure we end up
>>> with something useful.  SSH keys have been discussed.  I volunteer  
>>> to
>>> review OpenPGP related parts, I'm less concerned about getting good
>>> enough review on the PKIX part.
>>
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>
> -- 
> American Non-Sequitur Society;
> we don't make sense, but we do like pizza!
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Fri, 27 Aug 2010 16:16:21 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Phillip and all,

-----Original Message-----
>From: Phillip Hallam-Baker <[email-masked]>
>Sent: Aug 27, 2010 2:37 PM
>To: "Jeffrey A. Williams" <[email-masked]>
>Cc: Simon Josefsson <[email-masked]>, Ondřej Surý <[email-masked]>, [email-masked]
>Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki
>
>The approach that leads to fewest arguments is usually to write a
>charter that is agnostic on the issue of format in the text but only
>commits to produce a deliverable for the specific formats that are
>necessary to make it work.

  Yes of course.
>
>If anyone wants to propose a spec for additional formats, they can,
>but only if they can show that there are sufficient people to do the
>work and sufficient people in the target community to vet the work.

Problem here is in the vetting.  Out of the box thinking and than
product result may not have the necessary folks in the target
community to do a proper vetting, at least not early on.
>
>
>So for example in KEYPROV we started with an assumption that we were
>going to write a protocol in XML only. But the charter was agnostic on
>that issue and we later had a proposal to shadow the XML spec with an
>ASN.1 spec which is a perfectly justifiable approach. The fact that
>the draft in question is written by the IETF chair and one of the
>Security ADs is (mostly) besides the point.

  Good example point.
>
>
>2010/8/27 Jeffrey A. Williams <[email-masked]>:
>> Simon and all,
>>
>>  For a start on SPKI, one might want to review
>> the information at http://datatracker.ietf.org/doc/search/
>> Currently there is no IETF WG for SPKI.
>>
>>
>> -----Original Message-----
>>>From: Simon Josefsson <[email-masked]>
>>>Sent: Aug 27, 2010 1:11 PM
>>>To: Ondřej Surý <[email-masked]>
>>>Cc: [email-masked]
>>>Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki
>>>
>>>Thanks Ondřej, it looks like a good starting point.  I believe we need
>>>to qualify it with references to existing work and technologies though.
>>>
>>>For example, I propose that we qualify the "cryptographic material" to
>>>be authenticated to be PKIX certificates and OpenPGP keys.  Are there
>>>other formats that are an active use?  There is SPKI, but we need some
>>>SPKI experts to participate in the discussion to make sure we end up
>>>with something useful.  SSH keys have been discussed.  I volunteer to
>>>review OpenPGP related parts, I'm less concerned about getting good
>>>enough review on the PKIX part.
>>>
>>>/Simon
>>>
>>>Ondřej Surý <[email-masked]> writes:
>>>
>>>> [I took Warren's original text, added bit from Richard and Nicholas.]
>>>>
>>>> [I have also created a Wiki page for our charter work at:
>>>>  http://tools.ietf.org/area/sec/trac/wiki/Keyassure
>>>> ]
>>>>
>>>> Objective:
>>>>
>>>> Specify mechanisms and techniques that allow Internet applications to
>>>> establish cryptographically secured communications by using
>>>> information distributed through the DNS for discovering and
>>>> authenticating cryptographic material which is associated with a
>>>> service located at a domain name
>>>>
>>>> Problem Statement:
>>>>
>>>> Entities on the Internet are usually identified by domain names and
>>>> forming a cryptographically secured connection to the entity requires
>>>> the entity to authenticate its name.  For instance, in HTTPS, a server
>>>> responding to a query for <https://www.example.com> is expected to
>>>> authenticate as "www.example.com".  Security protocols such as TLS and
>>>> IPsec accomplish this authentication by allowing an endpoint to prove
>>>> ownership of a private key whose corresponding public key is somehow
>>>> bound to the name being authenticated.  As a pre-requisite for
>>>> authentication, then, these protocols require a mechanism for bindings
>>>> to be asserted between public keys and domain names.
>>>>
>>>> DNSSEC provides a mechanism for a domain operator to sign DNS
>>>> information directly, using keys that are bound to the domain by the
>>>> parent domain; relying parties can continue this chain up to any trust
>>>> anchor that they accept.  In this way, bindings of keys to domains are
>>>> asserted not by external entities, but by the entities that operate
>>>> the DNS.  In addition, this technique inherently limits the scope of
>>>> any given entity to the names in zones he controls.
>>>>
>>>> This working group will develop mechanisms for domain operators to
>>>> present bindings between names within their control and public keys,
>>>> in such a way that these bindings can be integrity-protected (and thus
>>>> shown to be authentically from the domain operator) using DNSSEC and
>>>> used as a basis for authentication in protocols that use domain names
>>>> as identifiers.  The group may also specify updates or clarifications
>>>> to protocols to describe how protocol entities discover and validate
>>>> these bindings in the execution of specific applications.
>>>>
>>>>
>>>> Have a nice weekend,
>>>_______________________________________________
>>>keyassure mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/keyassure
>>
>> Regards,
>> Jeffrey A. Williams
>> Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
>> "Obedience of the law is the greatest freedom" -
>>   Abraham Lincoln
>>
>> "Credit should go with the performance of duty and not with what is very
>> often the accident of glory" - Theodore Roosevelt
>>
>> "If the probability be called P; the injury, L; and the burden, B; liability
>> depends upon whether B is less than L multiplied by
>> P: i.e., whether B is less than PL."
>> United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
>> ===============================================================
>> Updated 1/26/04
>> CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
>> Information Network Eng.  INEG. INC.
>> ABA member in good standing member ID 01257402 E-Mail [email-masked]
>> Phone: 214-244-4827
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>>
>
>
>
>-- 
>Website: http://hallambaker.com/

Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

Date: Fri, 27 Aug 2010 16:10:12 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: John Gilmore <[email-masked]>, Stephen Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki
Reply-To: "Jeffrey A. Williams" <[email-masked]>

John and all,

  I for one fully agree with John here.

-----Original Message-----
>From: John Gilmore <[email-masked]>
>Sent: Aug 27, 2010 3:26 PM
>To: Stephen Schultze <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki
>
>> I think there's still legitimate debate over whether certs or keys are  
>> ideal, and at this stage I'd rather leave it open-ended.
>
>It is absolutely clear that this charter should not require the use
>of X.509 certificates for any purpose.
>
>Those who like ambiguity and error are free to use them, and we may
>even produce some RFCs that standardize that ambiguity and error.
>Those who wish to avoid those outcomes should be able to follow
>alternative paths.
>
>	John
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

To: Stephen Schultze <[email-masked]>
Comments: In-reply-to Stephen Schultze <[email-masked]> message dated "Fri, 27 Aug 2010 15:49:52 -0400."
Date: Fri, 27 Aug 2010 13:26:19 -0700
From: John Gilmore <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki

> I think there's still legitimate debate over whether certs or keys are  
> ideal, and at this stage I'd rather leave it open-ended.

It is absolutely clear that this charter should not require the use
of X.509 certificates for any purpose.

Those who like ambiguity and error are free to use them, and we may
even produce some RFCs that standardize that ambiguity and error.
Those who wish to avoid those outcomes should be able to follow
alternative paths.

	John

From: Warren Kumari <[email-masked]>
To: Stephen Schultze <[email-masked]>
Date: Fri, 27 Aug 2010 16:08:39 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki

On Aug 27, 2010, at 3:49 PM, Stephen Schultze wrote:

> I think there's still legitimate debate over whether certs or keys  
> are ideal, and at this stage I'd rather leave it open-ended.
>

+11 3/4

W

> On Aug 27, 2010, at 2:11 PM, Simon Josefsson wrote:
>> For example, I propose that we qualify the "cryptographic material"  
>> to
>> be authenticated to be PKIX certificates and OpenPGP keys.  Are there
>> other formats that are an active use?  There is SPKI, but we need  
>> some
>> SPKI experts to participate in the discussion to make sure we end up
>> with something useful.  SSH keys have been discussed.  I volunteer to
>> review OpenPGP related parts, I'm less concerned about getting good
>> enough review on the PKIX part.
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

-- 
American Non-Sequitur Society;
we don't make sense, but we do like pizza!

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Fri, 27 Aug 2010 15:49:52 -0400
Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki

I think there's still legitimate debate over whether certs or keys are  
ideal, and at this stage I'd rather leave it open-ended.

On Aug 27, 2010, at 2:11 PM, Simon Josefsson wrote:
> For example, I propose that we qualify the "cryptographic material" to
> be authenticated to be PKIX certificates and OpenPGP keys.  Are there
> other formats that are an active use?  There is SPKI, but we need some
> SPKI experts to participate in the discussion to make sure we end up
> with something useful.  SSH keys have been discussed.  I volunteer to
> review OpenPGP related parts, I'm less concerned about getting good
> enough review on the PKIX part.

Date: Fri, 27 Aug 2010 15:37:26 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Jeffrey A. Williams" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki

The approach that leads to fewest arguments is usually to write a
charter that is agnostic on the issue of format in the text but only
commits to produce a deliverable for the specific formats that are
necessary to make it work.

If anyone wants to propose a spec for additional formats, they can,
but only if they can show that there are sufficient people to do the
work and sufficient people in the target community to vet the work.

So for example in KEYPROV we started with an assumption that we were
going to write a protocol in XML only. But the charter was agnostic on
that issue and we later had a proposal to shadow the XML spec with an
ASN.1 spec which is a perfectly justifiable approach. The fact that
the draft in question is written by the IETF chair and one of the
Security ADs is (mostly) besides the point.

2010/8/27 Jeffrey A. Williams <[email-masked]>:
> Simon and all,
>
>  For a start on SPKI, one might want to review
> the information at http://datatracker.ietf.org/doc/search/
> Currently there is no IETF WG for SPKI.
>
>
> -----Original Message-----
>>From: Simon Josefsson <[email-masked]>
>>Sent: Aug 27, 2010 1:11 PM
>>To: Ondřej Surý <[email-masked]>
>>Cc: [email-masked]
>>Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki
>>
>>Thanks Ondřej, it looks like a good starting point.  I believe we need
>>to qualify it with references to existing work and technologies though.
>>
>>For example, I propose that we qualify the "cryptographic material" to
>>be authenticated to be PKIX certificates and OpenPGP keys.  Are there
>>other formats that are an active use?  There is SPKI, but we need some
>>SPKI experts to participate in the discussion to make sure we end up
>>with something useful.  SSH keys have been discussed.  I volunteer to
>>review OpenPGP related parts, I'm less concerned about getting good
>>enough review on the PKIX part.
>>
>>/Simon
>>
>>Ondřej Surý <[email-masked]> writes:
>>
>>> [I took Warren's original text, added bit from Richard and Nicholas.]
>>>
>>> [I have also created a Wiki page for our charter work at:
>>>  http://tools.ietf.org/area/sec/trac/wiki/Keyassure
>>> ]
>>>
>>> Objective:
>>>
>>> Specify mechanisms and techniques that allow Internet applications to
>>> establish cryptographically secured communications by using
>>> information distributed through the DNS for discovering and
>>> authenticating cryptographic material which is associated with a
>>> service located at a domain name
>>>
>>> Problem Statement:
>>>
>>> Entities on the Internet are usually identified by domain names and
>>> forming a cryptographically secured connection to the entity requires
>>> the entity to authenticate its name.  For instance, in HTTPS, a server
>>> responding to a query for <https://www.example.com> is expected to
>>> authenticate as "www.example.com".  Security protocols such as TLS and
>>> IPsec accomplish this authentication by allowing an endpoint to prove
>>> ownership of a private key whose corresponding public key is somehow
>>> bound to the name being authenticated.  As a pre-requisite for
>>> authentication, then, these protocols require a mechanism for bindings
>>> to be asserted between public keys and domain names.
>>>
>>> DNSSEC provides a mechanism for a domain operator to sign DNS
>>> information directly, using keys that are bound to the domain by the
>>> parent domain; relying parties can continue this chain up to any trust
>>> anchor that they accept.  In this way, bindings of keys to domains are
>>> asserted not by external entities, but by the entities that operate
>>> the DNS.  In addition, this technique inherently limits the scope of
>>> any given entity to the names in zones he controls.
>>>
>>> This working group will develop mechanisms for domain operators to
>>> present bindings between names within their control and public keys,
>>> in such a way that these bindings can be integrity-protected (and thus
>>> shown to be authentically from the domain operator) using DNSSEC and
>>> used as a basis for authentication in protocols that use domain names
>>> as identifiers.  The group may also specify updates or clarifications
>>> to protocols to describe how protocol entities discover and validate
>>> these bindings in the execution of specific applications.
>>>
>>>
>>> Have a nice weekend,
>>_______________________________________________
>>keyassure mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/keyassure
>
> Regards,
> Jeffrey A. Williams
> Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
> "Obedience of the law is the greatest freedom" -
>   Abraham Lincoln
>
> "Credit should go with the performance of duty and not with what is very
> often the accident of glory" - Theodore Roosevelt
>
> "If the probability be called P; the injury, L; and the burden, B; liability
> depends upon whether B is less than L multiplied by
> P: i.e., whether B is less than PL."
> United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
> ===============================================================
> Updated 1/26/04
> CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
> Information Network Eng.  INEG. INC.
> ABA member in good standing member ID 01257402 E-Mail [email-masked]
> Phone: 214-244-4827
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Fri, 27 Aug 2010 13:58:28 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Andrew Sullivan <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Poking the charter bear....
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Andrew and all,

  How true!  >:(  Too many are not managed or managed
properly unfortunately.  Some may never be...

-----Original Message-----
>From: Andrew Sullivan <[email-masked]>
>Sent: Aug 27, 2010 9:25 AM
>To: [email-masked]
>Subject: Re: [keyassure] Poking the charter bear....
>
>On Thu, Aug 26, 2010 at 03:43:16PM -0700, Douglas Otis wrote:
>> For cases where clients do not exchange domain names, reverse DNS could  
>> be utilized to authenticate clients.
>
>Except, of course, that you can't really rely on the reverse tree
>being managed.
>
>A
>
>-- 
>Andrew Sullivan
>[email-masked]
>Shinkuro, Inc.
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

Date: Fri, 27 Aug 2010 14:37:25 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] two vs multi

I would try to keep clear of the term two factor for anything other
than end user authentication and then where the authentication factors
are based on different principles (e.g. something known, something
carried).

The term has been widely abused of late due to the interpretation of
the federal reserve regulations requiring 'two factor' that allow for
non-two factor schemes.

This is machine-machine authentication and only one factor is possible.

We could use the phrase multiple trust chain or similar.

On Fri, Aug 27, 2010 at 2:30 PM, Paul Hoffman <[email-masked]> wrote:
> At 6:28 PM +0000 8/27/10, [email-masked] wrote:
>>On Fri, Aug 27, 2010 at 08:15:40PM +0200, Simon Josefsson wrote:
>>> [email-masked] writes:
>>>
>>> > One presumes that (a) validating the DNS delegation chain, and then finding at
>>> > the end of that validation, (b) a crypto-bundle of goodness is the functional
>>> > equivalent of what is known as "two-factor" authentication.
>>>
>>> I'm confused. �Unless I'm misunderstanding you, I wouldn't call what you
>>> describe two-factor authentication at all. �To me, two-factor
>>> authentication is about client authentication, and each factor has to be
>>> an independent authentication that is provided by the client. �See:
>>> http://en.wikipedia.org/wiki/Two-factor_authentication
>>>
>>> /Simon
>>
>>
>> � � � perhaps i misunderstand. �the DNSSEC validation chain as a factor
>> � � � consists of a series of independent folks vouching for each other.
>>
>> � � � the second factor is the CERT at the end of the chain, in my understanding
>> � � � of the CERT RR, this is effectively an x509 CERT, which is provided by
>> � � � a CA* �Thats two distinct, independent sources... neither of which is
>> � � � the client. �Right?
>>
>>* - presuming the same party signing a zone is not also your friendly CA... :)
>
> I'm with Simon: your description has nothing to do with what is commonly called two-factor authentication.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Fri, 27 Aug 2010 13:33:40 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Simon Josefsson <[email-masked]>,  =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Simon and all,

  For a start on SPKI, one might want to review
the information at http://datatracker.ietf.org/doc/search/
Currently there is no IETF WG for SPKI.

-----Original Message-----
>From: Simon Josefsson <[email-masked]>
>Sent: Aug 27, 2010 1:11 PM
>To: Ondřej Surý <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki
>
>Thanks Ondřej, it looks like a good starting point.  I believe we need
>to qualify it with references to existing work and technologies though.
>
>For example, I propose that we qualify the "cryptographic material" to
>be authenticated to be PKIX certificates and OpenPGP keys.  Are there
>other formats that are an active use?  There is SPKI, but we need some
>SPKI experts to participate in the discussion to make sure we end up
>with something useful.  SSH keys have been discussed.  I volunteer to
>review OpenPGP related parts, I'm less concerned about getting good
>enough review on the PKIX part.
>
>/Simon
>
>Ondřej Surý <[email-masked]> writes:
>
>> [I took Warren's original text, added bit from Richard and Nicholas.]
>>
>> [I have also created a Wiki page for our charter work at:
>>  http://tools.ietf.org/area/sec/trac/wiki/Keyassure
>> ]
>>
>> Objective:
>>
>> Specify mechanisms and techniques that allow Internet applications to
>> establish cryptographically secured communications by using
>> information distributed through the DNS for discovering and
>> authenticating cryptographic material which is associated with a
>> service located at a domain name
>>
>> Problem Statement:
>>
>> Entities on the Internet are usually identified by domain names and
>> forming a cryptographically secured connection to the entity requires
>> the entity to authenticate its name.  For instance, in HTTPS, a server
>> responding to a query for <https://www.example.com> is expected to
>> authenticate as "www.example.com".  Security protocols such as TLS and
>> IPsec accomplish this authentication by allowing an endpoint to prove
>> ownership of a private key whose corresponding public key is somehow
>> bound to the name being authenticated.  As a pre-requisite for
>> authentication, then, these protocols require a mechanism for bindings
>> to be asserted between public keys and domain names.
>>
>> DNSSEC provides a mechanism for a domain operator to sign DNS
>> information directly, using keys that are bound to the domain by the
>> parent domain; relying parties can continue this chain up to any trust
>> anchor that they accept.  In this way, bindings of keys to domains are
>> asserted not by external entities, but by the entities that operate
>> the DNS.  In addition, this technique inherently limits the scope of
>> any given entity to the names in zones he controls.
>>
>> This working group will develop mechanisms for domain operators to
>> present bindings between names within their control and public keys,
>> in such a way that these bindings can be integrity-protected (and thus
>> shown to be authentically from the domain operator) using DNSSEC and
>> used as a basis for authentication in protocols that use domain names
>> as identifiers.  The group may also specify updates or clarifications
>> to protocols to describe how protocol entities discover and validate
>> these bindings in the execution of specific applications.
>>
>>
>> Have a nice weekend,
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

Date: Fri, 27 Aug 2010 11:30:13 -0700
To: [email-masked], Simon Josefsson <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] two vs multi

At 6:28 PM +0000 8/27/10, [email-masked] wrote:
>On Fri, Aug 27, 2010 at 08:15:40PM +0200, Simon Josefsson wrote:
>> [email-masked] writes:
>>
>> > One presumes that (a) validating the DNS delegation chain, and then finding at
>> > the end of that validation, (b) a crypto-bundle of goodness is the functional
>> > equivalent of what is known as "two-factor" authentication.
>>
>> I'm confused.  Unless I'm misunderstanding you, I wouldn't call what you
>> describe two-factor authentication at all.  To me, two-factor
>> authentication is about client authentication, and each factor has to be
>> an independent authentication that is provided by the client.  See:
>> http://en.wikipedia.org/wiki/Two-factor_authentication
>>
>> /Simon
>
>
>	perhaps i misunderstand.  the DNSSEC validation chain as a factor
>	consists of a series of independent folks vouching for each other.
>
>	the second factor is the CERT at the end of the chain, in my understanding
>	of the CERT RR, this is effectively an x509 CERT, which is provided by
>	a CA*  Thats two distinct, independent sources... neither of which is
>	the client.  Right?
>
>* - presuming the same party signing a zone is not also your friendly CA... :)

I'm with Simon: your description has nothing to do with what is commonly called two-factor authentication.

--Paul Hoffman, Director
--VPN Consortium

Date: Fri, 27 Aug 2010 18:28:18 +0000
From: [email-masked]
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] two vs multi

On Fri, Aug 27, 2010 at 08:15:40PM +0200, Simon Josefsson wrote:
> [email-masked] writes:
> 
> > One presumes that (a) validating the DNS delegation chain, and then finding at 
> > the end of that validation, (b) a crypto-bundle of goodness is the functional
> > equivalent of what is known as "two-factor" authentication.
> 
> I'm confused.  Unless I'm misunderstanding you, I wouldn't call what you
> describe two-factor authentication at all.  To me, two-factor
> authentication is about client authentication, and each factor has to be
> an independent authentication that is provided by the client.  See:
> http://en.wikipedia.org/wiki/Two-factor_authentication
> 
> /Simon

	perhaps i misunderstand.  the DNSSEC validation chain as a factor
	consists of a series of independent folks vouching for each other.

	the second factor is the CERT at the end of the chain, in my understanding
	of the CERT RR, this is effectively an x509 CERT, which is provided by
	a CA*  Thats two distinct, independent sources... neither of which is
	the client.  Right?

* - presuming the same party signing a zone is not also your friendly CA... :)

--bill

From: Simon Josefsson <[email-masked]>
To: [email-masked]
OpenPGP: id�65716F; url=http://josefsson.org/key.txt
Date: Fri, 27 Aug 2010 20:15:40 +0200
Cc: [email-masked]
Subject: Re: [keyassure] two vs multi

[email-masked] writes:

> One presumes that (a) validating the DNS delegation chain, and then finding at 
> the end of that validation, (b) a crypto-bundle of goodness is the functional
> equivalent of what is known as "two-factor" authentication.

I'm confused.  Unless I'm misunderstanding you, I wouldn't call what you
describe two-factor authentication at all.  To me, two-factor
authentication is about client authentication, and each factor has to be
an independent authentication that is provided by the client.  See:
http://en.wikipedia.org/wiki/Two-factor_authentication

/Simon

From: Simon Josefsson <[email-masked]>
To: =?iso-8859-2?Q?Ond�ej_Sur�?= <[email-masked]>
OpenPGP: id�65716F; url=http://josefsson.org/key.txt
Date: Fri, 27 Aug 2010 20:11:15 +0200
Cc: [email-masked]
Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki

Thanks Ond�ej, it looks like a good starting point.  I believe we need
to qualify it with references to existing work and technologies though.

For example, I propose that we qualify the "cryptographic material" to
be authenticated to be PKIX certificates and OpenPGP keys.  Are there
other formats that are an active use?  There is SPKI, but we need some
SPKI experts to participate in the discussion to make sure we end up
with something useful.  SSH keys have been discussed.  I volunteer to
review OpenPGP related parts, I'm less concerned about getting good
enough review on the PKIX part.

/Simon

Ond�ej Sur� <[email-masked]> writes:

> [I took Warren's original text, added bit from Richard and Nicholas.]
>
> [I have also created a Wiki page for our charter work at:
>  http://tools.ietf.org/area/sec/trac/wiki/Keyassure
> ]
>
> Objective:
>
> Specify mechanisms and techniques that allow Internet applications to
> establish cryptographically secured communications by using
> information distributed through the DNS for discovering and
> authenticating cryptographic material which is associated with a
> service located at a domain name
>
> Problem Statement:
>
> Entities on the Internet are usually identified by domain names and
> forming a cryptographically secured connection to the entity requires
> the entity to authenticate its name.  For instance, in HTTPS, a server
> responding to a query for <https://www.example.com> is expected to
> authenticate as "www.example.com".  Security protocols such as TLS and
> IPsec accomplish this authentication by allowing an endpoint to prove
> ownership of a private key whose corresponding public key is somehow
> bound to the name being authenticated.  As a pre-requisite for
> authentication, then, these protocols require a mechanism for bindings
> to be asserted between public keys and domain names.
>
> DNSSEC provides a mechanism for a domain operator to sign DNS
> information directly, using keys that are bound to the domain by the
> parent domain; relying parties can continue this chain up to any trust
> anchor that they accept.  In this way, bindings of keys to domains are
> asserted not by external entities, but by the entities that operate
> the DNS.  In addition, this technique inherently limits the scope of
> any given entity to the names in zones he controls.
>
> This working group will develop mechanisms for domain operators to
> present bindings between names within their control and public keys,
> in such a way that these bindings can be integrity-protected (and thus
> shown to be authentically from the domain operator) using DNSSEC and
> used as a basis for authentication in protocols that use domain names
> as identifiers.  The group may also specify updates or clarifications
> to protocols to describe how protocol entities discover and validate
> these bindings in the execution of specific applications.
>
>
> Have a nice weekend,

Date: Fri, 27 Aug 2010 17:44:58 +0000
From: [email-masked]
To: [email-masked]
Subject: [keyassure] who vs what

This idea has been alluded to in other threads; there are even a couple
of drafts in circulation on one aspect of this idea.  It might have even
have been the premise of the bar-bof, the ensueing charter and work todate.

The idea?

	That the CERT/DKIM etc RR is targeted at a given app that
	may or may not be running on a given target.  EG  - WHAT

Is there any value in this?

	That the CERT is targeted at the given target.  EG  - WHO

I would like to think there is value in crypto certification that a target
node is whom it says it is - with other keys/hashes/app-specific crypto
as adjuncts to the RRset.  In this way, we don't have the "portmanteau"
effect of a given crypto bundle identifying both WHO and WHAT.

Or am I just being problematic?

--bill

Date: Fri, 27 Aug 2010 17:34:18 +0000
From: [email-masked]
To: [email-masked]
Subject: [keyassure] two vs multi

One presumes that (a) validating the DNS delegation chain, and then finding at 
the end of that validation, (b) a crypto-bundle of goodness is the functional
equivalent of what is known as "two-factor" authentication.

So if One validates (a) the forward delegation chain, (b) the reverse delegation 
chain, and finds (c) the _same_ crypto-bundle of goodness at the end of each
validation chain, would this be the functional equivalent of "Multi-factor"
authentication?

--bill

Date: Fri, 27 Aug 2010 12:48:42 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Steingruebl, Andy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Poking the charter bear....

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

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

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

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

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

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

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

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

On Fri, Aug 27, 2010 at 12:36 PM, Steingruebl, Andy
<[email-masked]> wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of [email-masked]
>> Sent: Friday, August 27, 2010 9:32 AM
>>
>> � � � the point being, that most folks seem to agree on the charter
>> � � � being applicable to the entire DNS namespace, not just a portion.
>
> On the one hand I conceptually agree. On the other hand any mechanism is going to rely on signed data from DNS. �Without getting into the arguments again about what the trust anchors will be, the necessarily restriction is still that the DNS space in question must be trust-anchored somehow.
>
> Yes?
>
> This means that for those using the DNS root as their trust-anchor, the 192.in-addr.arpa. space can't hold any of this data, right? �Or does it not mean that?
>
> - Andy
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Fri, 27 Aug 2010 12:40:36 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

On Fri, Aug 27, 2010 at 04:32:02PM +0000, [email-masked] wrote:
> 
> 	and you can rely on the forward tree being managed?

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

>  	the point being, that most folks seem to agree on the charter
> 	being applicable to the entire DNS namespace, not just a portion.

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

A

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

From: "Steingruebl, Andy" <[email-masked]>
To: "[email-masked]" <[email-masked]>, Andrew Sullivan <[email-masked]>
Date: Fri, 27 Aug 2010 10:36:10 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Poking the charter bear....

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Friday, August 27, 2010 9:32 AM
> 
>  	the point being, that most folks seem to agree on the charter
> 	being applicable to the entire DNS namespace, not just a portion.

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

Yes?

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

- Andy

Date: Fri, 27 Aug 2010 16:32:02 +0000
From: [email-masked]
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

On Fri, Aug 27, 2010 at 10:25:23AM -0400, Andrew Sullivan wrote:
> On Thu, Aug 26, 2010 at 03:43:16PM -0700, Douglas Otis wrote:
> > For cases where clients do not exchange domain names, reverse DNS could  
> > be utilized to authenticate clients.
> 
> Except, of course, that you can't really rely on the reverse tree
> being managed.

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

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

--bill

Date: Fri, 27 Aug 2010 17:22:57 +0200
From: =?ISO-8859-2?Q?Ond�ej_Sur�?= <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

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

Apologies, my mistake.

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

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

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

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

> But regardless of whether designing to support SSH is in or out of
> charter, experience from the SSH proposal is in charter.
>
>
> I suspect that SSH use has not been very extensive given the lack of
> an ICANN signed root. I would therefore suggest as an experiment we
> look to see if SSH use could be increased by using a CERT record to
> declare a local root for a zone and then configure SSH to use that
> as its trust anchor.

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

Ondrej

> On Fri, Aug 27, 2010 at 11:03 AM, Ond�ej Sur�<[email-masked]>
> wrote:
>> On 27.8.2010 16:49, Nicholas Weaver wrote:
>>>
>>> On Aug 27, 2010, at 7:45 AM, Ond�ej Sur� wrote:
>>>
>>>> On 27.8.2010 16:42, Phillip Hallam-Baker wrote:
>>>>>
>>>>> The reason that the reverse tree is not properly managed is
>>>>> that doing so is not necessary for most Web applications.
>>>>>
>>>>> I would see the utility of this approach being for use with
>>>>> applications such as SSH and other network management tools
>>>>> that are used by the type of people who make sure their
>>>>> reverse DNS works should they actually need it.
>>>>
>>>> May I remind this list, that SSH is out of the scope?  And we
>>>> already have a existing SSHFP RR.  So when you think about
>>>> reverse tree, please don't include SSH nor IPSec.
>>>
>>> Uh, actually SSH IMO, is perfectly in scope.
>>>
>>> The real scope is not new resource records but new APIs and
>>> techniques:  You may be able to get the SSHFP RR today, but we
>>> need ways for the SSH application to validate that the key is
>>> indeed valid, and we need protocol and policy to get reverse
>>> lookups to be reliable in this case.
>>
>>
>> Let me rephrase what I said...
>>
>> The SSH and IPSec was out of scope when we created this mailing
>> list, called the BoF and planned the creation of WG.  So I still
>> think the SSH is out-of-the-scope.  And I personally would like to
>> keep it that way.
>>
>> Ondrej -- Ond�ej Sur� vedouc� v�zkumu/Head of R&D department
>> ------------------------------------------- CZ.NIC, z.s.p.o.    --
>> Laborato�e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic
>> mailto:[email-masked]    http://nic.cz/ tel:+420.222745110
>> fax:+420.222745112 -------------------------------------------
>> _______________________________________________ keyassure mailing
>> list [email-masked]
>> 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
  -------------------------------------------

Date: Fri, 27 Aug 2010 17:15:35 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: [keyassure] Charter round 3 & KeyAssure Wiki

[I took Warren's original text, added bit from Richard and Nicholas.]

[I have also created a Wiki page for our charter work at:
  http://tools.ietf.org/area/sec/trac/wiki/Keyassure
]

Objective:

Specify mechanisms and techniques that allow Internet applications to 
establish cryptographically secured communications by using information 
distributed through the DNS for discovering and authenticating 
cryptographic material which is associated with a service located at a 
domain name

Problem Statement:

Entities on the Internet are usually identified by domain names and 
forming a cryptographically secured connection to the entity requires 
the entity to authenticate its name.  For instance, in HTTPS, a server 
responding to a query for <https://www.example.com> is expected to 
authenticate as "www.example.com".  Security protocols such as TLS and 
IPsec accomplish this authentication by allowing an endpoint to prove 
ownership of a private key whose corresponding public key is somehow 
bound to the name being authenticated.  As a pre-requisite for 
authentication, then, these protocols require a mechanism for bindings 
to be asserted between public keys and domain names.

DNSSEC provides a mechanism for a domain operator to sign DNS 
information directly, using keys that are bound to the domain by the 
parent domain; relying parties can continue this chain up to any trust 
anchor that they accept.  In this way, bindings of keys to domains are 
asserted not by external entities, but by the entities that operate the 
DNS.  In addition, this technique inherently limits the scope of any 
given entity to the names in zones he controls.

This working group will develop mechanisms for domain operators to 
present bindings between names within their control and public keys, in 
such a way that these bindings can be integrity-protected (and thus 
shown to be authentically from the domain operator) using DNSSEC and 
used as a basis for authentication in protocols that use domain names as 
identifiers.  The group may also specify updates or clarifications to 
protocols to describe how protocol entities discover and validate these 
bindings in the execution of specific applications.

Have a nice weekend,
-- 
  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: Fri, 27 Aug 2010 11:14:25 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

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

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

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

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

On Fri, Aug 27, 2010 at 11:03 AM, Ond�ej Sur� <[email-masked]> wrote:
> On 27.8.2010 16:49, Nicholas Weaver wrote:
>>
>> On Aug 27, 2010, at 7:45 AM, Ond�ej Sur� wrote:
>>
>>> On 27.8.2010 16:42, Phillip Hallam-Baker wrote:
>>>>
>>>> The reason that the reverse tree is not properly managed is that
>>>> doing so is not necessary for most Web applications.
>>>>
>>>> I would see the utility of this approach being for use with
>>>> applications such as SSH and other network management tools that
>>>> are used by the type of people who make sure their reverse DNS
>>>> works should they actually need it.
>>>
>>> May I remind this list, that SSH is out of the scope? �And we
>>> already have a existing SSHFP RR. �So when you think about reverse
>>> tree, please don't include SSH nor IPSec.
>>
>> Uh, actually SSH IMO, is perfectly in scope.
>>
>> The real scope is not new resource records but new APIs and
>> techniques: �You may be able to get the SSHFP RR today, but we need
>> ways for the SSH application to validate that the key is indeed
>> valid, and we need protocol and policy to get reverse lookups to be
>> reliable in this case.
>
>
> Let me rephrase what I said...
>
> The SSH and IPSec was out of scope when we created this mailing list, called
> the BoF and planned the creation of WG. �So I still think the SSH is
> out-of-the-scope. �And I personally would like to keep it that way.
>
> Ondrej
> --
> �Ond�ej Sur�
> �vedouc� v�zkumu/Head of R&D department
> �-------------------------------------------
> �CZ.NIC, z.s.p.o. � �-- � �Laborato�e CZ.NIC
> �Americka 23, 120 00 Praha 2, Czech Republic
> �mailto:[email-masked] � �http://nic.cz/
> �tel:+420.222745110 � � � fax:+420.222745112
> �-------------------------------------------
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Fri, 27 Aug 2010 17:03:06 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

On 27.8.2010 16:49, Nicholas Weaver wrote:
>
> On Aug 27, 2010, at 7:45 AM, Ondřej Surý wrote:
>
>> On 27.8.2010 16:42, Phillip Hallam-Baker wrote:
>>> The reason that the reverse tree is not properly managed is that
>>> doing so is not necessary for most Web applications.
>>>
>>> I would see the utility of this approach being for use with
>>> applications such as SSH and other network management tools that
>>> are used by the type of people who make sure their reverse DNS
>>> works should they actually need it.
>>
>> May I remind this list, that SSH is out of the scope?  And we
>> already have a existing SSHFP RR.  So when you think about reverse
>> tree, please don't include SSH nor IPSec.
>
> Uh, actually SSH IMO, is perfectly in scope.
>
> The real scope is not new resource records but new APIs and
> techniques:  You may be able to get the SSHFP RR today, but we need
> ways for the SSH application to validate that the key is indeed
> valid, and we need protocol and policy to get reverse lookups to be
> reliable in this case.

Let me rephrase what I said...

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

Ondrej
-- 
  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: Fri, 27 Aug 2010 11:02:38 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

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

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

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

On Fri, Aug 27, 2010 at 10:45 AM, Ond�ej Sur� <[email-masked]> wrote:
> On 27.8.2010 16:42, Phillip Hallam-Baker wrote:
>>
>> The reason that the reverse tree is not properly managed is that doing
>> so is not necessary for most Web applications.
>>
>> I would see the utility of this approach being for use with
>> applications such as SSH and other network management tools that are
>> used by the type of people who make sure their reverse DNS works
>> should they actually need it.
>
> May I remind this list, that SSH is out of the scope? �And we already have a
> existing SSHFP RR. �So when you think about reverse tree, please don't
> include SSH nor IPSec.
>
> Ondrej
> --
> �Ond�ej Sur�
> �vedouc� v�zkumu/Head of R&D department
> �-------------------------------------------
> �CZ.NIC, z.s.p.o. � �-- � �Laborato�e CZ.NIC
> �Americka 23, 120 00 Praha 2, Czech Republic
> �mailto:[email-masked] � �http://nic.cz/
> �tel:+420.222745110 � � � fax:+420.222745112
> �-------------------------------------------
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Fri, 27 Aug 2010 07:49:10 -0700
To: =?utf-8?Q?Ondřej_Surý?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

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

> On 27.8.2010 16:42, Phillip Hallam-Baker wrote:
>> The reason that the reverse tree is not properly managed is that doing
>> so is not necessary for most Web applications.
>> 
>> I would see the utility of this approach being for use with
>> applications such as SSH and other network management tools that are
>> used by the type of people who make sure their reverse DNS works
>> should they actually need it.
> 
> May I remind this list, that SSH is out of the scope?  And we already have a existing SSHFP RR.  So when you think about reverse tree, please don't include SSH nor IPSec.

Uh, actually SSH IMO, is perfectly in scope.  

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

Date: Fri, 27 Aug 2010 16:45:43 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

On 27.8.2010 16:42, Phillip Hallam-Baker wrote:
> The reason that the reverse tree is not properly managed is that doing
> so is not necessary for most Web applications.
>
> I would see the utility of this approach being for use with
> applications such as SSH and other network management tools that are
> used by the type of people who make sure their reverse DNS works
> should they actually need it.

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

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

Date: Fri, 27 Aug 2010 10:42:06 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

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

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

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

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

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

On Fri, Aug 27, 2010 at 10:25 AM, Andrew Sullivan <[email-masked]> wrote:
> On Thu, Aug 26, 2010 at 03:43:16PM -0700, Douglas Otis wrote:
>> For cases where clients do not exchange domain names, reverse DNS could
>> be utilized to authenticate clients.
>
> Except, of course, that you can't really rely on the reverse tree
> being managed.
>
> A
>
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Fri, 27 Aug 2010 10:25:23 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

On Thu, Aug 26, 2010 at 03:43:16PM -0700, Douglas Otis wrote:
> For cases where clients do not exchange domain names, reverse DNS could  
> be utilized to authenticate clients.

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

A

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

Date: Thu, 26 Aug 2010 23:09:08 -0400
To: Andrew Sullivan <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Does this work need to be "better"? (was: Introducing	draft-josefsson-keyassure-tls-00.txt)

At 11:48 AM -0400 8/26/10, Andrew Sullivan wrote:
>On Wed, Aug 25, 2010 at 07:18:30PM -0400, Stephen Kent wrote:
>>  one wants to provide via DNS-supplied keys or certs, and why the use of
>>  DNS to effect this function is better than extant mechanisms. If we can't
>>  clearly articulate this, then it is not clear that a Wg should be
>>  created.
>
>I don't see why it has to be "better" than.  Surely "better for some
>uses" or "useful alternative in some cases" are enough?

Better for enough use cases to make it worthwhile to add to our 
plethora of standards :-).

>I'm particularly uncomfortable with that "better" because it strikes
>me as a way of sneaking in some premises that maybe not everyone will
>grant.  For instance, a DNSSEC-based approach is clearly not better
>for showing cryptographically some relationship between a given name
>and some particular legal entity.  But one can simply set that issue
>aside as not relevant for this use, and be agnostic on whether it
>makes things "better".

Relax. If the proposed work is better for some reasonable class of
application contexts, then it makes sense.  The fact that it is not likely
to be a panacea ought not be part of the criteria.

I like the latest charter statement form Warren, with the minor tweaks
several folks have suggested.

Steve

Date: Thu, 26 Aug 2010 22:23:03 -0400
To: Phillip Hallam-Baker <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys

At 8:54 AM -0400 8/26/10, Phillip Hallam-Baker wrote:
>I don't think it is helpful to start bringing in the Security ADs
>opinion unless they have stated an opinion. Their concurrence may be a
>necessary condition, but certainly not a sufficient one.

Agreed that it is necessary, but not sufficient.

>You are correct that these are not self signed certificates in the
>proposed mode of use. They are actually a CA issued certificate with
>signature in the form of a countersignature on the self-signed
>certificate prototype.

OK.

>The zone KSK may be established through a number of different means.
>
>These means are out of scope for this discussion. But one means that
>you should probably consider in the context of making BGP security
>practical is the case where the DNS zone KSK is signed using an X.509
>certificate expressed in a CERT record.

I'm not sure how any DNSSEC capabilities relate to the RPKI that BGP 
secruity will rely upon. All 5 RIRs have committed to IOC for the 
RPKI on 1/1/11, based on a number of I-Ds that the SIDR WG is now 
aggressively pushing towards approval.

Steve

Date: Thu, 26 Aug 2010 15:43:16 -0700
From: Douglas Otis <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

  On 8/25/10 2:35 PM, Nicholas Weaver wrote:
>  On Aug 25, 2010, at 2:30 PM, Andrew Sullivan wrote:
> > On Wed, Aug 25, 2010 at 05:14:59PM -0400, Richard L. Barnes wrote:
> >> I would prefer the Objective be tightened a little to focus on
> >> authenticating domain names, as opposed to, say, negotiating
> >> crypto
> >
> > What do you mean "authenticating"?  If what you want to do is
> > ensure yourself that you're actually going to the right address,
> > you can do that now.  That's all DNSSEC does.
>
>  Why not "discovering and authenticating cryptographic material which
>  is associated with a service located at a domain name"?

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

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

So rewritten just a bit,

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

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

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

-Doug

Date: Thu, 26 Aug 2010 17:34:56 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: [email-masked], Paul Hoffman <[email-masked]>
Cc: Phillip Hallam-Baker <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Poking the charter bear....
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Paul and all,

  That's how I interprit the discussion thus far, yes...

-----Original Message-----
>From: [email-masked]
>Sent: Aug 26, 2010 4:22 PM
>To: Paul Hoffman <[email-masked]>
>Cc: [email-masked], Phillip Hallam-Baker <[email-masked]>
>Subject: Re: [keyassure] Poking the charter bear....
>
>
>	so, there seems to be tacit agreement that the entire DNS tree
>	is fair game under the text Warren posted... mod the existance
>	of IDs et.al.
>
>--bill
>
>
>On Thu, Aug 26, 2010 at 01:21:28PM -0700, Paul Hoffman wrote:
>> At 3:55 PM -0400 8/26/10, Phillip Hallam-Baker wrote:
>> >Looks like a cop out to me.
>> 
>> One person's prudent use of resources is another person's cop-out.
>> 
>> >Putting certs in the reverse DNS may turn out to be useless. But we
>> >have to understand why it is useless if we are going to be able to
>> >claim that we understand the proposals for the forward DNS.
>> 
>> We will never know until there are one or more concrete proposals, hopefully written as Internet Drafts and not just a changing thread on a mailing list.
>> 
>> 
>> --Paul Hoffman, Director
>> --VPN Consortium
>> _______________________________________________

Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

Date: Thu, 26 Aug 2010 21:22:18 +0000
From: [email-masked]
To: Paul Hoffman <[email-masked]>
Cc: [email-masked], Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] Poking the charter bear....

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

--bill

On Thu, Aug 26, 2010 at 01:21:28PM -0700, Paul Hoffman wrote:
> At 3:55 PM -0400 8/26/10, Phillip Hallam-Baker wrote:
> >Looks like a cop out to me.
> 
> One person's prudent use of resources is another person's cop-out.
> 
> >Putting certs in the reverse DNS may turn out to be useless. But we
> >have to understand why it is useless if we are going to be able to
> >claim that we understand the proposals for the forward DNS.
> 
> We will never know until there are one or more concrete proposals, hopefully written as Internet Drafts and not just a changing thread on a mailing list.
> 
> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Thu, 26 Aug 2010 17:16:12 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

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

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

But time spent understanding the problem is not wasted.

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

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

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

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

On Thu, Aug 26, 2010 at 4:21 PM, Paul Hoffman <[email-masked]> wrote:
> At 3:55 PM -0400 8/26/10, Phillip Hallam-Baker wrote:
>>Looks like a cop out to me.
>
> One person's prudent use of resources is another person's cop-out.
>
>>Putting certs in the reverse DNS may turn out to be useless. But we
>>have to understand why it is useless if we are going to be able to
>>claim that we understand the proposals for the forward DNS.
>
> We will never know until there are one or more concrete proposals, hopefully written as Internet Drafts and not just a changing thread on a mailing list.
>
>
> --Paul Hoffman, Director
> --VPN Consortium
>

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

Date: Thu, 26 Aug 2010 17:00:13 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked], Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] Poking the charter bear....

On Thu, 26 Aug 2010, Paul Hoffman wrote:

> At 3:55 PM -0400 8/26/10, Phillip Hallam-Baker wrote:
>> Looks like a cop out to me.
>
> One person's prudent use of resources is another person's cop-out.
>
>> Putting certs in the reverse DNS may turn out to be useless. But we
>> have to understand why it is useless if we are going to be able to
>> claim that we understand the proposals for the forward DNS.
>
> We will never know until there are one or more concrete proposals, hopefully written as Internet Drafts and not just a changing thread on a mailing list.

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

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

Paul

Date: Thu, 26 Aug 2010 13:21:28 -0700
To: Phillip Hallam-Baker <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

At 3:55 PM -0400 8/26/10, Phillip Hallam-Baker wrote:
>Looks like a cop out to me.

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

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

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

--Paul Hoffman, Director
--VPN Consortium

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Thu, 26 Aug 2010 13:20:01 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Poking the charter bear....

On Aug 26, 2010, at 12:55 PM, Phillip Hallam-Baker wrote:

> Looks like a cop out to me.
> 
> Putting certs in the reverse DNS may turn out to be useless. But we
> have to understand why it is useless if we are going to be able to
> claim that we understand the proposals for the forward DNS.
> 
> None of these schemes are going to make any sense except in the
> context of an application.
> 
> 
> Binding a cert to an IP address is does not seem to be very useful in
> an application layer protocol. But it could be very useful in a
> routing layer protocol. For example, BGP security. I can also see
> cases where it might be used to exchange messages reporting abusive
> behavior.
> 
> In the case of establishing a WiFi connection at an access point such
> as a coffee shop, this would seem to me to be a rather useful
> approach.

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

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

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

it passes through the chain of

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

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

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

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

Date: Thu, 26 Aug 2010 15:55:49 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

Looks like a cop out to me.

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

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

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

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

On Thu, Aug 26, 2010 at 2:01 PM, Paul Hoffman <[email-masked]> wrote:
> At 5:35 PM +0000 8/26/10, [email-masked] wrote:
>> wander off for a few days and look what happens! :)
>>
>> i have a question for the assembled masses...
>>
>> when the text below referes to "domain names" does this include
>> _all_ domain names or just those in the forward tree? �i.e.
>>
>> any problems using
>>
>> � � � 53.30.168.192.in-addr.arpa.
>>
>> as a domain name?
>
> Now thar's some good poking!
>
> I definitely have a problem with that name for what is in the charter in that I would hope that there could not be a server running TLS at the addresses in the A or AAAA records returned from a query sent for 53.30.168.192.in-addr.arpa.
>
> And, just in case you were messing with us by choosing a private address space, I would say exactly the same thing for 81.41.182.207.in-addr.arpa.
>
> The CNAME and SRV indirection threads here have not yielded widespread agreement; I think PTR indirection should be added to the list of things we might consider but might gingerly back away from.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Thu, 26 Aug 2010 11:01:23 -0700
To: [email-masked], Warren Kumari <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

At 5:35 PM +0000 8/26/10, [email-masked] wrote:
> wander off for a few days and look what happens! :)
>
> i have a question for the assembled masses...
>
> when the text below referes to "domain names" does this include
> _all_ domain names or just those in the forward tree?  i.e.
>
> any problems using
>
>	53.30.168.192.in-addr.arpa.
>
> as a domain name?

Now thar's some good poking!

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

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

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

--Paul Hoffman, Director
--VPN Consortium

Date: Thu, 26 Aug 2010 17:35:48 +0000
From: [email-masked]
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

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

 i have a question for the assembled masses...

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

 any problems using 

	53.30.168.192.in-addr.arpa. 

 as a domain name?

--bill

On Wed, Aug 25, 2010 at 04:59:01PM -0400, Warren Kumari wrote:
> So, a while back we had some discussions about a possible charter for  
> a possible working group. This discussion sort of veered off course,  
> so this is a new thread, unencumbered by previous grumpiness...
> 
> I have tried to distill essence from various folks comments and  
> proposed charters and come up with something that we can all (yeah,  
> right!) agree on... How do folk feel about the below?
> 
> -----------------------------------
> Objective:
> 
> Specify mechanisms and techniques that allow Internet applications to  
> establish cryptographically secured communications through use of  
> information distributed through the DNS.
> 
> Problem Statement:
> 
> Entities on the Internet are usually identified by domain names and  
> forming a cryptographically secured connection to the entity requires  
> the entity to authenticate its name.  For instance, in HTTPS, a server  
> responding to a query for <https://www.example.com> is expected to  
> authenticate as "www.example.com".  Security protocols such as TLS and  
> IPsec accomplish this authentication by allowing an endpoint to prove  
> ownership of a private key whose corresponding public key is somehow  
> bound to the name being authenticated.  As a pre-requisite for  
> authentication, then, these protocols require a mechanism for bindings  
> to be asserted between public keys and domain names.
> 
> DNSSEC provides a mechanism for a domain operator to sign DNS  
> information directly, using keys that are bound to the domain by the  
> parent domain; relying parties can continue this chain up to any trust  
> anchor that they accept.  In this way, bindings of keys to domains are  
> asserted not by external entities, but by the entities that operate  
> the DNS.  In addition, this technique inherently limits the scope of  
> any given entity to the names in zones he controls.
> 
> This working group will develop mechanisms for domain operators to  
> present bindings between names within their control and public keys,  
> in such a way that these bindings can be integrity-protected (and thus  
> shown to be authentically from the domain operator) using DNSSEC and  
> used as a basis for authentication in protocols that use domain names  
> as identifiers.  The group may also specify updates or clarifications  
> to protocols to describe how protocol entities discover and validate  
> these bindings in the execution of specific applications.
> 
> ---------------------------
> 
> I have attempted to pull bits from various people suggestions, and  
> this is a compromise -- I don't expect anyone to love it, but I hope  
> that it at least acceptable to most. I'm hoping that we can keep this  
> discussion on topic....
> 
> Whether or not this ends up being considered as a charter for a  
> possible WG is not important, what is is that we have some rough idea  
> of what we think we are hoping to accomplish...
> 
> 
> W
> 
> Below are the provided texts that I mainly pulled from (and then  
> massaged to try and remove the point ends).
> 
> --------------
> Ondrej Sury (apologies for pure ASCII munging) and myself had written  
> the original draft proposed charter as:
> ----
> Problem Statement:
> 
> The DNS Security Extensions are a collection of resource records and  
> protocol modifications that provide source authentication for the DNS.
> 
> The DNSSEC signed root infrastructure provides a single, well  
> published trust-anchor and a method to build a chain of trust from an  
> individual resource record (RR)  to that TA. By leveraging this  
> infrastructure we can securely bind information (such as a public key,  
> certificate identifier, etc) to a DNS name.
> 
> Increasingly people would like to be able to take advantage of the  
> confidentiality and identity validation provided by protocols such as  
> TLS. There are numerous barriers to this, including cost, ease of use,  
> complexity, certificate management, etc. By allowing users to securely  
> publish public key information we can allow users to easily and  
> securely make use of self-signed certificates.
> 
> Currently, one of the issues limiting the use of self-signed  
> certificates is the difficulty in key-distribution - it is infeasible  
> to distribute a key binding at the web scale. By providing a means to  
> publish (and securely validate) this information in the DNS, we allow  
> for users to attest to the validity of keying information and  
> establish trust in the published public key.
> 
> The DNSSEC root trust anchor can also be used for additional  
> validation during the current path validations. By validating that  
> the  certificate presented is the certificate identified by the DNS,  
> we can provide additional confidence that the client is connecting to  
> the intended server - this helps alleviate concerns that a valid  
> certificate has been obtained by an attacker (for example from a CA  
> not used by the victim).
> -----
> 
> Phillip Hallam-Baker has proposed:
> ----
> Objective:
> 
> Specify mechanisms that allow Internet applications to establish
> cryptographically enhanced communications through use of information
> distributed through the DNS.
> 
> Problem Statement:
> 
> Today the Internet is insecure by default and security is the
> exception. If the security of the Internet is to be improved, security
> must become the default. In particular modern computers have the
> ability to employ cryptographic security enhancements with minimal or
> negligible impact on performance, yet only a tiny proportion of
> Internet traffic is encrypted or authenticated.
> 
> One of the key weaknesses of the current Internet Public Key
> Infrastructure (PKI) is that the most widely used Internet PKI is
> based on the X.500 Directory scheme intended to support an entirely
> different networking infrastructure.
> 
> The naming infrastructure of the Internet is the DNS, not X.500. While
> the PKIX specifications provide a means of mapping X.509v3 attributes
> to DNS names there is currently no widely accepted, generalized means
> of achieving the mapping from DNS names to X.509 certificates in
> particular or to cryptographic keying material in general. DKIM and
> SSH have demonstrated the utility of this approach in specific
> domains, these specifications
> 
> Recent progress in deployment of DNSSEC has renewed focus on the use
> of the DNS naming system to support cryptographic operations. In
> particular:
> 
>  * Discovery of keying material by DNS name
>  * Discovery of security criteria by DNS names
>  * Verification of keying material through DNSSEC trust chains
> 
> Scope:
> 
>  * Use of existing security protocols with DNS established keys
>  * Use of DNS to verify existing certificate / keysigning / security
> assertion material formats
>  * Means of verifying key/certificate chains using DNSSEC exclusively
>  * Means of verifying key/certificate chains using DNSSEC in
> combination with other existing means
> 
> Out-Of-Scope:
> 
> * Reason for choice of specific trust paths
> * New formats for keying material (other than raw keys)
> * New trust architectures (unless they can be expressed in existing  
> formats
> 
> 
> ----
> And Richard L. Barnes has provided:
> Objective:
> 
> Specify mechanisms for Internet applications to use information  
> distributed through the DNS to establish cryptographically assured  
> bindings between domain names and public keys.
> 
> Problem Statement:
> 
> Many Internet applications require protocol entities to authenticate  
> that they represent a certain domain name.  For instance, in HTTPS, a  
> server responding to a query for <https://www.example.com> is expected  
> to authenticate as "www.example.com".  Security protocols such as TLS  
> and IPsec accomplish this authentication by allowing an endpoint to  
> prove ownership of a private key whose corresponding public key is  
> somehow bound to the name being authenticated.  As a pre-requisite for  
> authentication, then, these protocols require a mechanism for bindings  
> to be asserted between public keys and domain names.
> 
> In the past, these bindings have been asserted by parties external to  
> the DNS, using X.509 certificates.  A certification authority (CA) can  
> create certificates that contain a domain name (e.g., as a Common Name  
> or dNSName Subject Alternative Name) and a public key.  When a server  
> presents this certificate and proves ownership of the private key, a  
> relying party that trusts the CA to authenticate domain ownership can  
> be assured that the server legitimately represents the domain.
> 
> One problem with this model is that the CAs that are typically used  
> have no relationship to the DNS infrastructure about which they are  
> making assertions.  Modern browsers and operating systems typically  
> include more than a hundred CAs as trust anchors, any of which can  
> create a certificate for any domain name.
> 
> DNSSEC provides a mechanism for a domain operator to sign DNS  
> information directly, using keys that are bound to the domain by the  
> parent domain; relying parties can continue this chain up to any trust  
> anchor that they accept.  In this way, bindings of keys to domains are  
> asserted not by external entities, but by the entities that operate  
> the DNS.  In addition to providing a more authoritative way of binding  
> DNS names to keys, this technique inherently limits the scope of any  
> given entity to the names in zones he controls.
> 
> This working group will develop mechanisms for domain operators to  
> present bindings between names within their control and public keys,  
> in such a way that these bindings can be integrity-protected (and thus  
> shown to be authentically from the domain operator) using DNSSEC and  
> used as a basis for authentication in protocols that use domain names  
> as identifiers.  The group may also specify updates or clarifications  
> to protocols to describe how protocol entities discover and validate  
> these bindings in the execution of a specific application.
> 
> Note that this working group is specifically focused on bindings  
> between domain names and public keys, rather than bindings between  
> names and other sorts of information.  For example, an X.509  
> certificate can associate many types of information with its subject,  
> including things like IP address holdings and images of logos, as well  
> as bindings to higher-layer identities (e.g., corporate names).   
> Mechanisms developed by this group will not be focused on these  
> additional data, only on public keys.  This basic binding might be  
> used, however, to associate a domain name with rich data by including  
> the same public key in the certificate that is bound to the domain.
> 
> 
> 
> 
> 
> 
> --
> If the bad guys have copies of your MD5 passwords, then you have way  
> bigger problems than the bad guys having copies of your MD5 passwords.
> -- Richard A Steenbergen
> 
> 
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Thu, 26 Aug 2010 11:48:10 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: [keyassure] Does this work need to be "better"? (was: Introducing	draft-josefsson-keyassure-tls-00.txt)

On Wed, Aug 25, 2010 at 07:18:30PM -0400, Stephen Kent wrote:
> one wants to provide via DNS-supplied keys or certs, and why the use of 
> DNS to effect this function is better than extant mechanisms. If we can't 
> clearly articulate this, then it is not clear that a Wg should be 
> created.

I don't see why it has to be "better" than.  Surely "better for some
uses" or "useful alternative in some cases" are enough?

I'm particularly uncomfortable with that "better" because it strikes
me as a way of sneaking in some premises that maybe not everyone will
grant.  For instance, a DNSSEC-based approach is clearly not better
for showing cryptographically some relationship between a given name
and some particular legal entity.  But one can simply set that issue
aside as not relevant for this use, and be agnostic on whether it
makes things "better".

A

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

Date: Thu, 26 Aug 2010 08:54:11 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys

I don't think it is helpful to start bringing in the Security ADs
opinion unless they have stated an opinion. Their concurrence may be a
necessary condition, but certainly not a sufficient one.

You are correct that these are not self signed certificates in the
proposed mode of use. They are actually a CA issued certificate with
signature in the form of a countersignature on the self-signed
certificate prototype.

The zone KSK may be established through a number of different means.

These means are out of scope for this discussion. But one means that
you should probably consider in the context of making BGP security
practical is the case where the DNS zone KSK is signed using an X.509
certificate expressed in a CERT record.

On Wed, Aug 25, 2010 at 7:45 PM, Stephen Kent <[email-masked]> wrote:
> At 4:30 PM -0700 8/25/10, Nicholas Weaver wrote:
>>
>> On Aug 25, 2010, at 4:11 PM, Stephen Kent wrote:
>>
>>> �At 9:59 AM -0700 8/25/10, Nicholas Weaver wrote:
>>>>
>>>> �On Aug 25, 2010, at 9:50 AM, Richard L. Barnes wrote:
>>>> �...
>>>>
>>>> �And is there really a difference? �A "CERT" is simply the key-format
>>>> desired by the application: SSL's CERTs are x509, but the "CERT" for SSH is
>>>> just the bare host key: this seems like a distinction without a difference
>>>> to me.
>>>
>>> �A public key cert is a assertion of a binding between a public key and
>>> �a set of attributes, signed by an entity attesting to the accuracy of
>>> the assertion. This characterization applies to X.509 certs and PGP certs. A
>>> bare key is not a cert. �Let's not confuse terminology.
>>
>> For the purposes of storing records in DNS, is there a relevant
>> distinction?
>> I'd argue "absolutely not", especially since there is such a thing as
>> "Self signed cert": a self signed certificate is really no different from a
>> bare key except for some garbage around it for formatting.
>
> I'd suggest that the SEC ADs will frown upon this cavalier use of
> terminology,
> which is inconsistent with RFC 4949 :-).
>
> A self-signed cert allows the signer to bind attributes to a public key, in
> a fashion that provides a consistency check, even though it does not provide
> a secure basis for authentication the identity of the Issuer/Subject.
>
> Steve
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

From: "Richard L. Barnes" <[email-masked]>
To: Warren Kumari <[email-masked]>
Date: Wed, 25 Aug 2010 21:55:20 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Sample code

Yeah, there's more than a couple of things missing from this example  
(bounds checking, for example!).

With respect to Scott's specific concern, I was thinking that this SSL  
context would only be used for connection in question, in which case  
it's just an issue of semantics: Whether having the cert in the DNS  
means that the host at that name will present exactly that cert or a  
cert subordinate to it.

On Aug 25, 2010, at 9:01 PM, Warren Kumari wrote:

>
> On Aug 25, 2010, at 7:34 PM, Scott Schmit wrote:
>
>> On Mon, Aug 23, 2010 at 04:04:43PM -0400, Richard L. Barnes wrote:
>>>   // If we got a DNSSC-signed CERT record, add it to the SSL CA list
>>>   if (result->secure && result->havedata) {
>>>   	// Read the X509 bytes into an OpenSSL X509 object
>>>   	// Skip 5 bytes of type/tag/algorithm in the rrdata
>>>   	unsigned char *cert_data = (unsigned char*) result->data[0] + 5;
>>>   	int cert_len = result->len[0] - 5;
>>>   	X509* cert = d2i_X509(NULL, cert_data, cert_len);
>>>   	
>>>   	// Mark the cert as a trusted CA cert
>>>   	SSL_add_client_CA(ctx, cert);
>>
>> For what it's worth, depending on the context of this code, this  
>> could
>> be a very bad thing to do. For example, if this is a CA certificate  
>> and
>> another site presents a certificate signed by this one (but without
>> DNSSEC, etc), it will be accepted as valid.
>
> Yes -- I don't think that this was intended to actually be used, but  
> rather just an example of how easily stuff like this <waves hands  
> around> can be done...
>
>>
>> In other words, I don't think you can validate the certificates  
>> from DNS
>> without taking into account the domain they are bound to, or you lose
>> the benefit of this exercise.
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>

Date: Wed, 25 Aug 2010 19:45:23 -0400
To: Nicholas Weaver <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked], Nicholas Weaver <[email-masked]>
Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys

At 4:30 PM -0700 8/25/10, Nicholas Weaver wrote:
>On Aug 25, 2010, at 4:11 PM, Stephen Kent wrote:
>
>>  At 9:59 AM -0700 8/25/10, Nicholas Weaver wrote:
>>>  On Aug 25, 2010, at 9:50 AM, Richard L. Barnes wrote:
>>>  ...
>>>
>>>  And is there really a difference?  A "CERT" is simply the 
>>>key-format desired by the application: SSL's CERTs are x509, but 
>>>the "CERT" for SSH is just the bare host key: this seems like a 
>>>distinction without a difference to me.
>>
>>  A public key cert is a assertion of a binding between a public key and
>>  a set of attributes, signed by an entity attesting to the accuracy 
>>of the assertion. This characterization applies to X.509 certs and 
>>PGP certs. A bare key is not a cert.  Let's not confuse terminology.
>
>For the purposes of storing records in DNS, is there a relevant distinction? 
>
>I'd argue "absolutely not", especially since there is such a thing 
>as "Self signed cert": a self signed certificate is really no 
>different from a bare key except for some garbage around it for 
>formatting.

I'd suggest that the SEC ADs will frown upon this cavalier use of terminology,
which is inconsistent with RFC 4949 :-).

A self-signed cert allows the signer to bind attributes to a public key, in
a fashion that provides a consistency check, even though it does not 
provide a secure basis for authentication the identity of the 
Issuer/Subject.

Steve

From: Warren Kumari <[email-masked]>
Date: Wed, 25 Aug 2010 21:01:11 -0400
To: Scott Schmit <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Sample code

On Aug 25, 2010, at 7:34 PM, Scott Schmit wrote:

> On Mon, Aug 23, 2010 at 04:04:43PM -0400, Richard L. Barnes wrote:
>>    // If we got a DNSSC-signed CERT record, add it to the SSL CA list
>>    if (result->secure && result->havedata) {
>>    	// Read the X509 bytes into an OpenSSL X509 object
>>    	// Skip 5 bytes of type/tag/algorithm in the rrdata
>>    	unsigned char *cert_data = (unsigned char*) result->data[0] + 5;
>>    	int cert_len = result->len[0] - 5;
>>    	X509* cert = d2i_X509(NULL, cert_data, cert_len);
>>    	
>>    	// Mark the cert as a trusted CA cert
>>    	SSL_add_client_CA(ctx, cert);
> 
> For what it's worth, depending on the context of this code, this could
> be a very bad thing to do. For example, if this is a CA certificate and
> another site presents a certificate signed by this one (but without
> DNSSEC, etc), it will be accepted as valid.

Yes -- I don't think that this was intended to actually be used, but rather just an example of how easily stuff like this <waves hands around> can be done... 

> 
> In other words, I don't think you can validate the certificates from DNS
> without taking into account the domain they are bound to, or you lose
> the benefit of this exercise.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Wed, 25 Aug 2010 19:53:58 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys

Precedent is already set on that one.

CERT allows storage of raw keys.

On Wed, Aug 25, 2010 at 7:11 PM, Stephen Kent <[email-masked]> wrote:
> At 9:59 AM -0700 8/25/10, Nicholas Weaver wrote:
>>
>> On Aug 25, 2010, at 9:50 AM, Richard L. Barnes wrote:
>> ...
>>
>> And is there really a difference? �A "CERT" is simply the key-format
>> desired by the application: SSL's CERTs are x509, but the "CERT" for SSH is
>> just the bare host key: this seems like a distinction without a difference
>> to me.
>
> A public key cert is a assertion of a binding between a public key and
> a set of attributes, signed by an entity attesting to the accuracy of the
> assertion. This characterization applies to X.509 certs and PGP certs. A
> bare key is not a cert. �Let's not confuse terminology.
>
> Steve
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Wed, 25 Aug 2010 19:34:02 -0400
From: Scott Schmit <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Sample code

On Mon, Aug 23, 2010 at 04:04:43PM -0400, Richard L. Barnes wrote:
>     // If we got a DNSSC-signed CERT record, add it to the SSL CA list
>     if (result->secure && result->havedata) {
>     	// Read the X509 bytes into an OpenSSL X509 object
>     	// Skip 5 bytes of type/tag/algorithm in the rrdata
>     	unsigned char *cert_data = (unsigned char*) result->data[0] + 5;
>     	int cert_len = result->len[0] - 5;
>     	X509* cert = d2i_X509(NULL, cert_data, cert_len);
>     	
>     	// Mark the cert as a trusted CA cert
>     	SSL_add_client_CA(ctx, cert);

For what it's worth, depending on the context of this code, this could
be a very bad thing to do. For example, if this is a CA certificate and
another site presents a certificate signed by this one (but without
DNSSEC, etc), it will be accepted as valid.

In other words, I don't think you can validate the certificates from DNS
without taking into account the domain they are bound to, or you lose
the benefit of this exercise.

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Wed, 25 Aug 2010 16:30:30 -0700
To: Stephen Kent <[email-masked]>
Cc: [email-masked], Nicholas Weaver <[email-masked]>
Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys

On Aug 25, 2010, at 4:11 PM, Stephen Kent wrote:

> At 9:59 AM -0700 8/25/10, Nicholas Weaver wrote:
>> On Aug 25, 2010, at 9:50 AM, Richard L. Barnes wrote:
>> ...
>> 
>> And is there really a difference?  A "CERT" is simply the key-format desired by the application: SSL's CERTs are x509, but the "CERT" for SSH is just the bare host key: this seems like a distinction without a difference to me.
> 
> A public key cert is a assertion of a binding between a public key and
> a set of attributes, signed by an entity attesting to the accuracy of the assertion. This characterization applies to X.509 certs and PGP certs. A bare key is not a cert.  Let's not confuse terminology.

For the purposes of storing records in DNS, is there a relevant distinction?  

I'd argue "absolutely not", especially since there is such a thing as "Self signed cert": a self signed certificate is really no different from a bare key except for some garbage around it for formatting.

Date: Wed, 25 Aug 2010 19:18:30 -0400
To: Simon Josefsson <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked], Nicholas Weaver <[email-masked]>
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

At 10:20 PM +0200 8/25/10, Simon Josefsson wrote:
>...
>I think it is important to shift the focus from how the wire syntax
>should look like to how we really want this to be used and what
>properties we think are important.  The wire syntax is the simple part.
>
>/Simon

I agree. It's critical to have a very clear characterization of what functions
one wants to provide via DNS-supplied keys or certs, and why the use 
of DNS to effect this function is better than extant mechanisms. If 
we can't clearly articulate this, then it is not clear that a Wg 
should be created.

Steve

Date: Wed, 25 Aug 2010 19:11:11 -0400
To: Nicholas Weaver <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys

At 9:59 AM -0700 8/25/10, Nicholas Weaver wrote:
>On Aug 25, 2010, at 9:50 AM, Richard L. Barnes wrote:
>...
>
>And is there really a difference?  A "CERT" is simply the key-format 
>desired by the application: SSL's CERTs are x509, but the "CERT" for 
>SSH is just the bare host key: this seems like a distinction without 
>a difference to me.

A public key cert is a assertion of a binding between a public key and
a set of attributes, signed by an entity attesting to the accuracy of 
the assertion. This characterization applies to X.509 certs and PGP 
certs. A bare key is not a cert.  Let's not confuse terminology.

Steve

From: "Richard L. Barnes" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Aug 2010 18:22:53 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

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

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

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

> TLS and most other security protocols already have mechanisms for that
> type of parameter negotiation. Provided the credentials supplied are
> trustworthy, the negotiation mechanism is sufficient to prevent an
> in-protocol downgrade attack (e.g. use of md5in place of SHA256).
>
> The problem is that we do not have a mechanism for preventing
> downgrade attack on the security protocol as a whole. We can stop the
> use of substandard SSL but can't ensure that SSL is used at all.
>
> On Wed, Aug 25, 2010 at 5:54 PM, Richard L. Barnes <[email-masked]>  
> wrote:
>> Works for me.  I was going to suggest the slightly more compact  
>> phrase
>> "authenticating services identified by domain name".
>>
>> FWIW, what I meant by the "negotiating crypto parameters" was  
>> something
>> quite different, questions like "what cipher suite shall we use?",  
>> which
>> aren't what we're talking about, but could also be construed as  
>> helping
>> applications establish secure comms.
>>
>>
>>
>> On Aug 25, 2010, at 5:49 PM, Andrew Sullivan wrote:
>>
>>> On Wed, Aug 25, 2010 at 02:35:43PM -0700, Nicholas Weaver wrote:
>>>>
>>>> Why not "discovering and authenticating cryptographic material  
>>>> which is
>>>> associated with a service located at a domain name"?
>>>>
>>>
>>> Sure, that sounds right to me.
>>>
>>> A
>>>
>>> --
>>> Andrew Sullivan
>>> [email-masked]
>>> Shinkuro, Inc.
>>> _______________________________________________
>>> 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/

Date: Wed, 25 Aug 2010 18:14:43 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

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

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

On Wed, Aug 25, 2010 at 5:54 PM, Richard L. Barnes <[email-masked]> wrote:
> Works for me. �I was going to suggest the slightly more compact phrase
> "authenticating services identified by domain name".
>
> FWIW, what I meant by the "negotiating crypto parameters" was something
> quite different, questions like "what cipher suite shall we use?", which
> aren't what we're talking about, but could also be construed as helping
> applications establish secure comms.
>
>
>
> On Aug 25, 2010, at 5:49 PM, Andrew Sullivan wrote:
>
>> On Wed, Aug 25, 2010 at 02:35:43PM -0700, Nicholas Weaver wrote:
>>>
>>> Why not "discovering and authenticating cryptographic material which is
>>> associated with a service located at a domain name"?
>>>
>>
>> Sure, that sounds right to me.
>>
>> A
>>
>> --
>> Andrew Sullivan
>> [email-masked]
>> Shinkuro, Inc.
>> _______________________________________________
>> 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/

Date: Wed, 25 Aug 2010 18:09:57 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

This looks acceptable to me.

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

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

On Wed, Aug 25, 2010 at 4:59 PM, Warren Kumari <[email-masked]> wrote:
> So, a while back we had some discussions about a possible charter for a
> possible working group. This discussion sort of veered off course, so this
> is a new thread, unencumbered by previous grumpiness...
>
> I have tried to distill essence from various folks comments and proposed
> charters and come up with something that we can all (yeah, right!) agree
> on... How do folk feel about the below?
>
> -----------------------------------
> Objective:
>
> Specify mechanisms and techniques that allow Internet applications to
> establish cryptographically secured communications through use of
> information distributed through the DNS.
>
> Problem Statement:
>
> Entities on the Internet are usually identified by domain names and forming
> a cryptographically secured connection to the entity requires the entity to
> authenticate its name. �For instance, in HTTPS, a server responding to a
> query for <https://www.example.com> is expected to authenticate as
> "www.example.com". �Security protocols such as TLS and IPsec accomplish this
> authentication by allowing an endpoint to prove ownership of a private key
> whose corresponding public key is somehow bound to the name being
> authenticated. �As a pre-requisite for authentication, then, these protocols
> require a mechanism for bindings to be asserted between public keys and
> domain names.
>
> DNSSEC provides a mechanism for a domain operator to sign DNS information
> directly, using keys that are bound to the domain by the parent domain;
> relying parties can continue this chain up to any trust anchor that they
> accept. �In this way, bindings of keys to domains are asserted not by
> external entities, but by the entities that operate the DNS. �In addition,
> this technique inherently limits the scope of any given entity to the names
> in zones he controls.
>
> This working group will develop mechanisms for domain operators to present
> bindings between names within their control and public keys, in such a way
> that these bindings can be integrity-protected (and thus shown to be
> authentically from the domain operator) using DNSSEC and used as a basis for
> authentication in protocols that use domain names as identifiers. �The group
> may also specify updates or clarifications to protocols to describe how
> protocol entities discover and validate these bindings in the execution of
> specific applications.
>
> ---------------------------
>
> I have attempted to pull bits from various people suggestions, and this is a
> compromise -- I don't expect anyone to love it, but I hope that it at least
> acceptable to most. I'm hoping that we can keep this discussion on topic....
>
> Whether or not this ends up being considered as a charter for a possible WG
> is not important, what is is that we have some rough idea of what we think
> we are hoping to accomplish...
>
>
> W
>
> Below are the provided texts that I mainly pulled from (and then massaged to
> try and remove the point ends).
>
> --------------
> Ondrej Sury (apologies for pure ASCII munging) and myself had written the
> original draft proposed charter as:
> ----
> Problem Statement:
>
> The DNS Security Extensions are a collection of resource records and
> protocol modifications that provide source authentication for the DNS.
>
> The DNSSEC signed root infrastructure provides a single, well published
> trust-anchor and a method to build a chain of trust from an individual
> resource record (RR) �to that TA. By leveraging this infrastructure we can
> securely bind information (such as a public key, certificate identifier,
> etc) to a DNS name.
>
> Increasingly people would like to be able to take advantage of the
> confidentiality and identity validation provided by protocols such as TLS.
> There are numerous barriers to this, including cost, ease of use,
> complexity, certificate management, etc. By allowing users to securely
> publish public key information we can allow users to easily and securely
> make use of self-signed certificates.
>
> Currently, one of the issues limiting the use of self-signed certificates is
> the difficulty in key-distribution - it is infeasible to distribute a key
> binding at the web scale. By providing a means to publish (and securely
> validate) this information in the DNS, we allow for users to attest to the
> validity of keying information and establish trust in the published public
> key.
>
> The DNSSEC root trust anchor can also be used for additional validation
> during the current path validations. By validating that the �certificate
> presented is the certificate identified by the DNS, we can provide
> additional confidence that the client is connecting to the intended server -
> this helps alleviate concerns that a valid certificate has been obtained by
> an attacker (for example from a CA not used by the victim).
> -----
>
> Phillip Hallam-Baker has proposed:
> ----
> Objective:
>
> Specify mechanisms that allow Internet applications to establish
> cryptographically enhanced communications through use of information
> distributed through the DNS.
>
> Problem Statement:
>
> Today the Internet is insecure by default and security is the
> exception. If the security of the Internet is to be improved, security
> must become the default. In particular modern computers have the
> ability to employ cryptographic security enhancements with minimal or
> negligible impact on performance, yet only a tiny proportion of
> Internet traffic is encrypted or authenticated.
>
> One of the key weaknesses of the current Internet Public Key
> Infrastructure (PKI) is that the most widely used Internet PKI is
> based on the X.500 Directory scheme intended to support an entirely
> different networking infrastructure.
>
> The naming infrastructure of the Internet is the DNS, not X.500. While
> the PKIX specifications provide a means of mapping X.509v3 attributes
> to DNS names there is currently no widely accepted, generalized means
> of achieving the mapping from DNS names to X.509 certificates in
> particular or to cryptographic keying material in general. DKIM and
> SSH have demonstrated the utility of this approach in specific
> domains, these specifications
>
> Recent progress in deployment of DNSSEC has renewed focus on the use
> of the DNS naming system to support cryptographic operations. In
> particular:
>
> �* Discovery of keying material by DNS name
> �* Discovery of security criteria by DNS names
> �* Verification of keying material through DNSSEC trust chains
>
> Scope:
>
> �* Use of existing security protocols with DNS established keys
> �* Use of DNS to verify existing certificate / keysigning / security
> assertion material formats
> �* Means of verifying key/certificate chains using DNSSEC exclusively
> �* Means of verifying key/certificate chains using DNSSEC in
> combination with other existing means
>
> Out-Of-Scope:
>
> * Reason for choice of specific trust paths
> * New formats for keying material (other than raw keys)
> * New trust architectures (unless they can be expressed in existing formats
>
>
> ----
> And Richard L. Barnes has provided:
> Objective:
>
> Specify mechanisms for Internet applications to use information distributed
> through the DNS to establish cryptographically assured bindings between
> domain names and public keys.
>
> Problem Statement:
>
> Many Internet applications require protocol entities to authenticate that
> they represent a certain domain name. �For instance, in HTTPS, a server
> responding to a query for <https://www.example.com> is expected to
> authenticate as "www.example.com". �Security protocols such as TLS and IPsec
> accomplish this authentication by allowing an endpoint to prove ownership of
> a private key whose corresponding public key is somehow bound to the name
> being authenticated. �As a pre-requisite for authentication, then, these
> protocols require a mechanism for bindings to be asserted between public
> keys and domain names.
>
> In the past, these bindings have been asserted by parties external to the
> DNS, using X.509 certificates. �A certification authority (CA) can create
> certificates that contain a domain name (e.g., as a Common Name or dNSName
> Subject Alternative Name) and a public key. �When a server presents this
> certificate and proves ownership of the private key, a relying party that
> trusts the CA to authenticate domain ownership can be assured that the
> server legitimately represents the domain.
>
> One problem with this model is that the CAs that are typically used have no
> relationship to the DNS infrastructure about which they are making
> assertions. �Modern browsers and operating systems typically include more
> than a hundred CAs as trust anchors, any of which can create a certificate
> for any domain name.
>
> DNSSEC provides a mechanism for a domain operator to sign DNS information
> directly, using keys that are bound to the domain by the parent domain;
> relying parties can continue this chain up to any trust anchor that they
> accept. �In this way, bindings of keys to domains are asserted not by
> external entities, but by the entities that operate the DNS. �In addition to
> providing a more authoritative way of binding DNS names to keys, this
> technique inherently limits the scope of any given entity to the names in
> zones he controls.
>
> This working group will develop mechanisms for domain operators to present
> bindings between names within their control and public keys, in such a way
> that these bindings can be integrity-protected (and thus shown to be
> authentically from the domain operator) using DNSSEC and used as a basis for
> authentication in protocols that use domain names as identifiers. �The group
> may also specify updates or clarifications to protocols to describe how
> protocol entities discover and validate these bindings in the execution of a
> specific application.
>
> Note that this working group is specifically focused on bindings between
> domain names and public keys, rather than bindings between names and other
> sorts of information. �For example, an X.509 certificate can associate many
> types of information with its subject, including things like IP address
> holdings and images of logos, as well as bindings to higher-layer identities
> (e.g., corporate names). �Mechanisms developed by this group will not be
> focused on these additional data, only on public keys. �This basic binding
> might be used, however, to associate a domain name with rich data by
> including the same public key in the certificate that is bound to the
> domain.
>
>
>
>
>
>
> --
> If the bad guys have copies of your MD5 passwords, then you have way bigger
> problems than the bad guys having copies of your MD5 passwords.
> -- Richard A Steenbergen
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Wed, 25 Aug 2010 14:56:42 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: Nicholas Weaver <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 25, 2010, at 2:47 PM, Phillip Hallam-Baker wrote:

> On Wed, Aug 25, 2010 at 4:56 PM, Nicholas Weaver
> <[email-masked]> wrote:
>> 
>> On Aug 25, 2010, at 1:47 PM, Phillip Hallam-Baker wrote:
>> 
>>> I agree with the principle but would like to change the emphasis:
>>> 
>>> First we need to decide what information we need to carry in DNS.
>>> 
>>> AFTER we have done that we can decide if CERT matches those needs.
>>> 
>>> 
>>> What I do not want to do is look at the CERT record and work out how
>>> we can apply it to our problem. It is quite likely it does not fit.
>> 
>> For carrying data as an authenticated unit ("this BLOB OF BITS is authenticated by DNSSEC"), CERT is just fine: it accomplishes everything thats needed: its extensible, the application's job is to treat it as appropriate, and DNS sees just a binary blob.
>> 
>> Whats needed would be APIs and conventions to allow applications to use that result.
>> 
>> 
>> For carrying data only as a partially-authenticated blob ("this BLOB OF BITS is authenticated by DNSSEC, but you should only rely on X, Y, Z components"), yeah, that would probably be best with a new RR, or an ancillary RR to a CERT record.  BUT, and this is a big BUT, shouldn't the application know that it should only rely on X, Y, and Z?
> 
> I agree! That is not the type of additional information I was considering.
> 
> I want to digest the cert, the whole cert and nothing but the cert.
> 
> 
> I was considering information of the type 'only use this with specific
> protocols'.

I don't think that really needs a new RR, but perhaps a naming convention?  EG

_ssh.myhost.mydomain.com -> SSH public key
_ssl.myhost.mydomain.com -> x509 certificate for SSL
_auth_smtp.myhost...     -> x509 certificate for authenticated SMTP
_port_2121.myhost        -> the SSH public key for connecting on port 2121

???

You need something like that anyway just to prevent spmaming too big a results chain back?

From: "Richard L. Barnes" <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Date: Wed, 25 Aug 2010 17:54:48 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

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

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

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

> On Wed, Aug 25, 2010 at 02:35:43PM -0700, Nicholas Weaver wrote:
>>
>> Why not "discovering and authenticating cryptographic material  
>> which is associated with a service located at a domain name"?
>>
>
> Sure, that sounds right to me.
>
> A
>
> -- 
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Wed, 25 Aug 2010 17:49:34 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

On Wed, Aug 25, 2010 at 02:35:43PM -0700, Nicholas Weaver wrote:
> 
> Why not "discovering and authenticating cryptographic material which is associated with a service located at a domain name"?
> 

Sure, that sounds right to me.

A

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

Date: Wed, 25 Aug 2010 17:47:20 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Nicholas Weaver <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Wed, Aug 25, 2010 at 4:56 PM, Nicholas Weaver
<[email-masked]> wrote:
>
> On Aug 25, 2010, at 1:47 PM, Phillip Hallam-Baker wrote:
>
>> I agree with the principle but would like to change the emphasis:
>>
>> First we need to decide what information we need to carry in DNS.
>>
>> AFTER we have done that we can decide if CERT matches those needs.
>>
>>
>> What I do not want to do is look at the CERT record and work out how
>> we can apply it to our problem. It is quite likely it does not fit.
>
> For carrying data as an authenticated unit ("this BLOB OF BITS is authenticated by DNSSEC"), CERT is just fine: it accomplishes everything thats needed: its extensible, the application's job is to treat it as appropriate, and DNS sees just a binary blob.
>
> Whats needed would be APIs and conventions to allow applications to use that result.
>
>
> For carrying data only as a partially-authenticated blob ("this BLOB OF BITS is authenticated by DNSSEC, but you should only rely on X, Y, Z components"), yeah, that would probably be best with a new RR, or an ancillary RR to a CERT record. �BUT, and this is a big BUT, shouldn't the application know that it should only rely on X, Y, and Z?

I agree! That is not the type of additional information I was considering.

I want to digest the cert, the whole cert and nothing but the cert.

I was considering information of the type 'only use this with specific
protocols'.

Now one way out of this might well be to consider that the exact same
issue already exists in X.509v3 certs and a CA has to consider the
fact when they sign the certificate.

So one approach would be to require the party inserting the cert into
the zone to consider whether all the asserted purposes are acceptable
to them.

I am not trying to be a PITA on this. This is cutting through a lot of
PKIX and TLS work and in addition to the specifications we have to
consider there is also a body of 'lore' - i.e. deployed legacy stuff.

It may actually be safer to use keyassure to assure CA certs that are
then used to authenticate the end entity certs. We know how to do
that.

Then you want to put the whole CA cert in the CERT record.

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

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Wed, 25 Aug 2010 14:35:43 -0700
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

On Aug 25, 2010, at 2:30 PM, Andrew Sullivan wrote:

> On Wed, Aug 25, 2010 at 05:14:59PM -0400, Richard L. Barnes wrote:
>> I would prefer the Objective be tightened a little to focus on  
>> authenticating domain names, as opposed to, say, negotiating crypto  
> 
> What do you mwan "authenticating"?  If what you want to do is ensure
> yourself that you're actually going to the right address, you can do
> that now.  That's all DNSSEC does.

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

> 
> I think the goal here is to make sure that the certificate you're
> using is the right one for the service you're trying to talk to.  The
> traditional way to do that is already well-defined.  The current work
> is aimed at providing an alternate way to do that, using the
> assurances you can get from the DNS (using DNSSEC).  So I think the
> talk of "negotiating crypto parameters" and such is about right.
> 
> A
> 
> -- 
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Wed, 25 Aug 2010 17:30:56 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

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

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

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

A

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

From: "Richard L. Barnes" <[email-masked]>
To: Warren Kumari <[email-masked]>
Date: Wed, 25 Aug 2010 17:14:59 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

Best attempt so far!

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

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

> So, a while back we had some discussions about a possible charter  
> for a possible working group. This discussion sort of veered off  
> course, so this is a new thread, unencumbered by previous  
> grumpiness...
>
> I have tried to distill essence from various folks comments and  
> proposed charters and come up with something that we can all (yeah,  
> right!) agree on... How do folk feel about the below?
>
> -----------------------------------
> Objective:
>
> Specify mechanisms and techniques that allow Internet applications  
> to establish cryptographically secured communications through use of  
> information distributed through the DNS.
>
> Problem Statement:
>
> Entities on the Internet are usually identified by domain names and  
> forming a cryptographically secured connection to the entity  
> requires the entity to authenticate its name.  For instance, in  
> HTTPS, a server responding to a query for <https://www.example.com>  
> is expected to authenticate as "www.example.com".  Security  
> protocols such as TLS and IPsec accomplish this authentication by  
> allowing an endpoint to prove ownership of a private key whose  
> corresponding public key is somehow bound to the name being  
> authenticated.  As a pre-requisite for authentication, then, these  
> protocols require a mechanism for bindings to be asserted between  
> public keys and domain names.
>
> DNSSEC provides a mechanism for a domain operator to sign DNS  
> information directly, using keys that are bound to the domain by the  
> parent domain; relying parties can continue this chain up to any  
> trust anchor that they accept.  In this way, bindings of keys to  
> domains are asserted not by external entities, but by the entities  
> that operate the DNS.  In addition, this technique inherently limits  
> the scope of any given entity to the names in zones he controls.
>
> This working group will develop mechanisms for domain operators to  
> present bindings between names within their control and public keys,  
> in such a way that these bindings can be integrity-protected (and  
> thus shown to be authentically from the domain operator) using  
> DNSSEC and used as a basis for authentication in protocols that use  
> domain names as identifiers.  The group may also specify updates or  
> clarifications to protocols to describe how protocol entities  
> discover and validate these bindings in the execution of specific  
> applications.
>
> ---------------------------
>
> I have attempted to pull bits from various people suggestions, and  
> this is a compromise -- I don't expect anyone to love it, but I hope  
> that it at least acceptable to most. I'm hoping that we can keep  
> this discussion on topic....
>
> Whether or not this ends up being considered as a charter for a  
> possible WG is not important, what is is that we have some rough  
> idea of what we think we are hoping to accomplish...
>
>
> W
>
> Below are the provided texts that I mainly pulled from (and then  
> massaged to try and remove the point ends).
>
> --------------
> Ondrej Sury (apologies for pure ASCII munging) and myself had  
> written the original draft proposed charter as:
> ----
> Problem Statement:
>
> The DNS Security Extensions are a collection of resource records and  
> protocol modifications that provide source authentication for the DNS.
>
> The DNSSEC signed root infrastructure provides a single, well  
> published trust-anchor and a method to build a chain of trust from  
> an individual resource record (RR)  to that TA. By leveraging this  
> infrastructure we can securely bind information (such as a public  
> key, certificate identifier, etc) to a DNS name.
>
> Increasingly people would like to be able to take advantage of the  
> confidentiality and identity validation provided by protocols such  
> as TLS. There are numerous barriers to this, including cost, ease of  
> use, complexity, certificate management, etc. By allowing users to  
> securely publish public key information we can allow users to easily  
> and securely make use of self-signed certificates.
>
> Currently, one of the issues limiting the use of self-signed  
> certificates is the difficulty in key-distribution - it is  
> infeasible to distribute a key binding at the web scale. By  
> providing a means to publish (and securely validate) this  
> information in the DNS, we allow for users to attest to the validity  
> of keying information and establish trust in the published public key.
>
> The DNSSEC root trust anchor can also be used for additional  
> validation during the current path validations. By validating that  
> the  certificate presented is the certificate identified by the DNS,  
> we can provide additional confidence that the client is connecting  
> to the intended server - this helps alleviate concerns that a valid  
> certificate has been obtained by an attacker (for example from a CA  
> not used by the victim).
> -----
>
> Phillip Hallam-Baker has proposed:
> ----
> Objective:
>
> Specify mechanisms that allow Internet applications to establish
> cryptographically enhanced communications through use of information
> distributed through the DNS.
>
> Problem Statement:
>
> Today the Internet is insecure by default and security is the
> exception. If the security of the Internet is to be improved, security
> must become the default. In particular modern computers have the
> ability to employ cryptographic security enhancements with minimal or
> negligible impact on performance, yet only a tiny proportion of
> Internet traffic is encrypted or authenticated.
>
> One of the key weaknesses of the current Internet Public Key
> Infrastructure (PKI) is that the most widely used Internet PKI is
> based on the X.500 Directory scheme intended to support an entirely
> different networking infrastructure.
>
> The naming infrastructure of the Internet is the DNS, not X.500. While
> the PKIX specifications provide a means of mapping X.509v3 attributes
> to DNS names there is currently no widely accepted, generalized means
> of achieving the mapping from DNS names to X.509 certificates in
> particular or to cryptographic keying material in general. DKIM and
> SSH have demonstrated the utility of this approach in specific
> domains, these specifications
>
> Recent progress in deployment of DNSSEC has renewed focus on the use
> of the DNS naming system to support cryptographic operations. In
> particular:
>
> * Discovery of keying material by DNS name
> * Discovery of security criteria by DNS names
> * Verification of keying material through DNSSEC trust chains
>
> Scope:
>
> * Use of existing security protocols with DNS established keys
> * Use of DNS to verify existing certificate / keysigning / security
> assertion material formats
> * Means of verifying key/certificate chains using DNSSEC exclusively
> * Means of verifying key/certificate chains using DNSSEC in
> combination with other existing means
>
> Out-Of-Scope:
>
> * Reason for choice of specific trust paths
> * New formats for keying material (other than raw keys)
> * New trust architectures (unless they can be expressed in existing  
> formats
>
>
> ----
> And Richard L. Barnes has provided:
> Objective:
>
> Specify mechanisms for Internet applications to use information  
> distributed through the DNS to establish cryptographically assured  
> bindings between domain names and public keys.
>
> Problem Statement:
>
> Many Internet applications require protocol entities to authenticate  
> that they represent a certain domain name.  For instance, in HTTPS,  
> a server responding to a query for <https://www.example.com> is  
> expected to authenticate as "www.example.com".  Security protocols  
> such as TLS and IPsec accomplish this authentication by allowing an  
> endpoint to prove ownership of a private key whose corresponding  
> public key is somehow bound to the name being authenticated.  As a  
> pre-requisite for authentication, then, these protocols require a  
> mechanism for bindings to be asserted between public keys and domain  
> names.
>
> In the past, these bindings have been asserted by parties external  
> to the DNS, using X.509 certificates.  A certification authority  
> (CA) can create certificates that contain a domain name (e.g., as a  
> Common Name or dNSName Subject Alternative Name) and a public key.   
> When a server presents this certificate and proves ownership of the  
> private key, a relying party that trusts the CA to authenticate  
> domain ownership can be assured that the server legitimately  
> represents the domain.
>
> One problem with this model is that the CAs that are typically used  
> have no relationship to the DNS infrastructure about which they are  
> making assertions.  Modern browsers and operating systems typically  
> include more than a hundred CAs as trust anchors, any of which can  
> create a certificate for any domain name.
>
> DNSSEC provides a mechanism for a domain operator to sign DNS  
> information directly, using keys that are bound to the domain by the  
> parent domain; relying parties can continue this chain up to any  
> trust anchor that they accept.  In this way, bindings of keys to  
> domains are asserted not by external entities, but by the entities  
> that operate the DNS.  In addition to providing a more authoritative  
> way of binding DNS names to keys, this technique inherently limits  
> the scope of any given entity to the names in zones he controls.
>
> This working group will develop mechanisms for domain operators to  
> present bindings between names within their control and public keys,  
> in such a way that these bindings can be integrity-protected (and  
> thus shown to be authentically from the domain operator) using  
> DNSSEC and used as a basis for authentication in protocols that use  
> domain names as identifiers.  The group may also specify updates or  
> clarifications to protocols to describe how protocol entities  
> discover and validate these bindings in the execution of a specific  
> application.
>
> Note that this working group is specifically focused on bindings  
> between domain names and public keys, rather than bindings between  
> names and other sorts of information.  For example, an X.509  
> certificate can associate many types of information with its  
> subject, including things like IP address holdings and images of  
> logos, as well as bindings to higher-layer identities (e.g.,  
> corporate names).  Mechanisms developed by this group will not be  
> focused on these additional data, only on public keys.  This basic  
> binding might be used, however, to associate a domain name with rich  
> data by including the same public key in the certificate that is  
> bound to the domain.
>
>
>
>
>
>
> --
> If the bad guys have copies of your MD5 passwords, then you have way  
> bigger problems than the bad guys having copies of your MD5 passwords.
> -- Richard A Steenbergen
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Wed, 25 Aug 2010 17:05:56 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Poking the charter bear....

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

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

A

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

From: Warren Kumari <[email-masked]>
To: [email-masked]
Date: Wed, 25 Aug 2010 16:59:01 -0400
Subject: [keyassure] Poking the charter bear....

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

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

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

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

Problem Statement:

Entities on the Internet are usually identified by domain names and  
forming a cryptographically secured connection to the entity requires  
the entity to authenticate its name.  For instance, in HTTPS, a server  
responding to a query for <https://www.example.com> is expected to  
authenticate as "www.example.com".  Security protocols such as TLS and  
IPsec accomplish this authentication by allowing an endpoint to prove  
ownership of a private key whose corresponding public key is somehow  
bound to the name being authenticated.  As a pre-requisite for  
authentication, then, these protocols require a mechanism for bindings  
to be asserted between public keys and domain names.

DNSSEC provides a mechanism for a domain operator to sign DNS  
information directly, using keys that are bound to the domain by the  
parent domain; relying parties can continue this chain up to any trust  
anchor that they accept.  In this way, bindings of keys to domains are  
asserted not by external entities, but by the entities that operate  
the DNS.  In addition, this technique inherently limits the scope of  
any given entity to the names in zones he controls.

This working group will develop mechanisms for domain operators to  
present bindings between names within their control and public keys,  
in such a way that these bindings can be integrity-protected (and thus  
shown to be authentically from the domain operator) using DNSSEC and  
used as a basis for authentication in protocols that use domain names  
as identifiers.  The group may also specify updates or clarifications  
to protocols to describe how protocol entities discover and validate  
these bindings in the execution of specific applications.

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

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

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

W

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

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

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

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

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

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

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

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

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

Problem Statement:

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

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

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

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

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

Scope:

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

Out-Of-Scope:

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

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

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

Problem Statement:

Many Internet applications require protocol entities to authenticate  
that they represent a certain domain name.  For instance, in HTTPS, a  
server responding to a query for <https://www.example.com> is expected  
to authenticate as "www.example.com".  Security protocols such as TLS  
and IPsec accomplish this authentication by allowing an endpoint to  
prove ownership of a private key whose corresponding public key is  
somehow bound to the name being authenticated.  As a pre-requisite for  
authentication, then, these protocols require a mechanism for bindings  
to be asserted between public keys and domain names.

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

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

DNSSEC provides a mechanism for a domain operator to sign DNS  
information directly, using keys that are bound to the domain by the  
parent domain; relying parties can continue this chain up to any trust  
anchor that they accept.  In this way, bindings of keys to domains are  
asserted not by external entities, but by the entities that operate  
the DNS.  In addition to providing a more authoritative way of binding  
DNS names to keys, this technique inherently limits the scope of any  
given entity to the names in zones he controls.

This working group will develop mechanisms for domain operators to  
present bindings between names within their control and public keys,  
in such a way that these bindings can be integrity-protected (and thus  
shown to be authentically from the domain operator) using DNSSEC and  
used as a basis for authentication in protocols that use domain names  
as identifiers.  The group may also specify updates or clarifications  
to protocols to describe how protocol entities discover and validate  
these bindings in the execution of a specific application.

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

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

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Wed, 25 Aug 2010 13:56:10 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: Nicholas Weaver <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 25, 2010, at 1:47 PM, Phillip Hallam-Baker wrote:

> I agree with the principle but would like to change the emphasis:
> 
> First we need to decide what information we need to carry in DNS.
> 
> AFTER we have done that we can decide if CERT matches those needs.
> 
> 
> What I do not want to do is look at the CERT record and work out how
> we can apply it to our problem. It is quite likely it does not fit.

For carrying data as an authenticated unit ("this BLOB OF BITS is authenticated by DNSSEC"), CERT is just fine: it accomplishes everything thats needed: its extensible, the application's job is to treat it as appropriate, and DNS sees just a binary blob.

Whats needed would be APIs and conventions to allow applications to use that result.

For carrying data only as a partially-authenticated blob ("this BLOB OF BITS is authenticated by DNSSEC, but you should only rely on X, Y, Z components"), yeah, that would probably be best with a new RR, or an ancillary RR to a CERT record.  BUT, and this is a big BUT, shouldn't the application know that it should only rely on X, Y, and Z?

Date: Wed, 25 Aug 2010 16:47:54 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

I agree with the principle but would like to change the emphasis:

First we need to decide what information we need to carry in DNS.

AFTER we have done that we can decide if CERT matches those needs.

What I do not want to do is look at the CERT record and work out how
we can apply it to our problem. It is quite likely it does not fit.

On Wed, Aug 25, 2010 at 4:20 PM, Simon Josefsson <[email-masked]> wrote:
> Nicholas Weaver <[email-masked]> writes:
>
>>> I thought this group was to work on a good standard for those
>>> applications, and that those who want to use certs, can stick with using
>>> RFC 4398 (or non-DNS based validation, eg EVR)
>>
>> In many ways, I somewhat agree, but for a different reason: CERT RRs
>> are just a perfectly fine container class. �We probably don't need new
>> RR types.
>>
>> What we need is ways of using such container classes with DNSSEC: this
>> doesn't add any new to-the-wire representatiton, but does require new
>> ways (APIs, naming conventions) of using the DNSSEC data, both at a
>> low level (APIs) and high level ("cookbook recipies").
>
> +1
>
> I think it is important to shift the focus from how the wire syntax
> should look like to how we really want this to be used and what
> properties we think are important. �The wire syntax is the simple part.
>
> /Simon
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

From: Simon Josefsson <[email-masked]>
To: Nicholas Weaver <[email-masked]>
OpenPGP: id�65716F; url=http://josefsson.org/key.txt
Date: Wed, 25 Aug 2010 22:20:43 +0200
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

Nicholas Weaver <[email-masked]> writes:

>> I thought this group was to work on a good standard for those
>> applications, and that those who want to use certs, can stick with using
>> RFC 4398 (or non-DNS based validation, eg EVR)
>
> In many ways, I somewhat agree, but for a different reason: CERT RRs
> are just a perfectly fine container class.  We probably don't need new
> RR types.
>
> What we need is ways of using such container classes with DNSSEC: this
> doesn't add any new to-the-wire representatiton, but does require new
> ways (APIs, naming conventions) of using the DNSSEC data, both at a
> low level (APIs) and high level ("cookbook recipies").

+1

I think it is important to shift the focus from how the wire syntax
should look like to how we really want this to be used and what
properties we think are important.  The wire syntax is the simple part.

/Simon

From: "Richard L. Barnes" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Aug 2010 14:04:14 -0400
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] On eliminating ports

Not talking about delegation here -- the starting assumption is that  
all the services are using the same domain name.  For delegation  
considerations, see [1].

The scenario here is where example.com hosts:
EntityA on http://example.com:44300/
EntityB on http://example.com:44301/

If the server is poorly configured (so that you get (e) as below),  
then unless you can distinguish which cert goes with which port,  
EntityA can provide an EV cert for EntityB without the client noticing.

You might arrive at these port-wise services via an SRV or NAPTR  
record, but those should be authenticated themselves, so that the end  
server can authenticate as itself.  In other words, there are two  
separate authentications going on here:
1. Authenticate delegation record
2. Authenticate remote service
The first one is done with DNSSEC or DNA [1]; the second one is what  
we're doing here.

Again, IMO, this case is deep in the corner, but included for  
completeness.

--Richard

[1] <http://tools.ietf.org/html/draft-barnes-xmpp-dna>

On Aug 25, 2010, at 1:45 PM, Phillip Hallam-Baker wrote:

> The issue of delegation is a difficult one and might well be something
> that ESRV or SRV is used to address.
>
> The discovery of the delegation relationship is going to be discovered
> during service discovery, i.e. before we start the TCP connection or
> SSL tunnel.
>
> If I can sign a DNSSEC zone record to say 'for email service for
> hallambaker.com see gmail.com', then the service can and should expect
> to see an SSL cert presented for gmail.com as opposed to
> hallambaker.com.
>
> One of the issues I am trying to deal with here is the fact that the
> existing mechanism for SSL domain name binding does not work as it
> should.
>
>
> In order to claim that there is a system here it is going to be
> necessary to provide a pretty exhaustive explanation of how this all
> works with Web and with Mail.
>
> On Wed, Aug 25, 2010 at 1:15 PM, Richard L. Barnes <[email-masked]>  
> wrote:
>> I think there's something missing here.  You also run into problems  
>> if (!a
>> && b && c) and:
>>
>> d) The client is making decisions based on certificate attributes  
>> other than
>> domain names
>>
>> e) One service can access another's private key
>>
>> If (!a && b && c && d && e), then one service can present another  
>> service's
>> certificate, influencing client behavior.  You could envision  
>> problems
>> arising from differences in issuer (EV vs. DV).  In some sense,  
>> this isn't a
>> huge issue, since a lot of attributes are effectively the same for  
>> different
>> processes on the same machine, but there are still some trouble  
>> cases.  For
>> example, there are two entities with EV certs on the same server,  
>> with the
>> same domain-name, one service would be able to present the other's  
>> EV cert,
>> and the client would not be able to distinguish.  [1]
>>
>> I'll leave it as an exercise to the reader to determine how  
>> practical this
>> scenario is.  In all candor, I'm mainly including it for  
>> completeness; it
>> doesn't seem like a huge risk to me.
>>
>> --Richard
>>
>>
>> [1] Digression: THe CA/Browser Forum document describing EV certs  
>> says that
>> the domain name field in an EV cert "MUST contain one or more host  
>> domain
>> name(s) owned or controlled by the Subject and to be associated with
>> Subject�s server.  Such server MAY be owned and operated by the  
>> Subject or
>> another entity (e.g., a hosting service)."  This situation would  
>> arise in
>> the latter case, where another entity owns and operates the zone in
>> question.
>>
>>
>>
>> On Aug 25, 2010, at 12:10 PM, Paul Hoffman wrote:
>>
>>> First off, one of the more common criticisms we got on the -00 was  
>>> the
>>> complication of the ports, so this is not clear-cut. Having said  
>>> that, I
>>> believe the *only* situation where specifying the ports in the  
>>> TSLFP CERT
>>> request is valuable is when all the following are true:
>>>
>>> a) There are more than five or so servers on different ports on
>>> server.example.com
>>>
>>> b) Each server uses a different certificate
>>>
>>> c) The users always go to the tuple { dns=server.example.com &&  
>>> port=nnn }
>>>
>>> If (a) and (b) are true but (c) is not, for example if there are  
>>> addional
>>> names such as www.example.com and imap.example.com for the various  
>>> servers,
>>> there is no problem because the user will look up the individual  
>>> name.
>>>
>>> If (a) and (c) are true but (b) is not, there is no problem  
>>> because the
>>> user will get a useful response regardless of the port they go to.
>>>
>>> If (b) and (c) are true but (a) is not, then the client software  
>>> needs
>>> compare the hash of the cert gotten in TLS against a small number  
>>> of hashes.
>>> The only problem here is that the request for the TLSFP CERT RR is  
>>> somewhat
>>> large.
>>>
>>> In what real-world use cases is this a problem?
>>>
>>> --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
>>
>
>
>
> -- 
> Website: http://hallambaker.com/

Date: Wed, 25 Aug 2010 13:45:50 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] On eliminating ports

The issue of delegation is a difficult one and might well be something
that ESRV or SRV is used to address.

The discovery of the delegation relationship is going to be discovered
during service discovery, i.e. before we start the TCP connection or
SSL tunnel.

If I can sign a DNSSEC zone record to say 'for email service for
hallambaker.com see gmail.com', then the service can and should expect
to see an SSL cert presented for gmail.com as opposed to
hallambaker.com.

One of the issues I am trying to deal with here is the fact that the
existing mechanism for SSL domain name binding does not work as it
should.

In order to claim that there is a system here it is going to be
necessary to provide a pretty exhaustive explanation of how this all
works with Web and with Mail.

On Wed, Aug 25, 2010 at 1:15 PM, Richard L. Barnes <[email-masked]> wrote:
> I think there's something missing here. �You also run into problems if (!a
> && b && c) and:
>
> d) The client is making decisions based on certificate attributes other than
> domain names
>
> e) One service can access another's private key
>
> If (!a && b && c && d && e), then one service can present another service's
> certificate, influencing client behavior. �You could envision problems
> arising from differences in issuer (EV vs. DV). �In some sense, this isn't a
> huge issue, since a lot of attributes are effectively the same for different
> processes on the same machine, but there are still some trouble cases. �For
> example, there are two entities with EV certs on the same server, with the
> same domain-name, one service would be able to present the other's EV cert,
> and the client would not be able to distinguish. �[1]
>
> I'll leave it as an exercise to the reader to determine how practical this
> scenario is. �In all candor, I'm mainly including it for completeness; it
> doesn't seem like a huge risk to me.
>
> --Richard
>
>
> [1] Digression: THe CA/Browser Forum document describing EV certs says that
> the domain name field in an EV cert "MUST contain one or more host domain
> name(s) owned or controlled by the Subject and to be associated with
> Subject�s server. �Such server MAY be owned and operated by the Subject or
> another entity (e.g., a hosting service)." �This situation would arise in
> the latter case, where another entity owns and operates the zone in
> question.
>
>
>
> On Aug 25, 2010, at 12:10 PM, Paul Hoffman wrote:
>
>> First off, one of the more common criticisms we got on the -00 was the
>> complication of the ports, so this is not clear-cut. Having said that, I
>> believe the *only* situation where specifying the ports in the TSLFP CERT
>> request is valuable is when all the following are true:
>>
>> a) There are more than five or so servers on different ports on
>> server.example.com
>>
>> b) Each server uses a different certificate
>>
>> c) The users always go to the tuple { dns=server.example.com && port=nnn }
>>
>> If (a) and (b) are true but (c) is not, for example if there are addional
>> names such as www.example.com and imap.example.com for the various servers,
>> there is no problem because the user will look up the individual name.
>>
>> If (a) and (c) are true but (b) is not, there is no problem because the
>> user will get a useful response regardless of the port they go to.
>>
>> If (b) and (c) are true but (a) is not, then the client software needs
>> compare the hash of the cert gotten in TLS against a small number of hashes.
>> The only problem here is that the request for the TLSFP CERT RR is somewhat
>> large.
>>
>> In what real-world use cases is this a problem?
>>
>> --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
>

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

From: "Richard L. Barnes" <[email-masked]>
To: Jakob Schlyter <[email-masked]>
Date: Wed, 25 Aug 2010 13:22:13 -0400
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys

Responses inline.

>> It's actually kind of a big reduction in triviality.  The SSL  
>> libraries right now are set up so that users provide trust anchors  
>> in the form of certs instead of fingerprints.  (At least, I'm not  
>> aware of any that do the latter.)  If you require fingerprint  
>> matching in the validation, you have to start mucking around with  
>> TLS libraries, instead of just being able to make use of existing  
>> libraries.
>
> It is not trust anchors that are published in the DNS, it is the  
> very same cert. If we would publish trust anchors, only self-signed  
> certificates could be validated, no?

There's some misunderstanding of terms here: A trust anchor is any  
point where the client doesn't feel that it needs to continue  
validation.  (In particular, it doesn't have to be self-signed.)  So  
in the context of the domain being validated, the cert presented is a  
trust anchor -- if the server presents it and it matches, there's no  
further validation necesary.

>> The one thing you could do to hack around this is do post-hoc  
>> checking: Accept the cert to establish the TLS connection, then  
>> validate it and terminate the connection if the validation fails.   
>> But in order to make that secure, you basically have to put the  
>> connection on hold while you do the validation, which is a little  
>> weird.  And that in addition to the sort of philosophical point  
>> that it seems like the TLS negotiation should fail if you're not  
>> ultimately going to accept it.
>
> In the latest version of our draft we propose that the key  
> association is performed first, optionally followed by traditional  
> PKIX validation.

I'll have to go read that :)

>> Volume II: Certs vs. keys
>>
>> A related discussion we should be having is whether we want to be  
>> talking about certs or keys in the DNS. (Whether directly, e.g., as  
>> a subjectPublicKeyInfo structure, or hashed.)  It seems to me that  
>> working with keys would be more flexible, since you wouldn't be  
>> bound to a single cert.  That is, you could present multiple certs  
>> without having to have multiple RRs, and you could change your cert  
>> without updating the DNS (e.g., to renew it).
>
> With keys (or hash of key), any CA could pull that key and sign in  
> (with the key association still valid). With a hash-of-cert, that is  
> not possible (which I think is a feature for people depending on  
> things like EV).

I'm not sure what the risk is here.  If a CA takes my public key and  
issues a cert to some attacker, the attacker can't use it to  
masquerade as me, since he doesn't have my private key.

From: "Richard L. Barnes" <[email-masked]>
To: Paul Hoffman <[email-masked]>
Date: Wed, 25 Aug 2010 13:15:19 -0400
Cc: [email-masked]
Subject: Re: [keyassure] On eliminating ports

I think there's something missing here.  You also run into problems if  
(!a && b && c) and:

d) The client is making decisions based on certificate attributes  
other than domain names

e) One service can access another's private key

If (!a && b && c && d && e), then one service can present another  
service's certificate, influencing client behavior.  You could  
envision problems arising from differences in issuer (EV vs. DV).  In  
some sense, this isn't a huge issue, since a lot of attributes are  
effectively the same for different processes on the same machine, but  
there are still some trouble cases.  For example, there are two  
entities with EV certs on the same server, with the same domain-name,  
one service would be able to present the other's EV cert, and the  
client would not be able to distinguish.  [1]

I'll leave it as an exercise to the reader to determine how practical  
this scenario is.  In all candor, I'm mainly including it for  
completeness; it doesn't seem like a huge risk to me.

--Richard

[1] Digression: THe CA/Browser Forum document describing EV certs says  
that the domain name field in an EV cert "MUST contain one or more  
host domain name(s) owned or controlled by the Subject and to be  
associated with Subject�s server.  Such server MAY be owned and  
operated by the Subject or another entity (e.g., a hosting service)."   
This situation would arise in the latter case, where another entity  
owns and operates the zone in question.

On Aug 25, 2010, at 12:10 PM, Paul Hoffman wrote:

> First off, one of the more common criticisms we got on the -00 was  
> the complication of the ports, so this is not clear-cut. Having said  
> that, I believe the *only* situation where specifying the ports in  
> the TSLFP CERT request is valuable is when all the following are true:
>
> a) There are more than five or so servers on different ports on  
> server.example.com
>
> b) Each server uses a different certificate
>
> c) The users always go to the tuple { dns=server.example.com &&  
> port=nnn }
>
> If (a) and (b) are true but (c) is not, for example if there are  
> addional names such as www.example.com and imap.example.com for the  
> various servers, there is no problem because the user will look up  
> the individual name.
>
> If (a) and (c) are true but (b) is not, there is no problem because  
> the user will get a useful response regardless of the port they go to.
>
> If (b) and (c) are true but (a) is not, then the client software  
> needs compare the hash of the cert gotten in TLS against a small  
> number of hashes. The only problem here is that the request for the  
> TLSFP CERT RR is somewhat large.
>
> In what real-world use cases is this a problem?
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Wed, 25 Aug 2010 13:10:53 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] On eliminating ports

Well there was various criticism. In particular I don't think you have
appreciated the difference between the use of port numbers to
differentiate between certs in discovery and their use to restrict use
of a cert to a specific service and/or protocol.

Let us take as a use case the need to support google.com ten years
from now when it is supporting 1000 applications. It is not going to
be possible for people to remember the names of all those applications
so the simplest approach will be to have them all use google.com as
the domain name. This approach is certainly implicit in the SRV
approach.

It is clearly not going to be practical for all those services to use
the same cert. It is certainly not desirable to do so. So I consider
any attempt to use the domain alone as the discover mechanism to be
impractical. Even if you could transport 1000 certs in one DNS record,
you would not want to try.

We already have a solution for differentiating discovery in DKIM - key tags.

In the case of SSL you always know the cert before you need to validate it.

So I would differentiate the task of cert discovery and the task of
determining if a cert is acceptable for a specific purpose.

Cert discovery is relatively easy. We just need a means of uniquely
identifying the cert. That can be provided

* [By a hash of the cert itself]
* By a digest function on the cert itself
* By new data provided in the cert
* [By data provided in the TLS transaction]
* (Might be possible to use the cert serial number which should be unique)

I have used square brackets for the ones I consider unacceptable. Why
use a hash rather than a digest? I can't think of a good reason. I
don't want to have to touch the Web server code to enable this, IIS
has a several year development cycle and many people can't upgrade
their Apache without upgrading lots of other stuff thats likely to
break.

Most people seem to think that a digest function on the cert using the
digest function used to sign it works for them.

_b5Y6eWCdCwrrODTG+lJ3iob7Ks3+ybatOSlpWGMU8k0.example.com CERT ....

We can truncate to fit into a 64 octet label without issue.

The second issue is how to restrict the use of the cert to a specific
purpose. Here we have the following possibilities:

* data in the certificate
* data in the label field of the DNS record
* data in the data field of the DNS record
* data in a companion record to CERT
* use a new record rather than reuse CERT
* pretending this is not a security problem
* require use of SRV and a separate host name per certificate

If you want to reuse CERT, the data field is not available and if you
are going to use a companion record then you might as well abandon the
attempt to extend CERT.

Try to pretend it is not a problem and people will rightly scream that it is.

So taking out those we have:

* data in the certificate
* data in the label field of the DNS record
* require use of SRV and a separate host name per certificate
* use a new record rather than reuse CERT

I don't like the first since we are now talking about putting a fairly
complicated statement that can change over the cert validity period
into the cert. I have no problem generating a random identifier and
slamming it in, but I am nervous about anything requiring thought.

The label field might have been practical if we didn't also need the
digest in the tag. If we were to fully secure both the protocol and
the port we would have:

_8000,_http._tcp._b5Y6eWCdCwrrODTG_lJ3iob7Ks3_ybatOSlpWGMU8k0.example.com
CERT ....

We could trim this a little if we can use the serial #:

_8000,_http._tcp._-F8gAyPA_mLT-mb75FGgnQ.example.com CERT ....

If we insist on using SRV we have fundamentally changed HTTP in order
to make the key assurance work. Even though I am proposing to do just
that as an option, doing that right is research and key assurance
should not be research fifteen years after we started doing SSL.

I am quite happy to do research to make a protocol work better, but
building research on research is a Error 33 from Parc. We should not
do research for the sake of saving a DNS resource record.

Reuse of CERT is looking much less attractive to me. I had been
convinced to use it since it really does solve some problems,
particularly in the general case where we are not using SSL. But it
has parameters I do not want and lacks parameters I think we need.

This would give us:

_F8gAyPA_mLT-mb75FGgnQ.example.com APPKEY
       "port=80 protocol=_http._tcp
digest=b5Y6eWCdCwrrODTG+lJ3iob7Ks3+ybatOSlpWGMU8k0="

We could add in specifications to allow a link to a CERT record and/or a uri.

On Wed, Aug 25, 2010 at 12:10 PM, Paul Hoffman <[email-masked]> wrote:
> First off, one of the more common criticisms we got on the -00 was the complication of the ports, so this is not clear-cut. Having said that, I believe the *only* situation where specifying the ports in the TSLFP CERT request is valuable is when all the following are true:
>
> a) There are more than five or so servers on different ports on server.example.com
>
> b) Each server uses a different certificate
>
> c) The users always go to the tuple { dns=server.example.com && port=nnn }
>
> If (a) and (b) are true but (c) is not, for example if there are addional names such as www.example.com and imap.example.com for the various servers, there is no problem because the user will look up the individual name.
>
> If (a) and (c) are true but (b) is not, there is no problem because the user will get a useful response regardless of the port they go to.
>
> If (b) and (c) are true but (a) is not, then the client software needs compare the hash of the cert gotten in TLS against a small number of hashes. The only problem here is that the request for the TLSFP CERT RR is somewhat large.
>
> In what real-world use cases is this a problem?
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

From: Jakob Schlyter <[email-masked]>
Date: Wed, 25 Aug 2010 19:03:44 +0200
To: Richard L. Barnes <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys

On 25 aug 2010, at 18.50, Richard L. Barnes wrote:

> It's actually kind of a big reduction in triviality.  The SSL libraries right now are set up so that users provide trust anchors in the form of certs instead of fingerprints.  (At least, I'm not aware of any that do the latter.)  If you require fingerprint matching in the validation, you have to start mucking around with TLS libraries, instead of just being able to make use of existing libraries.

It is not trust anchors that are published in the DNS, it is the very same cert. If we would publish trust anchors, only self-signed certificates could be validated, no?

> The one thing you could do to hack around this is do post-hoc checking: Accept the cert to establish the TLS connection, then validate it and terminate the connection if the validation fails.  But in order to make that secure, you basically have to put the connection on hold while you do the validation, which is a little weird.  And that in addition to the sort of philosophical point that it seems like the TLS negotiation should fail if you're not ultimately going to accept it.

In the latest version of our draft we propose that the key association is performed first, optionally followed by traditional PKIX validation.

> Volume II: Certs vs. keys
> 
> A related discussion we should be having is whether we want to be talking about certs or keys in the DNS. (Whether directly, e.g., as a subjectPublicKeyInfo structure, or hashed.)  It seems to me that working with keys would be more flexible, since you wouldn't be bound to a single cert.  That is, you could present multiple certs without having to have multiple RRs, and you could change your cert without updating the DNS (e.g., to renew it).

With keys (or hash of key), any CA could pull that key and sign in (with the key association still valid). With a hash-of-cert, that is not possible (which I think is a feature for people depending on things like EV).

	jakob

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Wed, 25 Aug 2010 13:02:15 -0400
Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys

On Aug 25, 2010, at 12:59 PM, Nicholas Weaver wrote:
> On Aug 25, 2010, at 9:50 AM, Richard L. Barnes wrote:
>> Volume II: Certs vs. keys
>>
>> A related discussion we should be having is whether we want to be  
>> talking about certs or keys in the DNS. (Whether directly, e.g., as  
>> a subjectPublicKeyInfo structure, or hashed.)  It seems to me that  
>> working with keys would be more flexible, since you wouldn't be  
>> bound to a single cert.  That is, you could present multiple certs  
>> without having to have multiple RRs, and you could change your cert  
>> without updating the DNS (e.g., to renew it).
>
> I don't see how this would be the case: you have N keys or N certs  
> means N records for the host.
>
> And is there really a difference?  A "CERT" is simply the key-format  
> desired by the application: SSL's CERTs are x509, but the "CERT" for  
> SSH is just the bare host key: this seems like a distinction without  
> a difference to me.

Many certs may share the same public/private key pair.

It matters if what people are proposing is hashing one particular key- 
format, especially if that format includes things that are not  
assertable by the person who controls the zone (unless the spec  
explicitly outlines which elements are assertable and which are not).

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Wed, 25 Aug 2010 09:59:19 -0700
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys

On Aug 25, 2010, at 9:50 AM, Richard L. Barnes wrote:
> Volume II: Certs vs. keys
> 
> A related discussion we should be having is whether we want to be talking about certs or keys in the DNS. (Whether directly, e.g., as a subjectPublicKeyInfo structure, or hashed.)  It seems to me that working with keys would be more flexible, since you wouldn't be bound to a single cert.  That is, you could present multiple certs without having to have multiple RRs, and you could change your cert without updating the DNS (e.g., to renew it).

I don't see how this would be the case: you have N keys or N certs means N records for the host.  

And is there really a difference?  A "CERT" is simply the key-format desired by the application: SSL's CERTs are x509, but the "CERT" for SSH is just the bare host key: this seems like a distinction without a difference to me.

From: "Richard L. Barnes" <[email-masked]>
To: Paul Hoffman <[email-masked]>
Date: Wed, 25 Aug 2010 12:50:10 -0400
Cc: [email-masked]
Subject: [keyassure] Certs vs. hash-of-certs vs. keys

Volume I: Certs vs. hash-of-certs

It's actually kind of a big reduction in triviality.  The SSL  
libraries right now are set up so that users provide trust anchors in  
the form of certs instead of fingerprints.  (At least, I'm not aware  
of any that do the latter.)  If you require fingerprint matching in  
the validation, you have to start mucking around with TLS libraries,  
instead of just being able to make use of existing libraries.

The one thing you could do to hack around this is do post-hoc  
checking: Accept the cert to establish the TLS connection, then  
validate it and terminate the connection if the validation fails.  But  
in order to make that secure, you basically have to put the connection  
on hold while you do the validation, which is a little weird.  And  
that in addition to the sort of philosophical point that it seems like  
the TLS negotiation should fail if you're not ultimately going to  
accept it.

Volume II: Certs vs. keys

A related discussion we should be having is whether we want to be  
talking about certs or keys in the DNS. (Whether directly, e.g., as a  
subjectPublicKeyInfo structure, or hashed.)  It seems to me that  
working with keys would be more flexible, since you wouldn't be bound  
to a single cert.  That is, you could present multiple certs without  
having to have multiple RRs, and you could change your cert without  
updating the DNS (e.g., to renew it).

Using keys, though, causes the same implementation issues as above,  
whether they're represented as keys or fingerprints.  So there's a  
trade-off here between implementation complexity and operational  
complexity.

--Richard

On Aug 25, 2010, at 12:01 PM, Paul Hoffman wrote:

> At 9:23 PM -0400 8/24/10, Richard L. Barnes wrote:
>> 3. I realize that it's slightly more efficient for the DNS to  
>> transmit fingerprints, but I still prefer to have the whole cert  
>> there because it allows for a really trivial implementation:
>> <http://www.ietf.org/mail-archive/web/keyassure/current/ 
>> msg00209.html>
>
> Depending on the certificate, it is *much* more efficient to  
> transmit fingerprints. I don't think adding a single hash function  
> call to the comparison reduces the triviality by much.
>
> --Paul Hoffman, Director
> --VPN Consortium

Date: Wed, 25 Aug 2010 09:01:32 -0700
To: "Richard L. Barnes" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: [keyassure] Certs vs. hash-of-certs

At 9:23 PM -0400 8/24/10, Richard L. Barnes wrote:
>3. I realize that it's slightly more efficient for the DNS to transmit fingerprints, but I still prefer to have the whole cert there because it allows for a really trivial implementation:
><http://www.ietf.org/mail-archive/web/keyassure/current/msg00209.html>

Depending on the certificate, it is *much* more efficient to transmit fingerprints. I don't think adding a single hash function call to the comparison reduces the triviality by much.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 25 Aug 2010 09:10:34 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: [keyassure] On eliminating ports

First off, one of the more common criticisms we got on the -00 was the complication of the ports, so this is not clear-cut. Having said that, I believe the *only* situation where specifying the ports in the TSLFP CERT request is valuable is when all the following are true:

a) There are more than five or so servers on different ports on server.example.com

b) Each server uses a different certificate

c) The users always go to the tuple { dns=server.example.com && port=nnn }

If (a) and (b) are true but (c) is not, for example if there are addional names such as www.example.com and imap.example.com for the various servers, there is no problem because the user will look up the individual name.

If (a) and (c) are true but (b) is not, there is no problem because the user will get a useful response regardless of the port they go to.

If (b) and (c) are true but (a) is not, then the client software needs compare the hash of the cert gotten in TLS against a small number of hashes. The only problem here is that the request for the TLSFP CERT RR is somewhat large.

In what real-world use cases is this a problem?

--Paul Hoffman, Director
--VPN Consortium

From: Jakob Schlyter <[email-masked]>
Date: Wed, 25 Aug 2010 09:41:54 +0200
To: Vladimir Jirasek <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01

On 25 aug 2010, at 09.38, Vladimir Jirasek wrote:

I also like to note that if we would do SRV records, the existance of a SRV(_https._tcp.example.com) and a non-existance of a SRV(_http.tcp.example.com) is a pretty good indicator that HTTPS is required (aka strict transport security) by the service. 

	jakob

From: Vladimir Jirasek <[email-masked]>
Date: Wed, 25 Aug 2010 08:38:32 +0100
To: Jakob Schlyter <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01

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

I see. Should not that be more like:

_*https*._tcp.example.com. IN CERT TLSFP 0 0
AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ=

I see what you mean and it make sense.

-----------------
Vladimir Jirasek
www.jirasek.eu   +447538790302
GoogleTalk: [email-masked]
Read my blog: blog.jirasek.eu

On 25 August 2010 08:36, Jakob Schlyter <[email-masked]> wrote:

> On 25 aug 2010, at 09.01, Vladimir Jirasek wrote:
>
> > I do not understand what you mean with using SRV records and ports? yes
> you can store port number in SRV records (that is why there are here in the
> first place) but I do not see how this alone helps CERT records. Can you
> elaborate by example please?
>
> e.g.,
>
> _http._tcp.example.com. IN CERT TLSFP 0 0
> AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ=
>
>
>        jakob
>
>

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

I see. Should not that be more like:<br><br>_<b>https</b>._<a href="http://tcp.example.com/" target="_blank">tcp.example.com</a>. IN CERT TLSFP 0 0 AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ==<br><br>I see what you mean and it make sense. <br>

<br clear="all">-----------------<br><span style="font-family: trebuchet ms,sans-serif;">Vladimir Jirasek</span><br><font size="1"><a style="font-family: arial narrow,sans-serif;" href="http://www.jirasek.eu" target="_blank">www.jirasek.eu</a><span style="font-family: arial narrow,sans-serif;">�� +447538790302</span><br style="font-family: arial narrow,sans-serif;">

<span style="font-family: arial narrow,sans-serif;">GoogleTalk: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a></span><br style="font-family: arial narrow,sans-serif;"><span style="font-family: arial narrow,sans-serif;">Read my blog: </span><a style="font-family: arial narrow,sans-serif;" href="http://blog.jirasek.eu" target="_blank">blog.jirasek.eu</a></font><br>

<br>
<br><br><div class="gmail_quote">On 25 August 2010 08:36, Jakob Schlyter <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im">On 25 aug 2010, at 09.01, Vladimir Jirasek wrote:<br>
<br>
&gt; I do not understand what you mean with using SRV records and ports? yes you can store port number in SRV records (that is why there are here in the first place) but I do not see how this alone helps CERT records. Can you elaborate by example please?<br>

<br>
</div>e.g.,<br>
<br>
_http._<a href="http://tcp.example.com" target="_blank">tcp.example.com</a>. IN CERT TLSFP 0 0 AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ==<br>
<font color="#888888"><br>
<br>
 � � � �jakob<br>
<br>
</font></blockquote></div><br>

--001485f271cc1d0712048ea0f9c8--

From: Jakob Schlyter <[email-masked]>
Date: Wed, 25 Aug 2010 09:36:41 +0200
To: Vladimir Jirasek <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01

On 25 aug 2010, at 09.01, Vladimir Jirasek wrote:

> I do not understand what you mean with using SRV records and ports? yes you can store port number in SRV records (that is why there are here in the first place) but I do not see how this alone helps CERT records. Can you elaborate by example please?

e.g.,

_http._tcp.example.com. IN CERT TLSFP 0 0 AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ==

	jakob

From: Vladimir Jirasek <[email-masked]>
Date: Wed, 25 Aug 2010 08:01:59 +0100
To: Jakob Schlyter <[email-masked]>, "Richard L. Barnes" <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01

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

Hello,

re point a) you are right, the SRV records are likely outside of the scope
of this WG, I included it as an example of connecting it together. It is not
widely deployed, pretty much as CERT RR records are not deployed. So this is
an opportunity to push it more to wide implementation.

re point b) I think limiting the DNS records to just a given name without
the port is limiting in my view. One given name can be running diferent
services using different certificates.
I do not understand what you mean with using SRV records and ports? yes you
can store port number in SRV records (that is why there are here in the
first place) but I do not see how this alone helps CERT records. Can you
elaborate by example please?

Regards

-----------------
Vladimir Jirasek
www.jirasek.eu   +447538790302
GoogleTalk: [email-masked]
Read my blog: blog.jirasek.eu

On 25 August 2010 07:53, Jakob Schlyter <[email-masked]> wrote:

> There are two different issues here;
>
> a) The use of SRV to locate server X for name Y. This is not widely
> deployed (yet), and I'm not sure it is within the scope of this non-WG to
> address this lack of support.
>
> b) Support for per protocol certificates for name Y. In our draft we
> suggest that we limit ourselves to one (equal) set of certificates for a
> given name.  If this limitation is critical, I suggest we look into SRV
> naming for the CERT records instead of encoding protocol/port in the record
> itself. This also has the benefit that existing CERT records can use the
> same convention.
>
>
>        jakob
>
>

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

Hello,<br><br>re point a) you are right, the SRV records are likely outside of the scope of this WG, I included it as an example of connecting it together. It is not widely deployed, pretty much as CERT RR records are not deployed. So this is an opportunity to push it more to wide implementation.<br>

�<br>re point b) I think limiting the DNS records to just a given name without the port is limiting in my view. One given name can be running diferent services using different certificates.<br>I do not understand what you mean with using SRV records and ports? yes you can store port number in SRV records (that is why there are here in the first place) but I do not see how this alone helps CERT records. Can you elaborate by example please?<br>

<br>Regards<br><br clear="all">-----------------<br><span style="font-family: trebuchet ms,sans-serif;">Vladimir Jirasek</span><br><font size="1"><a style="font-family: arial narrow,sans-serif;" href="http://www.jirasek.eu" target="_blank">www.jirasek.eu</a><span style="font-family: arial narrow,sans-serif;">�� +447538790302</span><br style="font-family: arial narrow,sans-serif;">

<span style="font-family: arial narrow,sans-serif;">GoogleTalk: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a></span><br style="font-family: arial narrow,sans-serif;"><span style="font-family: arial narrow,sans-serif;">Read my blog: </span><a style="font-family: arial narrow,sans-serif;" href="http://blog.jirasek.eu" target="_blank">blog.jirasek.eu</a></font><br>

<br>
<br><br><div class="gmail_quote">On 25 August 2010 07:53, Jakob Schlyter <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

There are two different issues here;<br>
<br>
a) The use of SRV to locate server X for name Y. This is not widely deployed (yet), and I&#39;m not sure it is within the scope of this non-WG to address this lack of support.<br>
<br>
b) Support for per protocol certificates for name Y. In our draft we suggest that we limit ourselves to one (equal) set of certificates for a given name. �If this limitation is critical, I suggest we look into SRV naming for the CERT records instead of encoding protocol/port in the record itself. This also has the benefit that existing CERT records can use the same convention.<br>

<font color="#888888"><br>
<br>
 � � � �jakob<br>
<br>
</font></blockquote></div><br>

--0016e65a0fbc667630048ea0764a--

From: Jakob Schlyter <[email-masked]>
Date: Wed, 25 Aug 2010 08:53:16 +0200
To: Vladimir Jirasek <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01

There are two different issues here;

a) The use of SRV to locate server X for name Y. This is not widely deployed (yet), and I'm not sure it is within the scope of this non-WG to address this lack of support.

b) Support for per protocol certificates for name Y. In our draft we suggest that we limit ourselves to one (equal) set of certificates for a given name.  If this limitation is critical, I suggest we look into SRV naming for the CERT records instead of encoding protocol/port in the record itself. This also has the benefit that existing CERT records can use the same convention.

	jakob

From: Vladimir Jirasek <[email-masked]>
Date: Wed, 25 Aug 2010 07:33:43 +0100
To: Jakob Schlyter <[email-masked]>, "Richard L. Barnes" <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01

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

Hello,

I realised that the lack of information about the ports is more important
that previously thought. I envisage this RFC to cover other TLS services
than just HTTPs. These include POPs, SMTPS (including STARTTLS potentially),
IMAPs, FTPs, etc.
If that is the intention, and I think it should be, then we need to couple
two DNS queries to get desired effect. To illustrate I show the example.

Users want to access google IMAP server on imap.google.com over IMAPs:

1. the email client queries _imaps._tcp.imap.google.com SRV record and
receives response that IMAPs service is on port 993 on server
imap.google.com
2. it opens the TLS connection to imap.google.com on port 993 and receives
the certificate(s) and extracts the certificate fingerprint
3. client queries CERT RR: imap.google.com CERT - same query as currently
proposed
the record in the DNS is stored as:

imap.google.com. IN CERT TLSFP 0 0 (
AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ=:993 ) - note that I
added port number after double colon to indicate that the cert is
located on port 993

4. the response sent back to client is as per record above and the client
extracts the certificate hash and port number and verifies it against the
certificate it already has from step 2.

This simple, in my view, change will allow for any service to be verified. I
also think the existing proposal can be modified easily to modify the
storage of the certificate has with the port number. Please note that it
does not specify the protocol (tcp or udp).

Finally, if this is coupled with SRV records to indicate ports and servers
where _imap._tcp service is running (_imap._tcp.imap.google.com. IN SRV 0 5
993 imap.google.com.) the email client does not even need to be configured
what port the service should be on, something users get wrong occasionally.

Obviously the example above applies to HTTPs as well :)

I hope this makes sense.
-----------------
Vladimir Jirasek
www.jirasek.eu   +447538790302
GoogleTalk: [email-masked]
Read my blog: blog.jirasek.eu

On 25 August 2010 07:01, Jakob Schlyter <[email-masked]> wrote:

> On 25 aug 2010, at 03.23, Richard L. Barnes wrote:
>
> > 1. It's not clear to me from your document what name I should query for
> the CERT RRs.  If I'm trying to authenticate www.example.com, do I look
> under www.example.com, or something else?  If it's the former, that could
> be helpful for generalizing to the SRV case, and would help with the concern
> about multiple services (to some extent).
>
> For now I think have to assume that you lookup the name that you are trying
> to connect to, the owner of the A/AAAA record.
>
> In case of SRV; would you look up the name of the SRV record or the
> destination? I'm not sure. For SMTP, I would look up the certificate of the
> MX destination, not the MX domain.
>
> > 3. I realize that it's slightly more efficient for the DNS to transmit
> fingerprints, but I still prefer to have the whole cert there because it
> allows for a really trivial implementation:
> > <http://www.ietf.org/mail-archive/web/keyassure/current/msg00209.html>
>
> If you want to do whole certs, you can just use CERT PKIX certificate type
> - it's already defined and ready to implement. However, CERTs tend to be on
> the larger side - 1k+ - resulting in pretty large response sizes.
>
>
>        jakob
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Hello,<br><br>I realised that the lack of information about the ports is more important that previously thought. I envisage this RFC to cover other TLS services than just HTTPs. These include POPs, SMTPS (including STARTTLS potentially), IMAPs, FTPs, etc.<br>

If that is the intention, and I think it should be, then we need to couple two DNS queries to get desired effect. To illustrate I show the example.<br><br>Users want to access google IMAP server on <a href="http://imap.google.com" target="_blank">imap.google.com</a> over IMAPs:<br>

<br>1. the email client queries _imaps._<a href="http://tcp.imap.google.com" target="_blank">tcp.imap.google.com</a> SRV record and receives response that IMAPs service is on port 993 on server <a href="http://imap.google.com" target="_blank">imap.google.com</a><br>

2. it opens the TLS connection to <a href="http://imap.google.com" target="_blank">imap.google.com</a> on port 993 and receives the certificate(s) and extracts the certificate fingerprint<br>3. client queries CERT RR: <a href="http://imap.google.com" target="_blank">imap.google.com</a> CERT - same query as currently proposed<br>

the record in the DNS is stored as: <br><pre><br><a href="http://imap.google.com" target="_blank">imap.google.com</a>. IN CERT TLSFP 0 0 ( AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ==:993 ) - note that I added port number after double colon to indicate that the cert is located on port 993 <br>

</pre>4. the response sent back to client is as per record above and the client extracts the certificate hash and port number and verifies it against the certificate it already has from step 2.<br><br>This simple, in my view, change will allow for any service to be verified. I also think the existing proposal can be modified easily to modify the storage of the certificate has with the port number. Please note that it does not specify the protocol (tcp or udp).<br>

<br>Finally, if this is coupled with SRV records to indicate ports and servers where _imap._tcp service is running (_imap._<a href="http://tcp.imap.google.com" target="_blank">tcp.imap.google.com</a>. IN SRV 0 5 993 <a href="http://imap.google.com" target="_blank">imap.google.com</a>.) the email client does not even need to be configured what port the service should be on, something users get wrong occasionally. <br>

<br>Obviously the example above applies to HTTPs as well :)<br><br>I hope this makes sense. <br clear="all">-----------------<br><span style="font-family: trebuchet ms,sans-serif;">Vladimir Jirasek</span><br><font size="1"><a style="font-family: arial narrow,sans-serif;" href="http://www.jirasek.eu" target="_blank">www.jirasek.eu</a><span style="font-family: arial narrow,sans-serif;">�� +447538790302</span><br style="font-family: arial narrow,sans-serif;">

<span style="font-family: arial narrow,sans-serif;">GoogleTalk: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a></span><br style="font-family: arial narrow,sans-serif;"><span style="font-family: arial narrow,sans-serif;">Read my blog: </span><a style="font-family: arial narrow,sans-serif;" href="http://blog.jirasek.eu" target="_blank">blog.jirasek.eu</a></font><br>

<br>
<br><br><div class="gmail_quote">On 25 August 2010 07:01, Jakob Schlyter <span dir="ltr">&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div>On 25 aug 2010, at 03.23, Richard L. Barnes wrote:<br>
<br>
&gt; 1. It&#39;s not clear to me from your document what name I should query for the CERT RRs. �If I&#39;m trying to authenticate <a href="http://www.example.com" target="_blank">www.example.com</a>, do I look under <a href="http://www.example.com" target="_blank">www.example.com</a>, or something else? �If it&#39;s the former, that could be helpful for generalizing to the SRV case, and would help with the concern about multiple services (to some extent).<br>

<br>
</div>For now I think have to assume that you lookup the name that you are trying to connect to, the owner of the A/AAAA record.<br>
<br>
In case of SRV; would you look up the name of the SRV record or the destination? I&#39;m not sure. For SMTP, I would look up the certificate of the MX destination, not the MX domain.<br>
<div><br>
&gt; 3. I realize that it&#39;s slightly more efficient for the DNS to transmit fingerprints, but I still prefer to have the whole cert there because it allows for a really trivial implementation:<br>
&gt; &lt;<a href="http://www.ietf.org/mail-archive/web/keyassure/current/msg00209.html" target="_blank">http://www.ietf.org/mail-archive/web/keyassure/current/msg00209.html</a>&gt;<br>
<br>
</div>If you want to do whole certs, you can just use CERT PKIX certificate type - it&#39;s already defined and ready to implement. However, CERTs tend to be on the larger side - 1k+ - resulting in pretty large response sizes.<br>

<font color="#888888"><br>
<br>
 � � � �jakob<br>
</font><div><div></div><div><br>
_______________________________________________<br>
keyassure mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/keyassure" target="_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</div></div></blockquote></div><br>

--001636a7d85e4f7ce4048ea011f6--

From: Jakob Schlyter <[email-masked]>
Date: Wed, 25 Aug 2010 08:01:35 +0200
To: Richard L. Barnes <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01

On 25 aug 2010, at 03.23, Richard L. Barnes wrote:

> 1. It's not clear to me from your document what name I should query for the CERT RRs.  If I'm trying to authenticate www.example.com, do I look under www.example.com, or something else?  If it's the former, that could be helpful for generalizing to the SRV case, and would help with the concern about multiple services (to some extent).

For now I think have to assume that you lookup the name that you are trying to connect to, the owner of the A/AAAA record.

In case of SRV; would you look up the name of the SRV record or the destination? I'm not sure. For SMTP, I would look up the certificate of the MX destination, not the MX domain.

> 3. I realize that it's slightly more efficient for the DNS to transmit fingerprints, but I still prefer to have the whole cert there because it allows for a really trivial implementation:
> <http://www.ietf.org/mail-archive/web/keyassure/current/msg00209.html>

If you want to do whole certs, you can just use CERT PKIX certificate type - it's already defined and ready to implement. However, CERTs tend to be on the larger side - 1k+ - resulting in pretty large response sizes.

	jakob

Date: Tue, 24 Aug 2010 22:56:21 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01

On Tue, Aug 24, 2010 at 9:23 PM, Richard L. Barnes <[email-masked]> wrote:
> Couple of comments:
>
> 1. It's not clear to me from your document what name I should query for the
> CERT RRs. �If I'm trying to authenticate www.example.com, do I look under
> www.example.com, or something else? �If it's the former, that could be
> helpful for generalizing to the SRV case, and would help with the concern
> about multiple services (to some extent).

I don't think it works as written.

The SSL connection is going to present a certificate. If the objective
here is to work
with TLS then write a spec that allows the certificate presented in TLS to be
validated.

> 2. With respect to Vladimir's concern about multiple services under the same
> name, the risk with the approach in the document is that one service on a
> host can masquerade as another, since the client doesn't know which CERT
> goes with which service. �So if you have different services at different
> security levels, you're kind of screwed. �You can kind of work around the
> problem by assigning different host names for the two services (pointing to
> the same host):
> https://www1.website.org:443
> https://www2.website.org:4443
>
> On the one hand, I'm tempted to say it's not a big deal; it's all in the
> same host, so just manage your host properly. (If there are multiple hosts
> behind the name, ) �On the other hand, if you weren't concerned about
> service separation, why did you give them different certs in the first
> place. �On balance, though, I think the above work-around is probably good
> enough.

It looks to me like this is punting on the real problem in the design.

You have the cert in hand when you want to get the assurance. So it is not
impossible to do this right.

> 3. I realize that it's slightly more efficient for the DNS to transmit
> fingerprints, but I still prefer to have the whole cert there because it
> allows for a really trivial implementation:
> <http://www.ietf.org/mail-archive/web/keyassure/current/msg00209.html>

It does not help for SSL.

But the point of using the CERT record is precisely to allow this flexibility.

Incidentally, if this project is going to be limited in scope to SSL
then it should probably
be discussed by the existing TLS working group.

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

From: "Richard L. Barnes" <[email-masked]>
To: Paul Hoffman <[email-masked]>
Date: Tue, 24 Aug 2010 21:23:56 -0400
Cc: [email-masked]
Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01

Couple of comments:

1. It's not clear to me from your document what name I should query  
for the CERT RRs.  If I'm trying to authenticate www.example.com, do I  
look under www.example.com, or something else?  If it's the former,  
that could be helpful for generalizing to the SRV case, and would help  
with the concern about multiple services (to some extent).

2. With respect to Vladimir's concern about multiple services under  
the same name, the risk with the approach in the document is that one  
service on a host can masquerade as another, since the client doesn't  
know which CERT goes with which service.  So if you have different  
services at different security levels, you're kind of screwed.  You  
can kind of work around the problem by assigning different host names  
for the two services (pointing to the same host):
https://www1.website.org:443
https://www2.website.org:4443

On the one hand, I'm tempted to say it's not a big deal; it's all in  
the same host, so just manage your host properly. (If there are  
multiple hosts behind the name, )  On the other hand, if you weren't  
concerned about service separation, why did you give them different  
certs in the first place.  On balance, though, I think the above work- 
around is probably good enough.

3. I realize that it's slightly more efficient for the DNS to transmit  
fingerprints, but I still prefer to have the whole cert there because  
it allows for a really trivial implementation:
<http://www.ietf.org/mail-archive/web/keyassure/current/msg00209.html>

On Aug 24, 2010, at 6:32 PM, Paul Hoffman wrote:

> We made some significant updates based on some of the traffic here,  
> the biggest being we now do hash-of-cert instead of hash-of-key and  
> we got rid of ports.
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : Using Secure DNS to Associate Certificates with  
> Domain Names For TLS
> 	Author(s)       : P. Hoffman, et al.
> 	Filename        : draft-hoffman-keys-linkage-from-dns-01.txt
> 	Pages           : 8
> 	Date            : 2010-08-24
>
> TLS and DTLS uses certificates for authenticating the server.  Users
> want their applications to verify that the certificate provided by
> the TLS server is in fact associated with the domain name they
> expect.  Instead of trusting a certificate authority to have made
> this association correctly, the user might instead trust the
> authoritative DNS server for the domain name to make that
> association.  This document describes how to use secure DNS to
> associate the TLS server's certificate with the the intended domain
> name.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-01.txt
>
>
> The summary of changes is:
>
> Appendix B.  Changes between -00 and -01
>
>   Change the association from being a hash of the key of a PKIX
>   certificate to being a hash of a certificate (PKIX or other).  This,
>   of course, makes large changes throughout the document.
>
>   Expanded the document to cover DTLS as well.
>
>   Added a pointer to the keyassure mailing list.
>
>   Removed the proposals for two alternate formats (the TLSFP Resource
>   Record and the TXT record encoding).  Added a bit to Appendix A  
> about
>   this.
>
>   Got rid of the specification for ports within a single domain name.
>
>   Made the hash type one octet and used the DS registry instead of
>   defining our own.
>
>   Added "Necessarily" chosen in the title of Appendix A to show that  
> we
>   might (continue to) change our minds after discussion.
>
>   Added Simon Josefsson to the acknowledgements.
>
>
> We hope this helps form the discussion here.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Tue, 24 Aug 2010 17:10:04 -0700
To: Vladimir Jirasek <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [keyassure]
draft-hoffman-keys-linkage-from-dns-01</title></head><body>
<div>At 12:26 AM +0100 8/25/10, Vladimir Jirasek wrote:</div>
<blockquote type="cite" cite>Paul,</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>I have joined the list today, on kind
advice from Jeff Hodges. I have read the new proposal and I like it
with one comment:</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>The removal of port numbers means the
protocol cannot be used to validate multiple certificates running on
one hostname but different ports (i.e. <a
href="https://www.website.org:443">https://www.website.org:443</a> for
the first business application and&nbsp;<a
href="https://www.website.org:4443">https://www.website.org:4443</a>
for the second business application).</blockquote>
<div><br>
Yes, it can. The DNS request can get back multiple CERT RRs.<br>
</div>
<blockquote type="cite" cite>In this case the DNS admin must list all
certificates (hashes of them) in multiple DNS RR.</blockquote>
<div><br></div>
<div>Exactly right.</div>
<div><br></div>
<blockquote type="cite" cite>&nbsp;It is not specified in the draft
what happens if multiple records are returned in the DNS responses,
and potentially in random order as DNS servers may use round robin
method.</blockquote>
<div><br></div>
<div>A summary of the paragraphs in Section 3 is:</div>
<div><br></div>
<div>1 - Use DNSSEC, otherwise don't bother</div>
<div>2 - If you get zero TLSFP CERT RRs, do normal TLS
processing</div>
<div>3 - If you get one or more TLSFP CERT RRs that have hash
functions that you do not understand, ignore those RRs</div>
<div>4 - Try each TLSFP CERT RRs (the order doesn't matter); if none
match the hash of the cert, die with &quot;access_denied&quot;</div>
<div><br></div>
<div>I see now that we never actually said &quot;Try each usable TLSFP
CERT RR against the hash of the end-entity cert from the server. If
you find a match, stop with success; if you don't, die with
&quot;access_denied&quot;. We can add that to the -02.</div>
<div><br></div>
<blockquote type="cite" cite>There is not security threat in not
having these port numbers there. However, I think it should be
specified what the TLS client should do in such circumstances; such as
receiving all DNS responses and going through them one by one until a
returned hash matches TLS certificate hash.</blockquote>
<div><br></div>
<div>Yep, we should have had that. Thanks for noticing this (somewhat
glaring) error!</div>

<div><br>
--Paul Hoffman, Director<br>
--VPN Consortium</div>
</body>
</html>

From: Vladimir Jirasek <[email-masked]>
Date: Wed, 25 Aug 2010 00:26:25 +0100
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01

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

Paul,

I have joined the list today, on kind advice from Jeff Hodges. I have read the new proposal and I like it with one comment:

The removal of port numbers means the protocol cannot be used to validate multiple certificates running on one hostname but different ports (i.e. https://www.website.org:443 for the first business application and https://www.website.org:4443 for the second business application). In this case the DNS admin must list all certificates (hashes of them) in multiple DNS RR. It is not specified in the draft what happens if multiple records are returned in the DNS responses, and potentially in random order as DNS servers may use round robin method.

There is not security threat in not having these port numbers there. However, I think it should be specified what the TLS client should do in such circumstances; such as receiving all DNS responses and going through them one by one until a returned hash matches TLS certificate hash.

I hope this helps.

Vladimir Jirasek
mobile: +447538 790302, Fax: +441727375073
Email and Gtalk: [email-masked]
website: www.jirasek.eu
blog: blog.jirasek.eu

On 24 Aug 2010, at 23:32, Paul Hoffman wrote:

> We made some significant updates based on some of the traffic here, the biggest being we now do hash-of-cert instead of hash-of-key and we got rid of ports.
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Using Secure DNS to Associate Certificates with Domain Names For TLS
> 	Author(s)       : P. Hoffman, et al.
> 	Filename        : draft-hoffman-keys-linkage-from-dns-01.txt
> 	Pages           : 8
> 	Date            : 2010-08-24
> 
> TLS and DTLS uses certificates for authenticating the server.  Users
> want their applications to verify that the certificate provided by
> the TLS server is in fact associated with the domain name they
> expect.  Instead of trusting a certificate authority to have made
> this association correctly, the user might instead trust the
> authoritative DNS server for the domain name to make that
> association.  This document describes how to use secure DNS to
> associate the TLS server's certificate with the the intended domain
> name.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-01.txt
> 
> 
> The summary of changes is:
> 
> Appendix B.  Changes between -00 and -01
> 
>   Change the association from being a hash of the key of a PKIX
>   certificate to being a hash of a certificate (PKIX or other).  This,
>   of course, makes large changes throughout the document.
> 
>   Expanded the document to cover DTLS as well.
> 
>   Added a pointer to the keyassure mailing list.
> 
>   Removed the proposals for two alternate formats (the TLSFP Resource
>   Record and the TXT record encoding).  Added a bit to Appendix A about
>   this.
> 
>   Got rid of the specification for ports within a single domain name.
> 
>   Made the hash type one octet and used the DS registry instead of
>   defining our own.
> 
>   Added "Necessarily" chosen in the title of Appendix A to show that we
>   might (continue to) change our minds after discussion.
> 
>   Added Simon Josefsson to the acknowledgements.
> 
> 
> We hope this helps form the discussion here.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

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

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Paul,<div><br></div><div>I have joined the list today, on kind advice from Jeff Hodges. I have read the new proposal and I like it with one comment:</div><div><br></div><div>The removal of port numbers means the protocol cannot be used to validate multiple certificates running on one hostname but different ports (i.e. <a href="https://www.website.org:443">https://www.website.org:443</a> for the first business application and&nbsp;<a href="https://www.website.org:4443">https://www.website.org:4443</a> for the second business application). In this case the DNS admin must list all certificates (hashes of them) in multiple DNS RR. It is not specified in the draft what happens if multiple records are returned in the DNS responses, and potentially in random order as DNS servers may use round robin method.</div><div><br></div><div>There is not security threat in not having these port numbers there. However, I think it should be specified what the TLS client should do in such circumstances; such as receiving all DNS responses and going through them one by one until a returned hash matches TLS certificate hash.</div><div><br></div><div>I hope this helps.</div><div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Verdana; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; 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; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Verdana; font-size: medium; 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; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Verdana; font-size: medium; 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; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px; "><div><b style="font-weight: bold; "><span class="Apple-style-span" style="font-weight: bold; ">Vladimir Jirasek</span></b></div><div><font class="Apple-style-span" color="#929292">mobile: +447538 790302, Fax:&nbsp;+441727375073</font></div><div><font class="Apple-style-span" color="#929292">Email and Gtalk:&nbsp;<a href="mailto:[email-masked]">[email-masked]</a></font></div><div><span class="Apple-style-span" style="text-decoration: underline; "><font class="Apple-style-span" color="#929292">website: <a href="http://www.jirasek.eu">www.jirasek.eu</a></font></span></div><div><span class="Apple-style-span" style="text-decoration: underline; "><font class="Apple-style-span" color="#929292">blog: <a href="http://blog.jirasek.eu">blog.jirasek.eu</a></font></span></div><div><span class="Apple-style-span" style="text-decoration: underline; "><font class="Apple-style-span" color="#929292"><br></font></span></div></span></div></div></span></div></span></span><br class="Apple-interchange-newline">
</div>
<br><div><div>On 24 Aug 2010, at 23:32, Paul Hoffman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>We made some significant updates based on some of the traffic here, the biggest being we now do hash-of-cert instead of hash-of-key and we got rid of ports.<br><br>A New Internet-Draft is available from the on-line Internet-Drafts directories.<br><br><span class="Apple-tab-span" style="white-space:pre">	</span>Title &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: Using Secure DNS to Associate Certificates with Domain Names For TLS<br><span class="Apple-tab-span" style="white-space:pre">	</span>Author(s) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: P. Hoffman, et al.<br><span class="Apple-tab-span" style="white-space:pre">	</span>Filename &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: draft-hoffman-keys-linkage-from-dns-01.txt<br><span class="Apple-tab-span" style="white-space:pre">	</span>Pages &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: 8<br><span class="Apple-tab-span" style="white-space:pre">	</span>Date &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: 2010-08-24<br><br>TLS and DTLS uses certificates for authenticating the server. &nbsp;Users<br>want their applications to verify that the certificate provided by<br>the TLS server is in fact associated with the domain name they<br>expect. &nbsp;Instead of trusting a certificate authority to have made<br>this association correctly, the user might instead trust the<br>authoritative DNS server for the domain name to make that<br>association. &nbsp;This document describes how to use secure DNS to<br>associate the TLS server's certificate with the the intended domain<br>name.<br><br>A URL for this Internet-Draft is:<br><a href="http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-01.txt">http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-01.txt</a><br><br><br>The summary of changes is:<br><br>Appendix B. &nbsp;Changes between -00 and -01<br><br> &nbsp;&nbsp;Change the association from being a hash of the key of a PKIX<br> &nbsp;&nbsp;certificate to being a hash of a certificate (PKIX or other). &nbsp;This,<br> &nbsp;&nbsp;of course, makes large changes throughout the document.<br><br> &nbsp;&nbsp;Expanded the document to cover DTLS as well.<br><br> &nbsp;&nbsp;Added a pointer to the keyassure mailing list.<br><br> &nbsp;&nbsp;Removed the proposals for two alternate formats (the TLSFP Resource<br> &nbsp;&nbsp;Record and the TXT record encoding). &nbsp;Added a bit to Appendix A about<br> &nbsp;&nbsp;this.<br><br> &nbsp;&nbsp;Got rid of the specification for ports within a single domain name.<br><br> &nbsp;&nbsp;Made the hash type one octet and used the DS registry instead of<br> &nbsp;&nbsp;defining our own.<br><br> &nbsp;&nbsp;Added "Necessarily" chosen in the title of Appendix A to show that we<br> &nbsp;&nbsp;might (continue to) change our minds after discussion.<br><br> &nbsp;&nbsp;Added Simon Josefsson to the acknowledgements.<br><br><br>We hope this helps form the discussion here.<br><br>--Paul Hoffman, Director<br>--VPN Consortium<br>_______________________________________________<br>keyassure mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.org/mailman/listinfo/keyassure<br></div></blockquote></div><br></div></body></html>
--Apple-Mail-9--557492179--

Date: Tue, 24 Aug 2010 15:32:20 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: [keyassure] draft-hoffman-keys-linkage-from-dns-01

We made some significant updates based on some of the traffic here, the biggest being we now do hash-of-cert instead of hash-of-key and we got rid of ports.

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

	Title           : Using Secure DNS to Associate Certificates with Domain Names For TLS
	Author(s)       : P. Hoffman, et al.
	Filename        : draft-hoffman-keys-linkage-from-dns-01.txt
	Pages           : 8
	Date            : 2010-08-24

TLS and DTLS uses certificates for authenticating the server.  Users
want their applications to verify that the certificate provided by
the TLS server is in fact associated with the domain name they
expect.  Instead of trusting a certificate authority to have made
this association correctly, the user might instead trust the
authoritative DNS server for the domain name to make that
association.  This document describes how to use secure DNS to
associate the TLS server's certificate with the the intended domain
name.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-01.txt

The summary of changes is:

Appendix B.  Changes between -00 and -01

   Change the association from being a hash of the key of a PKIX
   certificate to being a hash of a certificate (PKIX or other).  This,
   of course, makes large changes throughout the document.

   Expanded the document to cover DTLS as well.

   Added a pointer to the keyassure mailing list.

   Removed the proposals for two alternate formats (the TLSFP Resource
   Record and the TXT record encoding).  Added a bit to Appendix A about
   this.

   Got rid of the specification for ports within a single domain name.

   Made the hash type one octet and used the DS registry instead of
   defining our own.

   Added "Necessarily" chosen in the title of Appendix A to show that we
   might (continue to) change our minds after discussion.

   Added Simon Josefsson to the acknowledgements.

We hope this helps form the discussion here.

--Paul Hoffman, Director
--VPN Consortium

From: Warren Kumari <[email-masked]>
Date: Tue, 24 Aug 2010 15:36:04 -0400
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Sample code

On Aug 23, 2010, at 4:04 PM, Richard L. Barnes wrote:

> Speaking, as Phillip was, of the importance of people writing code, here's a little bit of sample code that illustrates why it's handy to have the full cert in the DNS.  (Even though it is, I acknowledge, more than one needs, and does raise issues with certificate expiry.)  Namely, you can reduce implementation of DNSSEC-assured TLS keying to around 10 lines.

Wow, that's kinda sexy...

W

> 
> CAVEAT EMPTOR: I haven't tested this, but at least it compiles and links against libunbound and openssl.
> 
> -----BEGIN-----
> #include <unbound.h>
> #include <openssl/ssl.h>
> 
> void keyassure(char *name, SSL_CTX *ctx) {
>    // Obtain the CERT record from DNS, secured with DNSSEC
>    struct ub_ctx *dns_ctx = ub_ctx_create();
>    struct ub_result *result;
>    ub_resolve(
>    	dns_ctx, name,
>    	37, // TYPE CERT
>    	1,  // CLASS IN
>    	&result
>    );
> 
>    // If we got a DNSSC-signed CERT record, add it to the SSL CA list
>    if (result->secure && result->havedata) {
>    	// Read the X509 bytes into an OpenSSL X509 object
>    	// Skip 5 bytes of type/tag/algorithm in the rrdata
>    	unsigned char *cert_data = (unsigned char*) result->data[0] + 5;
>    	int cert_len = result->len[0] - 5;
>    	X509* cert = d2i_X509(NULL, cert_data, cert_len);
>    	
>    	// Mark the cert as a trusted CA cert
>    	SSL_add_client_CA(ctx, cert);
>    }
> }
> 
> int main(int argc, char **argv) {
>    if (argc < 2) return 1;
>    SSL_CTX *ctx = SSL_CTX_new(TLSv1_method());
>    keyassure(argv[1], ctx);
>    // Finish setting up context and make SSL connection...
> }
> -----END-----
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Tue, 24 Aug 2010 13:38:05 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Stephen Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

OK, so it sounds as if we have rough agreement on the idea of using
one record for policy and another (probably CERT) for keys and try not
to mix the two.

I was thinking that the CA flag is optional.

If we are talking about self-signed certs, adding an extension is
trivial and allows the use of DNSSEC assured certs without the use of
a policy record (ESRV)

I prefer to break down proposals so that one part can proceed
independently of the other.

There are some other considerations we might want to take into account
with the interaction of certs and wildcards. If we want to establish a
service for *.example.com, we need to be able to provide a wildcard
binding for the cert as well.

I had originally thought of using the cert extension to specify the
prefix part and the domain stem. So if I have example.com, I could
create a cert that had the extension:

DNS-CERT _tag1 example.com

So if the cert is presented when trying to create a connection to
www.example.com, the client looks for _tag1._http._tcp.example.com and
not _tag1._http._tcp.www.example.com

This mechanism would only permit upward traversal on the chain so if
the cert is for example.com it could not be used for www.fred.com

This approach may or may not be desirable. The disadvantage is that
the intermediate DNS zone is not necessarily trustworthy (we had this
discussion at length in DKIM) and so there is a risk of having rules
of the form 'only allow within scope of the SOA' which sound great
until you find out how DNS really works.

A better solution might be to simply state that if anyone wants to do
wildcarding with this scheme then they MUST use an ESRV record and the
scheme proposed earlier and use the domain specified in the redirect.

Incidentally, there is also an interaction with SRV that I spent a
couple of weeks looking at a while back. Basically my conclusion was
that if you are using SRV then you want to pull your cert records from
the domain specified in the SRV record, not the host name that you
used for the start of your discovery process.

The reason that is important is that we should be able to support
records of the form:

_pop._tcp.hallambaker.com ESRV "ptr=gmail.com"

or

_pop._tcp.hallambaker.com SRV 1 1 143 pop.google.com

I use google for my mail service. If I have DNSSEC and Google has
DNSSEC, then I should be able to create a pointer in my DNS that means
that my client securely discovers the Google POP service.

And to go one stage further. We could create a new IANA registry for
abstract services which would specify management of a class of
protocol. So rather than put yet another 'identity' protocol on the
table, we might specify an abstract protocol that would group together
Kerberos, SAML, IIM, etc. and a relying party could find out what is
supported in a single record.

In this case it would mean that instead of

_pop._tcp.hallambaker.com ESRV "ptr=gmail.com"
_imap._tcp.hallambaker.com ESRV "ptr=gmail.com"
_submit._tcp.hallambaker.com ESRV "ptr=gmail.com"

The same might be specified as

_mail._as.hallambaker.com ESRV "ptr=gmail.com"

And at gmail we might have:

_mail._as.gmail.com ESRV "protocol=pop,imap,submit ssl=required
auth=secure ssl=required discover=SRV"
_pop._tcp.gmail.com SRV ....
_pop._tcp.gmail.com SRV ....
...

Making this all work smoothly is the key to making Web Services
practical in my view. Which in turn is the reason why I am looking at
this whole problem a bit differently.

On Tue, Aug 24, 2010 at 1:00 PM, Stephen Schultze <[email-masked]> wrote:
> On Aug 24, 2010, at 12:51 PM, Love H�rnquist �strand wrote:
>>
>> I prefer just using the "ESRV" + prefix entry instead of "ESRV" + prefix
>> entry + CA putting stuff in my cert for the simple reason its on less
>> component to change.
>>
>> The only advantage for CA putting stuff in my cert is that you can skip
>> the ESRV step for the reason additional cert validation, you still might
>> want it for TLS=REQUIRED part.
>
> As I understand the proposal, CA putting stuff in the cert is optional.
> �That is how I think it should be.
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Tue, 24 Aug 2010 13:00:37 -0400
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 24, 2010, at 12:51 PM, Love H�rnquist �strand wrote:
> I prefer just using the "ESRV" + prefix entry instead of "ESRV" +  
> prefix entry + CA putting stuff in my cert for the simple reason its  
> on less component to change.
>
> The only advantage for CA putting stuff in my cert is that you can  
> skip the ESRV step for the reason additional cert validation, you  
> still might want it for TLS=REQUIRED part.

As I understand the proposal, CA putting stuff in the cert is  
optional.  That is how I think it should be.

From: =?iso-8859-1?Q?Love_H�rnquist_�strand?= <[email-masked]>
Date: Tue, 24 Aug 2010 09:51:15 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

--Apple-Mail-536--581202218
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

I wasn't proposing putting the hash in the "ESRV" RR, just a signal that the <HASH>.original-entry <ANY_RR> exists (prefix entry).

Using the prefix entry is good since it support multiple certs for one hostname (load balancing) and migration to new certificates. All this while not requiring users to pull down all RR of you would store the cert-hashes in the data part of the RR.

I prefer just using the "ESRV" + prefix entry instead of "ESRV" + prefix entry + CA putting stuff in my cert for the simple reason its on less component to change.

The only advantage for CA putting stuff in my cert is that you can skip the ESRV step for the reason additional cert validation, you still might want it for TLS=REQUIRED part.

Love

24 aug 2010 kl. 08:41 skrev Phillip Hallam-Baker:

> If at all possible I would like to keep the policy record and the key
> record separate for the purposes of discussion. Not everyone is going
> to agree on the value of policy as it is a new capability. It is much
> easier to get people to agree on re-solving an already solved problem
> than a new one. Even though there is considerably less advantage to
> doing so.
> 
> I agree that you can put the key hash in the policy record. But as I
> show later in this post, that creates management issues at renewal
> time because DNS records are cached.
> 
> 
> How about this for a cert discovery mechanism?
> 
> Use of DNSSEC key assurance may be signaled using:
> 
> * An ESRV record
> * An X.509v3 extension DNS-CERT
> * A TLS extension
> 
> All three are possible design approaches. I prefer the first two as
> they only affect parts of the system that we know we have to affect
> anyway for the system to work (DNS, cert generation). TLS extensions
> mean we have to upgrade the Web server before the system is useful.
> 
> Different CERT records may be distinguished according to a prefix specified by:
> 
> * The prefix parameter of the X.509v3 extension DNS-CERT
> * A fingerprint of the certificate generated using the hash algorithm
> specified in the cert
> 
> In addition we need to have a mechanism for specifying that the use of
> a cert is authorized with a particular protocol. At the moment there
> is a port based proposal on the table and my proposal to use SRV
> prefixes.
> 
> I much prefer the SRV prefix approach as I don't consider the port
> assignments to be a scalable approach. We are going to have far more
> than 65,535 protocols used on the Internet. And we already have
> protocols that use multiple port numbers (X.11, FTP, VOIP) and HTTP is
> designed to run on any port.
> 
> 
> In the very simplest case, one host, one service, one cert we could in
> theory express all the required information in a single record:
> 
> _imap._tcp.example.com ESRV "SSL=REQUIRED
> CERT=SHA256:fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19�
> f0d2ce9d"
> 
> However, consider the logistical problems that occur when you need to
> roll over the cert. The ESRV record will cache and so there is no
> guarantee that a relying party is going to have the right record to
> validate the cert presented.
> 
> Assuming that the cert has no 'DNS CERT" extension, the RR is going to
> be something like:
> 
> _imap._tcp.example.com ESRV "SSL=REQUIRED ASSURANCE=DNS"
> 
> _fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19�
> f0d2ce9d._imap._tcp.example.com CERT 9 15
> 83929394fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19�
> f0d2ce9d
> 
> If the cert does have the extension the RR would be something like
> 
> _imap._tcp.example.com ESRV "SSL=REQUIRED"
> 
> _eru32wir3._imap._tcp.example.com CERT 9 15
> 83929394fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19�
> f0d2ce9d
> 
> 
> It would really not take any great effort to write a little tool that
> would generate both the zone file specification and either the
> certificate itself or CSR for submission to a CA. So the relative
> opacity of these designations should not be a major concern.
> 
> 
> On Tue, Aug 24, 2010 at 1:26 AM, Love H�rnquist �strand <[email-masked]> wrote:
>> 
>> 23 aug 2010 kl. 22:10 skrev Phillip Hallam-Baker:
>> 
>>> Hmm, I didn't put that in the ESRV I presented.
>> 
>> I'm putting it there.
>> 
>>> It is certainly a possible design choice, the ESRV could have a flag
>>> to say 'DNSSEC validation', but that would tie the key discovery to my
>>> ESRV mechanism. Which seems like tying something relatively
>>> straightforward to something that I think has to be tailored to
>>> specific protocols...
>> 
>> I don't think it tailor more then "use_tls" (or what you now called it in ESRV).
>> 
>> Putting it the digest in DNS make the chain clearer in in the case of self-signed certificates.
>> 
>> Love
>> 
>> 
>>> 
>>> I did propose a version last week where I put the certhash in the ESRV
>>> record. But that was when I was trying to make everything work with a
>>> single record and calling it something else...
>>> 
>>> 
>>> On Tue, Aug 24, 2010 at 12:33 AM, Love H�rnquist �strand <[email-masked]> wrote:
>>>> It said so in your newly proposed ESRV RR.
>>>> 
>>>> Love
>>>> 
>>>> 
>>>> 23 aug 2010 kl. 21:23 skrev Phillip Hallam-Baker:
>>>> 
>>>>> How do we know that the zone contains keys or certs at all?
>>>>> 
>>>>> That would seem rather an odd assumption when no SSL certs are
>>>>> anchored in DNS at the moment.
>>>>> 
>>>>> Knowing that the site has DNSSEC does not tell apps to look there for keys.
>>>>> 
>>>>> 
>>>>> On Mon, Aug 23, 2010 at 11:58 PM, Love H�rnquist �strand <[email-masked]> wrote:
>>>>>> 
>>>>>> 23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker:
>>>>>> 
>>>>>> 5)  Server presents certificate
>>>>>> 
>>>>>> Parse the certificate and find a DNS-CERT extension with prefix _36fe829C
>>>>>> 
>>>>>> 6) Pull the DNS record to verify the certificate:
>>>>>> 
>>>>>> _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y==
>>>>>> _36fe829C.host2.example.com CERT 1 8 http://ca.example.com/36fe829C
>>>>>> <SIG for above>
>>>>>> 
>>>>>> Since we know that the site uses DNSSEC, just don't bother checking for
>>>>>> DNS-CERT extension and instead lookup
>>>>>> HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR.
>>>>>> Love
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Website: http://hallambaker.com/
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Website: http://hallambaker.com/
>> 
>> 
> 
> 
> 
> -- 
> Website: http://hallambaker.com/

--Apple-Mail-536--581202218
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-536--581202218--

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Tue, 24 Aug 2010 12:00:49 -0400
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

I basically agree.

I would rephrase the first option ("An ESRV record") as "an RR" just  
because we haven't settled on exactly how it is represented yet.

It would be nice if that RR supported:
- DNS wildcards (does ESRV?)
- the ability to query for it before receiving and parsing the cert,  
ie simultaneously with the initial A record query you are probably  
already making

If we use a prefix, why have two standards for the prefix?  Why not  
just always do it with the fingerprint of the cert/key?  Other than  
the X.509v3 extension DNS-CERT version being prettier for a human to  
read, I'm not sure what the benefit is.

For rollover, the logical solution seems to be to allow multiple certs/ 
RR's.  This addresses other situations in which there are good reasons  
to have more than one cert per service.

On Aug 24, 2010, at 11:41 AM, Phillip Hallam-Baker wrote:
> If at all possible I would like to keep the policy record and the key
> record separate for the purposes of discussion. Not everyone is going
> to agree on the value of policy as it is a new capability. It is much
> easier to get people to agree on re-solving an already solved problem
> than a new one. Even though there is considerably less advantage to
> doing so.
>
> I agree that you can put the key hash in the policy record. But as I
> show later in this post, that creates management issues at renewal
> time because DNS records are cached.
>
>
> How about this for a cert discovery mechanism?
>
> Use of DNSSEC key assurance may be signaled using:
>
> * An ESRV record
> * An X.509v3 extension DNS-CERT
> * A TLS extension
>
> All three are possible design approaches. I prefer the first two as
> they only affect parts of the system that we know we have to affect
> anyway for the system to work (DNS, cert generation). TLS extensions
> mean we have to upgrade the Web server before the system is useful.
>
> Different CERT records may be distinguished according to a prefix  
> specified by:
>
> * The prefix parameter of the X.509v3 extension DNS-CERT
> * A fingerprint of the certificate generated using the hash algorithm
> specified in the cert
>
> In addition we need to have a mechanism for specifying that the use of
> a cert is authorized with a particular protocol. At the moment there
> is a port based proposal on the table and my proposal to use SRV
> prefixes.
>
> I much prefer the SRV prefix approach as I don't consider the port
> assignments to be a scalable approach. We are going to have far more
> than 65,535 protocols used on the Internet. And we already have
> protocols that use multiple port numbers (X.11, FTP, VOIP) and HTTP is
> designed to run on any port.
>
>
> In the very simplest case, one host, one service, one cert we could in
> theory express all the required information in a single record:
>
> _imap._tcp.example.com ESRV "SSL=REQUIRED
> CERT=SHA256:fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19�
> f0d2ce9d"
>
> However, consider the logistical problems that occur when you need to
> roll over the cert. The ESRV record will cache and so there is no
> guarantee that a relying party is going to have the right record to
> validate the cert presented.
>
> Assuming that the cert has no 'DNS CERT" extension, the RR is going to
> be something like:
>
> _imap._tcp.example.com ESRV "SSL=REQUIRED ASSURANCE=DNS"
>
> _fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19�
> f0d2ce9d._imap._tcp.example.com CERT 9 15
> 83929394fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19�
> f0d2ce9d
>
> If the cert does have the extension the RR would be something like
>
> _imap._tcp.example.com ESRV "SSL=REQUIRED"
>
> _eru32wir3._imap._tcp.example.com CERT 9 15
> 83929394fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19�
> f0d2ce9d
>
>
> It would really not take any great effort to write a little tool that
> would generate both the zone file specification and either the
> certificate itself or CSR for submission to a CA. So the relative
> opacity of these designations should not be a major concern.
>
>
> On Tue, Aug 24, 2010 at 1:26 AM, Love H�rnquist �strand <[email-masked]>  
> wrote:
>>
>> 23 aug 2010 kl. 22:10 skrev Phillip Hallam-Baker:
>>
>>> Hmm, I didn't put that in the ESRV I presented.
>>
>> I'm putting it there.
>>
>>> It is certainly a possible design choice, the ESRV could have a flag
>>> to say 'DNSSEC validation', but that would tie the key discovery  
>>> to my
>>> ESRV mechanism. Which seems like tying something relatively
>>> straightforward to something that I think has to be tailored to
>>> specific protocols...
>>
>> I don't think it tailor more then "use_tls" (or what you now called  
>> it in ESRV).
>>
>> Putting it the digest in DNS make the chain clearer in in the case  
>> of self-signed certificates.
>>
>> Love
>>
>>
>>>
>>> I did propose a version last week where I put the certhash in the  
>>> ESRV
>>> record. But that was when I was trying to make everything work  
>>> with a
>>> single record and calling it something else...
>>>
>>>
>>> On Tue, Aug 24, 2010 at 12:33 AM, Love H�rnquist �strand  
>>> <[email-masked]> wrote:
>>>> It said so in your newly proposed ESRV RR.
>>>>
>>>> Love
>>>>
>>>>
>>>> 23 aug 2010 kl. 21:23 skrev Phillip Hallam-Baker:
>>>>
>>>>> How do we know that the zone contains keys or certs at all?
>>>>>
>>>>> That would seem rather an odd assumption when no SSL certs are
>>>>> anchored in DNS at the moment.
>>>>>
>>>>> Knowing that the site has DNSSEC does not tell apps to look  
>>>>> there for keys.
>>>>>
>>>>>
>>>>> On Mon, Aug 23, 2010 at 11:58 PM, Love H�rnquist �strand <[email-masked] 
>>>>> > wrote:
>>>>>>
>>>>>> 23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker:
>>>>>>
>>>>>> 5)  Server presents certificate
>>>>>>
>>>>>> Parse the certificate and find a DNS-CERT extension with prefix  
>>>>>> _36fe829C
>>>>>>
>>>>>> 6) Pull the DNS record to verify the certificate:
>>>>>>
>>>>>> _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y==
>>>>>> _36fe829C.host2.example.com CERT 1 8 http://ca.example.com/36fe829C
>>>>>> <SIG for above>
>>>>>>
>>>>>> Since we know that the site uses DNSSEC, just don't bother  
>>>>>> checking for
>>>>>> DNS-CERT extension and instead lookup
>>>>>> HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR.
>>>>>> Love
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Website: http://hallambaker.com/
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Website: http://hallambaker.com/
>>
>>
>
>
>
> -- 
> Website: http://hallambaker.com/

Date: Tue, 24 Aug 2010 11:41:38 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: =?ISO-8859-1?Q?Love_H�rnquist_�strand?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

If at all possible I would like to keep the policy record and the key
record separate for the purposes of discussion. Not everyone is going
to agree on the value of policy as it is a new capability. It is much
easier to get people to agree on re-solving an already solved problem
than a new one. Even though there is considerably less advantage to
doing so.

I agree that you can put the key hash in the policy record. But as I
show later in this post, that creates management issues at renewal
time because DNS records are cached.

How about this for a cert discovery mechanism?

Use of DNSSEC key assurance may be signaled using:

* An ESRV record
* An X.509v3 extension DNS-CERT
* A TLS extension

All three are possible design approaches. I prefer the first two as
they only affect parts of the system that we know we have to affect
anyway for the system to work (DNS, cert generation). TLS extensions
mean we have to upgrade the Web server before the system is useful.

Different CERT records may be distinguished according to a prefix specified by:

* The prefix parameter of the X.509v3 extension DNS-CERT
* A fingerprint of the certificate generated using the hash algorithm
specified in the cert

In addition we need to have a mechanism for specifying that the use of
a cert is authorized with a particular protocol. At the moment there
is a port based proposal on the table and my proposal to use SRV
prefixes.

I much prefer the SRV prefix approach as I don't consider the port
assignments to be a scalable approach. We are going to have far more
than 65,535 protocols used on the Internet. And we already have
protocols that use multiple port numbers (X.11, FTP, VOIP) and HTTP is
designed to run on any port.

In the very simplest case, one host, one service, one cert we could in
theory express all the required information in a single record:

_imap._tcp.example.com ESRV "SSL=REQUIRED
CERT=SHA256:fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19�
f0d2ce9d"

However, consider the logistical problems that occur when you need to
roll over the cert. The ESRV record will cache and so there is no
guarantee that a relying party is going to have the right record to
validate the cert presented.

Assuming that the cert has no 'DNS CERT" extension, the RR is going to
be something like:

_imap._tcp.example.com ESRV "SSL=REQUIRED ASSURANCE=DNS"

_fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19�
f0d2ce9d._imap._tcp.example.com CERT 9 15
83929394fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19�
f0d2ce9d

If the cert does have the extension the RR would be something like

_imap._tcp.example.com ESRV "SSL=REQUIRED"

_eru32wir3._imap._tcp.example.com CERT 9 15
83929394fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19�
f0d2ce9d

It would really not take any great effort to write a little tool that
would generate both the zone file specification and either the
certificate itself or CSR for submission to a CA. So the relative
opacity of these designations should not be a major concern.

On Tue, Aug 24, 2010 at 1:26 AM, Love H�rnquist �strand <[email-masked]> wrote:
>
> 23 aug 2010 kl. 22:10 skrev Phillip Hallam-Baker:
>
>> Hmm, I didn't put that in the ESRV I presented.
>
> I'm putting it there.
>
>> It is certainly a possible design choice, the ESRV could have a flag
>> to say 'DNSSEC validation', but that would tie the key discovery to my
>> ESRV mechanism. Which seems like tying something relatively
>> straightforward to something that I think has to be tailored to
>> specific protocols...
>
> I don't think it tailor more then "use_tls" (or what you now called it in ESRV).
>
> Putting it the digest in DNS make the chain clearer in in the case of self-signed certificates.
>
> Love
>
>
>>
>> I did propose a version last week where I put the certhash in the ESRV
>> record. But that was when I was trying to make everything work with a
>> single record and calling it something else...
>>
>>
>> On Tue, Aug 24, 2010 at 12:33 AM, Love H�rnquist �strand <[email-masked]> wrote:
>>> It said so in your newly proposed ESRV RR.
>>>
>>> Love
>>>
>>>
>>> 23 aug 2010 kl. 21:23 skrev Phillip Hallam-Baker:
>>>
>>>> How do we know that the zone contains keys or certs at all?
>>>>
>>>> That would seem rather an odd assumption when no SSL certs are
>>>> anchored in DNS at the moment.
>>>>
>>>> Knowing that the site has DNSSEC does not tell apps to look there for keys.
>>>>
>>>>
>>>> On Mon, Aug 23, 2010 at 11:58 PM, Love H�rnquist �strand <[email-masked]> wrote:
>>>>>
>>>>> 23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker:
>>>>>
>>>>> 5) �Server presents certificate
>>>>>
>>>>> Parse the certificate and find a DNS-CERT extension with prefix _36fe829C
>>>>>
>>>>> 6) Pull the DNS record to verify the certificate:
>>>>>
>>>>> _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y==
>>>>> _36fe829C.host2.example.com CERT 1 8 http://ca.example.com/36fe829C
>>>>> <SIG for above>
>>>>>
>>>>> Since we know that the site uses DNSSEC, just don't bother checking for
>>>>> DNS-CERT extension and instead lookup
>>>>> HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR.
>>>>> Love
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Website: http://hallambaker.com/
>>>
>>>
>>
>>
>>
>> --
>> Website: http://hallambaker.com/
>
>

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

From: =?iso-8859-1?Q?Love_H�rnquist_�strand?= <[email-masked]>
Date: Mon, 23 Aug 2010 22:26:20 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

--Apple-Mail-465--622297800
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

23 aug 2010 kl. 22:10 skrev Phillip Hallam-Baker:

> Hmm, I didn't put that in the ESRV I presented.

I'm putting it there.

> It is certainly a possible design choice, the ESRV could have a flag
> to say 'DNSSEC validation', but that would tie the key discovery to my
> ESRV mechanism. Which seems like tying something relatively
> straightforward to something that I think has to be tailored to
> specific protocols...

I don't think it tailor more then "use_tls" (or what you now called it in ESRV).

Putting it the digest in DNS make the chain clearer in in the case of self-signed certificates.

Love

> 
> I did propose a version last week where I put the certhash in the ESRV
> record. But that was when I was trying to make everything work with a
> single record and calling it something else...
> 
> 
> On Tue, Aug 24, 2010 at 12:33 AM, Love H�rnquist �strand <[email-masked]> wrote:
>> It said so in your newly proposed ESRV RR.
>> 
>> Love
>> 
>> 
>> 23 aug 2010 kl. 21:23 skrev Phillip Hallam-Baker:
>> 
>>> How do we know that the zone contains keys or certs at all?
>>> 
>>> That would seem rather an odd assumption when no SSL certs are
>>> anchored in DNS at the moment.
>>> 
>>> Knowing that the site has DNSSEC does not tell apps to look there for keys.
>>> 
>>> 
>>> On Mon, Aug 23, 2010 at 11:58 PM, Love H�rnquist �strand <[email-masked]> wrote:
>>>> 
>>>> 23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker:
>>>> 
>>>> 5)  Server presents certificate
>>>> 
>>>> Parse the certificate and find a DNS-CERT extension with prefix _36fe829C
>>>> 
>>>> 6) Pull the DNS record to verify the certificate:
>>>> 
>>>> _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y==
>>>> _36fe829C.host2.example.com CERT 1 8 http://ca.example.com/36fe829C
>>>> <SIG for above>
>>>> 
>>>> Since we know that the site uses DNSSEC, just don't bother checking for
>>>> DNS-CERT extension and instead lookup
>>>> HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR.
>>>> Love
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Website: http://hallambaker.com/
>> 
>> 
> 
> 
> 
> -- 
> Website: http://hallambaker.com/

--Apple-Mail-465--622297800
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-465--622297800--

Date: Tue, 24 Aug 2010 01:10:21 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: =?ISO-8859-1?Q?Love_H�rnquist_�strand?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

Hmm, I didn't put that in the ESRV I presented.

It is certainly a possible design choice, the ESRV could have a flag
to say 'DNSSEC validation', but that would tie the key discovery to my
ESRV mechanism. Which seems like tying something relatively
straightforward to something that I think has to be tailored to
specific protocols...

I did propose a version last week where I put the certhash in the ESRV
record. But that was when I was trying to make everything work with a
single record and calling it something else...

On Tue, Aug 24, 2010 at 12:33 AM, Love H�rnquist �strand <[email-masked]> wrote:
> It said so in your newly proposed ESRV RR.
>
> Love
>
>
> 23 aug 2010 kl. 21:23 skrev Phillip Hallam-Baker:
>
>> How do we know that the zone contains keys or certs at all?
>>
>> That would seem rather an odd assumption when no SSL certs are
>> anchored in DNS at the moment.
>>
>> Knowing that the site has DNSSEC does not tell apps to look there for keys.
>>
>>
>> On Mon, Aug 23, 2010 at 11:58 PM, Love H�rnquist �strand <[email-masked]> wrote:
>>>
>>> 23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker:
>>>
>>> 5) �Server presents certificate
>>>
>>> Parse the certificate and find a DNS-CERT extension with prefix _36fe829C
>>>
>>> 6) Pull the DNS record to verify the certificate:
>>>
>>> _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y==
>>> _36fe829C.host2.example.com CERT 1 8 http://ca.example.com/36fe829C
>>> <SIG for above>
>>>
>>> Since we know that the site uses DNSSEC, just don't bother checking for
>>> DNS-CERT extension and instead lookup
>>> HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR.
>>> Love
>>>
>>>
>>
>>
>>
>> --
>> Website: http://hallambaker.com/
>
>

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

From: =?iso-8859-1?Q?Love_H�rnquist_�strand?= <[email-masked]>
Date: Mon, 23 Aug 2010 21:33:11 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

--Apple-Mail-458--625486061
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

It said so in your newly proposed ESRV RR.

Love

23 aug 2010 kl. 21:23 skrev Phillip Hallam-Baker:

> How do we know that the zone contains keys or certs at all?
> 
> That would seem rather an odd assumption when no SSL certs are
> anchored in DNS at the moment.
> 
> Knowing that the site has DNSSEC does not tell apps to look there for keys.
> 
> 
> On Mon, Aug 23, 2010 at 11:58 PM, Love H�rnquist �strand <[email-masked]> wrote:
>> 
>> 23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker:
>> 
>> 5)  Server presents certificate
>> 
>> Parse the certificate and find a DNS-CERT extension with prefix _36fe829C
>> 
>> 6) Pull the DNS record to verify the certificate:
>> 
>> _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y==
>> _36fe829C.host2.example.com CERT 1 8 http://ca.example.com/36fe829C
>> <SIG for above>
>> 
>> Since we know that the site uses DNSSEC, just don't bother checking for
>> DNS-CERT extension and instead lookup
>> HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR.
>> Love
>> 
>> 
> 
> 
> 
> -- 
> Website: http://hallambaker.com/

--Apple-Mail-458--625486061
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-458--625486061--

Date: Tue, 24 Aug 2010 00:23:49 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: =?ISO-8859-1?Q?Love_H�rnquist_�strand?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

How do we know that the zone contains keys or certs at all?

That would seem rather an odd assumption when no SSL certs are
anchored in DNS at the moment.

Knowing that the site has DNSSEC does not tell apps to look there for keys.

On Mon, Aug 23, 2010 at 11:58 PM, Love H�rnquist �strand <[email-masked]> wrote:
>
> 23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker:
>
> 5) �Server presents certificate
>
> Parse the certificate and find a DNS-CERT extension with prefix _36fe829C
>
> 6) Pull the DNS record to verify the certificate:
>
> _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y==
> _36fe829C.host2.example.com CERT 1 8�http://ca.example.com/36fe829C
> <SIG for above>
>
> Since we know that the site uses DNSSEC, just don't bother checking for
> DNS-CERT extension and instead lookup
> HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR.
> Love
>
>

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

From: =?iso-8859-1?Q?Love_H�rnquist_�strand?= <[email-masked]>
Date: Mon, 23 Aug 2010 20:58:17 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

--Apple-Mail-455--627580201
Content-Type: multipart/alternative;
	boundary=Apple-Mail-454--627580254

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

23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker:

> 5)  Server presents certificate
> 
> Parse the certificate and find a DNS-CERT extension with prefix _36fe829C
> 
> 6) Pull the DNS record to verify the certificate:
> 
> _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y==
> _36fe829C.host2.example.com CERT 1 8 http://ca.example.com/36fe829C
> <SIG for above>

Since we know that the site uses DNSSEC, just don't bother checking for DNS-CERT extension and instead lookup HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR.

Love

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

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="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; ">5) &nbsp;Server presents certificate<br><br>Parse the certificate and find a DNS-CERT extension with prefix _36fe829C<br><br>6) Pull the DNS record to verify the certificate:<br><br>_36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y==<br>_36fe829C.host2.example.com CERT 1 8<span class="Apple-converted-space">&nbsp;</span><a href="http://ca.example.com/36fe829C">http://ca.example.com/36fe829C</a><br>&lt;SIG for above&gt;<br></span></blockquote></div><br><div>Since we know that the site uses DNSSEC, just don't bother checking for DNS-CERT extension and instead lookup HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR.</div><div><br></div><div>Love</div><div><br></div><div><br></div></body></html>
--Apple-Mail-454--627580254--

--Apple-Mail-455--627580201
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-455--627580201--

Date: Mon, 23 Aug 2010 18:36:35 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: [email-masked]
Cc: Paul Hoffman <[email-masked]>
Subject: [keyassure] comments on draft-hoffman-keys-linkage-from-dns-00.txt

My comments on draft-hoffman-keys-linkage-from-dns-00.txt,

In section 2, three alternatives are proposed. I prefer alternative
number two (The TLSFP Resource Record).

I am curious why no sub-typing was suggested. Instead of getting a
list of port numbers, would it not be better to request the TLSFP RR
for a specific port? Was this done to make adoption easier by not
requiring a new kind of subtype query? Or is there a more fundamental
DNS reason for this pick? And if subtype queries are to be avoided,
would it not be an option to use a _protocol._port. entry to avoid
returning multiple options that a client then has to dig through?

Paul

Date: Mon, 23 Aug 2010 17:12:48 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Mon, Aug 23, 2010 at 4:18 PM, Paul Wouters <[email-masked]> wrote:
> On Mon, 23 Aug 2010, Stephen Schultze wrote:

> Yes, we are talking about a changed security assumption, regardless of what
> this
> group decides. We can avoid stepping on the PKIX toes - by not using PKIX.

No, you tread on our toes by ignoring our work and repeating our mistakes.

> I guess we really need to step back and decide the problem we're solving.
> People
> are definitely solving totally different problems right now.

Since my reading of 5395 is that the criteria for issuing a new code
point to CERT are essentially the same as the criteria for issuing a
new code point for a resource record, it seems to me that we will
either have a CERT hash function for complete certs or we will have
one for complete certs and a second one for keys in certs.

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

Date: Mon, 23 Aug 2010 15:45:59 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Stephen Schultze <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Stephen and all,

-----Original Message-----
>From: Stephen Schultze <[email-masked]>
>Sent: Aug 23, 2010 2:54 PM
>To: [email-masked]
>Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt
>
>On Aug 23, 2010, at 3:45 PM, Nicholas Weaver wrote:
>>>> b)  It requires that all validators understand the semantics of  
>>>> the certificates rather than just treating them as opaque binary  
>>>> blobs.
>>>
>>> Certainly not all DNSSEC validators (that's what you seem to be  
>>> implying below).  Only the TLS module needs to be changed to first  
>>> pull out the key.  The rest of the DNSSEC chain works as normal.
>>
>> Except the model existing for DNSSEC is that an ARBITRARY RR can be  
>> validated by any DNSSEC cache or intermediatry.  By only validating  
>> a portion of the data, you break this model for no benefit: such an  
>> RR would be very different from every other resource record in terms  
>> of validation by intermediaries:  DNS has the property that any  
>> unknown record type should be treatable as an opaque blob of bits,  
>> including for the purpose of validation.
>
>One of us is radically misunderstanding the other.  It could be my  
>fault.
>
>The idea is that the DNSSEC validates the RR, just the same as any  
>other.  This gives you a trusted key.
>
>Then, in the course of TLS setup (for example), the client takes the  
>key that it got from the RR and compares that with the key it's  
>getting from the server (embedded in a cert or otherwise).  This is  
>happening in client libs, which might indeed need to be updated.
>
>None of this implicates changes to DNSSEC operations.
>
>What am I missing?

  I don't think your missing anything here.  Well done!
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

Date: Mon, 23 Aug 2010 16:45:41 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Stephen Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Mon, Aug 23, 2010 at 3:15 PM, Stephen Schultze <[email-masked]> wrote:
> On Aug 23, 2010, at 2:42 PM, Phillip Hallam-Baker wrote:
>>>
>>> Combining your approach with an
>>> approach that simply seeks to enable validated domain-to-key mapping
>>> based
>>> on the properties of DNSSEC itself has the following disadvantages:
>>>
>>> 1. mixing together assertions that require different authority
>>> 2. locking in applications to either implementing the cert format you
>>> choose, or adding duplicative cert hash DNS entries for each new cert
>>> format
>>
>> Actually, this appears to me to be the disadvantage of requiring the
>> DNS systems to pull out the key from the cert.
>
> Can you explain? �I'm not grokking.

At present, pretty much every SSL library consists of code to replace
open(x) with openssl(x,  callback, param)

The callback code throws the calling application a bundle of certs and
a context pointer passed in at the top. The callback has to then
decide whether it likes the taste of the cert or not and respond
accordingly.

As the term Secure Socket Library implies, this is totally wired into
the architecture of the protocol, it is what the patent was granted
for (cue ironic laughter).

So if you want to isolate the callback code from messing with ASN.1,
you want to allow them to treat the cert as simply a raw binary blob
to munch on with a digest function. The SSL library code they are
using already has the code necessary for extracting the key.

>>>> the reason we are using certs and not just keys is because we need
>>>> those additional bits.
>>>
>>> I think that the additional bits needed for fully featured operation of
>>> domain-to-key mapping (eg: "require SSL") can be easily built into the
>>> spec,
>>> whereas bits that assert other things can still ride in the cert itself
>>> and
>>> be validated by whoever signs the cert (if anyone).
>>
>> Logically speaking, you need to know about 'require SSL' before you
>> start processing the certificate that was presented in the SSL
>> transaction.
>
> Is the same not true for knowing whether the cert (or key) you were
> presented with hashes to what's in DNS? �If so, the blocking is the same.
> �You have to wait until you get the RR.

In the full version of my preferred architecture, the client does the
following when it wants to create a connection for (domain, service).
e.g. ("example.com", "_http._tcp")

1) Pull the ESRV record for the service

_http._tcp.example.com ESRV "tls=optional discovery=srv"
 <SIG for above>

2) Client supports the SRV discovery option so we pull that record as well:

_https._tcp.example.com SRV  1 1 443 host1.example.com
_https._tcp.example.com SRV  1 1 443 host2.example.com
 <SIG for above>

3) Try host2:

host2.example.com A 10.1.1.1
 <SIG for above>

4) Open the SSL tunnel to 10.1.1.1 port 443

5)  Server presents certificate

Parse the certificate and find a DNS-CERT extension with prefix _36fe829C

6) Pull the DNS record to verify the certificate:

_36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y==
_36fe829C.host2.example.com CERT 1 8 http://ca.example.com/36fe829C
 <SIG for above>

Note that at every stage we have a completely defined search set. We
have no hunting around for the next link in the chain.

The SRV step is optional of course. And for some protocols we might
want to use NAPTR or some other SRV variant.

Yes, this approach is not all within scope of what others on this list
are looking to build. But in my approach to protocol design I look at
the total functionality I want and then go about looking to see how I
divide it up into technology platforms. I do not start with a
technology platform and try to enumerate the maximum possible number
of nails to bash with it.

HTTP should have had SRV and SSL designed in from the start.

I don't think you want to include ESRV functionality in the CERT
record because it has to be tuned to the specific protocol.

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

From: "Richard L. Barnes" <[email-masked]>
To: Paul Wouters <[email-masked]>
Date: Mon, 23 Aug 2010 16:34:11 -0400
Cc: Stephen Schultze <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

>>> Data authorisation duplication is an extremely bad idea. Multiple  
>>> authorities
>>> could give different answers and then what do you end up doing?  
>>> Again, it
>>> makes no sense to reproduce X.509 in DNS and then use out-of- 
>>> bounds CA
>>> validation requirements.
>>
>> This is going to be an issue regardless of the decision on this  
>> issue.  What do you do if you have an expired or revoked  
>> certificate/key that nevertheless has a valid hash in DNS?
>
> Only when using X.509 containers. i've been advocating against those.

This question seems irrelevant to what sort of container you use.  If  
you have a key or fingerprint that's still in the zone, but the cert  
that's presented at the application layer is expired or revoked, is it  
still considered valid?

There's a little bit of an operational concern here in that you can  
keep the same key pair while changing the cert, but it doesn't seem  
like a huge deal to add "update CERT in DNS" to the TODO list when  
you're rolling over your cert.

>>> That's right. We no longer trust CA's. That's a feature, not a bug.
>>
>> Agreed, but it is a bug if somehow we end up allowing controllers  
>> of zones to make and have validated assertions for things that they  
>> shouldn't be trusted for, or if we create ambiguity about who is  
>> asserting what.  As such, if we end up cherry-picking fields from X. 
>> 509 we need to specify clearly what it means in this regard.
>
> Again, no cherry picking. key hashes in the DNS with flags/options  
> fields. Validity
> is determined by the presense in the zone with a valid DNSSEC  
> signature.

As above, the question of validity is independent of the question of  
which container is used.  Expired or revoked certificates can still be  
used as trust anchors, so even if the cert in the DNS is expired/ 
revoked, it can still be considered "good" if it's DNSSEC-validated.

>> In any case, my point was obviously that in either scenario we are  
>> presuming a changed security assumption, which was Phillip's  
>> objection.
>
> Yes, we are talking about a changed security assumption, regardless  
> of what this
> group decides. We can avoid stepping on the PKIX toes - by not using  
> PKIX.
>
> I guess we really need to step back and decide the problem we're  
> solving. People
> are definitely solving totally different problems right now.

Agree on all points here.  What we're proposing is an adjunct,  
parallel validation path to PKIX.

As to deciding what problem we're solving, I've tried to express my  
idea of the problem in a charter proposal:
<http://www.ietf.org/mail-archive/web/keyassure/current/msg00090.html>

--Richard

Date: Mon, 23 Aug 2010 16:18:12 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Stephen Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Mon, 23 Aug 2010, Stephen Schultze wrote:

>> Data authorisation duplication is an extremely bad idea. Multiple 
>> authorities
>> could give different answers and then what do you end up doing? Again, it
>> makes no sense to reproduce X.509 in DNS and then use out-of-bounds CA
>> validation requirements.
>
> This is going to be an issue regardless of the decision on this issue.  What 
> do you do if you have an expired or revoked certificate/key that nevertheless 
> has a valid hash in DNS?

Only when using X.509 containers. i've been advocating against those.

>> That's right. We no longer trust CA's. That's a feature, not a bug.
>
> Agreed, but it is a bug if somehow we end up allowing controllers of zones to 
> make and have validated assertions for things that they shouldn't be trusted 
> for, or if we create ambiguity about who is asserting what.  As such, if we 
> end up cherry-picking fields from X.509 we need to specify clearly what it 
> means in this regard.

Again, no cherry picking. key hashes in the DNS with flags/options fields. Validity
is determined by the presense in the zone with a valid DNSSEC signature.

> In any case, my point was obviously that in either scenario we are presuming 
> a changed security assumption, which was Phillip's objection.

Yes, we are talking about a changed security assumption, regardless of what this
group decides. We can avoid stepping on the PKIX toes - by not using PKIX.

I guess we really need to step back and decide the problem we're solving. People
are definitely solving totally different problems right now.

Paul

From: "Richard L. Barnes" <[email-masked]>
To: [email-masked]
Date: Mon, 23 Aug 2010 16:04:43 -0400
Subject: [keyassure] Sample code

Speaking, as Phillip was, of the importance of people writing code,  
here's a little bit of sample code that illustrates why it's handy to  
have the full cert in the DNS.  (Even though it is, I acknowledge,  
more than one needs, and does raise issues with certificate expiry.)   
Namely, you can reduce implementation of DNSSEC-assured TLS keying to  
around 10 lines.

CAVEAT EMPTOR: I haven't tested this, but at least it compiles and  
links against libunbound and openssl.

-----BEGIN-----
#include <unbound.h>
#include <openssl/ssl.h>

void keyassure(char *name, SSL_CTX *ctx) {
     // Obtain the CERT record from DNS, secured with DNSSEC
     struct ub_ctx *dns_ctx = ub_ctx_create();
     struct ub_result *result;
     ub_resolve(
     	dns_ctx, name,
     	37, // TYPE CERT
     	1,  // CLASS IN
     	&result
     );

     // If we got a DNSSC-signed CERT record, add it to the SSL CA list
     if (result->secure && result->havedata) {
     	// Read the X509 bytes into an OpenSSL X509 object
     	// Skip 5 bytes of type/tag/algorithm in the rrdata
     	unsigned char *cert_data = (unsigned char*) result->data[0] + 5;
     	int cert_len = result->len[0] - 5;
     	X509* cert = d2i_X509(NULL, cert_data, cert_len);
     	
     	// Mark the cert as a trusted CA cert
     	SSL_add_client_CA(ctx, cert);
     }
}

int main(int argc, char **argv) {
     if (argc < 2) return 1;
     SSL_CTX *ctx = SSL_CTX_new(TLSv1_method());
     keyassure(argv[1], ctx);
     // Finish setting up context and make SSL connection...
}
-----END-----

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Mon, 23 Aug 2010 13:01:15 -0700
To: Stephen Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 23, 2010, at 12:54 PM, Stephen Schultze wrote:

> On Aug 23, 2010, at 3:45 PM, Nicholas Weaver wrote:
>>>> b)  It requires that all validators understand the semantics of the certificates rather than just treating them as opaque binary blobs.
>>> 
>>> Certainly not all DNSSEC validators (that's what you seem to be implying below).  Only the TLS module needs to be changed to first pull out the key.  The rest of the DNSSEC chain works as normal.
>> 
>> Except the model existing for DNSSEC is that an ARBITRARY RR can be validated by any DNSSEC cache or intermediatry.  By only validating a portion of the data, you break this model for no benefit: such an RR would be very different from every other resource record in terms of validation by intermediaries:  DNS has the property that any unknown record type should be treatable as an opaque blob of bits, including for the purpose of validation.
> 
> One of us is radically misunderstanding the other.  It could be my fault.
> 
> The idea is that the DNSSEC validates the RR, just the same as any other.  This gives you a trusted key.
> 
> Then, in the course of TLS setup (for example), the client takes the key that it got from the RR and compares that with the key it's getting from the server (embedded in a cert or otherwise).  This is happening in client libs, which might indeed need to be updated.
> 
> None of this implicates changes to DNSSEC operations.
> 
> What am I missing?

I guess I got confused by the discussion that DNSSEC only validates parts of the certificate.

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Mon, 23 Aug 2010 15:54:49 -0400
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 23, 2010, at 3:45 PM, Nicholas Weaver wrote:
>>> b)  It requires that all validators understand the semantics of  
>>> the certificates rather than just treating them as opaque binary  
>>> blobs.
>>
>> Certainly not all DNSSEC validators (that's what you seem to be  
>> implying below).  Only the TLS module needs to be changed to first  
>> pull out the key.  The rest of the DNSSEC chain works as normal.
>
> Except the model existing for DNSSEC is that an ARBITRARY RR can be  
> validated by any DNSSEC cache or intermediatry.  By only validating  
> a portion of the data, you break this model for no benefit: such an  
> RR would be very different from every other resource record in terms  
> of validation by intermediaries:  DNS has the property that any  
> unknown record type should be treatable as an opaque blob of bits,  
> including for the purpose of validation.

One of us is radically misunderstanding the other.  It could be my  
fault.

The idea is that the DNSSEC validates the RR, just the same as any  
other.  This gives you a trusted key.

Then, in the course of TLS setup (for example), the client takes the  
key that it got from the RR and compares that with the key it's  
getting from the server (embedded in a cert or otherwise).  This is  
happening in client libs, which might indeed need to be updated.

None of this implicates changes to DNSSEC operations.

What am I missing?

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Mon, 23 Aug 2010 15:48:45 -0400
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 23, 2010, at 3:00 PM, Richard L. Barnes wrote:
>> That is close but I don't think we can reuse the CERT record and then
>> put policy information in it such as 'SSL required'.
>>
>> That should be separated out into another record. Otherwise we end up
>> treating CERT in the same manner as TXT has been (ab)used.
>
> Definitely agree with not using CERT for that sort of policy  
> information, but I would go further to say that policy isn't the  
> domain of this group.  The definition of "SSL required" will vary  
> quite a bit between applications, so policy work is more  
> appropriately done in more application-specific groups, such as the  
> proposed HASMAT group for HTTP:
> <http://tools.ietf.org/html/draft-hodges-strict-transport-sec>

Looking to HSTS is a good idea, and it makes sense to look at actual  
implementations too (including to understand its limitations), eg:
http://dev.chromium.org/sts

That approach would also argue for keeping any of these assertions out  
of the same X.509 certs that carry other third-party assertions.

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Mon, 23 Aug 2010 12:45:11 -0700
To: Stephen Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 23, 2010, at 12:21 PM, Stephen Schultze wrote:

> On Aug 23, 2010, at 2:58 PM, Nicholas Weaver wrote:
>> On Aug 23, 2010, at 11:51 AM, Stephen Schultze wrote:
>>> On Aug 23, 2010, at 1:18 PM, Phillip Hallam-Baker wrote:
>>>>> The DNS location can show the permitted use. DNSSEC can provide the
>>>>> validation for that.
>>>> 
>>>> So now your proposal is
>>>> 
>>>> 1) Only sign some of the bits in the cert
>>>> 2) find some other way to define the other bits we need to sign.
>>> 
>>> More or less, yes, I think so.  However I'd describe it as:
>>> 
>>> 1) Only include elements that controllers of a zone should be able to assert in the RR (key text, some usage requirements)
>>> 2) Put everything else in a cert signed by a third-party that has authority to assert that stuff
>> 
>> This is significantly inferior:
>> 
>> a)  It requires that domain authorities now understand the semantics of the certificates rather than just treating them as opaque binary blobs.
> 
> By "domain authorities" you mean the administrator of the zone data?  If so, then yes you are right.
> 
>> b)  It requires that all validators understand the semantics of the certificates rather than just treating them as opaque binary blobs.
> 
> Certainly not all DNSSEC validators (that's what you seem to be implying below).  Only the TLS module needs to be changed to first pull out the key.  The rest of the DNSSEC chain works as normal.

Except the model existing for DNSSEC is that an ARBITRARY RR can be validated by any DNSSEC cache or intermediatry.  By only validating a portion of the data, you break this model for no benefit: such an RR would be very different from every other resource record in terms of validation by intermediaries:  DNS has the property that any unknown record type should be treatable as an opaque blob of bits, including for the purpose of validation.

>> c)  It prevents the framework from ever accommodating other types of certificates.
> 
> I don't think this is the case.  The framework supports any kind of certificate that uses public keys, and application developers are free to develop such certs/protocols (eg. OpenPGP over TLS) without forcing anyone that wants to use it to put new certs into DNS.

I'd be really worried about "validating only part" actually being done right.  That really scares me as well.

Content-class: urn:content-classes:message
Date: Mon, 23 Aug 2010 15:43:57 -0400
From: "Carl Wallace" <[email-masked]>
To: "Paul Wouters" <[email-masked]>, "Stephen Schultze" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

> That's right. We no longer trust CA's. That's a feature, not a bug.

If the intent is to use the key association match exclusively, state
that in the I-D along with security considerations verbiage describing
what is gained/lost relative to the status quo.  The current draft calls
for conventional PKIX validation (nebulous processing rules aside).

> Anyone who wants to use CA's, can stick to what's deployed today. Any
> new trust
> or usage or authorization constraints can be resolved within the X.509
> attribute
> space.

This need not be either/or.  

Date: Mon, 23 Aug 2010 15:39:58 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Mon, Aug 23, 2010 at 3:00 PM, Richard L. Barnes <[email-masked]> wrote:
>> That is close but I don't think we can reuse the CERT record and then
>> put policy information in it such as 'SSL required'.
>>
>> That should be separated out into another record. Otherwise we end up
>> treating CERT in the same manner as TXT has been (ab)used.
>
> Definitely agree with not using CERT for that sort of policy information,
> but I would go further to say that policy isn't the domain of this group.
> �The definition of "SSL required" will vary quite a bit between
> applications, so policy work is more appropriately done in more
> application-specific groups, such as the proposed HASMAT group for HTTP:
> <http://tools.ietf.org/html/draft-hodges-strict-transport-sec>

Group? What Group?

You seem to be assuming that the outcome of this process is a group
that works out how to use DNSSEC to secure abstract applications. If
that type of work is practical, I would say it should be done in
DNSEXT.

I think the rather more likely outcome of this group is a WG that has
a scope limited to one specific application but is told to go and do
it in a general way. For example, work out how to make HTTP over SSL
work in this framework.

Unless we make some very precise statements about applications, I
can't see us getting the application writers involved. And without the
involvement of people who write code people use a WG means nothing.

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

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Mon, 23 Aug 2010 15:34:37 -0400
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 23, 2010, at 3:18 PM, Paul Wouters wrote:
> On Mon, 23 Aug 2010, Stephen Schultze wrote:
>
>> To the extent that there are constraints or other features that  
>> currently appear in X.509 or other cert standards that can be  
>> authoritatively asserted by the person who controls a zone, those  
>> should be made part of the RR.
>
> Data authorisation duplication is an extremely bad idea. Multiple  
> authorities
> could give different answers and then what do you end up doing?  
> Again, it
> makes no sense to reproduce X.509 in DNS and then use out-of-bounds CA
> validation requirements.

This is going to be an issue regardless of the decision on this  
issue.  What do you do if you have an expired or revoked certificate/ 
key that nevertheless has a valid hash in DNS?

The real problem is that if you do not explicitly separate the DNS  
answer and the certificate answer, especially if the cert is signed by  
a third party, it is not clear who is asserting the answer.  Sure, you  
could pick out which X.509 fields are considered asserted by a DNS  
answer if the hash is present (and perhaps this is what people will  
want to do) but that is no better than explicitly separating them with  
respect to your critique.

>> And I think that giving controllers of zones the ability to assert  
>> things that only CAs used to be able to assert would be a changed  
>> security assumption.
>
> That's right. We no longer trust CA's. That's a feature, not a bug.

Agreed, but it is a bug if somehow we end up allowing controllers of  
zones to make and have validated assertions for things that they  
shouldn't be trusted for, or if we create ambiguity about who is  
asserting what.  As such, if we end up cherry-picking fields from X. 
509 we need to specify clearly what it means in this regard.

In any case, my point was obviously that in either scenario we are  
presuming a changed security assumption, which was Phillip's objection.

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Mon, 23 Aug 2010 15:21:53 -0400
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 23, 2010, at 2:58 PM, Nicholas Weaver wrote:
> On Aug 23, 2010, at 11:51 AM, Stephen Schultze wrote:
>> On Aug 23, 2010, at 1:18 PM, Phillip Hallam-Baker wrote:
>>>> The DNS location can show the permitted use. DNSSEC can provide the
>>>> validation for that.
>>>
>>> So now your proposal is
>>>
>>> 1) Only sign some of the bits in the cert
>>> 2) find some other way to define the other bits we need to sign.
>>
>> More or less, yes, I think so.  However I'd describe it as:
>>
>> 1) Only include elements that controllers of a zone should be able  
>> to assert in the RR (key text, some usage requirements)
>> 2) Put everything else in a cert signed by a third-party that has  
>> authority to assert that stuff
>
> This is significantly inferior:
>
> a)  It requires that domain authorities now understand the semantics  
> of the certificates rather than just treating them as opaque binary  
> blobs.

By "domain authorities" you mean the administrator of the zone data?   
If so, then yes you are right.

> b)  It requires that all validators understand the semantics of the  
> certificates rather than just treating them as opaque binary blobs.

Certainly not all DNSSEC validators (that's what you seem to be  
implying below).  Only the TLS module needs to be changed to first  
pull out the key.  The rest of the DNSSEC chain works as normal.

> c)  It prevents the framework from ever accommodating other types of  
> certificates.

I don't think this is the case.  The framework supports any kind of  
certificate that uses public keys, and application developers are free  
to develop such certs/protocols (eg. OpenPGP over TLS) without forcing  
anyone that wants to use it to put new certs into DNS.

> B is especially bad:  Although I argue that DNSSEC validation on the  
> not-end-host caches is a bad idea, people want to do it.  A new  
> record type MUST NOT require a new validation algorithm that only  
> covers portions of the data, rather it MUST use the existing defined  
> mechanism of 'an unknown record is simply opaque data'.

Date: Mon, 23 Aug 2010 15:18:15 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Stephen Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Mon, 23 Aug 2010, Stephen Schultze wrote:

> To the extent that there are constraints or other features that currently 
> appear in X.509 or other cert standards that can be authoritatively asserted 
> by the person who controls a zone, those should be made part of the RR.

Data authorisation duplication is an extremely bad idea. Multiple authorities
could give different answers and then what do you end up doing? Again, it
makes no sense to reproduce X.509 in DNS and then use out-of-bounds CA
validation requirements.

> And I think that giving controllers of zones the ability to assert things 
> that only CAs used to be able to assert would be a changed security 
> assumption.

That's right. We no longer trust CA's. That's a feature, not a bug.

Anyone who wants to use CA's, can stick to what's deployed today. Any new trust
or usage or authorization constraints can be resolved within the X.509 attribute
space.

I feel like I'm time travelling into the past.

Paul

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Mon, 23 Aug 2010 15:15:51 -0400
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 23, 2010, at 2:42 PM, Phillip Hallam-Baker wrote:
>> Combining your approach with an
>> approach that simply seeks to enable validated domain-to-key  
>> mapping based
>> on the properties of DNSSEC itself has the following disadvantages:
>>
>> 1. mixing together assertions that require different authority
>> 2. locking in applications to either implementing the cert format you
>> choose, or adding duplicative cert hash DNS entries for each new  
>> cert format
>
> Actually, this appears to me to be the disadvantage of requiring the
> DNS systems to pull out the key from the cert.

Can you explain?  I'm not grokking.

>>> the reason we are using certs and not just keys is because we need
>>> those additional bits.
>>
>> I think that the additional bits needed for fully featured  
>> operation of
>> domain-to-key mapping (eg: "require SSL") can be easily built into  
>> the spec,
>> whereas bits that assert other things can still ride in the cert  
>> itself and
>> be validated by whoever signs the cert (if anyone).
>
> Logically speaking, you need to know about 'require SSL' before you
> start processing the certificate that was presented in the SSL
> transaction.

Is the same not true for knowing whether the cert (or key) you were  
presented with hashes to what's in DNS?  If so, the blocking is the  
same.  You have to wait until you get the RR.

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Mon, 23 Aug 2010 15:06:13 -0400
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

explicit:
- hash algorithm
- "use SSL"
- other handshake-related variables like secure renegotiation

implied:
- domain constraints within the zone in question
- expiration (TTL)
- pathLenConstraint=0 (I think this makes sense in order to limit  
DNSSEC key assurance to leaf nodes only)

On Aug 23, 2010, at 2:54 PM, Steingruebl, Andy wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:keyassure- 
>> [email-masked]] On Behalf Of Stephen Schultze
>>
>> Certification of which bits?  All of the bits in the cert, or only  
>> those that
>> you've decided are allowed?
>>
>> I do think that I now better understand what you are proposing.
>> Correct me if I'm wrong.  You want the ability for whoever controls  
>> a zone to
>> hash certs and place them in DNS (essentially signing them) so that  
>> they can
>> make any manner of assertions.  This turns them into their own  
>> little CA for
>> their own domain.
>
> I think it would help me if we could put together a list of types of  
> certificates and assertions that currently aren't conveyed via DNS  
> but that we are proposing can be conveyed that way.  And, which of  
> those that aren't currently conveyed via DNS implicitly rely somehow  
> on DNS in their lifecycle.
>
> As Warren has pointed out quite well in previous emails and Dan  
> Kaminsky has pointed out elsewhere, we're relying on DNS security  
> and whoever controls a zone for a huge portion of the trust already,  
> even if we don't realize it.  In those cases we're already trusting  
> whoever administers DNS, we just haven't listed them in our trust  
> model.
>
> In those cases since we already have to extend trust to them, we  
> might as well make it explicit and put all of that data into DNS. It  
> solves more problems than it causes.
>
> Should code-signing keys be in DNS, maybe not.  But it depends on  
> how they are currently issued I suppose. If the current trust chain  
> goes through DNS, then we either remove that dependency or  
> explicitly embrace it.
>
> I would like to see an enumeration of the keys/certs we're  
> discussing, use-cases, etc. Phillip laid out several criteria here: http://www.ietf.org/mail-archive/web/keyassure/current/msg00177.html 
>  but I think we can flesh this out a little with explicitly listing  
> what types of certs we will consider and which ones we won't.
>
> - Andy
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: "Richard L. Barnes" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Aug 2010 15:00:28 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

> That is close but I don't think we can reuse the CERT record and then
> put policy information in it such as 'SSL required'.
>
> That should be separated out into another record. Otherwise we end up
> treating CERT in the same manner as TXT has been (ab)used.

Definitely agree with not using CERT for that sort of policy  
information, but I would go further to say that policy isn't the  
domain of this group.  The definition of "SSL required" will vary  
quite a bit between applications, so policy work is more appropriately  
done in more application-specific groups, such as the proposed HASMAT  
group for HTTP:
<http://tools.ietf.org/html/draft-hodges-strict-transport-sec>

--Richard

>> I suppose this is an interesting use case, but it would require  
>> additional
>> client infrastructure to build in trust bits for individual zones.
>>  Furthermore, I'm not sure why you wouldn't just use the CERT RR as- 
>> is, or
>> even add a CERTHASH cert type to CERT.  Combining your approach  
>> with an
>> approach that simply seeks to enable validated domain-to-key  
>> mapping based
>> on the properties of DNSSEC itself has the following disadvantages:
>>
>> 1. mixing together assertions that require different authority
>> 2. locking in applications to either implementing the cert format you
>> choose, or adding duplicative cert hash DNS entries for each new  
>> cert format
>
> Actually, this appears to me to be the disadvantage of requiring the
> DNS systems to pull out the key from the cert.
>
> I really don't have a problem with a draft that says 'here is how you
> validate a trust chain in which portions of the chain are in DNSSEC
> and here is the conclusions that you may draw'. We give that advice to
> relying parties all the time.
>
> There is going to be a list of caveats on these trust chains that is
> going to be impressively long no matter what.
>
>
>>> the reason we are using certs and not just keys is because we need
>>> those additional bits.
>>
>> I think that the additional bits needed for fully featured  
>> operation of
>> domain-to-key mapping (eg: "require SSL") can be easily built into  
>> the spec,
>> whereas bits that assert other things can still ride in the cert  
>> itself and
>> be validated by whoever signs the cert (if anyone).
>
> Logically speaking, you need to know about 'require SSL' before you
> start processing the certificate that was presented in the SSL
> transaction.
>
>
>>
>> On Aug 23, 2010, at 11:38 AM, Phillip Hallam-Baker wrote:
>>>
>>> The idea of limiting the authentication to the key seems to be  
>>> because
>>> people are worried that people 'might do the wrong thing' with it.
>>>
>>> My experience is that this is a futile approach. If people are going
>>> to do the wrong thing with the subject field they are going to do  
>>> that
>>> whether or not it is authenticated by the CERT hash.
>>>
>>> The only way to ensure that people use nothing but the key is to put
>>> nothing but the key in the record (which we can do already).
>>>
>>>
>>> What we are trying to do here is to change the semantics of the CERT
>>> record so the act of publishing one in the DNS becomes in effect a  
>>> CA
>>> certification of those bits. That is a validation path in its own
>>> right.
>>>
>>> For example, I might have a device that ships with a device
>>> certificate. I want to use the device in my network. So I pull the
>>> cert from the device, take the hash and put the hash into my DNS,  
>>> thus
>>> declaring that this is a device I authorize for use with my DNS  
>>> zone.
>>>
>>> The device cert is CA issued and asserts a particular function. I am
>>> only going to put the cert in my DNS if I endorse that function.
>>>
>>> the reason we are using certs and not just keys is because we need
>>> those additional bits.
>>>
>>> Incidentally, one of the reasons we might want a new record is
>>> precisely because we are changing the semantics of CERT, even if  
>>> what
>>> we are doing here is to give it the semantics it should have had in
>>> the first place.
>>>
>>> On Mon, Aug 23, 2010 at 11:20 AM, Steve Schultze <[email-masked]>
>>> wrote:
>>>>
>>>> On Aug 23, 2010, at 11:01 AM, Phillip Hallam-Baker wrote:
>>>>>
>>>>> Given the choice between giving people with brains the information
>>>>> they need to do the job right and not giving the information in  
>>>>> case
>>>>> it is misused by cretins, I suggest taking the first approach.
>>>>
>>>> I'm having trouble figuring out who the cretins vs the people  
>>>> with brains
>>>> are in your scenario, but fortunately it doesn't matter if we  
>>>> design a
>>>> system in which people can assert only what they are trusted to  
>>>> assert.
>>>>
>>>> If your concern is...
>>>>>
>>>>> SSL use can be controlled by key use bits and extensions in the  
>>>>> cert.
>>>>
>>>> Then the answer is twofold:
>>>> 1. these bits can continue to be used, and will be trusted if the  
>>>> CA is
>>>> trusted
>>>> 2. if you wish to enforce this in the absence of a CA-trusted  
>>>> cert, we
>>>> can include an option in the RR standard for requiring SSL (which  
>>>> is an
>>>> assertion that the zone controller can be trusted to make)
>>
>>
>>
>>
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>>
>
>
>
> -- 
> Website: http://hallambaker.com/
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Mon, 23 Aug 2010 11:58:03 -0700
To: Stephen Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 23, 2010, at 11:51 AM, Stephen Schultze wrote:

> On Aug 23, 2010, at 1:18 PM, Phillip Hallam-Baker wrote:
>>> The DNS location can show the permitted use. DNSSEC can provide the
>>> validation for that.
>> 
>> So now your proposal is
>> 
>> 1) Only sign some of the bits in the cert
>> 2) find some other way to define the other bits we need to sign.
> 
> More or less, yes, I think so.  However I'd describe it as:
> 
> 1) Only include elements that controllers of a zone should be able to assert in the RR (key text, some usage requirements)
> 2) Put everything else in a cert signed by a third-party that has authority to assert that stuff

This is significantly inferior:

a)  It requires that domain authorities now understand the semantics of the certificates rather than just treating them as opaque binary blobs.

b)  It requires that all validators understand the semantics of the certificates rather than just treating them as opaque binary blobs.

c)  It prevents the framework from ever accommodating other types of certificates.

B is especially bad:  Although I argue that DNSSEC validation on the not-end-host caches is a bad idea, people want to do it.  A new record type MUST NOT require a new validation algorithm that only covers portions of the data, rather it MUST use the existing defined mechanism of 'an unknown record is simply opaque data'.

From: "Steingruebl, Andy" <[email-masked]>
To: Stephen Schultze <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 23 Aug 2010 12:54:38 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Schultze
> 
> Certification of which bits?  All of the bits in the cert, or only those that
> you've decided are allowed?
> 
> I do think that I now better understand what you are proposing.
> Correct me if I'm wrong.  You want the ability for whoever controls a zone to
> hash certs and place them in DNS (essentially signing them) so that they can
> make any manner of assertions.  This turns them into their own little CA for
> their own domain.  

I think it would help me if we could put together a list of types of certificates and assertions that currently aren't conveyed via DNS but that we are proposing can be conveyed that way.  And, which of those that aren't currently conveyed via DNS implicitly rely somehow on DNS in their lifecycle.  

As Warren has pointed out quite well in previous emails and Dan Kaminsky has pointed out elsewhere, we're relying on DNS security and whoever controls a zone for a huge portion of the trust already, even if we don't realize it.  In those cases we're already trusting whoever administers DNS, we just haven't listed them in our trust model.

In those cases since we already have to extend trust to them, we might as well make it explicit and put all of that data into DNS. It solves more problems than it causes.

Should code-signing keys be in DNS, maybe not.  But it depends on how they are currently issued I suppose. If the current trust chain goes through DNS, then we either remove that dependency or explicitly embrace it.

I would like to see an enumeration of the keys/certs we're discussing, use-cases, etc. Phillip laid out several criteria here: http://www.ietf.org/mail-archive/web/keyassure/current/msg00177.html but I think we can flesh this out a little with explicitly listing what types of certs we will consider and which ones we won't.

- Andy

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Mon, 23 Aug 2010 14:51:34 -0400
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 23, 2010, at 1:18 PM, Phillip Hallam-Baker wrote:
>> The DNS location can show the permitted use. DNSSEC can provide the
>> validation for that.
>
> So now your proposal is
>
> 1) Only sign some of the bits in the cert
> 2) find some other way to define the other bits we need to sign.

More or less, yes, I think so.  However I'd describe it as:

1) Only include elements that controllers of a zone should be able to  
assert in the RR (key text, some usage requirements)
2) Put everything else in a cert signed by a third-party that has  
authority to assert that stuff

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Mon, 23 Aug 2010 14:48:19 -0400
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 23, 2010, at 12:41 PM, Phillip Hallam-Baker wrote:
> Why not have the DNSSEC module check the hash against the full  
> certificate?
>
> That way the TLS module does not even need to know it is using DNSSEC
> key assurance?

If it does not know it is using DNSSEC key assurance, then it can't  
validate _anything_ without getting a third party involved.

> There are two types of information in a certificate besides the key:
>
> 1) Assertions concerning properties of the certificate subject
> 2) Assertions concerning the permitted uses of the key.
>
> Whatever you think about the desirability of authenticating the first.

Desirable, but not able to be authenticated via DNSSEC key assurance.

> You will break SSL if you do not authenticate the second set of
> information.

Any assertions concerning the permitted uses of the key that the  
controller of a zone should be authorized to make could be represented  
in the RR.  Any uses that they are not authorized to make should not  
be respected unless there is some third-party validation.  Unless you  
can give a more concrete example of how you think this breaks SSL I'm  
not sure how to answer.

> The reason that I do not want to modify SSL to use raw keys is that it
> was built on an assumption that the second type of information would
> be authenticated and assured.

To the extent that there are constraints or other features that  
currently appear in X.509 or other cert standards that can be  
authoritatively asserted by the person who controls a zone, those  
should be made part of the RR.  At that point it's not a "raw key."   
You're right, though, that to date that a DNSSEC-secured domain-based  
approach has not been a mode of operation for SSL.

In any case, the SSL handshake stays the same, and it can be an X.509- 
based handshake or OpenPGP-via-TLS or whatever other standard might  
exist.  The only difference is that the domain-to-key mapping portion  
of validation on the client, but this is work that has to be done  
regardless of whether you hash the whole cert or just the key.

> Changing the security assumptions on which an existing protocol is
> built is the most common way of breaking them.

And I think that giving controllers of zones the ability to assert  
things that only CAs used to be able to assert would be a changed  
security assumption.

Date: Mon, 23 Aug 2010 14:42:34 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Stephen Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Mon, Aug 23, 2010 at 2:23 PM, Stephen Schultze <[email-masked]> wrote:

> I do think that I now better understand what you are proposing. �Correct me
> if I'm wrong. �You want the ability for whoever controls a zone to hash
> certs and place them in DNS (essentially signing them) so that they can make
> any manner of assertions. �This turns them into their own little CA for
> their own domain. �You would define some subset of assertions that are
> trusted by default as long as they come from a signed record �(so far I've
> seen "text of public key" and "SSL required"). �However, other assertions
> might become trusted if the end user decides to trust the controller of the
> zone to a greater degree (a degree not justified merely by the fact that
> they are the controller of the zone). �One way of obtaining this greater
> degree of trust might be for a certificate to be signed by a trusted
> third-party (like today's CAs), but evidently you envision some other
> validation path from the signed zone to a trusted root.

That is close but I don't think we can reuse the CERT record and then
put policy information in it such as 'SSL required'.

That should be separated out into another record. Otherwise we end up
treating CERT in the same manner as TXT has been (ab)used.

> I suppose this is an interesting use case, but it would require additional
> client infrastructure to build in trust bits for individual zones.
> �Furthermore, I'm not sure why you wouldn't just use the CERT RR as-is, or
> even add a CERTHASH cert type to CERT. �Combining your approach with an
> approach that simply seeks to enable validated domain-to-key mapping based
> on the properties of DNSSEC itself has the following disadvantages:
>
> 1. mixing together assertions that require different authority
> 2. locking in applications to either implementing the cert format you
> choose, or adding duplicative cert hash DNS entries for each new cert format

Actually, this appears to me to be the disadvantage of requiring the
DNS systems to pull out the key from the cert.

I really don't have a problem with a draft that says 'here is how you
validate a trust chain in which portions of the chain are in DNSSEC
and here is the conclusions that you may draw'. We give that advice to
relying parties all the time.

There is going to be a list of caveats on these trust chains that is
going to be impressively long no matter what.

>> the reason we are using certs and not just keys is because we need
>> those additional bits.
>
> I think that the additional bits needed for fully featured operation of
> domain-to-key mapping (eg: "require SSL") can be easily built into the spec,
> whereas bits that assert other things can still ride in the cert itself and
> be validated by whoever signs the cert (if anyone).

Logically speaking, you need to know about 'require SSL' before you
start processing the certificate that was presented in the SSL
transaction.

>
> On Aug 23, 2010, at 11:38 AM, Phillip Hallam-Baker wrote:
>>
>> The idea of limiting the authentication to the key seems to be because
>> people are worried that people 'might do the wrong thing' with it.
>>
>> My experience is that this is a futile approach. If people are going
>> to do the wrong thing with the subject field they are going to do that
>> whether or not it is authenticated by the CERT hash.
>>
>> The only way to ensure that people use nothing but the key is to put
>> nothing but the key in the record (which we can do already).
>>
>>
>> What we are trying to do here is to change the semantics of the CERT
>> record so the act of publishing one in the DNS becomes in effect a CA
>> certification of those bits. That is a validation path in its own
>> right.
>>
>> For example, I might have a device that ships with a device
>> certificate. I want to use the device in my network. So I pull the
>> cert from the device, take the hash and put the hash into my DNS, thus
>> declaring that this is a device I authorize for use with my DNS zone.
>>
>> The device cert is CA issued and asserts a particular function. I am
>> only going to put the cert in my DNS if I endorse that function.
>>
>> the reason we are using certs and not just keys is because we need
>> those additional bits.
>>
>> Incidentally, one of the reasons we might want a new record is
>> precisely because we are changing the semantics of CERT, even if what
>> we are doing here is to give it the semantics it should have had in
>> the first place.
>>
>> On Mon, Aug 23, 2010 at 11:20 AM, Steve Schultze <[email-masked]>
>> wrote:
>>>
>>> On Aug 23, 2010, at 11:01 AM, Phillip Hallam-Baker wrote:
>>>>
>>>> Given the choice between giving people with brains the information
>>>> they need to do the job right and not giving the information in case
>>>> it is misused by cretins, I suggest taking the first approach.
>>>
>>> I'm having trouble figuring out who the cretins vs the people with brains
>>> are in your scenario, but fortunately it doesn't matter if we design a
>>> system in which people can assert only what they are trusted to assert.
>>>
>>> If your concern is...
>>>>
>>>> SSL use can be controlled by key use bits and extensions in the cert.
>>>
>>> Then the answer is twofold:
>>> 1. these bits can continue to be used, and will be trusted if the CA is
>>> trusted
>>> 2. if you wish to enforce this in the absence of a CA-trusted cert, we
>>> can include an option in the RR standard for requiring SSL (which is an
>>> assertion that the zone controller can be trusted to make)
>
>
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Mon, 23 Aug 2010 14:23:31 -0400
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

Phillip accidentally sent his response only to me.  His full message  
is at the bottom, but my in-lines are below.

On Aug 23, 2010, at 11:38 AM, Phillip Hallam-Baker wrote:
> The idea of limiting the authentication to the key seems to be because
> people are worried that people 'might do the wrong thing' with it.

I think the idea is that hashing the entire cert indicates that the  
controller of the zone asserts that everything contained in the cert  
is accurate, which is something that they alone do not have the  
authority to do.  The only way to avoid this would be a to create a  
whitelist of cert properties that are to be trusted purely based on  
receiving a DNSSEC-validated answer.

> The only way to ensure that people use nothing but the key is to put
> nothing but the key in the record (which we can do already).

I'm confused, how is it possible already to "put nothing but the key  
in the record"?

> What we are trying to do here is to change the semantics of the CERT
> record so the act of publishing one in the DNS becomes in effect a CA
> certification of those bits. That is a validation path in its own
> right.

Certification of which bits?  All of the bits in the cert, or only  
those that you've decided are allowed?

I do think that I now better understand what you are proposing.   
Correct me if I'm wrong.  You want the ability for whoever controls a  
zone to hash certs and place them in DNS (essentially signing them) so  
that they can make any manner of assertions.  This turns them into  
their own little CA for their own domain.  You would define some  
subset of assertions that are trusted by default as long as they come  
from a signed record  (so far I've seen "text of public key" and "SSL  
required").  However, other assertions might become trusted if the end  
user decides to trust the controller of the zone to a greater degree  
(a degree not justified merely by the fact that they are the  
controller of the zone).  One way of obtaining this greater degree of  
trust might be for a certificate to be signed by a trusted third-party  
(like today's CAs), but evidently you envision some other validation  
path from the signed zone to a trusted root.

I suppose this is an interesting use case, but it would require  
additional client infrastructure to build in trust bits for individual  
zones.  Furthermore, I'm not sure why you wouldn't just use the CERT  
RR as-is, or even add a CERTHASH cert type to CERT.  Combining your  
approach with an approach that simply seeks to enable validated domain- 
to-key mapping based on the properties of DNSSEC itself has the  
following disadvantages:

1. mixing together assertions that require different authority
2. locking in applications to either implementing the cert format you  
choose, or adding duplicative cert hash DNS entries for each new cert  
format

> the reason we are using certs and not just keys is because we need
> those additional bits.

I think that the additional bits needed for fully featured operation  
of domain-to-key mapping (eg: "require SSL") can be easily built into  
the spec, whereas bits that assert other things can still ride in the  
cert itself and be validated by whoever signs the cert (if anyone).

On Aug 23, 2010, at 11:38 AM, Phillip Hallam-Baker wrote:
> The idea of limiting the authentication to the key seems to be because
> people are worried that people 'might do the wrong thing' with it.
>
> My experience is that this is a futile approach. If people are going
> to do the wrong thing with the subject field they are going to do that
> whether or not it is authenticated by the CERT hash.
>
> The only way to ensure that people use nothing but the key is to put
> nothing but the key in the record (which we can do already).
>
>
> What we are trying to do here is to change the semantics of the CERT
> record so the act of publishing one in the DNS becomes in effect a CA
> certification of those bits. That is a validation path in its own
> right.
>
> For example, I might have a device that ships with a device
> certificate. I want to use the device in my network. So I pull the
> cert from the device, take the hash and put the hash into my DNS, thus
> declaring that this is a device I authorize for use with my DNS zone.
>
> The device cert is CA issued and asserts a particular function. I am
> only going to put the cert in my DNS if I endorse that function.
>
> the reason we are using certs and not just keys is because we need
> those additional bits.
>
> Incidentally, one of the reasons we might want a new record is
> precisely because we are changing the semantics of CERT, even if what
> we are doing here is to give it the semantics it should have had in
> the first place.
>
> On Mon, Aug 23, 2010 at 11:20 AM, Steve Schultze <[email-masked]>  
> wrote:
>> On Aug 23, 2010, at 11:01 AM, Phillip Hallam-Baker wrote:
>>> Given the choice between giving people with brains the information
>>> they need to do the job right and not giving the information in case
>>> it is misused by cretins, I suggest taking the first approach.
>>
>> I'm having trouble figuring out who the cretins vs the people with  
>> brains are in your scenario, but fortunately it doesn't matter if  
>> we design a system in which people can assert only what they are  
>> trusted to assert.
>>
>> If your concern is...
>>> SSL use can be controlled by key use bits and extensions in the  
>>> cert.
>>
>> Then the answer is twofold:
>> 1. these bits can continue to be used, and will be trusted if the  
>> CA is trusted
>> 2. if you wish to enforce this in the absence of a CA-trusted cert,  
>> we can include an option in the RR standard for requiring SSL  
>> (which is an assertion that the zone controller can be trusted to  
>> make)

Date: Mon, 23 Aug 2010 13:18:03 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Mon, Aug 23, 2010 at 1:02 PM, Paul Wouters <[email-masked]> wrote:
> On Mon, 23 Aug 2010, Phillip Hallam-Baker wrote:
>
>> There are two types of information in a certificate besides the key:
>>
>> 1) Assertions concerning properties of the certificate subject
>> 2) Assertions concerning the permitted uses of the key.
>>
>> Whatever you think about the desirability of authenticating the first.
>> You will break SSL if you do not authenticate the second set of
>> information.
>>
>> The reason that I do not want to modify SSL to use raw keys is that it
>> was built on an assumption that the second type of information would
>> be authenticated and assured.
>
> The DNS location can show the permitted use. DNSSEC can provide the
> validation for that.

So now your proposal is

1) Only sign some of the bits in the cert
2) find some other way to define the other bits we need to sign.

>> Changing the security assumptions on which an existing protocol is
>> built is the most common way of breaking them.
>
> Arguing like that, all X.509 should be removed from DNS and we should all
> stick to TXT records.

No, this is just another way to validate an X.509 certificate path.

Since we already use self-signed certificates, anything that provides
more assurance of the chain above the EE cert is useful.

>> I see zero advantage to your approach and I see no way that you, I,
>> Paul Kocher or anyone else can fully convince themselves that they are
>> not breaking SSL in some subtle way.
>
> SSL currently *is* broken with the 95% self signed certs out there. That
> shortcoming is something we're trying to fix - it's too late to prevent it.

No, Self-Signed was on the table before SSL v3. We have fifteen years
of experience.

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

Date: Mon, 23 Aug 2010 13:02:57 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Mon, 23 Aug 2010, Phillip Hallam-Baker wrote:

> There are two types of information in a certificate besides the key:
>
> 1) Assertions concerning properties of the certificate subject
> 2) Assertions concerning the permitted uses of the key.
>
> Whatever you think about the desirability of authenticating the first.
> You will break SSL if you do not authenticate the second set of
> information.
>
> The reason that I do not want to modify SSL to use raw keys is that it
> was built on an assumption that the second type of information would
> be authenticated and assured.

The DNS location can show the permitted use. DNSSEC can provide the validation for that.

> Changing the security assumptions on which an existing protocol is
> built is the most common way of breaking them.

Arguing like that, all X.509 should be removed from DNS and we should all
stick to TXT records.

> I see zero advantage to your approach and I see no way that you, I,
> Paul Kocher or anyone else can fully convince themselves that they are
> not breaking SSL in some subtle way.

SSL currently *is* broken with the 95% self signed certs out there. That
shortcoming is something we're trying to fix - it's too late to prevent it.

Paul

Date: Mon, 23 Aug 2010 12:41:41 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Stephen Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

Why not have the DNSSEC module check the hash against the full certificate?

That way the TLS module does not even need to know it is using DNSSEC
key assurance?

There are two types of information in a certificate besides the key:

1) Assertions concerning properties of the certificate subject
2) Assertions concerning the permitted uses of the key.

Whatever you think about the desirability of authenticating the first.
You will break SSL if you do not authenticate the second set of
information.

The reason that I do not want to modify SSL to use raw keys is that it
was built on an assumption that the second type of information would
be authenticated and assured.

Changing the security assumptions on which an existing protocol is
built is the most common way of breaking them.

I see zero advantage to your approach and I see no way that you, I,
Paul Kocher or anyone else can fully convince themselves that they are
not breaking SSL in some subtle way. Take a look at our recent Client
cert issue which is a consequence of client certs being supported as
an afterthought.

On Mon, Aug 23, 2010 at 12:00 PM, Stephen Schultze <[email-masked]> wrote:
> On Aug 23, 2010, at 11:19 AM, Nicholas Weaver wrote:
>>
>> Except that, IMO, there is a huge advantage to be had on simplicity of
>> just verifying the ENTIRE certificate. �Who says CERT RR's need to be just
>> X.509 format?
>
> If CERT RR's (or whatever RR we choose) contain public keys, then the
> standard supports an arbitrary number of cert formats without creating the
> need for an additional record every time an application wants a different
> type of cert.
>
>> If the model is the only part validated is the public key in the cert,
>> that means that DNS resolver, DNS APIs, and authorities need to be aware of
>> the X.509 format.
>
> Why is that? �Only the application needs to be aware of X.509 (or, in the
> case of OpenPGP via TLS, an OpenPGP key). �Once it gets the key out , it
> hashes it and checks it against the DNS hierarchy.
>
>> But if the entire record is just validated as a single binary blob, this
>> means that different certificate formats could be used in the future without
>> needing to change anything other than the application which is the final
>> consumer of the new certificate type.
>
> You would be forcing one of two things, either:
> a. every application must be updated to use whatever cert standard you chose
> b. you �must add duplicate entries for each public key for each new cert
> standard you chose
>
> Neither seems optimal.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Mon, 23 Aug 2010 12:00:21 -0400
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 23, 2010, at 11:19 AM, Nicholas Weaver wrote:
> Except that, IMO, there is a huge advantage to be had on simplicity  
> of just verifying the ENTIRE certificate.  Who says CERT RR's need  
> to be just X.509 format?

If CERT RR's (or whatever RR we choose) contain public keys, then the  
standard supports an arbitrary number of cert formats without creating  
the need for an additional record every time an application wants a  
different type of cert.

> If the model is the only part validated is the public key in the  
> cert, that means that DNS resolver, DNS APIs, and authorities need  
> to be aware of the X.509 format.

Why is that?  Only the application needs to be aware of X.509 (or, in  
the case of OpenPGP via TLS, an OpenPGP key).  Once it gets the key  
out , it hashes it and checks it against the DNS hierarchy.

> But if the entire record is just validated as a single binary blob,  
> this means that different certificate formats could be used in the  
> future without needing to change anything other than the application  
> which is the final consumer of the new certificate type.

You would be forcing one of two things, either:
a. every application must be updated to use whatever cert standard you  
chose
b. you  must add duplicate entries for each public key for each new  
cert standard you chose

Neither seems optimal.

Date: Mon, 23 Aug 2010 11:41:26 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

I think the argument here is that making the hash cover only the key
means that the DNS processing layer needs to be aware of much more of
the internals of the cert format than he would like.

I agree.

Putting the authentication round the whole cert is much cleaner and
means that there is a better layer separation.

On Mon, Aug 23, 2010 at 11:36 AM, Paul Wouters <[email-masked]> wrote:
> On Mon, 23 Aug 2010, Nicholas Weaver wrote:
>
>>> I can understand using the container X.509 format, but it should really
>>> (IMHO) be limited to just the verification of the public key.
>>
>> Except that, IMO, there is a huge advantage to be had on simplicity of
>> just verifying the ENTIRE certificate. �Who says CERT RR's need to be just
>> X.509 format?
>
> So what is wrong with RFC 4398? You already have that. Your app grabs
> the CERT via CERT RR and then your application can do all its Cert/CA
> based validation it wants to. I am not saying that is wrong - I just
> don't understand why you need another RFC for that.
>
> I think there is a strong desire to have the option of not using X.509
> or PKIX at all, and base validation and verification purely on DNSSEC
> as a trust model.
>
> I thought this group was to work on a good standard for those
> applications, and that those who want to use certs, can stick with using
> RFC 4398 (or non-DNS based validation, eg EVR)
>
> Paul
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Mon, 23 Aug 2010 08:39:45 -0700
To: Paul Wouters <[email-masked]>
Cc: [email-masked], Nicholas Weaver <[email-masked]>
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 23, 2010, at 8:36 AM, Paul Wouters wrote:

> On Mon, 23 Aug 2010, Nicholas Weaver wrote:
> 
>>> I can understand using the container X.509 format, but it should really
>>> (IMHO) be limited to just the verification of the public key.
>> 
>> Except that, IMO, there is a huge advantage to be had on simplicity of just verifying the ENTIRE certificate.  Who says CERT RR's need to be just X.509 format?
> 
> So what is wrong with RFC 4398? You already have that. Your app grabs
> the CERT via CERT RR and then your application can do all its Cert/CA
> based validation it wants to. I am not saying that is wrong - I just
> don't understand why you need another RFC for that.

Except you still need an API to understand the DNSSEC chain involved in validating that CERT binary blob and to handle failures in a reasonable manner...

> I think there is a strong desire to have the option of not using X.509
> or PKIX at all, and base validation and verification purely on DNSSEC
> as a trust model.

I think of CERTs as not really requiring PKIX, eg, self-signed certs become much more useful if they are validated through DNSSEC.

> I thought this group was to work on a good standard for those
> applications, and that those who want to use certs, can stick with using
> RFC 4398 (or non-DNS based validation, eg EVR)

In many ways, I somewhat agree, but for a different reason:  CERT RRs are just a perfectly fine container class.  We probably don't need new RR types.

What we need is ways of using such container classes with DNSSEC: this doesn't add any new to-the-wire representatiton, but does require new ways (APIs, naming conventions) of using the DNSSEC data, both at a low level (APIs) and high level ("cookbook recipies").

Date: Mon, 23 Aug 2010 11:36:02 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Nicholas Weaver <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Mon, 23 Aug 2010, Nicholas Weaver wrote:

>> I can understand using the container X.509 format, but it should really
>> (IMHO) be limited to just the verification of the public key.
>
> Except that, IMO, there is a huge advantage to be had on simplicity of just verifying the ENTIRE certificate.  Who says CERT RR's need to be just X.509 format?

So what is wrong with RFC 4398? You already have that. Your app grabs
the CERT via CERT RR and then your application can do all its Cert/CA
based validation it wants to. I am not saying that is wrong - I just
don't understand why you need another RFC for that.

I think there is a strong desire to have the option of not using X.509
or PKIX at all, and base validation and verification purely on DNSSEC
as a trust model.

I thought this group was to work on a good standard for those
applications, and that those who want to use certs, can stick with using
RFC 4398 (or non-DNS based validation, eg EVR)

Paul

From: Steve Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 11:20:00 -0400
To: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 23, 2010, at 11:01 AM, Phillip Hallam-Baker wrote:
> Given the choice between giving people with brains the information
> they need to do the job right and not giving the information in case
> it is misused by cretins, I suggest taking the first approach.

I'm having trouble figuring out who the cretins vs the people with brains are in your scenario, but fortunately it doesn't matter if we design a system in which people can assert only what they are trusted to assert.

If your concern is...
> SSL use can be controlled by key use bits and extensions in the cert.

Then the answer is twofold:
1. these bits can continue to be used, and will be trusted if the CA is trusted
2. if you wish to enforce this in the absence of a CA-trusted cert, we can include an option in the RR standard for requiring SSL (which is an assertion that the zone controller can be trusted to make)

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Mon, 23 Aug 2010 08:19:35 -0700
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 23, 2010, at 8:08 AM, Paul Wouters wrote:

> On Mon, 23 Aug 2010, Simon Josefsson wrote:
> 
>>  2) The entire certificate, and even its chain, is confirmed by Secure
>>     DNS.  This allows the client to store the certificate locally and
>>     mark it as verified for a particular domain.  Further, some
>>     applications is relying on the content of certificates (think
>>     X.509 extensions).  With this proposal, the entire certificate is
>>     confirmed by DNSSEC, but with
>>     draft-hoffman-keys-linkage-from-dns-00 only the public key is
>>     directly confirmed.
> 
> This seems wrong to me. This is now mixing two authority sources, DNSSEC
> and the CA. And it introduced the possibility of conflicting authoritve
> sources. Other problems that come to mind are subjectAltnames that are
> in the wrong spot in the DNS hierarchy.
> 
> I can understand using the container X.509 format, but it should really
> (IMHO) be limited to just the verification of the public key.

Except that, IMO, there is a huge advantage to be had on simplicity of just verifying the ENTIRE certificate.  Who says CERT RR's need to be just X.509 format?  

If the model is the only part validated is the public key in the cert, that means that DNS resolver, DNS APIs, and authorities need to be aware of the X.509 format.  

But if the entire record is just validated as a single binary blob, this means that different certificate formats could be used in the future without needing to change anything other than the application which is the final consumer of the new certificate type.

Date: Mon, 23 Aug 2010 11:15:24 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Mon, 23 Aug 2010, Phillip Hallam-Baker wrote:

> I have written code to parse asn.1 in JavaScript. It is really no biggie.

A search for "ASN.1" at http://web.nvd.nist.gov/ gives me 13 hits.

Openswan (the project I develop for) had to released two CVE's in 7 years.
One of those was an ASN.1 bug.

ASN.1 is not trivial, and it is really best avoided if possible.

> * multiple has algorithms
> * multiple certs per host for different protocols
> * multiple certs per service for multiple hosts
> * support dynamic port assignment
> * nat friendly
> * client side certs for machine to machine protocols
> * validation of a cert that is in hand
> * discovery of a cert bound to a service
>
> I can meet all of these with either the CERT record or a new RR

But your list can also be changed s/cert/pubkey/g

> I believe we still need a new RR for the purpose of telling clients what protocol enhancements to use when connecting to a service. For example, is tis on offer for imap. DNSSEC should allow me to answer that question with certainty. I do not want to overload CERT for that purpose.

Yes, and ideally that new RR should come in as additional record when the query had some kind of EDNS
option set.

Paul

Date: Mon, 23 Aug 2010 11:08:13 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Mon, 23 Aug 2010, Simon Josefsson wrote:

>   2) The entire certificate, and even its chain, is confirmed by Secure
>      DNS.  This allows the client to store the certificate locally and
>      mark it as verified for a particular domain.  Further, some
>      applications is relying on the content of certificates (think
>      X.509 extensions).  With this proposal, the entire certificate is
>      confirmed by DNSSEC, but with
>      draft-hoffman-keys-linkage-from-dns-00 only the public key is
>      directly confirmed.

This seems wrong to me. This is now mixing two authority sources, DNSSEC
and the CA. And it introduced the possibility of conflicting authoritve
sources. Other problems that come to mind are subjectAltnames that are
in the wrong spot in the DNS hierarchy.

I can understand using the container X.509 format, but it should really
(IMHO) be limited to just the verification of the public key.

> D) It reduces DNS transfer sizes by splitting unrelated services into
>   separate domain names.  Consider if EXAMPLE.COM has 100 different
>   services running all using TLS.  With the CERT RR type in
>   draft-hoffman-keys-linkage-from-dns-00, a client querying for any
>   service will get the hash of the key used for all 100 services.  This
>   causes an unnecessary high load on the DNS servers and increased
>   message sizes.

This also seems to be able to conflict with valid key use as specified
in the X.509 certificate extended properties.

Paul

Date: Mon, 23 Aug 2010 11:01:28 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Steve Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

SSL use can be controlled by key use bits and extensions in the cert.

Given the choice between giving people with brains the information
they need to do the job right and not giving the information in case
it is misused by cretins, I suggest taking the first approach.

Part of what I would like to see happen here is to focus attention on
the difference between what is asserted in a cert and what is
trustworthy.

On Mon, Aug 23, 2010 at 10:47 AM, Steve Schultze <[email-masked]> wrote:
> On Aug 23, 2010, at 9:45 AM, Phillip Hallam-Baker wrote:
>> The hash has to go over the full cert data or else you are passing trusted attributes in an untrusted fashion. That would be utterly abominable security practice.
>
> How so? �The only way those attributes should be trusted is if a CA that signed the cert is trusted, as I described. �If you trust the CA, then the attributes are passed in a trusted fashion because the cert is signed. �As such, it is irrelevant whether the hash presented by the zone controller covers those attributes.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

From: Steve Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 10:47:18 -0400
To: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

On Aug 23, 2010, at 9:45 AM, Phillip Hallam-Baker wrote:
> The hash has to go over the full cert data or else you are passing trusted attributes in an untrusted fashion. That would be utterly abominable security practice. 

How so?  The only way those attributes should be trusted is if a CA that signed the cert is trusted, as I described.  If you trust the CA, then the attributes are passed in a trusted fashion because the cert is signed.  As such, it is irrelevant whether the hash presented by the zone controller covers those attributes.

From: Phillip Hallam-Baker <[email-masked]>
To: Steve Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 09:45:32 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

Reading asn.1 is really not difficult. Writing out DER encoding is painful in the extreme because the designers made a major goof. 

I have written code to parse asn.1 in JavaScript. It is really no biggie.

The hash has to go over the full cert data or else you are passing trusted attributes in an untrusted fashion. That would be utterly abominable security practice. 

We could do with a set of design goals. I suggest as starters

* multiple has algorithms
* multiple certs per host for different protocols
* multiple certs per service for multiple hosts
* support dynamic port assignment 
* nat friendly
* client side certs for machine to machine protocols
* validation of a cert that is in hand
* discovery of a cert bound to a service

I can meet all of these with either the CERT record or a new RR

On the constraints side we have

* must be wildcard safe 
* ability to use wildcards to specify certs for wild carded services.

I believe we still need a new RR for the purpose of telling clients what protocol enhancements to use when connecting to a service. For example, is tis on offer for imap. DNSSEC should allow me to answer that question with certainty. I do not want to overload CERT for that purpose.

Sent from my iPad

On Aug 23, 2010, at 9:22 AM, Steve Schultze <[email-masked]> wrote:

> Does this allow for wildcards in these CERT records?
> What happens when there are multiple certs per service?  How many certs is too many?
> Where in the record can you place options such as additional hash algorithms, or do you expect this to remain static for all time?
> 
> On signing the entire cert (B.2.), I do not believe that the zone operator is in the position to assert anything about the contents of the cert other than the domain-to-key mapping.  Any additional assertions (such as company name) are validated by the CA that issued the cert, and trusted because the CA is trusted.  Even if bank-of-america.com signs a cert saying that the domain owner is "Bank of America Corp.", there's no reason for me to blindly trust that assertion simply because the zone controller says it is so.  The only reason to trust it is if a trusted CA has signed the cert (in particular, the EV cert) and in that case it's irrelevant whether the zone controller published the hash of the entire cert or not.  On the other hand, publishing a hash of only the key means that client protocols that do not use X.509 certs can simply do basic key exchange and check that against DNS.
> 
> On Aug 23, 2010, at 4:00 AM, Simon Josefsson wrote:
>> Folks,
>> 
>> I have published the following document:
>> 
>> http://www.ietf.org/id/draft-josefsson-keyassure-tls-00.txt
>> 
>> It is similar to the draft-hoffman-keys-linkage-from-dns-00 document and
>> my inspiration for writing this came from that draft (thanks guys!).
>> However, there are a number of essential differences:
>> 
>> A) It uses the CERT RR with no alternatives.  I believe the CERT RR is
>>  intended for this, or at least a very similar purpose, and it is
>>  exensible enough to support this approach.
>> 
>> B) It confirms the entire TLS Certificate structure rather than just a
>>  X.509 public key.  There are two important advantages with this:
>> 
>>  1) OpenPGP in TLS is supported directly, as is any other certificate
>>     based authentication scheme that is using the TLS Certificate
>>     structure.
>> 
>>  2) The entire certificate, and even its chain, is confirmed by Secure
>>     DNS.  This allows the client to store the certificate locally and
>>     mark it as verified for a particular domain.  Further, some
>>     applications is relying on the content of certificates (think
>>     X.509 extensions).  With this proposal, the entire certificate is
>>     confirmed by DNSSEC, but with
>>     draft-hoffman-keys-linkage-from-dns-00 only the public key is
>>     directly confirmed.
>> 
>> C) It makes it possible to have different services on the same port but
>>  on different protocols (TCP vs UDP).  In
>>  draft-hoffman-keys-linkage-from-dns-00 I do no see a way to run a
>>  DTLS service on UDP and a TLS service on TCP on the same port number
>>  and reliably learn the intended hash.
>> 
>> D) It reduces DNS transfer sizes by splitting unrelated services into
>>  separate domain names.  Consider if EXAMPLE.COM has 100 different
>>  services running all using TLS.  With the CERT RR type in
>>  draft-hoffman-keys-linkage-from-dns-00, a client querying for any
>>  service will get the hash of the key used for all 100 services.  This
>>  causes an unnecessary high load on the DNS servers and increased
>>  message sizes.
>> 
>> E) The RR data is only a hash value, and there are no binary integer
>>  encoding and variable length string issues.  Administrators can add
>>  the hash value in DNS zone files by adding the record easily.
>> 
>> F) There is a one-to-one mapping between the RR in the zone file and a
>>  particular TLS-enabled service.  This means that it is possible to
>>  delegate authority for the RR to the person responsible for that
>>  TLS-enabled service.  In draft-hoffman-keys-linkage-from-dns-00, if a
>>  service on port 4711 changes RSA key, this leads to a CERT RR change
>>  even for the CERT RR used for port 443.  In production environments,
>>  I would not want to touch the 443 CERT RR just because someone is
>>  adding an unrelated and potentially experimental service.
>> 
>> /Simon
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
> 
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Phillip Hallam-Baker <[email-masked]>
To: Simon Josefsson <[email-masked]>
Date: Mon, 23 Aug 2010 09:29:40 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] more early work

This works better than the original certain scheme. But I don't like the binding to ports. It works for tls server security but not for ws-* security and client side. 

For example, how does this work for chat and voip protocols where the port assignment is dynamic?

I don't like binding to one hash algorithm either. If you want to avoid having a dns hash field then we should use an asn1 oid in the hash field. Cert handling code can already deal with those.

One idea I had was to use the hash used in the cert signature to create a prefix tag that goes in the dns. So to declare a binding for cert fingerprint whdgchjwdgcjhdcwjhg at example.com there would be a record

_whdgchjwdgcjhdcwjhg.example.com CERT 1 9 http://repository.example.com/cert1

This approach works if you have the cert in hand when you validate. It also means that we can use the CERT field for a URL link to the repository where the cert can be pulled from.

That helps when trying to use this scheme to support a key to be used for key exchange with a dns resolver. 

Then I got started thinking about what a wildcard record would do to this. 

There has to be authentication to the right of the RR type. I would like authentication plus a URL to make the scheme fully general. 

_whdgchjwdgcjhdcwjhg.example.com CERT 1 10  whdgchjwdgcjhdcwjhg
_whdgchjwdgcjhdcwjhg.example.com CERT 1 8 http://example.com/cert1

Then in order to get binding to a specific service I would add in the srv prefix.

_whdgchjwdgcjhdcwjhg._http._tcp.example.com CERT ....

Sorry about the presentation here. This is a real &)$)&$)$& to enter on a touch screen without real copy and paste.

Sent from my iPad

On Aug 21, 2010, at 3:49 AM, Simon Josefsson <[email-masked]> wrote:

> Hi all.  I wanted to point to two more earlier work in this area:
> 
> http://tools.ietf.org/html/draft-josefsson-siked-framework-00
> http://tools.ietf.org/html/draft-josefsson-pkix-dns-00
> 
> The first one contains an overview of problems and solutions around that
> time and the goal was (IIRC) to do a BoF/WG at that time.  I hope things
> go better this time! ;)
> 
> /Simon
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Steve Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 09:22:57 -0400
To: [email-masked]
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

Does this allow for wildcards in these CERT records?
What happens when there are multiple certs per service?  How many certs is too many?
Where in the record can you place options such as additional hash algorithms, or do you expect this to remain static for all time?

On signing the entire cert (B.2.), I do not believe that the zone operator is in the position to assert anything about the contents of the cert other than the domain-to-key mapping.  Any additional assertions (such as company name) are validated by the CA that issued the cert, and trusted because the CA is trusted.  Even if bank-of-america.com signs a cert saying that the domain owner is "Bank of America Corp.", there's no reason for me to blindly trust that assertion simply because the zone controller says it is so.  The only reason to trust it is if a trusted CA has signed the cert (in particular, the EV cert) and in that case it's irrelevant whether the zone controller published the hash of the entire cert or not.  On the other hand, publishing a hash of only the key means that client protocols that do not use X.509 certs can simply do basic key exchange and check that against DNS.

On Aug 23, 2010, at 4:00 AM, Simon Josefsson wrote:
> Folks,
> 
> I have published the following document:
> 
> http://www.ietf.org/id/draft-josefsson-keyassure-tls-00.txt
> 
> It is similar to the draft-hoffman-keys-linkage-from-dns-00 document and
> my inspiration for writing this came from that draft (thanks guys!).
> However, there are a number of essential differences:
> 
> A) It uses the CERT RR with no alternatives.  I believe the CERT RR is
>   intended for this, or at least a very similar purpose, and it is
>   exensible enough to support this approach.
> 
> B) It confirms the entire TLS Certificate structure rather than just a
>   X.509 public key.  There are two important advantages with this:
> 
>   1) OpenPGP in TLS is supported directly, as is any other certificate
>      based authentication scheme that is using the TLS Certificate
>      structure.
> 
>   2) The entire certificate, and even its chain, is confirmed by Secure
>      DNS.  This allows the client to store the certificate locally and
>      mark it as verified for a particular domain.  Further, some
>      applications is relying on the content of certificates (think
>      X.509 extensions).  With this proposal, the entire certificate is
>      confirmed by DNSSEC, but with
>      draft-hoffman-keys-linkage-from-dns-00 only the public key is
>      directly confirmed.
> 
> C) It makes it possible to have different services on the same port but
>   on different protocols (TCP vs UDP).  In
>   draft-hoffman-keys-linkage-from-dns-00 I do no see a way to run a
>   DTLS service on UDP and a TLS service on TCP on the same port number
>   and reliably learn the intended hash.
> 
> D) It reduces DNS transfer sizes by splitting unrelated services into
>   separate domain names.  Consider if EXAMPLE.COM has 100 different
>   services running all using TLS.  With the CERT RR type in
>   draft-hoffman-keys-linkage-from-dns-00, a client querying for any
>   service will get the hash of the key used for all 100 services.  This
>   causes an unnecessary high load on the DNS servers and increased
>   message sizes.
> 
> E) The RR data is only a hash value, and there are no binary integer
>   encoding and variable length string issues.  Administrators can add
>   the hash value in DNS zone files by adding the record easily.
> 
> F) There is a one-to-one mapping between the RR in the zone file and a
>   particular TLS-enabled service.  This means that it is possible to
>   delegate authority for the RR to the person responsible for that
>   TLS-enabled service.  In draft-hoffman-keys-linkage-from-dns-00, if a
>   service on port 4711 changes RSA key, this leads to a CERT RR change
>   even for the CERT RR used for port 443.  In production environments,
>   I would not want to touch the 443 CERT RR just because someone is
>   adding an unrelated and potentially experimental service.
> 
> /Simon
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Mon, 23 Aug 2010 15:05:41 +0200
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Key linkage draft, -00 edition

On 08/22/2010 10:39 PM, Phillip Hallam-Baker wrote:
> On Sun, Aug 22, 2010 at 4:26 PM, Jakob Schlyter <[email-masked]> wrote:
>> On 22 aug 2010, at 15.13, Phillip Hallam-Baker wrote:
>>
>>> There are multiple design choices here:
>>>
>>> 1) Use TXT vs a new RR.
>>
>> The choices where actually CERT vs TXT vs new RR.
> 
> CERT seems sub-optimal to me since in most connection oriented
> protocols the cert is passed in band. That is the case for both SSL
> and SSH and for WS-*. The only protocols I know of where the certs
> need to be pulled out of band are email messaging and the world has
> already rejected that approach for S/MIME.

SAML and IMI (aka information card) uses quite a bit of XML-DSIG both in
trust establishment and in the protocol flows (as I believe you know
;-)) and the world hasn't rejected those yet.

	Cheers Leif

From: Simon Josefsson <[email-masked]>
To: [email-masked]
OpenPGP: id�65716F; url=http://josefsson.org/key.txt
Date: Mon, 23 Aug 2010 14:14:03 +0200
Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

Simon Josefsson <[email-masked]> writes:

> However, there are a number of essential differences:

I forgot this nice feature:

G) The TLS library does not have to do ASN.1/DER decoding to find the
   public key to hash before comparing with the DNS data.

A TLS library without ASN.1/DER but with X.509 certificate validation
via CERT would be possible.  Yay.

/Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
OpenPGP: id�65716F; url=http://josefsson.org/key.txt
Date: Mon, 23 Aug 2010 10:00:25 +0200
Subject: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

Folks,

I have published the following document:

http://www.ietf.org/id/draft-josefsson-keyassure-tls-00.txt

It is similar to the draft-hoffman-keys-linkage-from-dns-00 document and
my inspiration for writing this came from that draft (thanks guys!).
However, there are a number of essential differences:

A) It uses the CERT RR with no alternatives.  I believe the CERT RR is
   intended for this, or at least a very similar purpose, and it is
   exensible enough to support this approach.

B) It confirms the entire TLS Certificate structure rather than just a
   X.509 public key.  There are two important advantages with this:

   1) OpenPGP in TLS is supported directly, as is any other certificate
      based authentication scheme that is using the TLS Certificate
      structure.

   2) The entire certificate, and even its chain, is confirmed by Secure
      DNS.  This allows the client to store the certificate locally and
      mark it as verified for a particular domain.  Further, some
      applications is relying on the content of certificates (think
      X.509 extensions).  With this proposal, the entire certificate is
      confirmed by DNSSEC, but with
      draft-hoffman-keys-linkage-from-dns-00 only the public key is
      directly confirmed.

C) It makes it possible to have different services on the same port but
   on different protocols (TCP vs UDP).  In
   draft-hoffman-keys-linkage-from-dns-00 I do no see a way to run a
   DTLS service on UDP and a TLS service on TCP on the same port number
   and reliably learn the intended hash.

D) It reduces DNS transfer sizes by splitting unrelated services into
   separate domain names.  Consider if EXAMPLE.COM has 100 different
   services running all using TLS.  With the CERT RR type in
   draft-hoffman-keys-linkage-from-dns-00, a client querying for any
   service will get the hash of the key used for all 100 services.  This
   causes an unnecessary high load on the DNS servers and increased
   message sizes.

E) The RR data is only a hash value, and there are no binary integer
   encoding and variable length string issues.  Administrators can add
   the hash value in DNS zone files by adding the record easily.

F) There is a one-to-one mapping between the RR in the zone file and a
   particular TLS-enabled service.  This means that it is possible to
   delegate authority for the RR to the person responsible for that
   TLS-enabled service.  In draft-hoffman-keys-linkage-from-dns-00, if a
   service on port 4711 changes RSA key, this leads to a CERT RR change
   even for the CERT RR used for port 443.  In production environments,
   I would not want to touch the 443 CERT RR just because someone is
   adding an unrelated and potentially experimental service.

/Simon

Date: Sun, 22 Aug 2010 20:38:54 -0500
From: Anthony Iliopoulos <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: Phillip Hallam-Baker <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Key linkage draft, -00 edition

On Sun, Aug 22, 2010 at 05:32:16PM -0700, Paul Hoffman wrote:
> At 7:19 PM -0400 8/22/10, Phillip Hallam-Baker wrote:
> >On Sun, Aug 22, 2010 at 5:08 PM, Warren Kumari <[email-masked]> wrote:
> >>
> >> On Aug 22, 2010, at 4:39 PM, Phillip Hallam-Baker wrote:
> >>
> >>> On Sun, Aug 22, 2010 at 4:26 PM, Jakob Schlyter <[email-masked]> wrote:
> >>>> On 22 aug 2010, at 15.13, Phillip Hallam-Baker wrote:
> >>>>
> >>>>> There are multiple design choices here:
> >>>>>
> >>>>> 1) Use TXT vs a new RR.
> >>>>
> >>>> The choices where actually CERT vs TXT vs new RR.
> >>>
> >>> CERT seems sub-optimal to me since in most connection oriented
> >>> protocols the cert is passed in band. That is the case for both SSL
> >>> and SSH and for WS-*. The only protocols I know of where the certs
> >>> need to be pulled out of band are email messaging and the world has
> >>> already rejected that approach for S/MIME.
> >>>
> >>> Using CERT RRs means that the size of the messages will inevitably
> >>> spill over the 512 byte DNS boundary and will be close to the 1500
> >>> byte Ethernet MTU.
> >>
> >> Which is why the discussion has been to publish the fingerprint / hash and not the key / cert itself... You get key and validate that FP matches...
> >
> >So in the context of TXT, CERT or new RR, you are agreed that this
> >cannot be done with the CERT record?
> 
> Not at all; see <http://www.ietf.org/id/draft-hoffman-keys-linkage-from-dns-00.txt>.

I was actually about to respond that the CERT RR is extensible enough
to accommodate the fingerprint easily; just allocate a new type value
and the corresponding semantics, reserve one byte for the hash algorithm
type and the rest of the cert section is the fingerprint, but apparently
I had TLSFP in the back of my head.

Reading through the draft again, I wonder what is the motivation behind
including a TCP/UDP port number field. Although there is the provision
for specifying that the FP is valid for all ports, what purpose is that
field meant to serve ? It is introducing an additional authorization
layer/dimension to the TLS process. What is the consumer of this restriction
expected to be ? What if this needs to be more fine-grained e.g. allow
only a specific transport, or a transport other than TCP/UDP ?

Regards,
Anthony

Date: Sun, 22 Aug 2010 21:35:46 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Key linkage draft, -00 edition

OK, I had forgotten that 4398 had introduced URL types for certs. So
the principle that the cert record contain certs is already gone.

Do existing servers support adding new CERT types any more easily than new RRs?

How about storing a cert URL plus a hash? Two CERT records with the
same tag or define a new subformat to contain both parts?

As a practical matter we may have a bug in the standards process here
since according to RFC 4398 creating new CERT types requires a
standards action while assigning a new RR does not.

Rereading 4398, it is really not apparent how a relying party gets
from an SSL session initiation to a DNS cert record. It appears that
the tag field was intended for this, but I don't see how it can work,
the explanation is certainly rather vauge.

I would suggest combining the CERT record with the protocol specific
prefixing approach taken in DKIM.

On Sun, Aug 22, 2010 at 8:32 PM, Paul Hoffman <[email-masked]> wrote:
> At 7:19 PM -0400 8/22/10, Phillip Hallam-Baker wrote:
>>On Sun, Aug 22, 2010 at 5:08 PM, Warren Kumari <[email-masked]> wrote:
>>>
>>> On Aug 22, 2010, at 4:39 PM, Phillip Hallam-Baker wrote:
>>>
>>>> On Sun, Aug 22, 2010 at 4:26 PM, Jakob Schlyter <[email-masked]> wrote:
>>>>> On 22 aug 2010, at 15.13, Phillip Hallam-Baker wrote:
>>>>>
>>>>>> There are multiple design choices here:
>>>>>>
>>>>>> 1) Use TXT vs a new RR.
>>>>>
>>>>> The choices where actually CERT vs TXT vs new RR.
>>>>
>>>> CERT seems sub-optimal to me since in most connection oriented
>>>> protocols the cert is passed in band. That is the case for both SSL
>>>> and SSH and for WS-*. The only protocols I know of where the certs
>>>> need to be pulled out of band are email messaging and the world has
>>>> already rejected that approach for S/MIME.
>>>>
>>>> Using CERT RRs means that the size of the messages will inevitably
>>>> spill over the 512 byte DNS boundary and will be close to the 1500
>>>> byte Ethernet MTU.
>>>
>>> Which is why the discussion has been to publish the fingerprint / hash and not the key / cert itself... You get key and validate that FP matches...
>>
>>So in the context of TXT, CERT or new RR, you are agreed that this
>>cannot be done with the CERT record?
>
> Not at all; see <http://www.ietf.org/id/draft-hoffman-keys-linkage-from-dns-00.txt>.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

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

Date: Sun, 22 Aug 2010 17:32:16 -0700
To: Phillip Hallam-Baker <[email-masked]>, Warren Kumari <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Key linkage draft, -00 edition

At 7:19 PM -0400 8/22/10, Phillip Hallam-Baker wrote:
>On Sun, Aug 22, 2010 at 5:08 PM, Warren Kumari <[email-masked]> wrote:
>>
>> On Aug 22, 2010, at 4:39 PM, Phillip Hallam-Baker wrote:
>>
>>> On Sun, Aug 22, 2010 at 4:26 PM, Jakob Schlyter <[email-masked]> wrote:
>>>> On 22 aug 2010, at 15.13, Phillip Hallam-Baker wrote:
>>>>
>>>>> There are multiple design choices here:
>>>>>
>>>>> 1) Use TXT vs a new RR.
>>>>
>>>> The choices where actually CERT vs TXT vs new RR.
>>>
>>> CERT seems sub-optimal to me since in most connection oriented
>>> protocols the cert is passed in band. That is the case for both SSL
>>> and SSH and for WS-*. The only protocols I know of where the certs
>>> need to be pulled out of band are email messaging and the world has
>>> already rejected that approach for S/MIME.
>>>
>>> Using CERT RRs means that the size of the messages will inevitably
>>> spill over the 512 byte DNS boundary and will be close to the 1500
>>> byte Ethernet MTU.
>>
>> Which is why the discussion has been to publish the fingerprint / hash and not the key / cert itself... You get key and validate that FP matches...
>
>So in the context of TXT, CERT or new RR, you are agreed that this
>cannot be done with the CERT record?

Not at all; see <http://www.ietf.org/id/draft-hoffman-keys-linkage-from-dns-00.txt>.

--Paul Hoffman, Director
--VPN Consortium

Date: Sun, 22 Aug 2010 19:19:14 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Key linkage draft, -00 edition

On Sun, Aug 22, 2010 at 5:08 PM, Warren Kumari <[email-masked]> wrote:
>
> On Aug 22, 2010, at 4:39 PM, Phillip Hallam-Baker wrote:
>
>> On Sun, Aug 22, 2010 at 4:26 PM, Jakob Schlyter <[email-masked]> wrote:
>>> On 22 aug 2010, at 15.13, Phillip Hallam-Baker wrote:
>>>
>>>> There are multiple design choices here:
>>>>
>>>> 1) Use TXT vs a new RR.
>>>
>>> The choices where actually CERT vs TXT vs new RR.
>>
>> CERT seems sub-optimal to me since in most connection oriented
>> protocols the cert is passed in band. That is the case for both SSL
>> and SSH and for WS-*. The only protocols I know of where the certs
>> need to be pulled out of band are email messaging and the world has
>> already rejected that approach for S/MIME.
>>
>> Using CERT RRs means that the size of the messages will inevitably
>> spill over the 512 byte DNS boundary and will be close to the 1500
>> byte Ethernet MTU.
>
> Which is why the discussion has been to publish the fingerprint / hash and not the key / cert itself... You get key and validate that FP matches...

So in the context of TXT, CERT or new RR, you are agreed that this
cannot be done with the CERT record?

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

From: Warren Kumari <[email-masked]>
Date: Sun, 22 Aug 2010 17:08:33 -0400
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Key linkage draft, -00 edition

On Aug 22, 2010, at 4:39 PM, Phillip Hallam-Baker wrote:

> On Sun, Aug 22, 2010 at 4:26 PM, Jakob Schlyter <[email-masked]> wrote:
>> On 22 aug 2010, at 15.13, Phillip Hallam-Baker wrote:
>> 
>>> There are multiple design choices here:
>>> 
>>> 1) Use TXT vs a new RR.
>> 
>> The choices where actually CERT vs TXT vs new RR.
> 
> CERT seems sub-optimal to me since in most connection oriented
> protocols the cert is passed in band. That is the case for both SSL
> and SSH and for WS-*. The only protocols I know of where the certs
> need to be pulled out of band are email messaging and the world has
> already rejected that approach for S/MIME.
> 
> Using CERT RRs means that the size of the messages will inevitably
> spill over the 512 byte DNS boundary and will be close to the 1500
> byte Ethernet MTU.

Which is why the discussion has been to publish the fingerprint / hash and not the key / cert itself... You get key and validate that FP matches...

W

> 
> Yes we can back off into TCP, but that does not work very well through
> firewalls. I think we have a much cleaner approach using a new RR.
> 
> 
>>> In this case the use of a new RR is relatively unproblematic since we
>>> are assuming or at least encouraging the use of DNSSEC to sign the
>>> records and thus there is no need to support DNS servers that do not
>>> support additional RRs.
>> 
>> There is more than serving unknown RRs - one should also consider the provisioning side of things and the client API.
> 
> This was the deciding factor in DKIM.
> 
> While I think that there is a use for DNS key assurance without
> DNSSEC, mine is a minority view and my support for unsigned key
> assurance is strictly to try to hook them on using DNSSEC anyway.
> 
> If we are expecting DNSSEC, I think we can expect there to be an
> assumption of some degree of flexibility for provisioning. And this
> whole effort will require a new API set. Instead of gethostbyname, I
> would see us using getserviceconnection call that takes the name and
> protocol label as criteria and returns a trust path for evaluation.
> 
> 
> -- 
> Website: http://hallambaker.com/
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Sun, 22 Aug 2010 16:39:18 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Jakob Schlyter <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Key linkage draft, -00 edition

On Sun, Aug 22, 2010 at 4:26 PM, Jakob Schlyter <[email-masked]> wrote:
> On 22 aug 2010, at 15.13, Phillip Hallam-Baker wrote:
>
>> There are multiple design choices here:
>>
>> 1) Use TXT vs a new RR.
>
> The choices where actually CERT vs TXT vs new RR.

CERT seems sub-optimal to me since in most connection oriented
protocols the cert is passed in band. That is the case for both SSL
and SSH and for WS-*. The only protocols I know of where the certs
need to be pulled out of band are email messaging and the world has
already rejected that approach for S/MIME.

Using CERT RRs means that the size of the messages will inevitably
spill over the 512 byte DNS boundary and will be close to the 1500
byte Ethernet MTU.

Yes we can back off into TCP, but that does not work very well through
firewalls. I think we have a much cleaner approach using a new RR.

>> In this case the use of a new RR is relatively unproblematic since we
>> are assuming or at least encouraging the use of DNSSEC to sign the
>> records and thus there is no need to support DNS servers that do not
>> support additional RRs.
>
> There is more than serving unknown RRs - one should also consider the provisioning side of things and the client API.

This was the deciding factor in DKIM.

While I think that there is a use for DNS key assurance without
DNSSEC, mine is a minority view and my support for unsigned key
assurance is strictly to try to hook them on using DNSSEC anyway.

If we are expecting DNSSEC, I think we can expect there to be an
assumption of some degree of flexibility for provisioning. And this
whole effort will require a new API set. Instead of gethostbyname, I
would see us using getserviceconnection call that takes the name and
protocol label as criteria and returns a trust path for evaluation.

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

From: Jakob Schlyter <[email-masked]>
Date: Sun, 22 Aug 2010 22:26:48 +0200
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Key linkage draft, -00 edition

On 22 aug 2010, at 15.13, Phillip Hallam-Baker wrote:

> There are multiple design choices here:
> 
> 1) Use TXT vs a new RR.

The choices where actually CERT vs TXT vs new RR.

> In this case the use of a new RR is relatively unproblematic since we
> are assuming or at least encouraging the use of DNSSEC to sign the
> records and thus there is no need to support DNS servers that do not
> support additional RRs.

There is more than serving unknown RRs - one should also consider the provisioning side of things and the client API.

	jakob

Date: Sun, 22 Aug 2010 09:13:43 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Key linkage draft, -00 edition

DKIM uses a TXT record because it was designed to work with existing
DNS and inparticular with servers that do not support additional
records. For example the Windows DNS server where Microsoft presented
code from the server to dismiss claims to the effect that it could be
used to publish additional records.

There are multiple design choices here:

1) Use TXT vs a new RR.

In this case the use of a new RR is relatively unproblematic since we
are assuming or at least encouraging the use of DNSSEC to sign the
records and thus there is no need to support DNS servers that do not
support additional RRs.

Conclusion: New RR

2) Use of an ASCII format field with internal syntax versus DNS binary field

This is what I took Stephen to be suggesting. And I prefer this
approach since it means that we adopt a tag-value structure and
automatically gain the extensibility I believe is going to be
necessary to make this protocol work.

Those of us who have experience of DKIM know that this is going to
prove rather more complex than the fixed binary draft on the table. I
do not see a great value in trying to make the binary draft into an
extensible scheme, the savings in bits are rather trivial, the
complexity introduced into the code is considerable.

In particular, I really don't want to go for a scheme that introduces
yet another registry of code points to be registered for the tags in
the tag value pairs. Different protocols are going to have different
security requirements and some will require additional tags. In the
world of Web Services, protocol designs are going to proliferate
rapidly and creating choke points for code point assignment is going
to discourage use of the scheme.

Conclusion: Use ASCII

3) Use of existing DKIM tags versus new tags

Reuse of the DKIM tags is a tricky question, it would be a good idea
if we are going to use the same architecture and the tags can have the
same semantics. Since we require different semantics I would prefer to
use different tags since the same person is likely to be configuring
both sets of tags and confusion is going to be rather likely.

Here another design choice of DKIM may be significant, the choice of
single letter tags in a UNIX style command line format. I dislike this
approach as it means I have to always consult a manual to look at what
the tags mean.

Conclusion: Use different tags to those employed in DKIM

4) Use prefix records or per-protocol records.

As we have seen, the fact that a key is acceptable for one protocol
does not mean that it is acceptable for another. Consider a site that
has a payment invoicing application and a Web site on the same domain
name. We don't want to have the cross site scripting vulnerabilities
in the Web site enabling an attacker to start authorizing invoices for
payment (that would be bad).

Here the question is whether we are only going to support a limited
number of protocols or design something that can be used as generic
infrastructure for Web Services.

We already have several thousand Web Services in use. Protocols that
involve humans tend to be rather limited in number. Anyone can write
their own mail protocol, but people only want to use one mail
application. So once SMTP appeared there was no room for new
protocols. That constraint does not apply to Web services, payment
gateways typically support a different protocol per payment processor
(allegedly there is a standard - not).

If we accept that there will be tens of thousands of Web Service
protocols, burning a RR per protocol is clearly unacceptable.

The objection made in the IAB options draft had to do with wildcards
and prefixing TXT as a substitute for a new RR. These do not apply
here since we are using a new RR and the wildcard issue is fixable if
relevant.

Conclusion: Use SRV style prefixes

Putting these together, I see the following as the simplest example:

_http._tcp.www.example.com OPTIONS "ssl=offered
certh=sha256:0b92c7808b91f7dc1cadaf8f9afe4d9834372adcc3e18f1d
4df6704768eea870"

If we have more than one cert:

_smtp._tcp.example.com OPTIONS "ssl=offered"

cert1._smtp._tcp.example.com OPTIONS
"certh=(3e8e64500a2ac1ea38203ef943c5e3188e1e537076b7846219996aa225e76c0e)"
cert2._smtp._tcp.example.com OPTIONS
"certh=(a7fc2dcd765f94801bc06edd6420aad6cfe7fbfaa38113a5
e860a00607343b0d)"

Where the certs have the corresponding labels cert1 and cert2 embedded
as part of the issue process.

On Thu, Aug 19, 2010 at 10:59 AM, Paul Hoffman <[email-masked]> wrote:
>>Quick question: did you consider DKIM key records for this?
>>(With a new "s=" value in the TXT RR.)
>>
>>If so, why don't they rate a mention? If not, maybe worth a
>>look?
>
> First off, the idea of TXT RRs without _label prefixes has been mostly deprecated in the IETF. Second, the idea of saying "this isn't DKIM, it's this new thing" by changing "s=" is begging for trouble. There are enough tricky semantics in the DKIM spec (not as many as in PKIX, but it sometimes feels that way) that reusing it would likely prevent us from having the freedom we want.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Sat, 21 Aug 2010 15:01:13 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] who to trust
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Phillip and all,

  Yes, and this tactic from David and Randy has been used
many times before with unfortunately significant success.
As such the Internet community has on occasion been damaged
accordingly and to some degree suffers still as history has 
clearly shown.

-----Original Message-----
>From: Phillip Hallam-Baker <[email-masked]>
>Sent: Aug 20, 2010 5:08 PM
>To: David Conrad <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [keyassure] who to trust
>
>You know for people who say they want to focus on technology, you do
>all keep digging.
>
>Damn right I consider forming PIR as a bidding consortium and
>participating in a share of the profits on the award of the contract
>to be a commercial relationship.
>
>
>By the way, agenda denial is not a particularly effective tactic on
>me. I keep attempting to engage on technical proposals, I note that
>instead you and others prefer to focus on the assumptions on which my
>proposals are based and make assertions that you then declare to be
>off limits for discussion and then declare the conversation closed.
>
>
>On Fri, Aug 20, 2010 at 5:25 PM, David Conrad <[email-masked]> wrote:
>> Phillip,
>>
>> On Aug 20, 2010, at 1:09 PM, Phillip Hallam-Baker wrote:
>>> Last I heard isoc has a financial interest in .org
>>
>> So, your logic is that because PIR has a contract with ICANN for the operation of .ORG, ISOC receives money from PIR, and ISOC supports the IETF, that this imputes a commercial relationship between IETF and ICANN?  Really?
>>
>>> Qualifying that with the weasel word direct and claiming it impacts my credibility would seem to saymore about yours
>>
>> Riiight.  As Randy Bush might say <plonk>.
>>
>> Regards,
>> -drc
>>
>>
>
>
>
>-- 
>Website: http://hallambaker.com/
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

From: Simon Josefsson <[email-masked]>
To: [email-masked]
OpenPGP: id�65716F; url=http://josefsson.org/key.txt
Date: Sat, 21 Aug 2010 09:49:26 +0200
Subject: [keyassure] more early work

Hi all.  I wanted to point to two more earlier work in this area:

http://tools.ietf.org/html/draft-josefsson-siked-framework-00
http://tools.ietf.org/html/draft-josefsson-pkix-dns-00

The first one contains an overview of problems and solutions around that
time and the goal was (IIRC) to do a BoF/WG at that time.  I hope things
go better this time! ;)

/Simon

Date: Fri, 20 Aug 2010 18:08:13 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: David Conrad <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] who to trust

You know for people who say they want to focus on technology, you do
all keep digging.

Damn right I consider forming PIR as a bidding consortium and
participating in a share of the profits on the award of the contract
to be a commercial relationship.

By the way, agenda denial is not a particularly effective tactic on
me. I keep attempting to engage on technical proposals, I note that
instead you and others prefer to focus on the assumptions on which my
proposals are based and make assertions that you then declare to be
off limits for discussion and then declare the conversation closed.

On Fri, Aug 20, 2010 at 5:25 PM, David Conrad <[email-masked]> wrote:
> Phillip,
>
> On Aug 20, 2010, at 1:09 PM, Phillip Hallam-Baker wrote:
>> Last I heard isoc has a financial interest in .org
>
> So, your logic is that because PIR has a contract with ICANN for the operation of .ORG, ISOC receives money from PIR, and ISOC supports the IETF, that this imputes a commercial relationship between IETF and ICANN? �Really?
>
>> Qualifying that with the weasel word direct and claiming it impacts my credibility would seem to saymore about yours
>
> Riiight. �As Randy Bush might say <plonk>.
>
> Regards,
> -drc
>
>

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

Date: Fri, 20 Aug 2010 16:44:28 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: David Conrad <[email-masked]>, Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] who to trust
Reply-To: "Jeffrey A. Williams" <[email-masked]>

David and all,

  The financial relationship between PIR and the ISOC regarding
.ORG one has to admit is symbiotic, but perhaps not a COI
yet, But no one really knows that for sure do they?

  ICANN leadership has emphatically stated on more than
one occasion that the IETF is ICANN's "Good right arm".
So yes the arms length relationship between PIR/ICANN is two 
pronged at least.  Still again this does not necessarly
mean that there is 'problem' with such a relationship but
the appearance of such gives some pause.  There are also
some strong potential positives in such relationships that
can and do benifit everyone...   

-----Original Message-----
>From: David Conrad <[email-masked]>
>Sent: Aug 20, 2010 4:25 PM
>To: Phillip Hallam-Baker <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [keyassure] who to trust
>
>Phillip,
>
>On Aug 20, 2010, at 1:09 PM, Phillip Hallam-Baker wrote:
>> Last I heard isoc has a financial interest in .org
>
>So, your logic is that because PIR has a contract with ICANN for the operation of .ORG, ISOC receives money from PIR, and ISOC supports the IETF, that this imputes a commercial relationship between IETF and ICANN?  Really?
>
>> Qualifying that with the weasel word direct and claiming it impacts my credibility would seem to saymore about yours
>
>Riiight.  As Randy Bush might say <plonk>.
>
>Regards,
>-drc
>
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

From: David Conrad <[email-masked]>
Date: Fri, 20 Aug 2010 14:25:44 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] who to trust

Phillip,

On Aug 20, 2010, at 1:09 PM, Phillip Hallam-Baker wrote:
> Last I heard isoc has a financial interest in .org

So, your logic is that because PIR has a contract with ICANN for the operation of .ORG, ISOC receives money from PIR, and ISOC supports the IETF, that this imputes a commercial relationship between IETF and ICANN?  Really?

> Qualifying that with the weasel word direct and claiming it impacts my credibility would seem to saymore about yours

Riiight.  As Randy Bush might say <plonk>.

Regards,
-drc

From: Phillip Hallam-Baker <[email-masked]>
To: David Conrad <[email-masked]>
Date: Fri, 20 Aug 2010 16:09:03 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] who to trust

Last I heard isoc has a financial interest in .org

Qualifying that with the weasel word direct and claiming it impacts my  
credibility would seem to saymore about yours

Sent from my iPhone

On 20 Aug 2010, at 14:08, David Conrad <[email-masked]> wrote:

> On Aug 20, 2010, at 10:34 AM, Phillip Hallam-Baker wrote:
>> Since DNSSEC is not deployed, it is clearly not fully understood.
>
> DNSSEC is deployed at the root, at a couple dozen TLDs, and about  
> 24,000 other zones (according to SecSpider).
>
>> I am not proposing a new trust scheme. I am proposing that we permit
>> use of either the new trust scheme that you are proposing or the
>> existing trust scheme that has a 15 year deployment history.
>
> I believe one of the reasons people are looking at DNSSEC as a way  
> to build a new PKI (to use a shorthand) is because the existing  
> trust schemes have significant flaws. I'm unclear as to why you'd  
> like to import those flaws into the efforts here, but Paul's  
> hypothesis would appear reasonable.
>
>> As for your imputation of a commercial motive here, I suggest that  
>> you
>> consider whether you want to open up that topic of discussion. ICANN
>> has a commercial relationship to IETF through ISOC.
>
> No it doesn't. This is no direct relationship, commercial or  
> otherwise, between ICANN and ISOC. I'm curious why you think there  
> would be. There is a relationship between ICANN and the IETF (IASA,  
> IAOC, whatever) in the form of performance SLAs for registry  
> modifications, but I have difficulty seeing this as commercial or in  
> any way related to keyassure.
>
> You really should stop making things up -- it damages your  
> credibility.
>
> Regards,
> -drc
>

From: Steve Schultze <[email-masked]>
Date: Fri, 20 Aug 2010 15:04:34 -0400
To: [email-masked]
Subject: Re: [keyassure] who to trust

On Aug 20, 2010, at 1:34 PM, Phillip Hallam-Baker wrote:
> Since my scheme is already deployed and should be well understood by
> all participating in these discussions, I fail to see why there is a
> need for a draft on my part. If you understand the browser trust root
> model you will understand my proposal as being a logical refinement
> thereof to introduce more accountability just as I did with my
> proposal for EV certs.

What is your proposed scheme?  All I can find is:

On Aug 19, 2010, at 9:01 AM, Phillip Hallam-Baker wrote:
> The simple solution for this is to allow for certs in the dnssec trust path to validate KSKs. This would supplement the TLD signature if available.

Assuming I understand you correctly, it's not clear to me why this is any more secure than the current practice of CAs issuing certs for the leaf node TLS keys themselves.  Putting it in the DNSSEC trust path just perhaps adds a dependency for the DNSSEC TA (I can't tell from your two sentences if it's required to be signed and validated as such).  If you want (DNSSEC TA)+CA, zone controllers can just place the hash of each leaf's CA-issued cert in DNS (which is compatible with the main thrust of this group's proposed direction so far).  If you'r proposing that this is a mechanism for allowing third-party CAs to vouch for a KSK at some higher level of the DNS hierarchy such that they create an alternate trust hierarchy that subverts the exclusive domain-based delegation of the TLDs (and further sub-domains), then there are a whole host of questions which are most certainly outside the scope of what most of us are trying to do here.  As far as I can tell, none of this would have any bearing on a proposed mechanism for placing DNSSEC-signed leaf node key material in DNS (whether it chains to the ICANN root or elsewhere, via locally specified TAs or your scheme).

In any case, I don't intend this as an invitation to start a discussion on the merits but rather as a demonstration of why an I-D and a separate discussion seems appropriate to me as well.

From: David Conrad <[email-masked]>
Date: Fri, 20 Aug 2010 11:08:58 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] who to trust

On Aug 20, 2010, at 10:34 AM, Phillip Hallam-Baker wrote:
> Since DNSSEC is not deployed, it is clearly not fully understood.

DNSSEC is deployed at the root, at a couple dozen TLDs, and about 24,000 other zones (according to SecSpider).

> I am not proposing a new trust scheme. I am proposing that we permit
> use of either the new trust scheme that you are proposing or the
> existing trust scheme that has a 15 year deployment history.

I believe one of the reasons people are looking at DNSSEC as a way to build a new PKI (to use a shorthand) is because the existing trust schemes have significant flaws. I'm unclear as to why you'd like to import those flaws into the efforts here, but Paul's hypothesis would appear reasonable.
 
> As for your imputation of a commercial motive here, I suggest that you
> consider whether you want to open up that topic of discussion. ICANN
> has a commercial relationship to IETF through ISOC.

No it doesn't. This is no direct relationship, commercial or otherwise, between ICANN and ISOC. I'm curious why you think there would be. There is a relationship between ICANN and the IETF (IASA, IAOC, whatever) in the form of performance SLAs for registry modifications, but I have difficulty seeing this as commercial or in any way related to keyassure.

You really should stop making things up -- it damages your credibility.

Regards,
-drc

Date: Fri, 20 Aug 2010 12:48:40 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] who to trust
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Paul and all,

  As you already know the 'Trust system' you refrence is
not widely trusted.  There inlies the crux of the problem
and brings up multipul issues.  I for one still contend
that there never was, and still isn't a rough consensus
in respect to the 'Trust system' to which your refrence
in your remarks/statements below...

  That yet again re-stated and none the less, moving forward
'as is' is a compermise that we can supposedly attempt
to move forward with in a constructive manner.

-----Original Message-----
>From: Paul Hoffman <[email-masked]>
>Sent: Aug 20, 2010 12:11 PM
>To: Phillip Hallam-Baker <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] who to trust
>
>I strongly support a charter that specifically ties the gaining of trust that a key/cert is associated with a domain name to the DNS itself, using the DNSSEC protocol as the cryptographic protection for the binding statements. Doing so uses a trust system that is well understood and a protocol that is well understood.
>
>It is fine to propose that a different trust system be used. In order to make that proposal understandable, you can write an Internet Draft that explains the trust system and compares it to the ones commonly in use today (PKIX certificates with CAs, OpenPGP certificates with web-of-trust, DNS responses signed with DNSSEC).
>
>It is fine to propose that DNS responses be used but to use a different cryptographic method for assuring the origin. In order to make that proposal understandable, you can write an Internet Draft that explains the new cryptographic binding, and compare it to DNSSEC.
>
>At 11:33 AM -0400 8/20/10, Phillip Hallam-Baker wrote:
>>An IETF WG charter requires more than consensus amongst the proposers.
>>There has to be an IETF consensus and the IESG has to concur and there
>>has to be an AD willing to accept the WG.
>>
>>Making assertions and then ruling rebuttals as 'off topic' as you keep
>>doing is not the way to get an IETF charter accepted.
>
>Yes, it is.
>
>Allowing one person to derail the charter discussion because he or his employer doesn't like where it is going is not considered a best practice in the IETF. Instead, if you think that you have a group of people that would support your view, start your own pre-BoF mailing list, show that you have an interested group, and bring that to the IESG.
>
>>If you want to persist in making a proposal which tries to enforce a
>>certain trust model then it has to be in the security area.
>
>Your "has to be" and "must be" statements are not backed by any known precedent, are they?
>
>>I think
>>you will find at least one of the security ADs rather skeptical of the
>>viability of a single rooted model as even the US federal government
>>could not come to agreement on that architecture.
>
>And, at that point, we can continue the discussion with them. So far, you are only speculating in a way that supports your (to this point) lone opinion.
>
>>Consensus does not mean that you get to choose a group of people who
>>want to do it your way and then get a WG chartered to coronate that
>>specific proposal.
>
>Nor does it mean listening to one person who repeats arguments over and over without gaining support from others in the discussion. Some of us prefer the former method to the one you are proposing.
>
>--Paul Hoffman, Director
>--VPN Consortium
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

Date: Fri, 20 Aug 2010 13:47:54 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] who to trust

On Fri, Aug 20, 2010 at 01:34:30PM -0400, Phillip Hallam-Baker wrote:
> Since DNSSEC is not deployed, it is clearly not fully understood.

What are you talking about?  It is so deployed.  I can validate
answers from the root.  I can validate isoc.org from the root on down.

If what you are claiming instead is that DNSSEC is not fully deployed
always and everywhere, I don't think that premise even slightly
supports your other claim that DNSSEC is not fully understood.

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

Date: Fri, 20 Aug 2010 13:34:30 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] who to trust

Since DNSSEC is not deployed, it is clearly not fully understood.

I am not proposing a new trust scheme. I am proposing that we permit
use of either the new trust scheme that you are proposing or the
existing trust scheme that has a 15 year deployment history.

Since my scheme is already deployed and should be well understood by
all participating in these discussions, I fail to see why there is a
need for a draft on my part. If you understand the browser trust root
model you will understand my proposal as being a logical refinement
thereof to introduce more accountability just as I did with my
proposal for EV certs.

However, should you be insisting that the only way that we can
approach this problem is to do it your way and that we cannot listen
to any other, then I am going to keep asking questions that my
experience makes me know to be relevant and which you are not able to
answer.

As for your imputation of a commercial motive here, I suggest that you
consider whether you want to open up that topic of discussion. ICANN
has a commercial relationship to IETF through ISOC. None of us are
communists (well hardly any).

For the record, I was retired from April 2009 and only began
discussions with Comodo a few months back. I made similar observations
in my talk at RSA2010 when I was fully retired. I have made similar
statements in the same time period on the IETF and DNSEXT list. If you
recall, I objected to the notion that there be a single root for the
BGP Security solution.

I believe that your assertions in this regard are unhelpful, unfair
and should be withdrawn immediately.

On Fri, Aug 20, 2010 at 1:11 PM, Paul Hoffman <[email-masked]> wrote:
> I strongly support a charter that specifically ties the gaining of trust that a key/cert is associated with a domain name to the DNS itself, using the DNSSEC protocol as the cryptographic protection for the binding statements. Doing so uses a trust system that is well understood and a protocol that is well understood.
>
> It is fine to propose that a different trust system be used. In order to make that proposal understandable, you can write an Internet Draft that explains the trust system and compares it to the ones commonly in use today (PKIX certificates with CAs, OpenPGP certificates with web-of-trust, DNS responses signed with DNSSEC).
>
> It is fine to propose that DNS responses be used but to use a different cryptographic method for assuring the origin. In order to make that proposal understandable, you can write an Internet Draft that explains the new cryptographic binding, and compare it to DNSSEC.
>
> At 11:33 AM -0400 8/20/10, Phillip Hallam-Baker wrote:
>>An IETF WG charter requires more than consensus amongst the proposers.
>>There has to be an IETF consensus and the IESG has to concur and there
>>has to be an AD willing to accept the WG.
>>
>>Making assertions and then ruling rebuttals as 'off topic' as you keep
>>doing is not the way to get an IETF charter accepted.
>
> Yes, it is.
>
> Allowing one person to derail the charter discussion because he or his employer doesn't like where it is going is not considered a best practice in the IETF. Instead, if you think that you have a group of people that would support your view, start your own pre-BoF mailing list, show that you have an interested group, and bring that to the IESG.
>
>>If you want to persist in making a proposal which tries to enforce a
>>certain trust model then it has to be in the security area.
>
> Your "has to be" and "must be" statements are not backed by any known precedent, are they?
>
>>I think
>>you will find at least one of the security ADs rather skeptical of the
>>viability of a single rooted model as even the US federal government
>>could not come to agreement on that architecture.
>
> And, at that point, we can continue the discussion with them. So far, you are only speculating in a way that supports your (to this point) lone opinion.
>
>>Consensus does not mean that you get to choose a group of people who
>>want to do it your way and then get a WG chartered to coronate that
>>specific proposal.
>
> Nor does it mean listening to one person who repeats arguments over and over without gaining support from others in the discussion. Some of us prefer the former method to the one you are proposing.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

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

Date: Fri, 20 Aug 2010 10:11:53 -0700
To: Phillip Hallam-Baker <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] who to trust

I strongly support a charter that specifically ties the gaining of trust that a key/cert is associated with a domain name to the DNS itself, using the DNSSEC protocol as the cryptographic protection for the binding statements. Doing so uses a trust system that is well understood and a protocol that is well understood.

It is fine to propose that a different trust system be used. In order to make that proposal understandable, you can write an Internet Draft that explains the trust system and compares it to the ones commonly in use today (PKIX certificates with CAs, OpenPGP certificates with web-of-trust, DNS responses signed with DNSSEC).

It is fine to propose that DNS responses be used but to use a different cryptographic method for assuring the origin. In order to make that proposal understandable, you can write an Internet Draft that explains the new cryptographic binding, and compare it to DNSSEC.

At 11:33 AM -0400 8/20/10, Phillip Hallam-Baker wrote:
>An IETF WG charter requires more than consensus amongst the proposers.
>There has to be an IETF consensus and the IESG has to concur and there
>has to be an AD willing to accept the WG.
>
>Making assertions and then ruling rebuttals as 'off topic' as you keep
>doing is not the way to get an IETF charter accepted.

Yes, it is.

Allowing one person to derail the charter discussion because he or his employer doesn't like where it is going is not considered a best practice in the IETF. Instead, if you think that you have a group of people that would support your view, start your own pre-BoF mailing list, show that you have an interested group, and bring that to the IESG.

>If you want to persist in making a proposal which tries to enforce a
>certain trust model then it has to be in the security area.

Your "has to be" and "must be" statements are not backed by any known precedent, are they?

>I think
>you will find at least one of the security ADs rather skeptical of the
>viability of a single rooted model as even the US federal government
>could not come to agreement on that architecture.

And, at that point, we can continue the discussion with them. So far, you are only speculating in a way that supports your (to this point) lone opinion.

>Consensus does not mean that you get to choose a group of people who
>want to do it your way and then get a WG chartered to coronate that
>specific proposal.

Nor does it mean listening to one person who repeats arguments over and over without gaining support from others in the discussion. Some of us prefer the former method to the one you are proposing.

--Paul Hoffman, Director
--VPN Consortium

Date: Fri, 20 Aug 2010 12:52:05 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

That was a private, offlist email that you have now chosen to share
with the whole list.

While I probably should have remembered to flag it as [offlist], it is
generally proper to take care not to do this sort of thing.

Again, if you propose a technical infrastructure that has a dependency
on one particular party, then the behavior of that party becomes
relevant in the technical discussion.

If you wish to avoid that you must design an architecture that removes
the dependency.

from	Phillip Hallam-Baker <[email-masked]>
to	Ond�ej Sur� <[email-masked]>
date	Fri, Aug 20, 2010 at 7:49 AM
subject	Re: [keyassure] Charter discussion - Use of DNSSEC in applications
mailed-by	gmail.com

On Fri, Aug 20, 2010 at 9:58 AM, Ond�ej Sur� <[email-masked]> wrote:
> On 20.8.2010 13:49, Phillip Hallam-Baker wrote:
>>
>> Seems to me that you are making statements and then ruling objections
>> to those statements as off topic.
>
> You are ripping my words out of the context. �I am saying that this is no
> place to discuss whether we trust "ICANN, Verisign or USG". �This group has
> the proposed charter based on fact that we are going to use DNS and DNSSEC,
> and we trust it.
>
> Again this should be a place where the work is done, and not a chitchat list
> for discussing whether US companies are good or not. �And I ask all
> participants to respect that.
>
>> - Show quoted text -
>> Exactly. �The change of the trust model will be always scary. �But it
>> is important to realize that we don't change overall level of security
>> (in fact, we are improving it), just the trust model.
>>
>>
>> Ondrej
>>
>> On Fri, Aug 20, 2010 at 4:24 AM, Ond�ej Sur�<[email-masked]> �wrote:
>>>
>>> [moderator hat on]
>>> This is really off-topic. �Please cease a discussion on who to trust.
>>> This
>>> group is to get work done and not to discuss irrelevant topics like this.
>>> �Don't clutter the mailing list, thanks.
>>> [/moderator hat off]
>
>
> --
> �Ond�ej Sur�
> �vedouc� v�zkumu/Head of R&D department
> �-------------------------------------------
> �CZ.NIC, z.s.p.o. � �-- � �Laborato�e CZ.NIC
> �Americka 23, 120 00 Praha 2, Czech Republic
> �mailto:[email-masked] � �http://nic.cz/
> �tel:+420.222745110 � � � fax:+420.222745112
> �-------------------------------------------
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

From: "Richard L. Barnes" <[email-masked]>
To: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 20 Aug 2010 11:58:58 -0400
Cc: Tony Finch <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] who to trust

If the goal is an IETF working group, then the topic is protocol design.

"Key assurance" is a really inaccurate name.  If I were choosing, I  
would have used something like "Name Authentication with DNSSEC  
Assertions" (NADA!).

--Richard

On Aug 20, 2010, at 11:31 AM, Jeffrey A. Williams wrote:

> +2
>
>  But arn't we really concerned here more about key
> assurance and less about protocol design?
>
>
> -----Original Message-----
>> From: "Richard L. Barnes" <[email-masked]>
>> Sent: Aug 19, 2010 10:27 PM
>> To: Paul Hoffman <[email-masked]>
>> Cc: Tony Finch <[email-masked]>, [email-masked]
>> Subject: Re: [keyassure] who to trust
>>
>> +1
>>
>> All this trust anchor discussion is really irrelevant to protocol
>> design.  We just make the chains, the relying parties choose what
>> trust anchors to hang them from.
>>
>> --Richard
>>
>>
>> On Aug 19, 2010, at 9:16 PM, Paul Hoffman wrote:
>>
>>> At 2:01 AM +0100 8/20/10, Tony Finch wrote:
>>>> It seems to me from this week's discussion that (exaggerating
>>>> slightly) no
>>>> one wants to trust the x.509 certificate authorities and no one
>>>> wants to
>>>> trust ICANN's DNSSEC root anchor.
>>>
>>> Exaggerating wildly, I would say. Who other than Phill have said
>>> they don't trust ICANN's DNSSEC root anchor?
>>>
>>> --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
>
> Regards,
>
> Jeffrey A. Williams
> Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and  
> growing, strong!)
> "Obedience of the law is the greatest freedom" -
>   Abraham Lincoln
>
> "Credit should go with the performance of duty and not with what is  
> very
> often the accident of glory" - Theodore Roosevelt
>
> "If the probability be called P; the injury, L; and the burden, B;  
> liability
> depends upon whether B is less than L multiplied by
> P: i.e., whether B is less than PL."
> United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
> ===============================> Updated 1/26/04
> CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.  
> div. of
> Information Network Eng.  INEG. INC.
> ABA member in good standing member ID 01257402 E-Mail [email-masked]
> Phone: 214-244-4827

From: Steve Schultze <[email-masked]>
Date: Fri, 20 Aug 2010 11:43:58 -0400
To: [email-masked]
Subject: Re: [keyassure] who to trust

I like Richard's alternative charter proposal, which incorporates much of what Phillip wrote.  If it's easier to get consensus for it without paragraphs 2 and 3, that's fine.  I think it does a good job of laying out the problem area and scope, which includes the idea that zone controllers directly place key material in their zone.  I think that this functionality is in effect a new (or at least augmented) trust model, but Phillip doesn't think so given that his draft also included language to this effect and he thinks we can't be talking about trust models.  Frankly I don't care whether we call it a trust model or not as long as we get some work done.

In any case, the question of trust _anchor_ selection is out of scope according to both Richard and Phillip's drafts, so let's stop talking about it.

On Aug 20, 2010, at 11:33 AM, Phillip Hallam-Baker wrote:
> An IETF WG charter requires more than consensus amongst the proposers.
> There has to be an IETF consensus and the IESG has to concur and there
> has to be an AD willing to accept the WG.
> 
> Making assertions and then ruling rebuttals as 'off topic' as you keep
> doing is not the way to get an IETF charter accepted.
> 
> 
> If you want to persist in making a proposal which tries to enforce a
> certain trust model then it has to be in the security area. I think
> you will find at least one of the security ADs rather skeptical of the
> viability of a single rooted model as even the US federal government
> could not come to agreement on that architecture.
> 
> Consensus does not mean that you get to choose a group of people who
> want to do it your way and then get a WG chartered to coronate that
> specific proposal.
> 
> 
> 
> On Fri, Aug 20, 2010 at 11:04 AM, Ond�ej Sur� <[email-masked]> wrote:
>> On 20.8.2010 16:46, Phillip Hallam-Baker wrote:
>>> 
>>> Plenty of people have asserted that the objective is to do PKI for
>>> 'free'. Others have expressed the opinion that certain services are
>>> 'overpriced'.
>>> 
>>> Those are pricing discussions.
>>> 
>>> 
>>> If you read the other charter proposals you will see that they both
>>> contain statements to the effect that the advantage the group seeks to
>>> realize is to enforce use of a single root of trust. Those are the
>>> parts I find unacceptable.
>> 
>> Just to repeat what Paul already said.  You seem to be the only one who
>> complains.  Or is there anybody else who has similar objections?  If you are
>> out there, please speak up.
>> 
>> I would like to remind you that the IETF process works on rough consensus.
>>  Right now my feeling is that you are standing alone with your opinions on
>> what is acceptable and what is not.  And that's a hardly rough consensus to
>> change the charter.
>> 
>> I don't want to say that I (and other people) won't hear your complaints and
>> won't change the charter, but "plenty of people" (to cite you) is much
>> closer to rough consensus.  I would be happier to find a total 100%
>> consensus on our work, but if you barricade yourself in your position that
>> would be very very hard to achieve.
>> 
>> I was told that standard IETF process is a way how to have things not done
>> and that I am naive to push this through IETF, but I would like to prove
>> them wrong.
>> 
>> Ondrej
>> --
>>  Ond�ej Sur�
>>  vedouc� v�zkumu/Head of R&D department
>>  -------------------------------------------
>>  CZ.NIC, z.s.p.o.    --    Laborato�e CZ.NIC
>>  Americka 23, 120 00 Praha 2, Czech Republic
>>  mailto:[email-masked]    http://nic.cz/
>>  tel:+420.222745110       fax:+420.222745112
>>  -------------------------------------------
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>> 
> 
> 
> 
> -- 
> Website: http://hallambaker.com/
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Fri, 20 Aug 2010 11:33:48 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] who to trust

An IETF WG charter requires more than consensus amongst the proposers.
There has to be an IETF consensus and the IESG has to concur and there
has to be an AD willing to accept the WG.

Making assertions and then ruling rebuttals as 'off topic' as you keep
doing is not the way to get an IETF charter accepted.

If you want to persist in making a proposal which tries to enforce a
certain trust model then it has to be in the security area. I think
you will find at least one of the security ADs rather skeptical of the
viability of a single rooted model as even the US federal government
could not come to agreement on that architecture.

Consensus does not mean that you get to choose a group of people who
want to do it your way and then get a WG chartered to coronate that
specific proposal.

On Fri, Aug 20, 2010 at 11:04 AM, Ond�ej Sur� <[email-masked]> wrote:
> On 20.8.2010 16:46, Phillip Hallam-Baker wrote:
>>
>> Plenty of people have asserted that the objective is to do PKI for
>> 'free'. Others have expressed the opinion that certain services are
>> 'overpriced'.
>>
>> Those are pricing discussions.
>>
>>
>> If you read the other charter proposals you will see that they both
>> contain statements to the effect that the advantage the group seeks to
>> realize is to enforce use of a single root of trust. Those are the
>> parts I find unacceptable.
>
> Just to repeat what Paul already said. �You seem to be the only one who
> complains. �Or is there anybody else who has similar objections? �If you are
> out there, please speak up.
>
> I would like to remind you that the IETF process works on rough consensus.
> �Right now my feeling is that you are standing alone with your opinions on
> what is acceptable and what is not. �And that's a hardly rough consensus to
> change the charter.
>
> I don't want to say that I (and other people) won't hear your complaints and
> won't change the charter, but "plenty of people" (to cite you) is much
> closer to rough consensus. �I would be happier to find a total 100%
> consensus on our work, but if you barricade yourself in your position that
> would be very very hard to achieve.
>
> I was told that standard IETF process is a way how to have things not done
> and that I am naive to push this through IETF, but I would like to prove
> them wrong.
>
> Ondrej
> --
> �Ond�ej Sur�
> �vedouc� v�zkumu/Head of R&D department
> �-------------------------------------------
> �CZ.NIC, z.s.p.o. � �-- � �Laborato�e CZ.NIC
> �Americka 23, 120 00 Praha 2, Czech Republic
> �mailto:[email-masked] � �http://nic.cz/
> �tel:+420.222745110 � � � fax:+420.222745112
> �-------------------------------------------
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Fri, 20 Aug 2010 10:31:52 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>, Paul Hoffman <[email-masked]>
Cc: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: [keyassure] who to trust
Reply-To: "Jeffrey A. Williams" <[email-masked]>

+2

  But arn't we really concerned here more about key
assurance and less about protocol design?

-----Original Message-----
>From: "Richard L. Barnes" <[email-masked]>
>Sent: Aug 19, 2010 10:27 PM
>To: Paul Hoffman <[email-masked]>
>Cc: Tony Finch <[email-masked]>, [email-masked]
>Subject: Re: [keyassure] who to trust
>
>+1
>
>All this trust anchor discussion is really irrelevant to protocol  
>design.  We just make the chains, the relying parties choose what  
>trust anchors to hang them from.
>
>--Richard
>
>
>On Aug 19, 2010, at 9:16 PM, Paul Hoffman wrote:
>
>> At 2:01 AM +0100 8/20/10, Tony Finch wrote:
>>> It seems to me from this week's discussion that (exaggerating  
>>> slightly) no
>>> one wants to trust the x.509 certificate authorities and no one  
>>> wants to
>>> trust ICANN's DNSSEC root anchor.
>>
>> Exaggerating wildly, I would say. Who other than Phill have said  
>> they don't trust ICANN's DNSSEC root anchor?
>>
>> --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

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

From: "Richard L. Barnes" <[email-masked]>
To: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 20 Aug 2010 11:24:16 -0400
Cc: [email-masked], Phillip Hallam-Baker <[email-masked]>, Scott Rea <[email-masked]>
Subject: Re: [keyassure] who to trust

Let's try this again: Selection of trust anchors is not a topic for  
this list.  Not that it's not important; it's just irrelevant for  
protocol engineering.

On Aug 20, 2010, at 11:08 AM, Jeffrey A. Williams wrote:

> Phillip and all,
>
>  From a personal prefrence point of view only, I would
> much prefer a single root of trust.  But the practical
> and technical side of me keeps such notions in check as
> such notions are not realistic.  Same would be so for
> free PKI.  Free PKI is not realistic.  Inexpensive PKI
> is definately possible and done now.  However business
> entities see t eh potential huge quick profit potential
> and will likely put upward pressure on PKI costs.
>
>  Back the roots of trust and trust models and methods.
>
>  What we seem to be gradually moving towards is multipul
> trust roots with the seemingly growing desire to do so
> via a inside DNS method, OR the use of trust anchors
> for validation of certs but with a simpler yet robust
> means of providing same.   So two of my questions are
> for now:
>
> 1.) How many trust anchors is sufficient and/or trustworthy
>    and how is the trustworthyness of same determined?
>
> 2.)Key strength of certs: is NIST's current standard sufficient?
>   My answer to this currently is NO.
>
> 3.) Is the current trust chain for trusted anchors sufficient,
>    secure, and also consistantly trustworthy?
>
>  What we do know is that there at least 5m domains that
> by any reasonably thinking person are not presently
> trustworthy and need to either become so via some
> means of method, or be dispensed with entirely.
> See:
>
> http://news.slashdot.org/story/10/08/16/214228/5-Million-Domains-Serving-Malware-Via-Netwo%7C
>
> http://blog.armorize.com/2010/08/smci-widget-by-network-solutions-still.html
> http://www.net-security.org/malware_news.php?id31
> http://blog.armorize.com/2010/08/more-than-500000-network-solutions.html
>
>
> -----Original Message-----
>> From: Phillip Hallam-Baker <[email-masked]>
>> Sent: Aug 20, 2010 9:46 AM
>> To: "Richard L. Barnes" <[email-masked]>
>> Cc: [email-masked], Scott Rea <[email-masked]>
>> Subject: Re: [keyassure] who to trust
>>
>> Plenty of people have asserted that the objective is to do PKI for
>> 'free'. Others have expressed the opinion that certain services are
>> 'overpriced'.
>>
>> Those are pricing discussions.
>>
>>
>> If you read the other charter proposals you will see that they both
>> contain statements to the effect that the advantage the group seeks  
>> to
>> realize is to enforce use of a single root of trust. Those are the
>> parts I find unacceptable.
>>
>>
>> On Fri, Aug 20, 2010 at 10:40 AM, Richard L. Barnes  
>> <[email-masked]> wrote:
>>>> If people want to propose a system with a single point of failure  
>>>> then
>>>> that point of failure has to be on the table for discussion. The  
>>>> only
>>>> reason I brought ICANN up is that others insisted that we only  
>>>> design
>>>> a system where the only choice is to trust the ICANN monopoly.
>>>
>>> [Citation needed]
>>>
>>>
>>>> I do not think that we want two separate groups, one to do DNSSEC  
>>>> for
>>>> applications using only the ICANN root and a separate group for
>>>> applications using a choice of roots. And even if we wanted to, I
>>>> doubt that a charter of that nature could be accepted by the IESG.
>>>
>>> Obviously we don't, because this whole discussion is completely  
>>> unrelated to
>>> a choice of trust anchors.  DNSSEC and other protocols we develop  
>>> in the
>>> IETF do not require any relying party to use any given trust  
>>> anchor.  If you
>>> want a concrete example, just look at the DLV.
>>>
>>>
>>>> One other charter point. We cannot have any discussion of pricing  
>>>> of
>>>> products or services (including 'free'). IETF rules have been quite
>>>> lax on this point to date. However we have to take care not to be  
>>>> the
>>>> group that brings down the lawyers.
>>>
>>> That seems kind of obvious.  Who has expressed a desire to discuss  
>>> pricing?
>>>
>>> --Richard
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> On Fri, Aug 20, 2010 at 6:43 AM, Scott Rea  
>>>> <[email-masked]>
>>>> wrote:
>>>>>
>>>>>  On 8/19/2010 9:16 PM, Paul Hoffman wrote:
>>>>>>
>>>>>> At 2:01 AM +0100 8/20/10, Tony Finch wrote:
>>>>>>>
>>>>>>> It seems to me from this week's discussion that (exaggerating  
>>>>>>> slightly)
>>>>>>> no
>>>>>>> one wants to trust the x.509 certificate authorities and no  
>>>>>>> one wants
>>>>>>> to
>>>>>>> trust ICANN's DNSSEC root anchor.
>>>>>>
>>>>>> Exaggerating wildly, I would say. Who other than Phill have  
>>>>>> said they
>>>>>> don't trust ICANN's DNSSEC root anchor?
>>>>>>
>>>>>> --Paul Hoffman, Director
>>>>>> --VPN Consortium
>>>>>> _______________________________________________
>>>>>> keyassure mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>>>
>>>>> Hmmm... nothing against ICANN personally, but lots against a  
>>>>> single point
>>>>> of
>>>>> failure, I prefer to share that responsibility around
>>>>>
>>>>> --
>>>>> Scott Rea
>>>>> Sr PKI Architect (Contractor)
>>>>> Em: [email-masked]
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keyassure mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Website: http://hallambaker.com/
>>>> _______________________________________________
>>>> keyassure mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>
>>>
>>
>>
>>
>> -- 
>> Website: http://hallambaker.com/
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>
> Regards,
>
> Jeffrey A. Williams
> Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and  
> growing, strong!)
> "Obedience of the law is the greatest freedom" -
>   Abraham Lincoln
>
> "Credit should go with the performance of duty and not with what is  
> very
> often the accident of glory" - Theodore Roosevelt
>
> "If the probability be called P; the injury, L; and the burden, B;  
> liability
> depends upon whether B is less than L multiplied by
> P: i.e., whether B is less than PL."
> United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
> ===============================> Updated 1/26/04
> CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.  
> div. of
> Information Network Eng.  INEG. INC.
> ABA member in good standing member ID 01257402 E-Mail [email-masked]
> Phone: 214-244-4827

Date: Fri, 20 Aug 2010 10:19:50 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>,  Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Scott Rea <[email-masked]>
Subject: Re: [keyassure] who to trust
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Richard and all,

  Do I understand you right stating what you said below
differently, that your less concerned regarding the end
points than ensuring that the binded keys to any domain name
overlaying DNS is valid and/or good?  If I do understand
you right, than I see your point.  But shouldn't we
have a better/stronger and known trusted starting point?
Can the user even assume same necessarly?  

-----Original Message-----
>From: "Richard L. Barnes" <[email-masked]>
>Sent: Aug 20, 2010 9:55 AM
>To: Phillip Hallam-Baker <[email-masked]>
>Cc: [email-masked], Scott Rea <[email-masked]>
>Subject: Re: [keyassure] who to trust
>
>Ah, I have only just now read the initial charter proposal that Warren  
>sent out.  I agree that that one is too root-centric.
>
>But clearly the problem can be phrased more in terms of application  
>needs (binding keys to domain names) and validation paths (overlaid on  
>DNS) instead of what TAs those paths end in.  That's what I tried to  
>do in my earlier proposal.
>
>
>
>
>On Aug 20, 2010, at 10:46 AM, Phillip Hallam-Baker wrote:
>
>> Plenty of people have asserted that the objective is to do PKI for
>> 'free'. Others have expressed the opinion that certain services are
>> 'overpriced'.
>>
>> Those are pricing discussions.
>>
>>
>> If you read the other charter proposals you will see that they both
>> contain statements to the effect that the advantage the group seeks to
>> realize is to enforce use of a single root of trust. Those are the
>> parts I find unacceptable.
>>
>>
>> On Fri, Aug 20, 2010 at 10:40 AM, Richard L. Barnes  
>> <[email-masked]> wrote:
>>>> If people want to propose a system with a single point of failure  
>>>> then
>>>> that point of failure has to be on the table for discussion. The  
>>>> only
>>>> reason I brought ICANN up is that others insisted that we only  
>>>> design
>>>> a system where the only choice is to trust the ICANN monopoly.
>>>
>>> [Citation needed]
>>>
>>>
>>>> I do not think that we want two separate groups, one to do DNSSEC  
>>>> for
>>>> applications using only the ICANN root and a separate group for
>>>> applications using a choice of roots. And even if we wanted to, I
>>>> doubt that a charter of that nature could be accepted by the IESG.
>>>
>>> Obviously we don't, because this whole discussion is completely  
>>> unrelated to
>>> a choice of trust anchors.  DNSSEC and other protocols we develop  
>>> in the
>>> IETF do not require any relying party to use any given trust  
>>> anchor.  If you
>>> want a concrete example, just look at the DLV.
>>>
>>>
>>>> One other charter point. We cannot have any discussion of pricing of
>>>> products or services (including 'free'). IETF rules have been quite
>>>> lax on this point to date. However we have to take care not to be  
>>>> the
>>>> group that brings down the lawyers.
>>>
>>> That seems kind of obvious.  Who has expressed a desire to discuss  
>>> pricing?
>>>
>>> --Richard
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> On Fri, Aug 20, 2010 at 6:43 AM, Scott Rea <[email-masked]>
>>>> wrote:
>>>>>
>>>>>  On 8/19/2010 9:16 PM, Paul Hoffman wrote:
>>>>>>
>>>>>> At 2:01 AM +0100 8/20/10, Tony Finch wrote:
>>>>>>>
>>>>>>> It seems to me from this week's discussion that (exaggerating  
>>>>>>> slightly)
>>>>>>> no
>>>>>>> one wants to trust the x.509 certificate authorities and no one  
>>>>>>> wants
>>>>>>> to
>>>>>>> trust ICANN's DNSSEC root anchor.
>>>>>>
>>>>>> Exaggerating wildly, I would say. Who other than Phill have said  
>>>>>> they
>>>>>> don't trust ICANN's DNSSEC root anchor?
>>>>>>
>>>>>> --Paul Hoffman, Director
>>>>>> --VPN Consortium
>>>>>> _______________________________________________
>>>>>> keyassure mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>>>
>>>>> Hmmm... nothing against ICANN personally, but lots against a  
>>>>> single point
>>>>> of
>>>>> failure, I prefer to share that responsibility around
>>>>>
>>>>> --
>>>>> Scott Rea
>>>>> Sr PKI Architect (Contractor)
>>>>> Em: [email-masked]
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keyassure mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Website: http://hallambaker.com/
>>>> _______________________________________________
>>>> keyassure mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>
>>>
>>
>>
>>
>> -- 
>> Website: http://hallambaker.com/
>
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

Date: Fri, 20 Aug 2010 10:08:33 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>,  "Richard L. Barnes" <[email-masked]>
Cc: [email-masked], Scott Rea <[email-masked]>
Subject: Re: [keyassure] who to trust
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Phillip and all,

  From a personal prefrence point of view only, I would
much prefer a single root of trust.  But the practical
and technical side of me keeps such notions in check as
such notions are not realistic.  Same would be so for 
free PKI.  Free PKI is not realistic.  Inexpensive PKI
is definately possible and done now.  However business
entities see t eh potential huge quick profit potential
and will likely put upward pressure on PKI costs.

  Back the roots of trust and trust models and methods.

  What we seem to be gradually moving towards is multipul
trust roots with the seemingly growing desire to do so
via a inside DNS method, OR the use of trust anchors
for validation of certs but with a simpler yet robust
means of providing same.   So two of my questions are 
for now:

1.) How many trust anchors is sufficient and/or trustworthy
    and how is the trustworthyness of same determined?

2.)Key strength of certs: is NIST's current standard sufficient?
   My answer to this currently is NO.

3.) Is the current trust chain for trusted anchors sufficient,
    secure, and also consistantly trustworthy?

  What we do know is that there at least 5m domains that
by any reasonably thinking person are not presently
trustworthy and need to either become so via some
means of method, or be dispensed with entirely.
See:

http://news.slashdot.org/story/10/08/16/214228/5-Million-Domains-Serving-Malware-Via-Netwo%7C

http://blog.armorize.com/2010/08/smci-widget-by-network-solutions-still.html
http://www.net-security.org/malware_news.php?id=1431
http://blog.armorize.com/2010/08/more-than-500000-network-solutions.html

-----Original Message-----
>From: Phillip Hallam-Baker <[email-masked]>
>Sent: Aug 20, 2010 9:46 AM
>To: "Richard L. Barnes" <[email-masked]>
>Cc: [email-masked], Scott Rea <[email-masked]>
>Subject: Re: [keyassure] who to trust
>
>Plenty of people have asserted that the objective is to do PKI for
>'free'. Others have expressed the opinion that certain services are
>'overpriced'.
>
>Those are pricing discussions.
>
>
>If you read the other charter proposals you will see that they both
>contain statements to the effect that the advantage the group seeks to
>realize is to enforce use of a single root of trust. Those are the
>parts I find unacceptable.
>
>
>On Fri, Aug 20, 2010 at 10:40 AM, Richard L. Barnes <[email-masked]> wrote:
>>> If people want to propose a system with a single point of failure then
>>> that point of failure has to be on the table for discussion. The only
>>> reason I brought ICANN up is that others insisted that we only design
>>> a system where the only choice is to trust the ICANN monopoly.
>>
>> [Citation needed]
>>
>>
>>> I do not think that we want two separate groups, one to do DNSSEC for
>>> applications using only the ICANN root and a separate group for
>>> applications using a choice of roots. And even if we wanted to, I
>>> doubt that a charter of that nature could be accepted by the IESG.
>>
>> Obviously we don't, because this whole discussion is completely unrelated to
>> a choice of trust anchors.  DNSSEC and other protocols we develop in the
>> IETF do not require any relying party to use any given trust anchor.  If you
>> want a concrete example, just look at the DLV.
>>
>>
>>> One other charter point. We cannot have any discussion of pricing of
>>> products or services (including 'free'). IETF rules have been quite
>>> lax on this point to date. However we have to take care not to be the
>>> group that brings down the lawyers.
>>
>> That seems kind of obvious.  Who has expressed a desire to discuss pricing?
>>
>> --Richard
>>
>>
>>
>>
>>>
>>>
>>> On Fri, Aug 20, 2010 at 6:43 AM, Scott Rea <[email-masked]>
>>> wrote:
>>>>
>>>>  On 8/19/2010 9:16 PM, Paul Hoffman wrote:
>>>>>
>>>>> At 2:01 AM +0100 8/20/10, Tony Finch wrote:
>>>>>>
>>>>>> It seems to me from this week's discussion that (exaggerating slightly)
>>>>>> no
>>>>>> one wants to trust the x.509 certificate authorities and no one wants
>>>>>> to
>>>>>> trust ICANN's DNSSEC root anchor.
>>>>>
>>>>> Exaggerating wildly, I would say. Who other than Phill have said they
>>>>> don't trust ICANN's DNSSEC root anchor?
>>>>>
>>>>> --Paul Hoffman, Director
>>>>> --VPN Consortium
>>>>> _______________________________________________
>>>>> keyassure mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>>
>>>> Hmmm... nothing against ICANN personally, but lots against a single point
>>>> of
>>>> failure, I prefer to share that responsibility around
>>>>
>>>> --
>>>> Scott Rea
>>>> Sr PKI Architect (Contractor)
>>>> Em: [email-masked]
>>>>
>>>>
>>>> _______________________________________________
>>>> keyassure mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>>
>>>
>>>
>>>
>>> --
>>> Website: http://hallambaker.com/
>>> _______________________________________________
>>> keyassure mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/keyassure
>>
>>
>
>
>
>-- 
>Website: http://hallambaker.com/
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

Date: Fri, 20 Aug 2010 17:04:24 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] who to trust

On 20.8.2010 16:46, Phillip Hallam-Baker wrote:
> Plenty of people have asserted that the objective is to do PKI for
> 'free'. Others have expressed the opinion that certain services are
> 'overpriced'.
>
> Those are pricing discussions.
>
>
> If you read the other charter proposals you will see that they both
> contain statements to the effect that the advantage the group seeks to
> realize is to enforce use of a single root of trust. Those are the
> parts I find unacceptable.

Just to repeat what Paul already said.  You seem to be the only one who 
complains.  Or is there anybody else who has similar objections?  If you 
are out there, please speak up.

I would like to remind you that the IETF process works on rough 
consensus.  Right now my feeling is that you are standing alone with 
your opinions on what is acceptable and what is not.  And that's a 
hardly rough consensus to change the charter.

I don't want to say that I (and other people) won't hear your complaints 
and won't change the charter, but "plenty of people" (to cite you) is 
much closer to rough consensus.  I would be happier to find a total 100% 
consensus on our work, but if you barricade yourself in your position 
that would be very very hard to achieve.

I was told that standard IETF process is a way how to have things not 
done and that I am naive to push this through IETF, but I would like to 
prove them wrong.

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

From: "Richard L. Barnes" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Aug 2010 10:55:14 -0400
Cc: [email-masked], Scott Rea <[email-masked]>
Subject: Re: [keyassure] who to trust

Ah, I have only just now read the initial charter proposal that Warren  
sent out.  I agree that that one is too root-centric.

But clearly the problem can be phrased more in terms of application  
needs (binding keys to domain names) and validation paths (overlaid on  
DNS) instead of what TAs those paths end in.  That's what I tried to  
do in my earlier proposal.

On Aug 20, 2010, at 10:46 AM, Phillip Hallam-Baker wrote:

> Plenty of people have asserted that the objective is to do PKI for
> 'free'. Others have expressed the opinion that certain services are
> 'overpriced'.
>
> Those are pricing discussions.
>
>
> If you read the other charter proposals you will see that they both
> contain statements to the effect that the advantage the group seeks to
> realize is to enforce use of a single root of trust. Those are the
> parts I find unacceptable.
>
>
> On Fri, Aug 20, 2010 at 10:40 AM, Richard L. Barnes  
> <[email-masked]> wrote:
>>> If people want to propose a system with a single point of failure  
>>> then
>>> that point of failure has to be on the table for discussion. The  
>>> only
>>> reason I brought ICANN up is that others insisted that we only  
>>> design
>>> a system where the only choice is to trust the ICANN monopoly.
>>
>> [Citation needed]
>>
>>
>>> I do not think that we want two separate groups, one to do DNSSEC  
>>> for
>>> applications using only the ICANN root and a separate group for
>>> applications using a choice of roots. And even if we wanted to, I
>>> doubt that a charter of that nature could be accepted by the IESG.
>>
>> Obviously we don't, because this whole discussion is completely  
>> unrelated to
>> a choice of trust anchors.  DNSSEC and other protocols we develop  
>> in the
>> IETF do not require any relying party to use any given trust  
>> anchor.  If you
>> want a concrete example, just look at the DLV.
>>
>>
>>> One other charter point. We cannot have any discussion of pricing of
>>> products or services (including 'free'). IETF rules have been quite
>>> lax on this point to date. However we have to take care not to be  
>>> the
>>> group that brings down the lawyers.
>>
>> That seems kind of obvious.  Who has expressed a desire to discuss  
>> pricing?
>>
>> --Richard
>>
>>
>>
>>
>>>
>>>
>>> On Fri, Aug 20, 2010 at 6:43 AM, Scott Rea <[email-masked]>
>>> wrote:
>>>>
>>>>  On 8/19/2010 9:16 PM, Paul Hoffman wrote:
>>>>>
>>>>> At 2:01 AM +0100 8/20/10, Tony Finch wrote:
>>>>>>
>>>>>> It seems to me from this week's discussion that (exaggerating  
>>>>>> slightly)
>>>>>> no
>>>>>> one wants to trust the x.509 certificate authorities and no one  
>>>>>> wants
>>>>>> to
>>>>>> trust ICANN's DNSSEC root anchor.
>>>>>
>>>>> Exaggerating wildly, I would say. Who other than Phill have said  
>>>>> they
>>>>> don't trust ICANN's DNSSEC root anchor?
>>>>>
>>>>> --Paul Hoffman, Director
>>>>> --VPN Consortium
>>>>> _______________________________________________
>>>>> keyassure mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>>
>>>> Hmmm... nothing against ICANN personally, but lots against a  
>>>> single point
>>>> of
>>>> failure, I prefer to share that responsibility around
>>>>
>>>> --
>>>> Scott Rea
>>>> Sr PKI Architect (Contractor)
>>>> Em: [email-masked]
>>>>
>>>>
>>>> _______________________________________________
>>>> keyassure mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>>
>>>
>>>
>>>
>>> --
>>> Website: http://hallambaker.com/
>>> _______________________________________________
>>> keyassure mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/keyassure
>>
>>
>
>
>
> -- 
> Website: http://hallambaker.com/

Date: Fri, 20 Aug 2010 10:46:41 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked], Scott Rea <[email-masked]>
Subject: Re: [keyassure] who to trust

Plenty of people have asserted that the objective is to do PKI for
'free'. Others have expressed the opinion that certain services are
'overpriced'.

Those are pricing discussions.

If you read the other charter proposals you will see that they both
contain statements to the effect that the advantage the group seeks to
realize is to enforce use of a single root of trust. Those are the
parts I find unacceptable.

On Fri, Aug 20, 2010 at 10:40 AM, Richard L. Barnes <[email-masked]> wrote:
>> If people want to propose a system with a single point of failure then
>> that point of failure has to be on the table for discussion. The only
>> reason I brought ICANN up is that others insisted that we only design
>> a system where the only choice is to trust the ICANN monopoly.
>
> [Citation needed]
>
>
>> I do not think that we want two separate groups, one to do DNSSEC for
>> applications using only the ICANN root and a separate group for
>> applications using a choice of roots. And even if we wanted to, I
>> doubt that a charter of that nature could be accepted by the IESG.
>
> Obviously we don't, because this whole discussion is completely unrelated to
> a choice of trust anchors. �DNSSEC and other protocols we develop in the
> IETF do not require any relying party to use any given trust anchor. �If you
> want a concrete example, just look at the DLV.
>
>
>> One other charter point. We cannot have any discussion of pricing of
>> products or services (including 'free'). IETF rules have been quite
>> lax on this point to date. However we have to take care not to be the
>> group that brings down the lawyers.
>
> That seems kind of obvious. �Who has expressed a desire to discuss pricing?
>
> --Richard
>
>
>
>
>>
>>
>> On Fri, Aug 20, 2010 at 6:43 AM, Scott Rea <[email-masked]>
>> wrote:
>>>
>>> �On 8/19/2010 9:16 PM, Paul Hoffman wrote:
>>>>
>>>> At 2:01 AM +0100 8/20/10, Tony Finch wrote:
>>>>>
>>>>> It seems to me from this week's discussion that (exaggerating slightly)
>>>>> no
>>>>> one wants to trust the x.509 certificate authorities and no one wants
>>>>> to
>>>>> trust ICANN's DNSSEC root anchor.
>>>>
>>>> Exaggerating wildly, I would say. Who other than Phill have said they
>>>> don't trust ICANN's DNSSEC root anchor?
>>>>
>>>> --Paul Hoffman, Director
>>>> --VPN Consortium
>>>> _______________________________________________
>>>> keyassure mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>
>>> Hmmm... nothing against ICANN personally, but lots against a single point
>>> of
>>> failure, I prefer to share that responsibility around
>>>
>>> --
>>> Scott Rea
>>> Sr PKI Architect (Contractor)
>>> Em: [email-masked]
>>>
>>>
>>> _______________________________________________
>>> keyassure mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>
>>
>>
>>
>> --
>> Website: http://hallambaker.com/
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>
>

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

From: "Richard L. Barnes" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Aug 2010 10:40:08 -0400
Cc: [email-masked], Scott Rea <[email-masked]>
Subject: Re: [keyassure] who to trust

> If people want to propose a system with a single point of failure then
> that point of failure has to be on the table for discussion. The only
> reason I brought ICANN up is that others insisted that we only design
> a system where the only choice is to trust the ICANN monopoly.

[Citation needed]

> I do not think that we want two separate groups, one to do DNSSEC for
> applications using only the ICANN root and a separate group for
> applications using a choice of roots. And even if we wanted to, I
> doubt that a charter of that nature could be accepted by the IESG.

Obviously we don't, because this whole discussion is completely  
unrelated to a choice of trust anchors.  DNSSEC and other protocols we  
develop in the IETF do not require any relying party to use any given  
trust anchor.  If you want a concrete example, just look at the DLV.

> One other charter point. We cannot have any discussion of pricing of
> products or services (including 'free'). IETF rules have been quite
> lax on this point to date. However we have to take care not to be the
> group that brings down the lawyers.

That seems kind of obvious.  Who has expressed a desire to discuss  
pricing?

--Richard

>
>
> On Fri, Aug 20, 2010 at 6:43 AM, Scott Rea <[email-masked]>  
> wrote:
>>  On 8/19/2010 9:16 PM, Paul Hoffman wrote:
>>>
>>> At 2:01 AM +0100 8/20/10, Tony Finch wrote:
>>>>
>>>> It seems to me from this week's discussion that (exaggerating  
>>>> slightly)
>>>> no
>>>> one wants to trust the x.509 certificate authorities and no one  
>>>> wants to
>>>> trust ICANN's DNSSEC root anchor.
>>>
>>> Exaggerating wildly, I would say. Who other than Phill have said  
>>> they
>>> don't trust ICANN's DNSSEC root anchor?
>>>
>>> --Paul Hoffman, Director
>>> --VPN Consortium
>>> _______________________________________________
>>> keyassure mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/keyassure
>>
>> Hmmm... nothing against ICANN personally, but lots against a single  
>> point of
>> failure, I prefer to share that responsibility around
>>
>> --
>> Scott Rea
>> Sr PKI Architect (Contractor)
>> Em: [email-masked]
>>
>>
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>>
>
>
>
> -- 
> Website: http://hallambaker.com/
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Fri, 20 Aug 2010 10:25:18 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Scott Rea <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] who to trust

That is precisely my position.

If people want to propose a system with a single point of failure then
that point of failure has to be on the table for discussion. The only
reason I brought ICANN up is that others insisted that we only design
a system where the only choice is to trust the ICANN monopoly.

I do not think that we want two separate groups, one to do DNSSEC for
applications using only the ICANN root and a separate group for
applications using a choice of roots. And even if we wanted to, I
doubt that a charter of that nature could be accepted by the IESG.

One other charter point. We cannot have any discussion of pricing of
products or services (including 'free'). IETF rules have been quite
lax on this point to date. However we have to take care not to be the
group that brings down the lawyers.

On Fri, Aug 20, 2010 at 6:43 AM, Scott Rea <[email-masked]> wrote:
> �On 8/19/2010 9:16 PM, Paul Hoffman wrote:
>>
>> At 2:01 AM +0100 8/20/10, Tony Finch wrote:
>>>
>>> It seems to me from this week's discussion that (exaggerating slightly)
>>> no
>>> one wants to trust the x.509 certificate authorities and no one wants to
>>> trust ICANN's DNSSEC root anchor.
>>
>> Exaggerating wildly, I would say. Who other than Phill have said they
>> don't trust ICANN's DNSSEC root anchor?
>>
>> --Paul Hoffman, Director
>> --VPN Consortium
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>
> Hmmm... nothing against ICANN personally, but lots against a single point of
> failure, I prefer to share that responsibility around
>
> --
> Scott Rea
> Sr PKI Architect (Contractor)
> Em: [email-masked]
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Fri, 20 Aug 2010 15:58:06 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On 20.8.2010 13:49, Phillip Hallam-Baker wrote:
> Seems to me that you are making statements and then ruling objections
> to those statements as off topic.

You are ripping my words out of the context.  I am saying that this is 
no place to discuss whether we trust "ICANN, Verisign or USG".  This 
group has the proposed charter based on fact that we are going to use 
DNS and DNSSEC, and we trust it.

Again this should be a place where the work is done, and not a chitchat 
list for discussing whether US companies are good or not.  And I ask all 
participants to respect that.

> - Show quoted text -
> Exactly.  The change of the trust model will be always scary.  But it
> is important to realize that we don't change overall level of security
> (in fact, we are improving it), just the trust model.
>
>
> Ondrej
>
> On Fri, Aug 20, 2010 at 4:24 AM, Ondřej Surý<[email-masked]>  wrote:
>> [moderator hat on]
>> This is really off-topic.  Please cease a discussion on who to trust. This
>> group is to get work done and not to discuss irrelevant topics like this.
>>   Don't clutter the mailing list, thanks.
>> [/moderator hat off]

-- 
  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: Fri, 20 Aug 2010 07:55:46 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] key per host

My preference is to rule it out of scope as well.

It is possible to use the DNS for purposes other than resolution of
names, but that does not mean it is a good idea.

On Fri, Aug 20, 2010 at 4:29 AM, Ond�ej Sur� <[email-masked]> wrote:
> On 19.8.2010 21:47, Richard L. Barnes wrote:
>>
>> Depends on what you mean by "system identity", doesn't it?
>>
>> I tend to take a user-centric view of this. If I type in "ssh 10.1.1.1",
>> then the key should be bound to the address, but if I type in "ssh
>> example.com", the key should be bound to the name -- I don't care what
>> the IP address is as long as the guy at the other end has the right key
>> for the domain.
>>
>> This does raise an interesting question for the group, though: How do we
>> want to handle "https://10.1.1.1/" and "https://[fe80::abcd:123]/"?
>> Seems like there are two basic possibilities:
>> 1. Use the reverse DNS tree
>> 2. Declare it out of scope because we're focused authenticating domain
>> names
>>
>> My slight preference is for (2).
>
> Because of RFC1918 addresses, I tend to prefer (2).
>
> Ondrej
> --
> �Ond�ej Sur�
> �vedouc� v�zkumu/Head of R&D department
> �-------------------------------------------
> �CZ.NIC, z.s.p.o. � �-- � �Laborato�e CZ.NIC
> �Americka 23, 120 00 Praha 2, Czech Republic
> �mailto:[email-masked] � �http://nic.cz/
> �tel:+420.222745110 � � � fax:+420.222745112
> �-------------------------------------------
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Fri, 20 Aug 2010 07:53:41 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] key per host

We definitely should not write that protocol here. Hence I wrote 'at a
high level'.

But we should not paint ourselves into a corner here and adopt
unrealistic assumptions that preclude that type of approach.

Limiting services to a single shared key is bad crypto hygiene and
harder to manage. There is no advantage to doing so.

On Fri, Aug 20, 2010 at 4:22 AM, Ond�ej Sur� <[email-masked]> wrote:
> On 19.8.2010 19:30, Richard L. Barnes wrote:
>>>>
>>>> At a high level, what I would like to see here is a mechanism that
>>>> allows an application to generate a key pair and request registration
>>>> in the DNS as part of the install package.
>>>
>>> Dynamic DNS updates ought to be part of the solution, though I don't know
>>> how to make it easier to manage the trust relationship (i.e. the nsupdate
>>> keys) between the DNS admin and the app admins.
>>
>> I would say that this sort of provisioning information should be out of
>> the scope of the working group. Standard DNS provisioning techniques
>> apply.
>
> Ack. �I don't see a reason why we should do anything with DNS provisioning.
> �(If anybody is willing to write BCP, he could, but I don't see a reason for
> that.)
>
> Ondrej
> --
> �Ond�ej Sur�
> �vedouc� v�zkumu/Head of R&D department
> �-------------------------------------------
> �CZ.NIC, z.s.p.o. � �-- � �Laborato�e CZ.NIC
> �Americka 23, 120 00 Praha 2, Czech Republic
> �mailto:[email-masked] � �http://nic.cz/
> �tel:+420.222745110 � � � fax:+420.222745112
> �-------------------------------------------
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Fri, 20 Aug 2010 07:47:19 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

There will be no change in the trust model. You are adding in one
additional root. You are not going to remove the others.

The IETF is very likely to charter a group that is going to look at
the problem of how to enable applications to use DNSSEC. But I think
it highly unlikely that they would charter a group to engineer a
change in the trust model from a market based solution to a monopoly.
That just is not going to happen.

On Fri, Aug 20, 2010 at 4:13 AM, Ond�ej Sur� <[email-masked]> wrote:
> On 20.8.2010 00:04, Warren Kumari wrote:
>>
>> On Aug 19, 2010, at 12:40 PM, Stephen Schultze wrote:
>>
>>> David said basically what I was going to say on your other points, but
>>> I wanted to also note the following:
>>>
>>> On Aug 19, 2010, at 9:01 AM, Phillip Hallam-Baker wrote:
>>>>
>>>> The point you are still not getting here is that the security of the
>>>> system is measured from the point of view of the relying party. The
>>>> relying party does not choose either the CA or the Registrar, but an
>>>> attacker can.
>>>
>>>
>>> Let's describe the assurances that the relying party has in each case:
>>>
>>> Standard CA DV cert:
>>> One of thousands of entities with cert-issuing authority said that the
>>> holder of the corresponding private key controls the zone for the
>>> domain in question. There may be other people out there who also have
>>> certificates that assert that they control the domain, but neither you
>>> nor this issuing CA necessarily know if they exist. Every root CA has
>>> equivalent authority as far as you're concerned, and an attacker can
>>> choose the lowest common denominator CA and serve you those certs at
>>> will.
>>>
>>> DNSSEC domain-key assertion:
>>> The person who controls the zone for the domain in question holds the
>>> corresponding private key. The only opportunity for mischief or
>>> mistake is in the one single path that the zone controller chose:
>>> their nameserver (especially if they are doing online signing), the
>>> registrar, the registry, and the root (and if there are DS records for
>>> sub-domains, whoever controls those). What's more, any substitution of
>>> a baddie's DS record for the true domain owner's DS record would be
>>> highly visible and likely to be immediately corrected.
>>
>> So, when I initially started looking at all this (leveraging the DNSSEC
>> TA as a TA for other things) I thought that it was the best thing since
>> sliced bread... until it occurred to me that this was changing who all
>> could muck with your security.
>> CA certs were handed out by CAs, and you didn't need to worry about
>> being attacked by your (probably outsourced) DNS provider, your
>> (probably reseller) registrar, their parent registrar and the registry
>> (or, more likely, the chappie who owned your nameserver because you
>> thought that 'P@ssword' was a good choice). I ended up rewriting my
>> initial draft saying that the only use for this was to allow you to
>> attest to what the *correct* CA issued cert was, and apologized to the
>> folk to whom I had given the original drafts to for wasting their time...
>> A long set of emails and phonecalls and IMs then occurred, with me
>> kvetching about how this was changing the fundamental trust model, and
>> opening you up to dinking with by all of the folk in the registration /
>> DNS side of things and how the sky was falling... but, for every
>> scenario that I came up with (rogue DNS provider, hacked nameserver, bad
>> registrar) folk convinced me that the attackers could just as easily
>> redirect my MX record and use that to obtain a CA signed cert... It took
>> some time (I guess because I didn't want to admit to myself just how
>> screwed we were), but they have fully convinced me -- once someone in a
>> position to change your DNS responses (by inserting DNSSEC signed
>> keymaterial or something) they are in a position to get a cert....
>
> Exactly. �The change of the trust model will be always scary. �But it is
> important to realize that we don't change overall level of security (in
> fact, we are improving it), just the trust model.
>
> Ondrej
> --
> �Ond�ej Sur�
> �vedouc� v�zkumu/Head of R&D department
> �-------------------------------------------
> �CZ.NIC, z.s.p.o. � �-- � �Laborato�e CZ.NIC
> �Americka 23, 120 00 Praha 2, Czech Republic
> �mailto:[email-masked] � �http://nic.cz/
> �tel:+420.222745110 � � � fax:+420.222745112
> �-------------------------------------------
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Fri, 20 Aug 2010 06:43:23 -0400
From: Scott Rea <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] who to trust

  On 8/19/2010 9:16 PM, Paul Hoffman wrote:
> At 2:01 AM +0100 8/20/10, Tony Finch wrote:
>> It seems to me from this week's discussion that (exaggerating slightly) no
>> one wants to trust the x.509 certificate authorities and no one wants to
>> trust ICANN's DNSSEC root anchor.
> Exaggerating wildly, I would say. Who other than Phill have said they don't trust ICANN's DNSSEC root anchor?
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
Hmmm... nothing against ICANN personally, but lots against a single 
point of failure, I prefer to share that responsibility around

-- 
Scott Rea
Sr PKI Architect (Contractor)
Em: [email-masked]

Date: Fri, 20 Aug 2010 10:29:00 +0100
From: Ben Laurie <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] user keys

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

On 19 August 2010 18:08, Tony Finch <[email-masked]> wrote:

> Paul Wouters <[email-masked]> wrote:
> >On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote:
> >>
> >> In my view user keys do not belong in the DNS because the DNS is an
> >> infrastructure for locating network services, not network users.
> >
> > I disagree. You are locating an identity. Currently, that is mostly done
> > based on an IP address and port. I'd hope tomorrow that would mostly be
> > done based on a public key or hash. Especially with mobile devices, IP's
> > are very volatile. To locate a service or user, we need the DNS.
>
> Yes. At the moment the PKIs for identifying people are rather cumbersome.
> It would be nice to be able to use DNSSEC for verifying S/MIME or PGP
> messages.
>

Webfinger seems like a better vehicle for this kind of thing (probably
combined with some DNSSEC for key bootstrapping).

>
> Tony.
> --
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
> SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

<br><br><div class="gmail_quote">On 19 August 2010 18:08, Tony Finch <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Paul Wouters &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote:<br>
&gt;&gt;<br>
&gt;&gt; In my view user keys do not belong in the DNS because the DNS is an<br>
&gt;&gt; infrastructure for locating network services, not network users.<br>
&gt;<br>
&gt; I disagree. You are locating an identity. Currently, that is mostly done<br>
&gt; based on an IP address and port. I&#39;d hope tomorrow that would mostly be<br>
&gt; done based on a public key or hash. Especially with mobile devices, IP&#39;s<br>
&gt; are very volatile. To locate a service or user, we need the DNS.<br>
<br>
Yes. At the moment the PKIs for identifying people are rather cumbersome.<br>
It would be nice to be able to use DNSSEC for verifying S/MIME or PGP<br>
messages.<br></blockquote><div><br></div><div>Webfinger seems like a better vehicle for this kind of thing (probably combined with some DNSSEC for key bootstrapping).</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Tony.<br>
<font color="#888888">--<br>
f.anthony.n.finch �&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; �<a href="http://dotat.at/" target="_blank">http://dotat.at/</a><br>
SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD.<br>
_______________________________________________<br>
keyassure mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/keyassure" target="_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</font></blockquote></div><br>

--001636e1ef9dc4447b048e3ded3e--

Date: Fri, 20 Aug 2010 11:09:55 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] user keys

On 19.8.2010 19:35, Paul Hoffman wrote:
> At 1:22 PM -0400 8/19/10, Richard L. Barnes wrote:
>> This seems like a bad path to be headed down.  There are lots of
>> identifiers that can be tied to public keys: email addresses, SIP
>> URIs, telephone numbers, childhood nicknames.  It would be a
>> mistake to try to smash them all into the DNS.
>
> +1. The DNS is good for giving information that is related to domain
> names, not all the users of the things at the domain names.

As Jakob already said.  RFC 4398 Section 3.2 for X.509 (and 3.3 for 
OpenPGP) states the coding of email address into a domain name.

We don't have to solve all the identifiers.  We could do that just for 
email address.

But I certainly don't want to mangle all together in this (non-)WG.  BTW 
is there any work?  RFC 4398 is already there.  Does it miss something 
important which cannot be used for S/MIME, OpenPGP?
Or is this just an non-existent implementation issue?

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: Fri, 20 Aug 2010 10:58:42 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] user keys

On 19.8.2010 19:25, Phillip Hallam-Baker wrote:
> I agree it would be nice to use DNSSEC in the validation path.
>
> But the problem is that the DNS management is typically under control
> of people responsible for managing machines and not people.
>
> We have a spec for putting certs onto a Web server and pulling them via HTTP.
>
>
> oops, just saw a can of worms here. If we are not careful with our
> validation scheme, we will end up in a situation where people can use
> the S/MIME cert they were issued (e.g. [email-masked]) to set up a
> Web Server (https://bigbank.com/)

The would be a very bad specification.  However we already have a 
mechanism for coding a email into a domain identifier.  Remember the SOA 
record? :)

So we could specify that

[email-masked] becomes fred.bigbank.com
   and
[email-masked] becomes ondrej\.sury.nic.cz

Also the information in the DNS has to be DNSSEC validated, so how would 
[email-masked] be able to put the information into DNS?  And if we 
assume tight control over DNS, we could maybe specify something like 
"usage" flag?  Or entirely new RR type, so:

bigbank.com TLSFP ....

fred.bigbank.com SMIMEFP ...

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: Fri, 20 Aug 2010 10:29:58 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] key per host

On 19.8.2010 21:47, Richard L. Barnes wrote:
> Depends on what you mean by "system identity", doesn't it?
>
> I tend to take a user-centric view of this. If I type in "ssh 10.1.1.1",
> then the key should be bound to the address, but if I type in "ssh
> example.com", the key should be bound to the name -- I don't care what
> the IP address is as long as the guy at the other end has the right key
> for the domain.
>
> This does raise an interesting question for the group, though: How do we
> want to handle "https://10.1.1.1/" and "https://[fe80::abcd:123]/"?
> Seems like there are two basic possibilities:
> 1. Use the reverse DNS tree
> 2. Declare it out of scope because we're focused authenticating domain
> names
>
> My slight preference is for (2).

Because of RFC1918 addresses, I tend to prefer (2).

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: Fri, 20 Aug 2010 10:24:24 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

[moderator hat on]
This is really off-topic.  Please cease a discussion on who to trust. 
This group is to get work done and not to discuss irrelevant topics like 
this.  Don't clutter the mailing list, thanks.
[/moderator hat off]

On 19.8.2010 22:58, Jeffrey A. Williams wrote:
> David and all,
>
>    The choices for whom to trust are:  Verisign, ICANN, or the
> USG.  Well that's a poor group to pick from according to
> many folks, eh Dave?>;)  As most americans know the trust
> in their government is at a nearly 70 year low, Trust in ICANN
> has ebbed and flowed but is nearly as low, and Verisign all
> be they have good folks there, seems to be the default remaining
> choice.  Seems like a logical deduction choice that leaves
> in some folks mind and experiance, not very good choices.
>
>    We need more choices OR we need better choices, take your
> pick.  The 'Truste Anchors' approach in DNSSEC gives a few
> more, but perhaps not enough OR not the 'Right' ones to choose
> from?
>
>
> -----Original Message-----
>> From: David Conrad<[email-masked]>
>> Sent: Aug 18, 2010 10:42 PM
>> To: Phillip Hallam-Baker<[email-masked]>
>> Cc: [email-masked]
>> Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications
>>
>> On Aug 18, 2010, at 7:26 PM, Phillip Hallam-Baker wrote:
>>> I want to use dnssec without the ICANN root.
>>
>> Feel free.  There are (currently) only about 300 TLD trust anchors you'll have to keep track of if all the TLDs started signing. ICANN says they'll be adding no more than about 1000/year. You'll have to figure out a way of securely fetching the trust anchors from the TLD admins who sign their zones to install into your validating resolver, but that's a minor detail.
>>
>> A single root of trust _can be_ better since there are less parties to vet and audit (1 versus many).  However, as I said, if you don't want to trust ICANN, VeriSign, and the US Government, you don't have to.
>>
>> Regards,
>> -drc
>>
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>
> Regards,
>
> Jeffrey A. Williams
> Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
> "Obedience of the law is the greatest freedom" -
>     Abraham Lincoln
>
> "Credit should go with the performance of duty and not with what is very
> often the accident of glory" - Theodore Roosevelt
>
> "If the probability be called P; the injury, L; and the burden, B; liability
> depends upon whether B is less than L multiplied by
> P: i.e., whether B is less than PL."
> United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
> ===============================> Updated 1/26/04
> CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
> Information Network Eng.  INEG. INC.
> ABA member in good standing member ID 01257402 E-Mail [email-masked]
> Phone: 214-244-4827
> _______________________________________________
> 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
  -------------------------------------------

Date: Fri, 20 Aug 2010 10:22:06 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] key per host

On 19.8.2010 19:30, Richard L. Barnes wrote:
>>> At a high level, what I would like to see here is a mechanism that
>>> allows an application to generate a key pair and request registration
>>> in the DNS as part of the install package.
>>
>> Dynamic DNS updates ought to be part of the solution, though I don't know
>> how to make it easier to manage the trust relationship (i.e. the nsupdate
>> keys) between the DNS admin and the app admins.
>
> I would say that this sort of provisioning information should be out of
> the scope of the working group. Standard DNS provisioning techniques apply.

Ack.  I don't see a reason why we should do anything with DNS 
provisioning.  (If anybody is willing to write BCP, he could, but I 
don't see a reason for that.)

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: Fri, 20 Aug 2010 10:13:51 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On 20.8.2010 00:04, Warren Kumari wrote:
>
> On Aug 19, 2010, at 12:40 PM, Stephen Schultze wrote:
>
>> David said basically what I was going to say on your other points, but
>> I wanted to also note the following:
>>
>> On Aug 19, 2010, at 9:01 AM, Phillip Hallam-Baker wrote:
>>> The point you are still not getting here is that the security of the
>>> system is measured from the point of view of the relying party. The
>>> relying party does not choose either the CA or the Registrar, but an
>>> attacker can.
>>
>>
>> Let's describe the assurances that the relying party has in each case:
>>
>> Standard CA DV cert:
>> One of thousands of entities with cert-issuing authority said that the
>> holder of the corresponding private key controls the zone for the
>> domain in question. There may be other people out there who also have
>> certificates that assert that they control the domain, but neither you
>> nor this issuing CA necessarily know if they exist. Every root CA has
>> equivalent authority as far as you're concerned, and an attacker can
>> choose the lowest common denominator CA and serve you those certs at
>> will.
>>
>> DNSSEC domain-key assertion:
>> The person who controls the zone for the domain in question holds the
>> corresponding private key. The only opportunity for mischief or
>> mistake is in the one single path that the zone controller chose:
>> their nameserver (especially if they are doing online signing), the
>> registrar, the registry, and the root (and if there are DS records for
>> sub-domains, whoever controls those). What's more, any substitution of
>> a baddie's DS record for the true domain owner's DS record would be
>> highly visible and likely to be immediately corrected.
>
> So, when I initially started looking at all this (leveraging the DNSSEC
> TA as a TA for other things) I thought that it was the best thing since
> sliced bread... until it occurred to me that this was changing who all
> could muck with your security.
> CA certs were handed out by CAs, and you didn't need to worry about
> being attacked by your (probably outsourced) DNS provider, your
> (probably reseller) registrar, their parent registrar and the registry
> (or, more likely, the chappie who owned your nameserver because you
> thought that 'P@ssword' was a good choice). I ended up rewriting my
> initial draft saying that the only use for this was to allow you to
> attest to what the *correct* CA issued cert was, and apologized to the
> folk to whom I had given the original drafts to for wasting their time...
> A long set of emails and phonecalls and IMs then occurred, with me
> kvetching about how this was changing the fundamental trust model, and
> opening you up to dinking with by all of the folk in the registration /
> DNS side of things and how the sky was falling... but, for every
> scenario that I came up with (rogue DNS provider, hacked nameserver, bad
> registrar) folk convinced me that the attackers could just as easily
> redirect my MX record and use that to obtain a CA signed cert... It took
> some time (I guess because I didn't want to admit to myself just how
> screwed we were), but they have fully convinced me -- once someone in a
> position to change your DNS responses (by inserting DNSSEC signed
> keymaterial or something) they are in a position to get a cert....

Exactly.  The change of the trust model will be always scary.  But it is 
important to realize that we don't change overall level of security (in 
fact, we are improving it), just the trust model.

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

From: Jakob Schlyter <[email-masked]>
Date: Fri, 20 Aug 2010 07:25:12 +0200
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] user keys

On 20 aug 2010, at 03.24, Phillip Hallam-Baker wrote:

> People asked me to justify the design proposal I made, so I did.
> 
> In the case of SSL the answer is twofold
> 
> 1) The full cert is passed in the protocol in any case.
> 2) Having a separate record bound to a specific protocol means we can
> have statements of the form 'SSL is always offered'.

while this thread is about 'user keys', I'm not sure how SSL is ready applicable (unless you talk about client certificates). for user keys, and as already mentioned, the CERT RR has support for indirect information, including URLs of X.509 data objects and OpenPGP packets.

	jakob

From: "Richard L. Barnes" <[email-masked]>
To: Paul Hoffman <[email-masked]>
Date: Thu, 19 Aug 2010 23:27:37 -0400
Cc: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: [keyassure] who to trust

+1

All this trust anchor discussion is really irrelevant to protocol  
design.  We just make the chains, the relying parties choose what  
trust anchors to hang them from.

--Richard

On Aug 19, 2010, at 9:16 PM, Paul Hoffman wrote:

> At 2:01 AM +0100 8/20/10, Tony Finch wrote:
>> It seems to me from this week's discussion that (exaggerating  
>> slightly) no
>> one wants to trust the x.509 certificate authorities and no one  
>> wants to
>> trust ICANN's DNSSEC root anchor.
>
> Exaggerating wildly, I would say. Who other than Phill have said  
> they don't trust ICANN's DNSSEC root anchor?
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Thu, 19 Aug 2010 21:24:03 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] user keys

People asked me to justify the design proposal I made, so I did.

In the case of SSL the answer is twofold

1) The full cert is passed in the protocol in any case.
2) Having a separate record bound to a specific protocol means we can
have statements of the form 'SSL is always offered'.

Now the thing about the cert size is why it has not been done that way
in the past. Whether it is a valid reason or not, it is a reason. A
cert signed with RSA 2048 for a RSA 2048 key is going to have 512
bytes of just the signature data. And an RSA 4096 cert is going to be
1K which is pushing the ethernet MTU with fairly minimal X.509
gubbins.

I don't see the transport issue on following a URL, if the hash is in
the DNS we have accreditation for the bits. No further bootstrapping
is necessary.

There are some minor additional advantages to hashes over raw certs,
one is that hashes leak less information. Though why that is an
advantage I am not sure.

Of course this is all reinventing the wheel that many of us have
proposed before. I wrote a chapter in my book proposing a similar
scheme. There is also DKIM and there was the FREESWAN work. We all
seem to be in violent agreement on this specific point.

A new record with the hash algorithm and hash value with an optional
URL field seems to work for most people here.

It also has the advantage that it does not tie us to X.509 certs. The
X.509 certs are clearly optimal for SSL because that is what it is
designed to use. They may not be optimal for other
applications/protocols.

On Thu, Aug 19, 2010 at 9:03 PM, Paul Hoffman <[email-masked]> wrote:
> At 7:52 PM -0400 8/19/10, Phillip Hallam-Baker wrote:
>>Main problem I have heard is that certs tend to be quite large in dns terms
>
> First off, there have been many earlier threads on DNSEXT about this. If you are saying "I agree with the few people who think this is a problem", that's fine, but it is not widely-agreed to. I do not believe that this mailing list is a good place to recreate that debate without all the DNS mafia here to chime in.
>
> Secondly, you don't have to use certs in the CERT RR. For example, see our proposal in our draft.
>
>>I was thinking of using a URL to retrieve the cert if that was necessary. Then you can get the trust path as well - if your app needs that.
>
> This is re-inventing what we did in IKEv2bis, and you have the chicken-and-egg problem of needing to have secure transport of certificate after getting the URL securely.
>
> Really, this has all been discussed and written down before.
>
> At 4:56 PM -0700 8/19/10, Nicholas Weaver wrote:
>>However, keeping certs is arguably unnecessary: just a hash of a cert accomplishes the same thing in pretty much any existing cryptographic protocol.
>
> Exactly.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

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

Date: Thu, 19 Aug 2010 18:16:04 -0700
To: Tony Finch <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] who to trust

At 2:01 AM +0100 8/20/10, Tony Finch wrote:
>It seems to me from this week's discussion that (exaggerating slightly) no
>one wants to trust the x.509 certificate authorities and no one wants to
>trust ICANN's DNSSEC root anchor.

Exaggerating wildly, I would say. Who other than Phill have said they don't trust ICANN's DNSSEC root anchor?

--Paul Hoffman, Director
--VPN Consortium

Date: Thu, 19 Aug 2010 18:03:02 -0700
To: Phillip Hallam-Baker <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] user keys

At 7:52 PM -0400 8/19/10, Phillip Hallam-Baker wrote:
>Main problem I have heard is that certs tend to be quite large in dns terms

First off, there have been many earlier threads on DNSEXT about this. If you are saying "I agree with the few people who think this is a problem", that's fine, but it is not widely-agreed to. I do not believe that this mailing list is a good place to recreate that debate without all the DNS mafia here to chime in.

Secondly, you don't have to use certs in the CERT RR. For example, see our proposal in our draft.

>I was thinking of using a URL to retrieve the cert if that was necessary. Then you can get the trust path as well - if your app needs that.

This is re-inventing what we did in IKEv2bis, and you have the chicken-and-egg problem of needing to have secure transport of certificate after getting the URL securely.

Really, this has all been discussed and written down before.

At 4:56 PM -0700 8/19/10, Nicholas Weaver wrote:
>However, keeping certs is arguably unnecessary: just a hash of a cert accomplishes the same thing in pretty much any existing cryptographic protocol.

Exactly.

--Paul Hoffman, Director
--VPN Consortium

Date: Fri, 20 Aug 2010 02:01:05 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Sender: Tony Finch <[email-masked]>
Subject: [keyassure] who to trust

It seems to me from this week's discussion that (exaggerating slightly) no
one wants to trust the x.509 certificate authorities and no one wants to
trust ICANN's DNSSEC root anchor. So how can users decouple their trust
anchors for their important applications (banking! email!) from third
parties that they don't want to trust very much?

At the moment most crypto implementations have one of two models (ignoring
weird geeky outliers):

(a) Stateless trusted third party. Like SSL / X.509. Forget any past
interactions with the service, all you care about is whether its
certificate is signed with any of innumerable minimally trustworthy third
parties.

(b) Static trust anchor configuration, established manually or with a
semi-manual ssh-style leap of faith. Any disagreement is an attack.

Neither of these support key rollover properly. In case (a) a client
cannot tell the difference between a key rollover and an exploit against
an untrustworthy CA. In case (b) a key rollover is a festival of exciting
warnings, just like a man-in-the-middle attack.

There is a better solution between these extremes, where a chain of
signatures maintains trust across key rollovers. This model is used with
more or less automation by RFC 5011 and PGP. It means you only need to
trust third parties to establish initial authentication, after which your
ongoing relationship with the second party maintains that authentication.

So perhaps this group should see its job as providing another way
(alongside x.509 / pgp / etc) of authenticating an initial introduction to
a service, or of re-establishing authentication after a hiatus. After that
introduction apps should maintain an independent trust relationship.

The fact that apps do not maintain trust relationships across key
rollovers in this way is a very important problem. I do not think this
group is the right one to solve it.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
PORTLAND PLYMOUTH NORTH BISCAY: SOUTHERLY OR SOUTHWESTERLY 5 TO 7. MODERATE OR
ROUGH. RAIN OR DRIZZLE. MODERATE OR POOR.

From: Warren Kumari <[email-masked]>
Date: Thu, 19 Aug 2010 20:57:48 -0400
To: "Richard L. Barnes" <[email-masked]>
Cc: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: [keyassure] user keys

On Aug 19, 2010, at 7:43 PM, Richard L. Barnes wrote:

> Why?  Is it broken?
> 
> I've actually been thinking that CERT records will be one of the main mechanisms we'll be using here.
> 

Me too -- I (still) believe that the CERT RR representation is the most elegant -- there are a large number of type values that be be used to represent whatever, and the "certificate or CRL" field is flexible enough that we can extend it by having structured data in it if we need to plomp in more than just a hash / key / blob.

W

> 
> 
> 
> On Aug 19, 2010, at 7:26 PM, Tony Finch wrote:
> 
>> On Fri, 20 Aug 2010, Jakob Schlyter wrote:
>>> 
>>> We should keep in mind that RFC 4398 specifies a method to do this for
>>> PGP, e.g. look up CERT(jakob.kirei.se).
>> 
>> Aren't we aiming to supersede that?
>> 
>> Tony.
>> -- 
>> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
>> ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 7 TO
>> SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH BECOMING VERY
>> ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR.
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
> 
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: "Richard L. Barnes" <[email-masked]>
To: Nicholas Weaver <[email-masked]>
Date: Thu, 19 Aug 2010 19:57:57 -0400
Cc: Tony Finch <[email-masked]>, "[email-masked]" <[email-masked]>, Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] user keys

Also, CERT records can carry certificates by reference, i.e., with a  
URI to a cert instead of the cert itself.  So MTU / packet sizes  
shouldn't be an issue unless your URIs are crazy long.
--Richar

On Aug 19, 2010, at 7:56 PM, Nicholas Weaver wrote:

>
> On Aug 19, 2010, at 4:52 PM, Phillip Hallam-Baker wrote:
>
>> Main problem I have heard is that certs tend to be quite large in  
>> dns terms
>>
>> Some are larger than the Ethernet mtu. Most are bigger than the 512  
>> bytes that idiot firewalls tend to filter.
>
> Actually, the idiot firewall isn't the problem for the most part,  
> but the Ethernet MTU is, but even then its still only a ~12% problem  
> or so.  But you can always fall back to TCP for DNS with not too bad  
> a latency hit, especially if you design your DNS resolver to KNOW  
> there are dumb firewalls that can't handle fragments.
>
> However, keeping certs is arguably unnecessary: just a hash of a  
> cert accomplishes the same thing in pretty much any existing  
> cryptographic protocol, and for those that the DNS conveys the cert  
> itself rather than the presence of the cert, then yeah, you have the  
> size of the cert but you can manage: DNSSEC is already blowing out  
> the crap that can't handle fragments and/or 512B.
>
>>
>> For ssl it is not necessary to have the cert as it is passed in  
>> band. Same for ssh (I think). corner case is smime but that is per  
>> user keying anyway.
>>
>> I was thinking of using a URL to retrieve the cert if that was  
>> necessary. Then you can get the trust path as well - if your app  
>> needs that.
>>
>>
>> Sent from my iPad
>>
>> On Aug 19, 2010, at 7:43 PM, "Richard L. Barnes" <[email-masked]>  
>> wrote:
>>
>>> Why?  Is it broken?
>>>
>>> I've actually been thinking that CERT records will be one of the  
>>> main mechanisms we'll be using here.
>>>
>>>
>>>
>>>
>>> On Aug 19, 2010, at 7:26 PM, Tony Finch wrote:
>>>
>>>> On Fri, 20 Aug 2010, Jakob Schlyter wrote:
>>>>>
>>>>> We should keep in mind that RFC 4398 specifies a method to do  
>>>>> this for
>>>>> PGP, e.g. look up CERT(jakob.kirei.se).
>>>>
>>>> Aren't we aiming to supersede that?
>>>>
>>>> Tony.
>>>> -- 
>>>> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
>>>> ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING  
>>>> CYCLONIC 7 TO
>>>> SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH  
>>>> BECOMING VERY
>>>> ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR.
>>>> _______________________________________________
>>>> keyassure mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>
>>> _______________________________________________
>>> keyassure mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/keyassure
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Thu, 19 Aug 2010 16:56:40 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: Tony Finch <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] user keys

On Aug 19, 2010, at 4:52 PM, Phillip Hallam-Baker wrote:

> Main problem I have heard is that certs tend to be quite large in dns terms 
> 
> Some are larger than the Ethernet mtu. Most are bigger than the 512 bytes that idiot firewalls tend to filter.

Actually, the idiot firewall isn't the problem for the most part, but the Ethernet MTU is, but even then its still only a ~12% problem or so.  But you can always fall back to TCP for DNS with not too bad a latency hit, especially if you design your DNS resolver to KNOW there are dumb firewalls that can't handle fragments.

However, keeping certs is arguably unnecessary: just a hash of a cert accomplishes the same thing in pretty much any existing cryptographic protocol, and for those that the DNS conveys the cert itself rather than the presence of the cert, then yeah, you have the size of the cert but you can manage: DNSSEC is already blowing out the crap that can't handle fragments and/or 512B.

> 
> For ssl it is not necessary to have the cert as it is passed in band. Same for ssh (I think). corner case is smime but that is per user keying anyway.
> 
> I was thinking of using a URL to retrieve the cert if that was necessary. Then you can get the trust path as well - if your app needs that. 
> 
> 
> Sent from my iPad
> 
> On Aug 19, 2010, at 7:43 PM, "Richard L. Barnes" <[email-masked]> wrote:
> 
>> Why?  Is it broken?
>> 
>> I've actually been thinking that CERT records will be one of the main mechanisms we'll be using here.
>> 
>> 
>> 
>> 
>> On Aug 19, 2010, at 7:26 PM, Tony Finch wrote:
>> 
>>> On Fri, 20 Aug 2010, Jakob Schlyter wrote:
>>>> 
>>>> We should keep in mind that RFC 4398 specifies a method to do this for
>>>> PGP, e.g. look up CERT(jakob.kirei.se).
>>> 
>>> Aren't we aiming to supersede that?
>>> 
>>> Tony.
>>> -- 
>>> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
>>> ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 7 TO
>>> SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH BECOMING VERY
>>> ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR.
>>> _______________________________________________
>>> keyassure mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/keyassure
>> 
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Phillip Hallam-Baker <[email-masked]>
To: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 19:53:58 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] multi-application certificate RRs

Yes zone walking is really really bad. Let's not do that.

Sent from my iPad

On Aug 19, 2010, at 7:47 PM, Tony Finch <[email-masked]> wrote:

> On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote:
> 
>> There are issues with wildcards that are very specific to DKIM.
>> Specifically, in DKIM you want to be able to create policy records
>> that bind to *.example.com.
> 
> There are other email-related policy proposals (e.g. CSV "client SMTP
> validation") that have the same problem. CSV specifies tree walking to
> deal with wildcard problems, but tree walking is also discouraged.
> 
> http://www.bbiw.net/CSV/index.html
> 
> Tony.
> -- 
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
> MALIN: EASTERLY 5 OR 6 BECOMING SOUTHWESTERLY GALE 8 TO STORM 10, PERHAPS
> VIOLENT STORM 11 LATER. ROUGH OR VERY ROUGH, BECOMING HIGH FOR A TIME. RAIN OR
> SQUALLY SHOWERS. MODERATE OR POOR.

From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Aug 2010 19:52:37 -0400
Cc: Tony Finch <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] user keys

Main problem I have heard is that certs tend to be quite large in dns terms 

Some are larger than the Ethernet mtu. Most are bigger than the 512 bytes that idiot firewalls tend to filter.

For ssl it is not necessary to have the cert as it is passed in band. Same for ssh (I think). corner case is smime but that is per user keying anyway.

I was thinking of using a URL to retrieve the cert if that was necessary. Then you can get the trust path as well - if your app needs that. 

Sent from my iPad

On Aug 19, 2010, at 7:43 PM, "Richard L. Barnes" <[email-masked]> wrote:

> Why?  Is it broken?
> 
> I've actually been thinking that CERT records will be one of the main mechanisms we'll be using here.
> 
> 
> 
> 
> On Aug 19, 2010, at 7:26 PM, Tony Finch wrote:
> 
>> On Fri, 20 Aug 2010, Jakob Schlyter wrote:
>>> 
>>> We should keep in mind that RFC 4398 specifies a method to do this for
>>> PGP, e.g. look up CERT(jakob.kirei.se).
>> 
>> Aren't we aiming to supersede that?
>> 
>> Tony.
>> -- 
>> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
>> ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 7 TO
>> SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH BECOMING VERY
>> ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR.
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
> 
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Fri, 20 Aug 2010 00:47:32 +0100
From: Tony Finch <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] multi-application certificate RRs

On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote:

> There are issues with wildcards that are very specific to DKIM.
> Specifically, in DKIM you want to be able to create policy records
> that bind to *.example.com.

There are other email-related policy proposals (e.g. CSV "client SMTP
validation") that have the same problem. CSV specifies tree walking to
deal with wildcard problems, but tree walking is also discouraged.

http://www.bbiw.net/CSV/index.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
MALIN: EASTERLY 5 OR 6 BECOMING SOUTHWESTERLY GALE 8 TO STORM 10, PERHAPS
VIOLENT STORM 11 LATER. ROUGH OR VERY ROUGH, BECOMING HIGH FOR A TIME. RAIN OR
SQUALLY SHOWERS. MODERATE OR POOR.

From: "Richard L. Barnes" <[email-masked]>
To: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 19:43:59 -0400
Cc: [email-masked]
Subject: Re: [keyassure] user keys

Why?  Is it broken?

I've actually been thinking that CERT records will be one of the main  
mechanisms we'll be using here.

On Aug 19, 2010, at 7:26 PM, Tony Finch wrote:

> On Fri, 20 Aug 2010, Jakob Schlyter wrote:
>>
>> We should keep in mind that RFC 4398 specifies a method to do this  
>> for
>> PGP, e.g. look up CERT(jakob.kirei.se).
>
> Aren't we aiming to supersede that?
>
> Tony.
> -- 
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
> ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC  
> 7 TO
> SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH  
> BECOMING VERY
> ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Fri, 20 Aug 2010 00:41:05 +0100
From: Tony Finch <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] key per host

On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote:

> First off, remember that due to a bug in the way SSL was originally
> designed, we currently have to burn an IPv4 address per SSL instance.
> I know that there are work-arounds, but if you start to depend on them
> you make th backwards compatibility story much harder.

I don't do web seriously any more but I get the impression that the main
brake on SNI deployment (like many other things) is IE6.

> Say that I am managing 100,000 sites on 100 actual machines. Do I want
> to have to manage 100,000 keys that are bound to the sites or 100 keys
> that are bound to machines? Note that the sites float fairly freely
> from machine to machine and moving crypto on machines that use crypto
> accelerators is non-trivial.

If the server farm acts as a single service then a single key would seem
right to me. The crypto accelerator is more likely to live on the load
balancer than the servers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FAIR ISLE: CYCLONIC 5 BECOMING SOUTHERLY 7 TO SEVERE GALE 9, PERHAPS STORM 10
LATER. MODERATE OR ROUGH. RAIN. MODERATE OR POOR.

From: "Richard L. Barnes" <[email-masked]>
To: Warren Kumari <[email-masked]>
Date: Thu, 19 Aug 2010 19:40:25 -0400
Cc: Stephen Schultze <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

+1

There's some analogy to be made here to the RPKI [1], which overlays a  
PKI attesting to Internet resource holdings on the existing hierarchy  
for managing these resources.  Using the same management structure  
means the same set of people have to be trusted [2].  The security  
infrastructure just allows secured things to be tied back to these  
trusted entities.

[1] <http://tools.ietf.org/html/draft-ietf-sidr-arch>
[2] "trusted" in the sense of RFC 4949 :)

On Aug 19, 2010, at 6:04 PM, Warren Kumari wrote:

>
> On Aug 19, 2010, at 12:40 PM, Stephen Schultze wrote:
>
>> David said basically what I was going to say on your other points,  
>> but I wanted to also note the following:
>>
>> On Aug 19, 2010, at 9:01 AM, Phillip Hallam-Baker wrote:
>>> The point you are still not getting here is that the security of  
>>> the system is measured from the point of view of the relying  
>>> party. The relying party does not choose either the CA or the  
>>> Registrar, but an attacker can.
>>
>>
>> Let's describe the assurances that the relying party has in each  
>> case:
>>
>> Standard CA DV cert:
>> One of thousands of entities with cert-issuing authority said that  
>> the holder of the corresponding private key controls the zone for  
>> the domain in question.  There may be other people out there who  
>> also have certificates that assert that they control the domain,  
>> but neither you nor this issuing CA necessarily know if they  
>> exist.  Every root CA has equivalent authority as far as you're  
>> concerned, and an attacker can choose the lowest common denominator  
>> CA and serve you those certs at will.
>>
>> DNSSEC domain-key assertion:
>> The person who controls the zone for the domain in question holds  
>> the corresponding private key.  The only opportunity for mischief  
>> or mistake is in the one single path that the zone controller  
>> chose: their nameserver (especially if they are doing online  
>> signing), the registrar, the registry, and the root (and if there  
>> are DS records for sub-domains, whoever controls those).  What's  
>> more, any substitution of a baddie's DS record for the true domain  
>> owner's DS record would be highly visible and likely to be  
>> immediately corrected.
>
> So, when I initially started looking at all this (leveraging the  
> DNSSEC TA as a TA for other things) I thought that it was the best  
> thing since sliced bread... until it occurred to me that this was  
> changing who all could muck with your security.
> CA certs were handed out by CAs, and you didn't need to worry about  
> being attacked by your (probably outsourced) DNS provider, your  
> (probably reseller) registrar, their parent registrar and the  
> registry (or, more likely, the chappie who owned your nameserver  
> because you thought that 'P@ssword' was a good choice). I ended up  
> rewriting my initial draft saying that the only use for this was to  
> allow you to attest to what the *correct* CA issued cert was, and  
> apologized to the folk to whom I had given the original drafts to  
> for wasting their time...
> A long set of emails and phonecalls and IMs then occurred, with me  
> kvetching about how this was changing the fundamental trust model,  
> and opening you up to dinking with by all of the folk in the  
> registration / DNS side of things and how the sky was falling...  
> but, for every scenario that I came up with (rogue DNS provider,  
> hacked nameserver, bad registrar) folk convinced me that the  
> attackers could just as easily redirect my MX record and use that to  
> obtain a CA signed cert...  It took some time (I guess because I  
> didn't want to admit to myself just how screwed we were), but they  
> have fully convinced me -- once someone in a position to change your  
> DNS responses (by inserting DNSSEC signed keymaterial or something)  
> they are in a position to get a cert....
>
> W
>
>
>
>
>>
>> DNSSEC domain-key assertion plus EV:
>> Not only is there a high level of assurance that you are talking to  
>> the person who controls the zone, a third-party has verified who  
>> that person is.  You can have a substantial degree of trust in that  
>> third-party because they have been approved according to the more  
>> stringent EV requirements.
>>
>> DNSSEC domain-key assertions are backed up by the technical  
>> architecture.  CA assertions are backed up by standards groups,  
>> reputation, and perhaps even legal liability.
>>
>> The caveat for both systems are that technical vulnerabilities can  
>> and do happen, but I think that's well beyond this group's mandate  
>> to discuss.
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>
> --
> If the bad guys have copies of your MD5 passwords, then you have way  
> bigger problems than the bad guys having copies of your MD5 passwords.
> -- Richard A Steenbergen
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Fri, 20 Aug 2010 00:31:15 +0100
From: Tony Finch <[email-masked]>
To: Nicholas Weaver <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] key per host

On Thu, 19 Aug 2010, Nicholas Weaver wrote:
> On Aug 19, 2010, at 10:51 AM, Tony Finch wrote:
> >
> > Could you explain why you think [keys tied to IP addresses are]
> > necessary? TLS doesn't currently bind names and addresses in this way,
> > and doing so makes services less mobile than they could be.
>
> But SSH might:  If you want to bind to system identity rather than
> hostname, that would require asking based on IP.

Not if hosts are mobile. With an infrastructure like Bonjour, hostnames
have a more stable relationship to host identiry than IP addresses.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HEBRIDES: EASTERLY 4 BECOMING CYCLONIC GALE 8 TO STORM 10, PERHAPS VIOLENT
STORM 11 LATER. ROUGH OR VERY ROUGH. RAIN OR SQUALLY SHOWERS. MODERATE OR
POOR.

Date: Fri, 20 Aug 2010 00:26:24 +0100
From: Tony Finch <[email-masked]>
To: Jakob Schlyter <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] user keys

On Fri, 20 Aug 2010, Jakob Schlyter wrote:
>
> We should keep in mind that RFC 4398 specifies a method to do this for
> PGP, e.g. look up CERT(jakob.kirei.se).

Aren't we aiming to supersede that?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 7 TO
SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH BECOMING VERY
ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR.

From: Warren Kumari <[email-masked]>
To: Stephen Schultze <[email-masked]>
Date: Thu, 19 Aug 2010 18:04:10 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On Aug 19, 2010, at 12:40 PM, Stephen Schultze wrote:

> David said basically what I was going to say on your other points,  
> but I wanted to also note the following:
>
> On Aug 19, 2010, at 9:01 AM, Phillip Hallam-Baker wrote:
>> The point you are still not getting here is that the security of  
>> the system is measured from the point of view of the relying party.  
>> The relying party does not choose either the CA or the Registrar,  
>> but an attacker can.
>
>
> Let's describe the assurances that the relying party has in each case:
>
> Standard CA DV cert:
> One of thousands of entities with cert-issuing authority said that  
> the holder of the corresponding private key controls the zone for  
> the domain in question.  There may be other people out there who  
> also have certificates that assert that they control the domain, but  
> neither you nor this issuing CA necessarily know if they exist.   
> Every root CA has equivalent authority as far as you're concerned,  
> and an attacker can choose the lowest common denominator CA and  
> serve you those certs at will.
>
> DNSSEC domain-key assertion:
> The person who controls the zone for the domain in question holds  
> the corresponding private key.  The only opportunity for mischief or  
> mistake is in the one single path that the zone controller chose:  
> their nameserver (especially if they are doing online signing), the  
> registrar, the registry, and the root (and if there are DS records  
> for sub-domains, whoever controls those).  What's more, any  
> substitution of a baddie's DS record for the true domain owner's DS  
> record would be highly visible and likely to be immediately corrected.

So, when I initially started looking at all this (leveraging the  
DNSSEC TA as a TA for other things) I thought that it was the best  
thing since sliced bread... until it occurred to me that this was  
changing who all could muck with your security.
CA certs were handed out by CAs, and you didn't need to worry about  
being attacked by your (probably outsourced) DNS provider, your  
(probably reseller) registrar, their parent registrar and the registry  
(or, more likely, the chappie who owned your nameserver because you  
thought that 'P@ssword' was a good choice). I ended up rewriting my  
initial draft saying that the only use for this was to allow you to  
attest to what the *correct* CA issued cert was, and apologized to the  
folk to whom I had given the original drafts to for wasting their  
time...
A long set of emails and phonecalls and IMs then occurred, with me  
kvetching about how this was changing the fundamental trust model, and  
opening you up to dinking with by all of the folk in the  
registration / DNS side of things and how the sky was falling... but,  
for every scenario that I came up with (rogue DNS provider, hacked  
nameserver, bad registrar) folk convinced me that the attackers could  
just as easily redirect my MX record and use that to obtain a CA  
signed cert...  It took some time (I guess because I didn't want to  
admit to myself just how screwed we were), but they have fully  
convinced me -- once someone in a position to change your DNS  
responses (by inserting DNSSEC signed keymaterial or something) they  
are in a position to get a cert....

W

>
> DNSSEC domain-key assertion plus EV:
> Not only is there a high level of assurance that you are talking to  
> the person who controls the zone, a third-party has verified who  
> that person is.  You can have a substantial degree of trust in that  
> third-party because they have been approved according to the more  
> stringent EV requirements.
>
> DNSSEC domain-key assertions are backed up by the technical  
> architecture.  CA assertions are backed up by standards groups,  
> reputation, and perhaps even legal liability.
>
> The caveat for both systems are that technical vulnerabilities can  
> and do happen, but I think that's well beyond this group's mandate  
> to discuss.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

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

From: Jakob Schlyter <[email-masked]>
Date: Fri, 20 Aug 2010 00:02:25 +0200
To: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] user keys

On 19 aug 2010, at 19.08, Tony Finch wrote:

> Yes. At the moment the PKIs for identifying people are rather cumbersome.
> It would be nice to be able to use DNSSEC for verifying S/MIME or PGP
> messages.

We should keep in mind that RFC 4398 specifies a method to do this for PGP, e.g. look up CERT(jakob.kirei.se).

	jakob

From: Jakob Schlyter <[email-masked]>
Date: Thu, 19 Aug 2010 23:43:26 +0200
To: "Richard L. Barnes" <[email-masked]>
Cc: Tony Finch <[email-masked]>, [email-masked], Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] multi-application certificate RRs

On 19 aug 2010, at 19.18, Richard L. Barnes wrote:

> _xmpp-client._tcp.example.com CERT 1 1 1 http://example.com/xmpp.cer

why serve the cert over HTTP, when you can provide a fingerprint of the public key that you should expect via DNS (with DNSSEC) right away?

> If you're assuming DNSSEC and want to bind a key to a name, you don't need to attach the CRYPTO/CERT/whatever RR to the SRV.  Since the SRV is DNSSEC-signed, the target host just needs to authenticate as itself, so you would want the key to go with the target hostname (or its A/AAAA record).

+1

	jakob

Date: Thu, 19 Aug 2010 15:58:40 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: David Conrad <[email-masked]>, Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications
Reply-To: "Jeffrey A. Williams" <[email-masked]>

David and all,

  The choices for whom to trust are:  Verisign, ICANN, or the
USG.  Well that's a poor group to pick from according to 
many folks, eh Dave? >;)  As most americans know the trust
in their government is at a nearly 70 year low, Trust in ICANN
has ebbed and flowed but is nearly as low, and Verisign all
be they have good folks there, seems to be the default remaining
choice.  Seems like a logical deduction choice that leaves 
in some folks mind and experiance, not very good choices.

  We need more choices OR we need better choices, take your
pick.  The 'Truste Anchors' approach in DNSSEC gives a few
more, but perhaps not enough OR not the 'Right' ones to choose
from?

-----Original Message-----
>From: David Conrad <[email-masked]>
>Sent: Aug 18, 2010 10:42 PM
>To: Phillip Hallam-Baker <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications
>
>On Aug 18, 2010, at 7:26 PM, Phillip Hallam-Baker wrote:
>> I want to use dnssec without the ICANN root. 
>
>Feel free.  There are (currently) only about 300 TLD trust anchors you'll have to keep track of if all the TLDs started signing. ICANN says they'll be adding no more than about 1000/year. You'll have to figure out a way of securely fetching the trust anchors from the TLD admins who sign their zones to install into your validating resolver, but that's a minor detail.
>
>A single root of trust _can be_ better since there are less parties to vet and audit (1 versus many).  However, as I said, if you don't want to trust ICANN, VeriSign, and the US Government, you don't have to.
>
>Regards,
>-drc
>
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

Date: Thu, 19 Aug 2010 16:18:46 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: [keyassure] user keys

I think it is very clear that we are all agreed that we want this functionality.

But there is a distinct difference of opinion as to whether this
should be done using the DNS alone or by using the DNS to provide a
secured like to a service where the data is managed.

We already have protocols for the second approach. What we do not have
is a mechanism for finding out that the data is on offer.

Extending my previous proposal

_smtp._tcp.example.com OPTIONS "ssl=offered SMIME=XKMS,PKIXREP"

(see RFC 4386 for more info)

On Thu, Aug 19, 2010 at 4:02 PM, Richard L. Barnes <[email-masked]> wrote:
> I'm willing to admit that there are ways to massage different identifiers
> into the DNS if you want to. �It just seems to me like that work is more the
> domain of the working groups that are focused on the applications that use
> those identifiers, rather than a group focused on DNS and security. �If the
> application can map an identifier to a domain name, we can handle it, but I
> don't think we should be focused on defining mappings for all the different
> identifiers that are around.
>
> Let me try to clarify what I meant when I said "the DNS is about domain
> names". �As an example, consider the difference between domain names and SIP
> URIs and how they're managed. Information about a domain name is stored in a
> name server, in the form of RRs. �Information about a SIP URI is stored in a
> SIP registrar. �When a DNS application wants information about a domain
> name, it asks the name server; when a SIP application wants information
> about a URI, it asks the registrar.
>
> If information about a SIP URI is going to be published in the DNS, then it
> has to be transferred from the registrar to a name server. �In addition to
> the brittleness this introduces (in terms of keeping data in sync, making
> sure the name translation is done properly, etc.), there's also something of
> a security concern here. �Now a relying party has to trust two entities
> instead of one for the information it's using at the application layer --
> the registrar and the name server. �Even if the registrar is completely
> honest, the operator of the name server might be able to bid down security
> by saying that there's no public key available for the URI in question.
>
> The up-shot is that it seems like the client/RP should be able to ask the
> registrar directly. �In SIP, you might use a presence request; in SMTP, you
> might add a header that UAs can cache. �There doesn't seem to me to be any
> especial benefit in doing it in the DNS, especially since the needs of
> different applications can be very different.
>
> --Richard
>
>
>
> On Aug 19, 2010, at 3:19 PM, David Conrad wrote:
>
>> On Aug 19, 2010, at 11:07 AM, Richard L. Barnes wrote:
>>>>
>>>> In many cases user keys have a username@domain structure so it would
>>>> make
>>>> sense for user keys to be signed by a domain key which can in turn be
>>>> validated using the DNS.
>>>
>>> Although many user identifiers have that form superficially, there are
>>> more worms here than you expect. �If you're going to be precise and
>>> thorough, you'll need to address the full syntax of the URI scheme you're
>>> considering, which is significantly more complex.
>>
>> Why would you need to deal with the full syntax of a URI? �What scenarios
>> are you imagining that would suggest we can't solve the username@domain
>> structure? �My understanding of the suggestion (which may be wrong) is
>> signing something like
>>
>> $ORIGIN virtualized.org.
>> drc � � IN PGPKEY <mumble>
>> drc � � IN SMIMEKEY <mumble>
>> ...
>>
>>> And this is not mentioning things like internationalization...
>>
>> Which isn't a problem since the DNS is 8-bit clean and since you don't
>> have to worry about backwards compatibility, you could put anything into the
>> label. �The only constraint is the label has to be less than 64 bytes.
>>
>>> Even if you went to the trouble of defining a mapping, it would just be
>>> an specific way of constructing the names you would use to find keys for a
>>> given type of identifier. �Nothing would be different about how the
>>> information is encoded in the DNS.
>>
>> Right. �It would just be using the DNS as a distributed tag lookup system
>> that now returns validatable values. �Which is OK since that is what the DNS
>> is.
>>
>>> Like Paul said, the DNS is about domain names.
>>
>> I honestly don't understand what this means.
>>
>>> A zone is authoritative for the names it contains. �If you start talking
>>> about things like email addresses, you have a whole different way that
>>> identifiers are assigned, and the trust model should map along with that.
>>
>> A whole different way than what? �I'd think that if you care about the
>> trust model mapping to the way the identifiers were assigned, you'd do zone
>> delegations to make that happen.
>>
>> I'm clearly missing something.
>>
>> Regards,
>> -drc
>>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Thu, 19 Aug 2010 16:11:41 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] key per host

First off, remember that due to a bug in the way SSL was originally
designed, we currently have to burn an IPv4 address per SSL instance.
I know that there are work-arounds, but if you start to depend on them
you make th backwards compatibility story much harder.

What we are trying to do here is to make use of crypto as easy and
painless as possible. So we should make as much effort as possible to
conform to the existing infrastructure rather than create unnecessary
restrictions.

Take for example the common case today where we have 300 web servers
on one host with one IP address. At the moment only one of those
virtual web servers can have SSL enabled since the client does not
tell the server which domain it is interested in until after the cert
is transferred.

Say that I am managing 100,000 sites on 100 actual machines. Do I want
to have to manage 100,000 keys that are bound to the sites or 100 keys
that are bound to machines? Note that the sites float fairly freely
from machine to machine and moving crypto on machines that use crypto
accelerators is non-trivial.

If the crypto keys are bound to the machine, then all I need to do to
transfer a virtual web server is to move the content and once that is
complete flip the relevant bits in the DNS to redirect queries.

When I started I was looking at three RRs to support the features I
consider necessary. But I now see that I could do it with a single
record, provided that it is extensible.

Say that a web client is trying to connect to www.example.com. Today
the resolution process begins with pulling the A record. I suggest
that instead the client should make requests for:

www.example.com           A
_http._tcp.example.com   OPTIONS

These can fire in parallel so there is no real performance hit.

The OPTIONS record is a list of ASCII encoded tag-value pairs, just
like TXT and just like DKIM uses.

The record may contain:

* key information
* security policy information
* protocol information

All the fields in the record are defined on a per-application protocol
record basis. So there would be a general draft and an application
specific draft to state how to use this record with HTTP, SMTP,
SUBMIT, IMAP, POP3 and others.

For the simplest Web site the record might be

_http._tcp.www.example.com OPTIONS "ssl=offered
certh=(sha2,0b92c7808b91f7dc1cadaf8f9afe4d9834372adcc3e18f1d
4df6704768eea870)"

For a site with two separate inbound SMTP servers we would want to
have separate keys because the failover is being run by another
company that we don't want to give a key to:

_smtp._tcp.example.com OPTIONS "ssl=offered"

cert1._smtp._tcp.example.com OPTIONS "ssl=offered
certh=(3e8e64500a2ac1ea38203ef943c5e3188e1e537076b7846219996aa225e76c0e)"
cert2._smtp._tcp.example.com OPTIONS "ssl=offered
certh=(a7fc2dcd765f94801bc06edd6420aad6cfe7fbfaa38113a5
e860a00607343b0d)"

Each cert has an X.509v3 extension inside to disambiguate it from
other certs for that service.

For the IMAP service, SSL is required rather than merely supported. So we have:

_submit._tcp.example.com OPTIONS "ssl=required SRV"
_imap._tcp.example.com OPTIONS "ssl=required SRV"
_pop._tcp.example.com OPTIONS "ssl=required SRV"

A mail client that understood this record could complete the entire
account configuration correctly from the email address, authentication
info and this record alone. And since the binding is to an SRV record
rather than to specific host names as is current practice, maintenance
of large sites is made easier.

I am not certain how SSH fits into this scheme. I typically use SSH to
log into specific machines. But since SSH can use certificates, people
could put the disambiguating blob in the cert should they need it.

This approach also opens up possibilities of specifying other protocol
enhancements. I slipped in SRV earlier, there could well be other
options.

On Thu, Aug 19, 2010 at 1:55 PM, Tony Finch <[email-masked]> wrote:
> On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote:
>> On Aug 19, 2010, at 1:39 PM, Tony Finch <[email-masked]> wrote:
>> >
>> > Who buys multiple certificates when they only need one?
>>
>> People who read their terms of service?
>
> :-)
>
> IME, though one might need to buy a licence to use a certificate on
> multiple hosts, this does not mean one needs multiple certificates
> associated with multiple private keys.
>
> Tony.
> --
> f.anthony.n.finch �<[email-masked]> �http://dotat.at/
> IRISH SEA: SOUTHEAST, VEERING SOUTH 5 TO 7, OCCASIONALLY GALE 8. MODERATE OR
> ROUGH. RAIN THEN SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
>

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

Date: Thu, 19 Aug 2010 16:10:36 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] multi-application certificate RRs

There are issues with wildcards that are very specific to DKIM.
Specifically, in DKIM you want to be able to create policy records
that bind to *.example.com.

I don't see that as a problem here. But it is not insoluble in any
case. It would be addressed by XPTR.

The bigger problem is with using prefixes as a substitute for
requesting a new record by overloading TXT. There you have the problem
that a wildcard for one purpose can clobber unrelated prefixes.

That is not a problem here because we are using a separate record.

On Thu, Aug 19, 2010 at 2:02 PM, Tony Finch <[email-masked]> wrote:
> On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote:
>
>> I would hope that if we get people to start using DNS for their keying
>> material that there would also be more widespread use of SRV.
>> Wouldn't it make sense to use the exact same approach for the protocol
>> specific keying information?
>
> RFC 5507 argues against SRV-style name prefixes because they interact
> badly with wildcards. On the other hand it is rather complacent about RR
> type exhaustion.
>
> Tony.
> --
> f.anthony.n.finch �<[email-masked]> �http://dotat.at/
> SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD.
>

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

From: "Richard L. Barnes" <[email-masked]>
To: David Conrad <[email-masked]>
Date: Thu, 19 Aug 2010 16:02:58 -0400
Cc: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: [keyassure] user keys

I'm willing to admit that there are ways to massage different  
identifiers into the DNS if you want to.  It just seems to me like  
that work is more the domain of the working groups that are focused on  
the applications that use those identifiers, rather than a group  
focused on DNS and security.  If the application can map an identifier  
to a domain name, we can handle it, but I don't think we should be  
focused on defining mappings for all the different identifiers that  
are around.

Let me try to clarify what I meant when I said "the DNS is about  
domain names".  As an example, consider the difference between domain  
names and SIP URIs and how they're managed. Information about a domain  
name is stored in a name server, in the form of RRs.  Information  
about a SIP URI is stored in a SIP registrar.  When a DNS application  
wants information about a domain name, it asks the name server; when a  
SIP application wants information about a URI, it asks the registrar.

If information about a SIP URI is going to be published in the DNS,  
then it has to be transferred from the registrar to a name server.  In  
addition to the brittleness this introduces (in terms of keeping data  
in sync, making sure the name translation is done properly, etc.),  
there's also something of a security concern here.  Now a relying  
party has to trust two entities instead of one for the information  
it's using at the application layer -- the registrar and the name  
server.  Even if the registrar is completely honest, the operator of  
the name server might be able to bid down security by saying that  
there's no public key available for the URI in question.

The up-shot is that it seems like the client/RP should be able to ask  
the registrar directly.  In SIP, you might use a presence request; in  
SMTP, you might add a header that UAs can cache.  There doesn't seem  
to me to be any especial benefit in doing it in the DNS, especially  
since the needs of different applications can be very different.

--Richard

On Aug 19, 2010, at 3:19 PM, David Conrad wrote:

> On Aug 19, 2010, at 11:07 AM, Richard L. Barnes wrote:
>>> In many cases user keys have a username@domain structure so it  
>>> would make
>>> sense for user keys to be signed by a domain key which can in turn  
>>> be
>>> validated using the DNS.
>>
>> Although many user identifiers have that form superficially, there  
>> are more worms here than you expect.  If you're going to be precise  
>> and thorough, you'll need to address the full syntax of the URI  
>> scheme you're considering, which is significantly more complex.
>
> Why would you need to deal with the full syntax of a URI?  What  
> scenarios are you imagining that would suggest we can't solve the  
> username@domain structure?  My understanding of the suggestion  
> (which may be wrong) is signing something like
>
> $ORIGIN virtualized.org.
> drc	IN PGPKEY <mumble>
> drc	IN SMIMEKEY <mumble>
> ...
>
>> And this is not mentioning things like internationalization...
>
> Which isn't a problem since the DNS is 8-bit clean and since you  
> don't have to worry about backwards compatibility, you could put  
> anything into the label.  The only constraint is the label has to be  
> less than 64 bytes.
>
>> Even if you went to the trouble of defining a mapping, it would  
>> just be an specific way of constructing the names you would use to  
>> find keys for a given type of identifier.  Nothing would be  
>> different about how the information is encoded in the DNS.
>
> Right.  It would just be using the DNS as a distributed tag lookup  
> system that now returns validatable values.  Which is OK since that  
> is what the DNS is.
>
>> Like Paul said, the DNS is about domain names.
>
> I honestly don't understand what this means.
>
>> A zone is authoritative for the names it contains.  If you start  
>> talking about things like email addresses, you have a whole  
>> different way that identifiers are assigned, and the trust model  
>> should map along with that.
>
> A whole different way than what?  I'd think that if you care about  
> the trust model mapping to the way the identifiers were assigned,  
> you'd do zone delegations to make that happen.
>
> I'm clearly missing something.
>
> Regards,
> -drc
>

From: "Richard L. Barnes" <[email-masked]>
To: Nicholas Weaver <[email-masked]>
Date: Thu, 19 Aug 2010 15:47:18 -0400
Cc: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: [keyassure] key per host

Depends on what you mean by "system identity", doesn't it?

I tend to take a user-centric view of this.  If I type in "ssh  
10.1.1.1", then the key should be bound to the address, but if I type  
in "ssh example.com", the key should be bound to the name -- I don't  
care what the IP address is as long as the guy at the other end has  
the right key for the domain.

This does raise an interesting question for the group, though: How do  
we want to handle "https://10.1.1.1/" and "https://[fe80::abcd: 
123]/"?  Seems like there are two basic possibilities:
1. Use the reverse DNS tree
2. Declare it out of scope because we're focused authenticating domain  
names

My slight preference is for (2).

--Richard

On Aug 19, 2010, at 3:43 PM, Nicholas Weaver wrote:

>
> On Aug 19, 2010, at 10:51 AM, Tony Finch wrote:
>
>> On Thu, 19 Aug 2010, Nicholas Weaver wrote:
>>>
>>> However, service should be identified by both hostname AND IP  
>>> address
>>> depending on the server's preference, thus any scheme that says
>>>
>>> _keymaterial_.host.mydomain.com as a query should also include a  
>>> query for
>>>
>>> _keymaterial_.{A/AAAA record for host.mydomain.com}, IFF the  
>>> reference
>>> for _keymaterial_.host.mydomain.com says that IP should be  
>>> referred OR
>>> the service was contacted based on IP rather than hostname.
>>
>> Could you explain why you think this is necessary? TLS doesn't  
>> currently
>> bind names and addresses in this way, and doing so makes services  
>> less
>> mobile than they could be.
>
> But SSH might:  If you want to bind to system identity rather than  
> hostname, that would require asking based on IP.
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Thu, 19 Aug 2010 12:43:44 -0700
To: Tony Finch <[email-masked]>
Cc: [email-masked], Nicholas Weaver <[email-masked]>
Subject: Re: [keyassure] key per host

On Aug 19, 2010, at 10:51 AM, Tony Finch wrote:

> On Thu, 19 Aug 2010, Nicholas Weaver wrote:
>> 
>> However, service should be identified by both hostname AND IP address
>> depending on the server's preference, thus any scheme that says
>> 
>> _keymaterial_.host.mydomain.com as a query should also include a query for
>> 
>> _keymaterial_.{A/AAAA record for host.mydomain.com}, IFF the reference
>> for _keymaterial_.host.mydomain.com says that IP should be referred OR
>> the service was contacted based on IP rather than hostname.
> 
> Could you explain why you think this is necessary? TLS doesn't currently
> bind names and addresses in this way, and doing so makes services less
> mobile than they could be.

But SSH might:  If you want to bind to system identity rather than hostname, that would require asking based on IP.

From: "Richard L. Barnes" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 15:38:07 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Alternative Charter Proposal

I don't think this text claims that one model is better than another  
(ok, except for the word "problem"), just that they offer different  
characteristics.  Namely, in DNSSEC, the key heirarchy overlays is the  
DNS heirarchy, while with the traditional CA model, the key heirarchy  
isn't related to anything in particular.  If you want, we could  
eliminate the second and third paragraphs that discuss the different  
models, but it seems like the charter should explain why what we're  
doing is different from what has happened in the past.

Neither this charter nor any other document can say anything about the  
"validity" of a trust model.  As always, it's up to the entity that's  
authenticating to choose what system he wants to use to claim an  
identity, and it's up to an RP to decide what he trusts.

The only question about trust models that is germane to the charter  
discussion is whether there exist domain operators who want to assert  
name/key bindings in the DNS for use with security protocols, and  
whether there are relying parties who would be interested in using  
this information.  If the answer is "yes", then the work should  
proceed, IMO, with about the scope described below.  And the sense I  
got in the room in Maastricht was that the answer is "yes".

--Richard

On Aug 19, 2010, at 3:18 PM, Phillip Hallam-Baker wrote:

> That is still an architectural statement, not a problem statement.
>
> If you want to put statements into the charter asserting the benefit
> of one particular trust topology, then you have to accept the argument
> over whether those claims are actually true as being in scope for
> charter discussions.
>
> If you want to avoid those discussions then simply take the statements
> out. They are not necessary.
>
> On Thu, Aug 19, 2010 at 2:16 PM, Richard L. Barnes <[email-masked]>  
> wrote:
>> I disagree with the objective and problem statement here; the  
>> objective is
>> too vague, and the problem statement seems completely unrelated.  I  
>> actually
>> started out writing the email not intending to write a new charter,  
>> but
>> here's another proposal:
>>
>> Objective:
>>
>> Specify mechanisms for Internet applications to use information  
>> distributed
>> through the DNS to establish cryptographically assured bindings  
>> between
>> domain names and public keys.
>>
>> Problem Statement:
>>
>> Many Internet applications require protocol entities to  
>> authenticate that
>> they represent a certain domain name.  For instance, in HTTPS, a  
>> server
>> responding to a query for <https://www.example.com> is expected to
>> authenticate as "www.example.com".  Security protocols such as TLS  
>> and IPsec
>> accomplish this authentication by allowing an endpoint to prove  
>> ownership of
>> a private key whose corresponding public key is somehow bound to  
>> the name
>> being authenticated.  As a pre-requisite for authentication, then,  
>> these
>> protocols require a mechanism for bindings to be asserted between  
>> public
>> keys and domain names.
>>
>> In the past, these bindings have been asserted by parties external  
>> to the
>> DNS, using X.509 certificates.  A certification authority (CA) can  
>> create
>> certificates that contain a domain name (e.g., as a Common Name or  
>> dNSName
>> Subject Alternative Name) and a public key.  When a server presents  
>> this
>> certificate and proves ownership of the private key, a relying  
>> party that
>> trusts the CA to authenticate domain ownership can be assured that  
>> the
>> server legitimately represents the domain.
>>
>> One problem with this model is that the CAs that are typically used  
>> have no
>> relationship to the DNS infrastructure about which they are making
>> assertions.  Modern browsers and operating systems typically  
>> include more
>> than a hundred CAs as trust anchors, any of which can create a  
>> certificate
>> for any domain name.
>>
>> DNSSEC provides a mechanism for a domain operator to sign DNS  
>> information
>> directly, using keys that are bound to the domain by the parent  
>> domain;
>> relying parties can continue this chain up to any trust anchor that  
>> they
>> accept.  In this way, bindings of keys to domains are asserted not by
>> external entities, but by the entities that operate the DNS.  In  
>> addition to
>> providing a more authoritative way of binding DNS names to keys, this
>> technique inherently limits the scope of any given entity to the  
>> names in
>> zones he controls.
>>
>> This working group will develop mechanisms for domain operators to  
>> present
>> bindings between names within their control and public keys, in  
>> such a way
>> that these bindings can be integrity-protected (and thus shown to be
>> authentically from the domain operator) using DNSSEC and used as a  
>> basis for
>> authentication in protocols that use domain names as identifiers.   
>> The group
>> may also specify updates or clarifications to protocols to describe  
>> how
>> protocol entities discover and validate these bindings in the  
>> execution of a
>> specific application.
>>
>> Note that this working group is specifically focused on bindings  
>> between
>> domain names and public keys, rather than bindings between names  
>> and other
>> sorts of information.  For example, an X.509 certificate can  
>> associate many
>> types of information with its subject, including things like IP  
>> address
>> holdings and images of logos, as well as bindings to higher-layer  
>> identities
>> (e.g., corporate names).  Mechanisms developed by this group will  
>> not be
>> focused on these additional data, only on public keys.  This basic  
>> binding
>> might be used, however, to associate a domain name with rich data by
>> including the same public key in the certificate that is bound to the
>> domain.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Aug 19, 2010, at 1:12 PM, Phillip Hallam-Baker wrote:
>>
>>> In response to Paul's request, I propose the following as a better
>>> statement of what the group is trying to do and to not do.
>>>
>>>
>>> Objective:
>>>
>>> Specify mechanisms that allow Internet applications to establish
>>> cryptographically enhanced communications through use of information
>>> distributed through the DNS.
>>>
>>> Problem Statement:
>>>
>>> Today the Internet is insecure by default and security is the
>>> exception. If the security of the Internet is to be improved,  
>>> security
>>> must become the default. In particular modern computers have the
>>> ability to employ cryptographic security enhancements with minimal  
>>> or
>>> negligible impact on performance, yet only a tiny proportion of
>>> Internet traffic is encrypted or authenticated.
>>>
>>> One of the key weaknesses of the current Internet Public Key
>>> Infrastructure (PKI) is that the most widely used Internet PKI is
>>> based on the X.500 Directory scheme intended to support an entirely
>>> different networking infrastructure.
>>>
>>> The naming infrastructure of the Internet is the DNS, not X.500.  
>>> While
>>> the PKIX specifications provide a means of mapping X.509v3  
>>> attributes
>>> to DNS names there is currently no widely accepted, generalized  
>>> means
>>> of achieving the mapping from DNS names to X.509 certificates in
>>> particular or to cryptographic keying material in general. DKIM and
>>> SSH have demonstrated the utility of this approach in specific
>>> domains, these specifications
>>>
>>> Recent progress in deployment of DNSSEC has renewed focus on the use
>>> of the DNS naming system to support cryptographic operations. In
>>> particular:
>>>
>>>  * Discovery of keying material by DNS name
>>>  * Discovery of security criteria by DNS names
>>>  * Verification of keying material through DNSSEC trust chains
>>>
>>> Scope:
>>>
>>>  * Use of existing security protocols with DNS established keys
>>>  * Use of DNS to verify existing certificate / keysigning / security
>>> assertion material formats
>>>  * Means of verifying key/certificate chains using DNSSEC  
>>> exclusively
>>>  * Means of verifying key/certificate chains using DNSSEC in
>>> combination with other existing means
>>>
>>> Out-Of-Scope:
>>>
>>> * Reason for choice of specific trust paths
>>> * New formats for keying material (other than raw keys)
>>> * New trust architectures (unless they can be expressed in existing
>>> formats
>>>
>>>
>>> What I am proposing here is that instead of committing up front to a
>>> view of DNSSEC as being intrinsically opposed to existing PKI  
>>> schemes
>>> in that charter, we look for way that we can use DNSSEC and existing
>>> infrastructures together.
>>>
>>> The biggest mistake made in the PKI world was when the PGP and PEM
>>> people decided that they could not possibly work together and so  
>>> they
>>> developed to schemes for email security that have competed for
>>> mindshare ever since. Jon Callas and I tried to work out ways of
>>> overcoming the consequences of that choice on many occasions without
>>> much success. The result has been that neither PGP nor SMIME is  
>>> widely
>>> used.
>>>
>>>
>>> --
>>> Website: http://hallambaker.com/
>>> _______________________________________________
>>> keyassure mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/keyassure
>>
>>
>
>
>
> -- 
> Website: http://hallambaker.com/

Date: Thu, 19 Aug 2010 14:26:40 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: [keyassure] user keys
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Tony and all,

  FWIW, I think this should be a primary goal...

-----Original Message-----
>From: Tony Finch <[email-masked]>
>Sent: Aug 19, 2010 12:08 PM
>To: [email-masked]
>Subject: [keyassure] user keys
>
>Paul Wouters <[email-masked]> wrote:
>>On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote:
>>>
>>> In my view user keys do not belong in the DNS because the DNS is an
>>> infrastructure for locating network services, not network users.
>>
>> I disagree. You are locating an identity. Currently, that is mostly done
>> based on an IP address and port. I'd hope tomorrow that would mostly be
>> done based on a public key or hash. Especially with mobile devices, IP's
>> are very volatile. To locate a service or user, we need the DNS.
>
>Yes. At the moment the PKIs for identifying people are rather cumbersome.
>It would be nice to be able to use DNSSEC for verifying S/MIME or PGP
>messages.
>
>Tony.
>-- 
>f.anthony.n.finch  <[email-masked]>  http://dotat.at/
>SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD.
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

From: David Conrad <[email-masked]>
Date: Thu, 19 Aug 2010 12:19:48 -0700
To: Richard L. Barnes <[email-masked]>
Cc: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: [keyassure] user keys

On Aug 19, 2010, at 11:07 AM, Richard L. Barnes wrote:
>> In many cases user keys have a username@domain structure so it would make
>> sense for user keys to be signed by a domain key which can in turn be
>> validated using the DNS.
> 
> Although many user identifiers have that form superficially, there are more worms here than you expect.  If you're going to be precise and thorough, you'll need to address the full syntax of the URI scheme you're considering, which is significantly more complex.  

Why would you need to deal with the full syntax of a URI?  What scenarios are you imagining that would suggest we can't solve the username@domain structure?  My understanding of the suggestion (which may be wrong) is signing something like

$ORIGIN virtualized.org.
drc	IN PGPKEY <mumble>
drc	IN SMIMEKEY <mumble>
...

> And this is not mentioning things like internationalization...

Which isn't a problem since the DNS is 8-bit clean and since you don't have to worry about backwards compatibility, you could put anything into the label.  The only constraint is the label has to be less than 64 bytes.

> Even if you went to the trouble of defining a mapping, it would just be an specific way of constructing the names you would use to find keys for a given type of identifier.  Nothing would be different about how the information is encoded in the DNS.

Right.  It would just be using the DNS as a distributed tag lookup system that now returns validatable values.  Which is OK since that is what the DNS is.

> Like Paul said, the DNS is about domain names.  

I honestly don't understand what this means.

> A zone is authoritative for the names it contains.  If you start talking about things like email addresses, you have a whole different way that identifiers are assigned, and the trust model should map along with that.

A whole different way than what?  I'd think that if you care about the trust model mapping to the way the identifiers were assigned, you'd do zone delegations to make that happen.

I'm clearly missing something.

Regards,
-drc

Date: Thu, 19 Aug 2010 15:18:01 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Alternative Charter Proposal

That is still an architectural statement, not a problem statement.

If you want to put statements into the charter asserting the benefit
of one particular trust topology, then you have to accept the argument
over whether those claims are actually true as being in scope for
charter discussions.

If you want to avoid those discussions then simply take the statements
out. They are not necessary.

On Thu, Aug 19, 2010 at 2:16 PM, Richard L. Barnes <[email-masked]> wrote:
> I disagree with the objective and problem statement here; the objective is
> too vague, and the problem statement seems completely unrelated. �I actually
> started out writing the email not intending to write a new charter, but
> here's another proposal:
>
> Objective:
>
> Specify mechanisms for Internet applications to use information distributed
> through the DNS to establish cryptographically assured bindings between
> domain names and public keys.
>
> Problem Statement:
>
> Many Internet applications require protocol entities to authenticate that
> they represent a certain domain name. �For instance, in HTTPS, a server
> responding to a query for <https://www.example.com> is expected to
> authenticate as "www.example.com". �Security protocols such as TLS and IPsec
> accomplish this authentication by allowing an endpoint to prove ownership of
> a private key whose corresponding public key is somehow bound to the name
> being authenticated. �As a pre-requisite for authentication, then, these
> protocols require a mechanism for bindings to be asserted between public
> keys and domain names.
>
> In the past, these bindings have been asserted by parties external to the
> DNS, using X.509 certificates. �A certification authority (CA) can create
> certificates that contain a domain name (e.g., as a Common Name or dNSName
> Subject Alternative Name) and a public key. �When a server presents this
> certificate and proves ownership of the private key, a relying party that
> trusts the CA to authenticate domain ownership can be assured that the
> server legitimately represents the domain.
>
> One problem with this model is that the CAs that are typically used have no
> relationship to the DNS infrastructure about which they are making
> assertions. �Modern browsers and operating systems typically include more
> than a hundred CAs as trust anchors, any of which can create a certificate
> for any domain name.
>
> DNSSEC provides a mechanism for a domain operator to sign DNS information
> directly, using keys that are bound to the domain by the parent domain;
> relying parties can continue this chain up to any trust anchor that they
> accept. �In this way, bindings of keys to domains are asserted not by
> external entities, but by the entities that operate the DNS. �In addition to
> providing a more authoritative way of binding DNS names to keys, this
> technique inherently limits the scope of any given entity to the names in
> zones he controls.
>
> This working group will develop mechanisms for domain operators to present
> bindings between names within their control and public keys, in such a way
> that these bindings can be integrity-protected (and thus shown to be
> authentically from the domain operator) using DNSSEC and used as a basis for
> authentication in protocols that use domain names as identifiers. �The group
> may also specify updates or clarifications to protocols to describe how
> protocol entities discover and validate these bindings in the execution of a
> specific application.
>
> Note that this working group is specifically focused on bindings between
> domain names and public keys, rather than bindings between names and other
> sorts of information. �For example, an X.509 certificate can associate many
> types of information with its subject, including things like IP address
> holdings and images of logos, as well as bindings to higher-layer identities
> (e.g., corporate names). �Mechanisms developed by this group will not be
> focused on these additional data, only on public keys. �This basic binding
> might be used, however, to associate a domain name with rich data by
> including the same public key in the certificate that is bound to the
> domain.
>
>
>
>
>
>
>
>
>
> On Aug 19, 2010, at 1:12 PM, Phillip Hallam-Baker wrote:
>
>> In response to Paul's request, I propose the following as a better
>> statement of what the group is trying to do and to not do.
>>
>>
>> Objective:
>>
>> Specify mechanisms that allow Internet applications to establish
>> cryptographically enhanced communications through use of information
>> distributed through the DNS.
>>
>> Problem Statement:
>>
>> Today the Internet is insecure by default and security is the
>> exception. If the security of the Internet is to be improved, security
>> must become the default. In particular modern computers have the
>> ability to employ cryptographic security enhancements with minimal or
>> negligible impact on performance, yet only a tiny proportion of
>> Internet traffic is encrypted or authenticated.
>>
>> One of the key weaknesses of the current Internet Public Key
>> Infrastructure (PKI) is that the most widely used Internet PKI is
>> based on the X.500 Directory scheme intended to support an entirely
>> different networking infrastructure.
>>
>> The naming infrastructure of the Internet is the DNS, not X.500. While
>> the PKIX specifications provide a means of mapping X.509v3 attributes
>> to DNS names there is currently no widely accepted, generalized means
>> of achieving the mapping from DNS names to X.509 certificates in
>> particular or to cryptographic keying material in general. DKIM and
>> SSH have demonstrated the utility of this approach in specific
>> domains, these specifications
>>
>> Recent progress in deployment of DNSSEC has renewed focus on the use
>> of the DNS naming system to support cryptographic operations. In
>> particular:
>>
>> �* Discovery of keying material by DNS name
>> �* Discovery of security criteria by DNS names
>> �* Verification of keying material through DNSSEC trust chains
>>
>> Scope:
>>
>> �* Use of existing security protocols with DNS established keys
>> �* Use of DNS to verify existing certificate / keysigning / security
>> assertion material formats
>> �* Means of verifying key/certificate chains using DNSSEC exclusively
>> �* Means of verifying key/certificate chains using DNSSEC in
>> combination with other existing means
>>
>> Out-Of-Scope:
>>
>> * Reason for choice of specific trust paths
>> * New formats for keying material (other than raw keys)
>> * New trust architectures (unless they can be expressed in existing
>> formats
>>
>>
>> What I am proposing here is that instead of committing up front to a
>> view of DNSSEC as being intrinsically opposed to existing PKI schemes
>> in that charter, we look for way that we can use DNSSEC and existing
>> infrastructures together.
>>
>> The biggest mistake made in the PKI world was when the PGP and PEM
>> people decided that they could not possibly work together and so they
>> developed to schemes for email security that have competed for
>> mindshare ever since. Jon Callas and I tried to work out ways of
>> overcoming the consequences of that choice on many occasions without
>> much success. The result has been that neither PGP nor SMIME is widely
>> used.
>>
>>
>> --
>> Website: http://hallambaker.com/
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>
>

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

From: "Richard L. Barnes" <[email-masked]>
To: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 14:59:52 -0400
Cc: [email-masked]
Subject: Re: [keyassure] user keys

Ok, but if you're representing users as domain names, then you're just  
doing the same thing as you're doing for any other domain name, and  
it's not interesting any more.

On Aug 19, 2010, at 2:58 PM, Tony Finch wrote:

> On Thu, 19 Aug 2010, Richard L. Barnes wrote:
>>
>>>> It seems like it would be a big enough win for this group to come
>>>> up with a better way of binding keys to domain names.
>>>
>>> That sounds like an argument for putting user keys in the DNS.
>>
>> Not sure how that follows?
>
> See below. I was facetiously pointing out that two adjacent sentences
> seemed to contradict each other. I don't think "domain name" rules out
> "user identifier represented as a domain name". For example several  
> ISPs
> create a domain per user, and some sites shard their mail services  
> with
> per-user service host names.
>
>>> Sorry for being argumentative but you need to be clear about where  
>>> and why
>>> you are drawing a line :-)
>
> Tony.
> -- 
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
> ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC  
> 7 TO
> SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH  
> BECOMING VERY
> ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR.

From: "Richard L. Barnes" <[email-masked]>
To: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 14:58:55 -0400
Cc: [email-masked]
Subject: Re: [keyassure] signalling use of crypto as well as service keys

These are not DNS problems or TLS problems, hence out of scope for  
this group.

>> * there is no way to know if the web site uses ssl

This is being discussed in the HASMAT group.  See, for example:
<http://tools.ietf.org/html/draft-hodges-strict-transport-sec>

>> * there is no way to know if the recipient can accept smime
>> * there is no way to find an smime recipient cert that is widely  
>> supported

DNS is not the proper mechanism for distributing information of this  
character, since it's bound to email addresses, not domain names.

> The cause of the problem was that it was never specified what the TLS
> certificate identifies in SMTP: hostname? mail domain? and at the time
> there was no way to signal to a mail server what certificate the  
> client
> expected. As a result mail server certificates are never validated  
> so most
> of them present certificates that cannot be validated since any old  
> cert
> will work.
>
> The only way to fix this is to clearly specify how authentication must
> work, and add some kind of signal so the server can indicate that it
> supports this spec and so clients should be able to authenticate it.

The fact that SMTP has a poorly specified security mechanism is not  
something for this group.  That would be an APPAREA group that would  
update the SMTP specs to do proper server identity checking.

> One of the key differences between the web and SMTP is the extra
> indirection in MX records. SRV records have the same property. This  
> is a
> great boon for virtual hosting - it's so normal for a mail server to  
> host
> multiple mail domains that it isn't even called virtual hosting.  
> It's also
> normal for a mail domain's DNS, primary, and backup MXs to be hosted  
> by
> three or more different organizations.
>
> If the DNS associates keys directly with a mail domain [1] then  
> there's a
> coupling problem between the DNS host and the application host: an  
> app key
> rollover will require updating hundreds of domains which may be  
> hosted by
> many third parties. If the DNS associates keys with host names (i.e.  
> the
> targets of MX records) then we have to think very carefully about the
> security properties of that indirection, since normally we want to
> directly secure the identity that the user sees.

The underlying problem here is that MX records aren't authenticated.   
If they are, then you just do the same thing as with the web and  
authenticate against the server's host name; if not, then you have to  
authenticate against the mail domain.  This is exactly the problem  
discussed in these drafts...
<http://tools.ietf.org/html/draft-ietf-xmpp-dna>
<http://tools.ietf.org/html/draft-barnes-hard-problem>
... and it goes away if you have DNSSEC.  So it's really not germane  
here, where we're starting with the assumption of DNSSEC.

> Nicholas Weaver has also been talking about the next layer of  
> indirection,
> associating keys with IP addresses. I'm doubtful that this would be  
> useful
> since it is even further from securing the identity that the user  
> sees,
> and it does not have obvious vhosting benefits.

On this at least we agree :)

Date: Thu, 19 Aug 2010 19:58:44 +0100
From: Tony Finch <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] user keys

On Thu, 19 Aug 2010, Richard L. Barnes wrote:
>
> > > It seems like it would be a big enough win for this group to come
> > > up with a better way of binding keys to domain names.
> >
> > That sounds like an argument for putting user keys in the DNS.
>
> Not sure how that follows?

See below. I was facetiously pointing out that two adjacent sentences
seemed to contradict each other. I don't think "domain name" rules out
"user identifier represented as a domain name". For example several ISPs
create a domain per user, and some sites shard their mail services with
per-user service host names.

> > Sorry for being argumentative but you need to be clear about where and why
> > you are drawing a line :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 7 TO
SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH BECOMING VERY
ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR.

Date: Thu, 19 Aug 2010 19:43:02 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Sender: Tony Finch <[email-masked]>
Subject: [keyassure] signalling use of crypto as well as service keys

Phillip Hallam-Baker <hallam at gmail.com>
>
> At the moment the biggest holes in smime and ssl are
>
> * there is no way to know if the web site uses ssl
> * there is no way to know if the recipient can accept smime
> * there is no way to find an smime recipient cert that is widely supported
>
> All of these stem from the fact that x.509 certs are not properly
> integrated into dns. And those are the areas where I see big potential
> for creating a unique value for dnssec.

Yes.

This is a particular problem for SMTP. There is no certificate
verification in inter-domain SMTP+TLS, so the crypto doesn't provide much
benefit.

The cause of the problem was that it was never specified what the TLS
certificate identifies in SMTP: hostname? mail domain? and at the time
there was no way to signal to a mail server what certificate the client
expected. As a result mail server certificates are never validated so most
of them present certificates that cannot be validated since any old cert
will work.

The only way to fix this is to clearly specify how authentication must
work, and add some kind of signal so the server can indicate that it
supports this spec and so clients should be able to authenticate it.

One of the key differences between the web and SMTP is the extra
indirection in MX records. SRV records have the same property. This is a
great boon for virtual hosting - it's so normal for a mail server to host
multiple mail domains that it isn't even called virtual hosting. It's also
normal for a mail domain's DNS, primary, and backup MXs to be hosted by
three or more different organizations.

If the DNS associates keys directly with a mail domain [1] then there's a
coupling problem between the DNS host and the application host: an app key
rollover will require updating hundreds of domains which may be hosted by
many third parties. If the DNS associates keys with host names (i.e. the
targets of MX records) then we have to think very carefully about the
security properties of that indirection, since normally we want to
directly secure the identity that the user sees.

Perhaps the policy RR should be associated with the mail domain, but the
app key RR should be associated with the host name. This also deals with
the problem of backup MX keys.

[1] I'm being concrete for simplicity but you can replace "mail domain"
with your favourite application identity.

Nicholas Weaver has also been talking about the next layer of indirection,
associating keys with IP addresses. I'm doubtful that this would be useful
since it is even further from securing the identity that the user sees,
and it does not have obvious vhosting benefits.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: NORTHEASTERLY 6 TO GALE 8. ROUGH OR VERY ROUGH. RAIN. GOOD,
OCCASIONALLY POOR.

Content-class: urn:content-classes:message
Date: Thu, 19 Aug 2010 11:42:10 -0700
From: "Doreswamy, Rangan" <[email-masked]>
To: "Jeffrey A. Williams" <[email-masked]>, "Phillip Hallam-Baker" <[email-masked]>, "Andrew Sullivan" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

If the reference is to the Code signing certificates that appear to be stolen VeriSign Code Signing certificates I would like to highlight that no VeriSign infrastructure was compromised or any key material was stolen from VeriSign's systems. We became aware of both these attacks when they were reported in the press, and both of the certificates involved are revoked. Each certificate holder was fully cooperative and understanding about the need to revoke the certificates in question. We're looking at potential methods of predicting certificates that may be compromised and therefore used in subsequent attacks and then encouraging preemptive replacement by the holders of those certificates. Microsoft has issued an advisory on the Windows flaw and states it's working on a fix. 

Thanks,
RD
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey A. Williams
Sent: Wednesday, August 18, 2010 2:25 PM
To: Phillip Hallam-Baker; Andrew Sullivan
Cc: [email-masked]; [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

Phillip and all,

  FWIW, I am not sure I would trust a cert signed
by Verisign right now given that recently their 
Cert database was hacked/breached and I have no
independant assurance that Verisign has 'fixed'
that breach adaquately and/or informed 'All' of its
Cert customers accordingly.  None the less, Verisign
produces good Certs, so the question than becomes 
is the user of that Cert now the correct one and
how does anyone know that for sure?

-----Original Message-----
>From: Phillip Hallam-Baker <[email-masked]>
>Sent: Aug 18, 2010 2:55 PM
>To: Andrew Sullivan <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications
>
>On Wed, Aug 18, 2010 at 12:39 PM, Andrew Sullivan <[email-masked]> wrote:
>>>
>>> 1 - DNSSEC can tell me who owns some DNS data, like an assertion about
>>> a hostname. �I don't think I know any more than that. �That's pretty
>>> important, but
>>>
>>> 2 - X.509 certificates could tell me a lot more about what I can expect
>>> from the transaction I am starting. �It can deliver a level of assurance
>>> attribute, a policy pointer of some kind that can lead to a complete
>>> disclosure of what this certificate means, and other attributes that
>>> describe what this certificate is supposed to permit or deny. �I don't
>>> think this is available in DNSSEC. �We can argue about the utility of
>>> some of this but that's not the issue.
>>>
>>> Another way of looking at it - this should be up the stack & closer to
>>> the application's viewpoint than DNS is (should be). �So perhaps
>>
>> It seems to me that this distinction is one on which we foundered
>> during the BOF, too.
>>
>> There are two completely different use cases for TLS, and we will get
>> nowhere if we assert that solutions for one are inadequate solutions
>> for the other.
>>
>> The goal in the current keys-linkage draft, as I read it, is simply to
>> gain some assurance that the PKIX cert in question is actually
>> associated with the domain it claims to be. �That is by no means any
>> kind of assurance that (say) the domain is actually operated by the
>> organization one thinks it is (i.e. it doesn't prove that
>> www.mybank.com is actually operated by My Bank, member FDIC).
>
>With DNSSEC alone we have a domain linkage, but no accountability for it.
>
>With DV we have a measure of accountability in that CAs that really
>screw up could in theory be dumped out of the browsers and we have
>defined and audited processes.
>
>With EV we have an industry standard assurance level and audited process.
>
>Now we could have a pointless discussion about whether DV is really
>more secure than DNSSEC, but I think thats pointless as I don't think
>anyone is willing to state that either is a sufficient basis for
>handing over your credit card number or doing banking. And so neither
>should merit a padlock icon.
>
>
>> The first of those is not too far from your (1) (but I think your
>> description doesn't quite capture the power of being able to guarantee
>> you got the right result from the DNS). �The second of these is
>> plainly related to your (2).
>>
>> The fact is that many people think (2) is a waste of time for many
>> purposes: many of the actual CAs simply don't do anything like the job
>> necessary to believe their assertions about identity and so on
>> embodied in the cert. �Therefore, the "utility of some of this" is not
>> the issue directly, but it certainly is a motivating factor in the
>> discussion. �I don't think we can dismiss it. �If the facilities that
>> are supposed to be offered by a technology don't work in practice,
>> then the lack of utility is relevant to rhe duscussion. �(This is not
>> to say the facilities are never useful. �But as general
>> infrastructure, they haven't worked out so well in terms of actually
>> identifying complete strangers to one anhother.)
>
>One big problem here, one that I did insist we deal with in EV was to
>actually show who is providing the certificate to the end user. A
>green bar from a VeriSign or a Comodo may not mean the same to the end
>user as a green bar from Bogocert CA they never heard of before.
>
>The importance of this distinction was just demonstrated in the UAE
>case. Perhaps people are not going to want to trust CAs in certain
>parts of the world for certain purposes. I would not accept code
>signed with a cert from a Nigerian, Sudanese or Russian CA.
>
>
>
>-- 
>Website: http://hallambaker.com/
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

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

From: "Richard L. Barnes" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 14:16:46 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Alternative Charter Proposal

I disagree with the objective and problem statement here; the  
objective is too vague, and the problem statement seems completely  
unrelated.  I actually started out writing the email not intending to  
write a new charter, but here's another proposal:

Objective:

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

Problem Statement:

Many Internet applications require protocol entities to authenticate  
that they represent a certain domain name.  For instance, in HTTPS, a  
server responding to a query for <https://www.example.com> is expected  
to authenticate as "www.example.com".  Security protocols such as TLS  
and IPsec accomplish this authentication by allowing an endpoint to  
prove ownership of a private key whose corresponding public key is  
somehow bound to the name being authenticated.  As a pre-requisite for  
authentication, then, these protocols require a mechanism for bindings  
to be asserted between public keys and domain names.

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

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

DNSSEC provides a mechanism for a domain operator to sign DNS  
information directly, using keys that are bound to the domain by the  
parent domain; relying parties can continue this chain up to any trust  
anchor that they accept.  In this way, bindings of keys to domains are  
asserted not by external entities, but by the entities that operate  
the DNS.  In addition to providing a more authoritative way of binding  
DNS names to keys, this technique inherently limits the scope of any  
given entity to the names in zones he controls.

This working group will develop mechanisms for domain operators to  
present bindings between names within their control and public keys,  
in such a way that these bindings can be integrity-protected (and thus  
shown to be authentically from the domain operator) using DNSSEC and  
used as a basis for authentication in protocols that use domain names  
as identifiers.  The group may also specify updates or clarifications  
to protocols to describe how protocol entities discover and validate  
these bindings in the execution of a specific application.

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

On Aug 19, 2010, at 1:12 PM, Phillip Hallam-Baker wrote:

> In response to Paul's request, I propose the following as a better
> statement of what the group is trying to do and to not do.
>
>
> Objective:
>
> Specify mechanisms that allow Internet applications to establish
> cryptographically enhanced communications through use of information
> distributed through the DNS.
>
> Problem Statement:
>
> Today the Internet is insecure by default and security is the
> exception. If the security of the Internet is to be improved, security
> must become the default. In particular modern computers have the
> ability to employ cryptographic security enhancements with minimal or
> negligible impact on performance, yet only a tiny proportion of
> Internet traffic is encrypted or authenticated.
>
> One of the key weaknesses of the current Internet Public Key
> Infrastructure (PKI) is that the most widely used Internet PKI is
> based on the X.500 Directory scheme intended to support an entirely
> different networking infrastructure.
>
> The naming infrastructure of the Internet is the DNS, not X.500. While
> the PKIX specifications provide a means of mapping X.509v3 attributes
> to DNS names there is currently no widely accepted, generalized means
> of achieving the mapping from DNS names to X.509 certificates in
> particular or to cryptographic keying material in general. DKIM and
> SSH have demonstrated the utility of this approach in specific
> domains, these specifications
>
> Recent progress in deployment of DNSSEC has renewed focus on the use
> of the DNS naming system to support cryptographic operations. In
> particular:
>
>  * Discovery of keying material by DNS name
>  * Discovery of security criteria by DNS names
>  * Verification of keying material through DNSSEC trust chains
>
> Scope:
>
>  * Use of existing security protocols with DNS established keys
>  * Use of DNS to verify existing certificate / keysigning / security
> assertion material formats
>  * Means of verifying key/certificate chains using DNSSEC exclusively
>  * Means of verifying key/certificate chains using DNSSEC in
> combination with other existing means
>
> Out-Of-Scope:
>
> * Reason for choice of specific trust paths
> * New formats for keying material (other than raw keys)
> * New trust architectures (unless they can be expressed in existing  
> formats
>
>
> What I am proposing here is that instead of committing up front to a
> view of DNSSEC as being intrinsically opposed to existing PKI schemes
> in that charter, we look for way that we can use DNSSEC and existing
> infrastructures together.
>
> The biggest mistake made in the PKI world was when the PGP and PEM
> people decided that they could not possibly work together and so they
> developed to schemes for email security that have competed for
> mindshare ever since. Jon Callas and I tried to work out ways of
> overcoming the consequences of that choice on many occasions without
> much success. The result has been that neither PGP nor SMIME is widely
> used.
>
>
> -- 
> Website: http://hallambaker.com/
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: "Richard L. Barnes" <[email-masked]>
To: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 14:07:06 -0400
Cc: [email-masked]
Subject: Re: [keyassure] user keys

>> This seems like a bad path to be headed down.  There are lots of  
>> identifiers
>> that can be tied to public keys: email addresses, SIP URIs,  
>> telephone numbers,
>> childhood nicknames.  It would be a mistake to try to smash them  
>> all into the
>> DNS.
>
> In many cases user keys have a username@domain structure so it would  
> make
> sense for user keys to be signed by a domain key which can in turn be
> validated using the DNS.

Although many user identifiers have that form superficially, there are  
more worms here than you expect.  If you're going to be precise and  
thorough, you'll need to address the full syntax of the URI scheme  
you're considering, which is significantly more complex.  And this is  
not mentioning things like internationalization...

Even if you went to the trouble of defining a mapping, it would just  
be an specific way of constructing the names you would use to find  
keys for a given type of identifier.  Nothing would be different about  
how the information is encoded in the DNS.

>> Authenticating identifiers from other protocols should be the job  
>> of those
>> protocols.
>
> That sounds like an argument for leaving TLS as it currently is.

Like Paul said, the DNS is about domain names.  A zone is  
authoritative for the names it contains.  If you start talking about  
things like email addresses, you have a whole different way that  
identifiers are assigned, and the trust model should map along with  
that.

>> It seems like it would be a big enough win for this group to come
>> up with a better way of binding keys to domain names.
>
> That sounds like an argument for putting user keys in the DNS.

Not sure how that follows?

--Richard

>
> Sorry for being argumentative but you need to be clear about where  
> and why
> you are drawing a line :-)
>
> Tony.
> -- 
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
> HEBRIDES: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 6 TO  
> GALE 8
> LATER. ROUGH. SHOWERS, RAIN LATER. MODERATE OR GOOD.

Date: Thu, 19 Aug 2010 19:02:50 +0100
From: Tony Finch <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] multi-application certificate RRs

On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote:

> I would hope that if we get people to start using DNS for their keying
> material that there would also be more widespread use of SRV.
> Wouldn't it make sense to use the exact same approach for the protocol
> specific keying information?

RFC 5507 argues against SRV-style name prefixes because they interact
badly with wildcards. On the other hand it is rather complacent about RR
type exhaustion.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD.

Date: Thu, 19 Aug 2010 18:55:04 +0100
From: Tony Finch <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] key per host

On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote:
> On Aug 19, 2010, at 1:39 PM, Tony Finch <[email-masked]> wrote:
> >
> > Who buys multiple certificates when they only need one?
>
> People who read their terms of service?

:-)

IME, though one might need to buy a licence to use a certificate on
multiple hosts, this does not mean one needs multiple certificates
associated with multiple private keys.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHEAST, VEERING SOUTH 5 TO 7, OCCASIONALLY GALE 8. MODERATE OR
ROUGH. RAIN THEN SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Thu, 19 Aug 2010 18:51:47 +0100
From: Tony Finch <[email-masked]>
To: Nicholas Weaver <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] key per host

On Thu, 19 Aug 2010, Nicholas Weaver wrote:
>
> However, service should be identified by both hostname AND IP address
> depending on the server's preference, thus any scheme that says
>
> _keymaterial_.host.mydomain.com as a query should also include a query for
>
> _keymaterial_.{A/AAAA record for host.mydomain.com}, IFF the reference
> for _keymaterial_.host.mydomain.com says that IP should be referred OR
> the service was contacted based on IP rather than hostname.

Could you explain why you think this is necessary? TLS doesn't currently
bind names and addresses in this way, and doing so makes services less
mobile than they could be.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HEBRIDES: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 6 TO GALE 8
LATER. ROUGH. SHOWERS, RAIN LATER. MODERATE OR GOOD.

From: Phillip Hallam-Baker <[email-masked]>
To: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 13:51:43 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] key per host

People who read their terms of service?

Sent from my iPad

On Aug 19, 2010, at 1:39 PM, Tony Finch <[email-masked]> wrote:

> On Thu, 19 Aug 2010, Richard L. Barnes wrote:
>> 
>> Not true.  In TLS connection establishment, the server only presents one
>> key/cert, but different servers for the same domain can present different
>> keys/certs.
> 
> Who buys multiple certificates when they only need one?
> 
> Tony.
> -- 
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
> CROMARTY FORTH TYNE: SOUTH OR SOUTHEAST, 4 OR 5, OCCASIONALLY 6, VEERING
> SOUTHWEST 5 TO 7 LATER. SLIGHT OR MODERATE. SHOWERS, THEN RAIN. MODERATE OR
> GOOD.

Date: Thu, 19 Aug 2010 18:39:17 +0100
From: Tony Finch <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: Phillip Hallam-Baker <[email-masked]>, [email-masked]
Subject: Re: [keyassure] key per host

On Thu, 19 Aug 2010, Richard L. Barnes wrote:
>
> Not true.  In TLS connection establishment, the server only presents one
> key/cert, but different servers for the same domain can present different
> keys/certs.

Who buys multiple certificates when they only need one?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
CROMARTY FORTH TYNE: SOUTH OR SOUTHEAST, 4 OR 5, OCCASIONALLY 6, VEERING
SOUTHWEST 5 TO 7 LATER. SLIGHT OR MODERATE. SHOWERS, THEN RAIN. MODERATE OR
GOOD.

Date: Thu, 19 Aug 2010 10:35:38 -0700
To: "Richard L. Barnes" <[email-masked]>, Tony Finch <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] user keys

At 1:22 PM -0400 8/19/10, Richard L. Barnes wrote:
>This seems like a bad path to be headed down.  There are lots of identifiers that can be tied to public keys: email addresses, SIP URIs, telephone numbers, childhood nicknames.  It would be a mistake to try to smash them all into the DNS.

+1. The DNS is good for giving information that is related to domain names, not all the users of the things at the domain names.

--Paul Hoffman, Director
--VPN Consortium

Date: Thu, 19 Aug 2010 18:34:31 +0100
From: Tony Finch <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] user keys

On Thu, 19 Aug 2010, Richard L. Barnes wrote:

> This seems like a bad path to be headed down.  There are lots of identifiers
> that can be tied to public keys: email addresses, SIP URIs, telephone numbers,
> childhood nicknames.  It would be a mistake to try to smash them all into the
> DNS.

In many cases user keys have a username@domain structure so it would make
sense for user keys to be signed by a domain key which can in turn be
validated using the DNS.

> Authenticating identifiers from other protocols should be the job of those
> protocols.

That sounds like an argument for leaving TLS as it currently is.

> It seems like it would be a big enough win for this group to come
> up with a better way of binding keys to domain names.

That sounds like an argument for putting user keys in the DNS.

Sorry for being argumentative but you need to be clear about where and why
you are drawing a line :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HEBRIDES: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 6 TO GALE 8
LATER. ROUGH. SHOWERS, RAIN LATER. MODERATE OR GOOD.

From: "Richard L. Barnes" <[email-masked]>
To: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 13:30:45 -0400
Cc: [email-masked], Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] key per host

>> As long as we can have multiple keys per service, that is fine.
>
> I can see that support for multiple key signatures might be  
> necessary to
> deal with key rollover. Are there other reasons?

Some names provide multiple A records for different hosts.  If these  
hosts have different private keys, they'll need to publish different  
public keys.

>> What I was objecting to was the idea of a single key for the Web
>> Service for www.example.com. That is not going to work.
>
> That's how TLS currently works.

Not true.  In TLS connection establishment, the server only presents  
one key/cert, but different servers for the same domain can present  
different keys/certs.

>> At a high level, what I would like to see here is a mechanism that
>> allows an application to generate a key pair and request registration
>> in the DNS as part of the install package.
>
> Dynamic DNS updates ought to be part of the solution, though I don't  
> know
> how to make it easier to manage the trust relationship (i.e. the  
> nsupdate
> keys) between the DNS admin and the app admins.

I would say that this sort of provisioning information should be out  
of the scope of the working group.  Standard DNS provisioning  
techniques apply.

From: "Richard L. Barnes" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 13:28:19 -0400
Cc: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: [keyassure] user keys

> oops, just saw a can of worms here. If we are not careful with our
> validation scheme, we will end up in a situation where people can use
> the S/MIME cert they were issued (e.g. [email-masked]) to set up a
> Web Server (https://bigbank.com/)
>
> That would be bad. The DNS key validation mechanism is going to have
> to specify the protocol it is validated for.

That would certainly be bad, but it doesn't necessarily follow that  
you need to specify a protocol.   "[email-masked]" and "bigbank.com"  
are different identifiers, so if you simply make sure that keys are  
properly bound to identifiers, then you don't need to say anything  
about protocols.

--Richard

>
> On Thu, Aug 19, 2010 at 1:08 PM, Tony Finch <[email-masked]> wrote:
>> Paul Wouters <[email-masked]> wrote:
>>> On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote:
>>>>
>>>> In my view user keys do not belong in the DNS because the DNS is an
>>>> infrastructure for locating network services, not network users.
>>>
>>> I disagree. You are locating an identity. Currently, that is  
>>> mostly done
>>> based on an IP address and port. I'd hope tomorrow that would  
>>> mostly be
>>> done based on a public key or hash. Especially with mobile  
>>> devices, IP's
>>> are very volatile. To locate a service or user, we need the DNS.
>>
>> Yes. At the moment the PKIs for identifying people are rather  
>> cumbersome.
>> It would be nice to be able to use DNSSEC for verifying S/MIME or PGP
>> messages.
>>
>> Tony.
>> --
>> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
>> SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE  
>> OR GOOD.
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>>
>
>
>
> -- 
> Website: http://hallambaker.com/
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Thu, 19 Aug 2010 18:26:57 +0100
From: Tony Finch <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] key per host

On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote:

> As long as we can have multiple keys per service, that is fine.

I can see that support for multiple key signatures might be necessary to
deal with key rollover. Are there other reasons?

> What I was objecting to was the idea of a single key for the Web
> Service for www.example.com. That is not going to work.

That's how TLS currently works.

> At a high level, what I would like to see here is a mechanism that
> allows an application to generate a key pair and request registration
> in the DNS as part of the install package.

Dynamic DNS updates ought to be part of the solution, though I don't know
how to make it easier to manage the trust relationship (i.e. the nsupdate
keys) between the DNS admin and the app admins.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HEBRIDES: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 6 TO GALE 8
LATER. ROUGH. SHOWERS, RAIN LATER. MODERATE OR GOOD.

Date: Thu, 19 Aug 2010 13:25:37 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] user keys

I agree it would be nice to use DNSSEC in the validation path.

But the problem is that the DNS management is typically under control
of people responsible for managing machines and not people.

We have a spec for putting certs onto a Web server and pulling them via HTTP.

oops, just saw a can of worms here. If we are not careful with our
validation scheme, we will end up in a situation where people can use
the S/MIME cert they were issued (e.g. [email-masked]) to set up a
Web Server (https://bigbank.com/)

That would be bad. The DNS key validation mechanism is going to have
to specify the protocol it is validated for.

On Thu, Aug 19, 2010 at 1:08 PM, Tony Finch <[email-masked]> wrote:
> Paul Wouters <[email-masked]> wrote:
>>On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote:
>>>
>>> In my view user keys do not belong in the DNS because the DNS is an
>>> infrastructure for locating network services, not network users.
>>
>> I disagree. You are locating an identity. Currently, that is mostly done
>> based on an IP address and port. I'd hope tomorrow that would mostly be
>> done based on a public key or hash. Especially with mobile devices, IP's
>> are very volatile. To locate a service or user, we need the DNS.
>
> Yes. At the moment the PKIs for identifying people are rather cumbersome.
> It would be nice to be able to use DNSSEC for verifying S/MIME or PGP
> messages.
>
> Tony.
> --
> f.anthony.n.finch �<[email-masked]> �http://dotat.at/
> SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

From: "Richard L. Barnes" <[email-masked]>
To: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 13:22:16 -0400
Cc: [email-masked]
Subject: Re: [keyassure] user keys

This seems like a bad path to be headed down.  There are lots of  
identifiers that can be tied to public keys: email addresses, SIP  
URIs, telephone numbers, childhood nicknames.  It would be a mistake  
to try to smash them all into the DNS.

Authenticating identifiers from other protocols should be the job of  
those protocols.  It seems like it would be a big enough win for this  
group to come up with a better way of binding keys to domain names.

--Richard

On Aug 19, 2010, at 1:08 PM, Tony Finch wrote:

> Paul Wouters <[email-masked]> wrote:
>> On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote:
>>>
>>> In my view user keys do not belong in the DNS because the DNS is an
>>> infrastructure for locating network services, not network users.
>>
>> I disagree. You are locating an identity. Currently, that is mostly  
>> done
>> based on an IP address and port. I'd hope tomorrow that would  
>> mostly be
>> done based on a public key or hash. Especially with mobile devices,  
>> IP's
>> are very volatile. To locate a service or user, we need the DNS.
>
> Yes. At the moment the PKIs for identifying people are rather  
> cumbersome.
> It would be nice to be able to use DNSSEC for verifying S/MIME or PGP
> messages.
>
> Tony.
> -- 
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
> SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR  
> GOOD.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Thu, 19 Aug 2010 13:18:57 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] key per host

As long as we can have multiple keys per service, that is fine.

What I was objecting to was the idea of a single key for the Web
Service for www.example.com. That is not going to work.

Nor does it need to as the cert is passed in band in SSL (as could be
any new keying material format). So the cert can tell the relying
party where to look for the instance specific key.

It also means that we can punt on issues like key rollover and such.

At a high level, what I would like to see here is a mechanism that
allows an application to generate a key pair and request registration
in the DNS as part of the install package.

On Thu, Aug 19, 2010 at 1:01 PM, Tony Finch <[email-masked]> wrote:
> Phillip Hallam-Baker <[email-masked]>
>>
>> We should be encouraging people to use a separate private key for each
>> physical host. So we certainly should not be creating specs that make it
>> hard to do that.
>
> I think the ship has already sailed on that one. A large proportion of
> deployments have some kind of load balancing router / proxy between the
> actual servers and the internet, so the mapping between public service
> addresses (whether names or numbers) and hosts is completely virtualized.
> Also a physical host will often support many virtual hosts, whether they
> are entire OS instances or just lightweight web server vhosts.
>
> Really the key should be per service, and we should not design protocols
> with any idea of a visible or externally meaningful map between services
> and hosts.
>
> Tony.
> --
> f.anthony.n.finch �<[email-masked]> �http://dotat.at/
> IRISH SEA: SOUTHEAST, VEERING SOUTH 5 TO 7, OCCASIONALLY GALE 8. MODERATE OR
> ROUGH. RAIN THEN SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

From: "Richard L. Barnes" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 13:18:50 -0400
Cc: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: [keyassure] multi-application certificate RRs

SRV is a good idea, but maybe not exactly what we want here.  In a  
related vein, we've been discussing in the XMPP WG how to authenticate  
delegations of services (so that an outsourced server can authenticate  
as itself instead of its customer), and this is approach I'm  
advocating now:

_xmpp-client._tcp.example.com SRV 1 1 1 apps.example.net
_xmpp-client._tcp.example.com CERT 1 1 1 http://example.com/xmpp.cer

(Should have the draft out later this week.) Note, however, that this  
is a slightly different use case from what we're discussing here.   
Namely, the goal of the XMPP stuff is to enable some sort of  
authentication on the SRV in the absence of DNSSEC.  It helps the RP  
figure out what *name* to expect, not what key.

If you're assuming DNSSEC and want to bind a key to a name, you don't  
need to attach the CRYPTO/CERT/whatever RR to the SRV.  Since the SRV  
is DNSSEC-signed, the target host just needs to authenticate as  
itself, so you would want the key to go with the target hostname (or  
its A/AAAA record).

--Richard

On Aug 19, 2010, at 12:50 PM, Phillip Hallam-Baker wrote:

> I would hope that if we get people to start using DNS for their keying
> material that there would also be more widespread use of SRV. In
> particular for Web Services applications since we are likely to end up
> with several hundred thousand of those in the not too different
> future.
>
> So if we are going to have
>
> _http._tcp.example.com SRV 1 1 1 www1.example.com
>
> Wouldn't it make sense to use the exact same approach for the protocol
> specific keying information?
>
> _http._tcp.example.com SRV 1 1 1 www1.example.com
> _http._tcp.example.com CRYPTO "blah .... blah"
>
>
> Note that in the case of SSL the client receives the server cert
> during the protocol negotiation. Thus the question is not 'what cert
> should I use', it is the same question as in DKIM 'is this key
> (certificate) valid'. And if we are using certs we can stick an
> extension in the cert to give the prefix at which to find it.
>
> In DKIM there are actually two separate records. There are key records
> that state that a key is valid for the domain and there are policy
> records that state that a message from a domain should have a
> signature.
>
> If we are going to provide decent application security we need the
> same scheme here. So the protocol specific record is going to be the
> policy record and the key record is going to be another record:
>
> _http._tcp.example.com SRV 1 1 1 www1.example.com
> _http._tcp.example.com OPTIONS "ALWAY USE SLL FOR THIS"
> _2wefih223h2.example.com CERTHASH "digest=SHA1:wehwefkjhwkjfh"
>
>
> Question: should we copy from DKIM as Stephen suggests or try to
> create a fixed binary format label?
>
> My experience doing DKIM is that we are not going to enumerate all the
> possible requirements for the policy record first time and we probably
> won't get the certhash record right first time either.
>
> My preference is to follow the DKIM precedent but use new RRs (not
> TXT) as we are assuming people are doing DNSSEC here.
>
> On Thu, Aug 19, 2010 at 12:35 PM, Tony Finch <[email-masked]> wrote:
>> Paul Wouters <[email-masked]> wrote:
>>>
>>> 2) Try to make a new DNS record that can be used by more then just  
>>> one
>>>    application (eg not SSHFP) to avoid spamming the apex.
>>
>> Isn't this contrary to RFC 5507?
>>
>> Tony.
>> --
>> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
>> SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. SHOWERS AT  
>> FIRST. MODERATE
>> OR GOOD.
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>>
>
>
>
> -- 
> Website: http://hallambaker.com/
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Thu, 19 Aug 2010 13:12:49 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Subject: [keyassure] Alternative Charter Proposal

In response to Paul's request, I propose the following as a better
statement of what the group is trying to do and to not do.

Objective:

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

Problem Statement:

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

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

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

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

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

Scope:

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

Out-Of-Scope:

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

What I am proposing here is that instead of committing up front to a
view of DNSSEC as being intrinsically opposed to existing PKI schemes
in that charter, we look for way that we can use DNSSEC and existing
infrastructures together.

The biggest mistake made in the PKI world was when the PGP and PEM
people decided that they could not possibly work together and so they
developed to schemes for email security that have competed for
mindshare ever since. Jon Callas and I tried to work out ways of
overcoming the consequences of that choice on many occasions without
much success. The result has been that neither PGP nor SMIME is widely
used.

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

Date: Thu, 19 Aug 2010 18:08:58 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Sender: Tony Finch <[email-masked]>
Subject: [keyassure] user keys

Paul Wouters <[email-masked]> wrote:
>On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote:
>>
>> In my view user keys do not belong in the DNS because the DNS is an
>> infrastructure for locating network services, not network users.
>
> I disagree. You are locating an identity. Currently, that is mostly done
> based on an IP address and port. I'd hope tomorrow that would mostly be
> done based on a public key or hash. Especially with mobile devices, IP's
> are very volatile. To locate a service or user, we need the DNS.

Yes. At the moment the PKIs for identifying people are rather cumbersome.
It would be nice to be able to use DNSSEC for verifying S/MIME or PGP
messages.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD.

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Thu, 19 Aug 2010 10:05:38 -0700
To: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] key per host

On Aug 19, 2010, at 10:01 AM, Tony Finch wrote:

> Phillip Hallam-Baker <[email-masked]>
>> 
>> We should be encouraging people to use a separate private key for each
>> physical host. So we certainly should not be creating specs that make it
>> hard to do that.
> 
> I think the ship has already sailed on that one. A large proportion of
> deployments have some kind of load balancing router / proxy between the
> actual servers and the internet, so the mapping between public service
> addresses (whether names or numbers) and hosts is completely virtualized.
> Also a physical host will often support many virtual hosts, whether they
> are entire OS instances or just lightweight web server vhosts.
> 
> Really the key should be per service, and we should not design protocols
> with any idea of a visible or externally meaningful map between services
> and hosts.

However, service should be identified by both hostname AND IP address depending on the server's preference, thus any scheme that says

_keymaterial_.host.mydomain.com as a query should also include a query for

_keymaterial_.{A/AAAA record for host.mydomain.com}, IFF the reference for _keymaterial_.host.mydomain.com says that IP should be referred OR the service was contacted based on IP rather than hostname.

Date: Thu, 19 Aug 2010 18:01:37 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Sender: Tony Finch <[email-masked]>
Subject: [keyassure] key per host

Phillip Hallam-Baker <[email-masked]>
>
> We should be encouraging people to use a separate private key for each
> physical host. So we certainly should not be creating specs that make it
> hard to do that.

I think the ship has already sailed on that one. A large proportion of
deployments have some kind of load balancing router / proxy between the
actual servers and the internet, so the mapping between public service
addresses (whether names or numbers) and hosts is completely virtualized.
Also a physical host will often support many virtual hosts, whether they
are entire OS instances or just lightweight web server vhosts.

Really the key should be per service, and we should not design protocols
with any idea of a visible or externally meaningful map between services
and hosts.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHEAST, VEERING SOUTH 5 TO 7, OCCASIONALLY GALE 8. MODERATE OR
ROUGH. RAIN THEN SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Thu, 19 Aug 2010 12:50:50 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] multi-application certificate RRs

I would hope that if we get people to start using DNS for their keying
material that there would also be more widespread use of SRV. In
particular for Web Services applications since we are likely to end up
with several hundred thousand of those in the not too different
future.

So if we are going to have

_http._tcp.example.com SRV 1 1 1 www1.example.com

Wouldn't it make sense to use the exact same approach for the protocol
specific keying information?

_http._tcp.example.com SRV 1 1 1 www1.example.com
_http._tcp.example.com CRYPTO "blah .... blah"

Note that in the case of SSL the client receives the server cert
during the protocol negotiation. Thus the question is not 'what cert
should I use', it is the same question as in DKIM 'is this key
(certificate) valid'. And if we are using certs we can stick an
extension in the cert to give the prefix at which to find it.

In DKIM there are actually two separate records. There are key records
that state that a key is valid for the domain and there are policy
records that state that a message from a domain should have a
signature.

If we are going to provide decent application security we need the
same scheme here. So the protocol specific record is going to be the
policy record and the key record is going to be another record:

_http._tcp.example.com SRV 1 1 1 www1.example.com
_http._tcp.example.com OPTIONS "ALWAY USE SLL FOR THIS"
_2wefih223h2.example.com CERTHASH "digest=SHA1:wehwefkjhwkjfh"

Question: should we copy from DKIM as Stephen suggests or try to
create a fixed binary format label?

My experience doing DKIM is that we are not going to enumerate all the
possible requirements for the policy record first time and we probably
won't get the certhash record right first time either.

My preference is to follow the DKIM precedent but use new RRs (not
TXT) as we are assuming people are doing DNSSEC here.

On Thu, Aug 19, 2010 at 12:35 PM, Tony Finch <[email-masked]> wrote:
> Paul Wouters <[email-masked]> wrote:
>>
>> 2) Try to make a new DNS record that can be used by more then just one
>> � �application (eg not SSHFP) to avoid spamming the apex.
>
> Isn't this contrary to RFC 5507?
>
> Tony.
> --
> f.anthony.n.finch �<[email-masked]> �http://dotat.at/
> SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. SHOWERS AT FIRST. MODERATE
> OR GOOD.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Thu, 19 Aug 2010 12:40:18 -0400
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

David said basically what I was going to say on your other points, but  
I wanted to also note the following:

On Aug 19, 2010, at 9:01 AM, Phillip Hallam-Baker wrote:
> The point you are still not getting here is that the security of the  
> system is measured from the point of view of the relying party. The  
> relying party does not choose either the CA or the Registrar, but an  
> attacker can.

Let's describe the assurances that the relying party has in each case:

Standard CA DV cert:
One of thousands of entities with cert-issuing authority said that the  
holder of the corresponding private key controls the zone for the  
domain in question.  There may be other people out there who also have  
certificates that assert that they control the domain, but neither you  
nor this issuing CA necessarily know if they exist.  Every root CA has  
equivalent authority as far as you're concerned, and an attacker can  
choose the lowest common denominator CA and serve you those certs at  
will.

DNSSEC domain-key assertion:
The person who controls the zone for the domain in question holds the  
corresponding private key.  The only opportunity for mischief or  
mistake is in the one single path that the zone controller chose:  
their nameserver (especially if they are doing online signing), the  
registrar, the registry, and the root (and if there are DS records for  
sub-domains, whoever controls those).  What's more, any substitution  
of a baddie's DS record for the true domain owner's DS record would be  
highly visible and likely to be immediately corrected.

DNSSEC domain-key assertion plus EV:
Not only is there a high level of assurance that you are talking to  
the person who controls the zone, a third-party has verified who that  
person is.  You can have a substantial degree of trust in that third- 
party because they have been approved according to the more stringent  
EV requirements.

DNSSEC domain-key assertions are backed up by the technical  
architecture.  CA assertions are backed up by standards groups,  
reputation, and perhaps even legal liability.

The caveat for both systems are that technical vulnerabilities can and  
do happen, but I think that's well beyond this group's mandate to  
discuss.

Date: Thu, 19 Aug 2010 17:35:55 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Sender: Tony Finch <[email-masked]>
Subject: [keyassure] multi-application certificate RRs

Paul Wouters <[email-masked]> wrote:
>
> 2) Try to make a new DNS record that can be used by more then just one
>    application (eg not SSHFP) to avoid spamming the apex.

Isn't this contrary to RFC 5507?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. SHOWERS AT FIRST. MODERATE
OR GOOD.

From: David Conrad <[email-masked]>
Date: Thu, 19 Aug 2010 08:31:05 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On Aug 19, 2010, at 6:01 AM, Phillip Hallam-Baker wrote:
> The registrar does the work but the registrar does not even have a key. It's the registry that has the key. 

The registrar does essentially nothing.  I remain a bit confused as to why you keep harping on the registrar here.  The registrar accepts public information from the registrant and asks the registry to place that information into the registry's zone. If the registrar accidentally or intentionally asks for the wrong information to be placed into the zone, the registrant will notice as soon as the registry publishes the zone. 

Exactly what threat do you see the registrar facilitating?

> The simple solution for this is to allow for certs in the dnssec trust path to validate KSKs. This would supplement the TLD signature if available. This allows the liability issues to be managed, moots the limitations of a single root of trust and allows for certain practical efficiency optimizations.

Pointer to your draft?

> We can then use dnssec for anything from opportunistic encryption all the way up to million dollar commercial transactions. 

We can do this today.

Regards,
-drc

Date: Thu, 19 Aug 2010 08:14:34 -0700
To: Phillip Hallam-Baker <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [keyassure] Charter discussion: please send alternate text

If you feel that the proposed charter text is using the wrong model, please send specific proposals to the list so that others can consider them. Slowly expanding on your model description over the course of many messages doesn't seem to be working at gaining consensus.

--Paul Hoffman, Director
--VPN Consortium

From: Phillip Hallam-Baker <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Thu, 19 Aug 2010 10:59:47 -0400
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: [keyassure] DKIM Format

I took another look at DKIM. We do have a few differences. One of the most important being that we are pretty much assuming DNSSEC capable clients and infrastructures. So we are looking at at least one new RR and I think we need three if we are going to do a complete job.

The big question at this point in my view is whether the format is DKIM style unrestricted text field with a registry of tags or a DNS style byte code field approach with fixed fields.

I don't much care about the bit packing issue but I definitely want extensibility.

This is not a massively difficult problem but we may make it one if we have a fixed format record as NXT was. I don't want to have to create a new RR for each iteration of the design. I want an extensible record format.

Whether people agree with me or not on the need for my approach, I hope we can agree that pki has proved to be deceptively complex in the past. I can't see that we lose anything from an extensible format. Coming to consensus on a fixed format is going to be impossible.

My experience in this field suggests that it is going to be highly desirable to have a lot of experimentation with different approaches and converge on the ones that work. What works for mail may not work for web may not work for web services.

Sent from my iPad

On Aug 18, 2010, at 8:13 PM, Stephen Farrell <[email-masked]> wrote:

> 
> Quick question: did you consider DKIM key records for this?
> (With a new "s=" value in the TXT RR.)
> 
> If so, why don't they rate a mention? If not, maybe worth a
> look?
> 
> S.
> 
> On 18/08/10 15:45, Paul Hoffman wrote:
>> Greetings again. A gang of us created a draft that pulls together some of the many ideas that have been floating around. There are multiple options for some features, so we chose one option in each category and started an appendix to document the choices.
>> 
>> <http://www.ietf.org/id/draft-hoffman-keys-linkage-from-dns-00.txt>
>> 
>> Discussion is welcome. Please don't assume that any of the options are set in stone, although note that changing some options might also require changing other options at the same time. In particular, I think my idea of listing ports is going to go away, given that few sites run services on different ports but keep the same domain name.
>> 
>> --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

Date: Thu, 19 Aug 2010 07:59:28 -0700
To: Stephen Farrell <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Key linkage draft, -00 edition

>Quick question: did you consider DKIM key records for this?
>(With a new "s=" value in the TXT RR.)
>
>If so, why don't they rate a mention? If not, maybe worth a
>look?

First off, the idea of TXT RRs without _label prefixes has been mostly deprecated in the IETF. Second, the idea of saying "this isn't DKIM, it's this new thing" by changing "s=" is begging for trouble. There are enough tricky semantics in the DKIM spec (not as many as in PKIX, but it sometimes feels that way) that reusing it would likely prevent us from having the freedom we want.

--Paul Hoffman, Director
--VPN Consortium

Date: Thu, 19 Aug 2010 09:07:54 -0400
From: "Perry E. Metzger" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On Thu, 19 Aug 2010 01:10:39 -0400 Phillip Hallam-Baker
<[email-masked]> wrote:
> We have a proposed charter that asserts that the benefit of dnssec
> lies in having a single root of trust because that means fewer

Leave people alone to get their work done. You're not going to
convince them, you're just going to annoy them, and the mere existence
of a standard doesn't imply that anything will actually be deployed
(or do you use RSVP every day? or how about CLNP?)

> Don't forget that in the originally proposed and deployed ssl model
> that there was a single root of trust.

I don't think that was ever the case. Netscape invented it, and the
first browsers they shipped with SSL had multiple roots.

Anyway, if you don't like the work, stay away. Leave the people who
want to try it alone.

Perry
-- 
Perry E. Metzger		[email-masked]

From: Phillip Hallam-Baker <[email-masked]>
To: Steve Schultze <[email-masked]>
Date: Thu, 19 Aug 2010 09:01:39 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

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

The reason I think we can do better is that we can block downgrade attack. Validating domain names is not the issue because I bank with a company, not a domain name.

At the moment the biggest holes in smime and ssl are

* there is no way to know if the web site uses ssl
* there is no way to know if the recipient can accept smime
* there is no way to find an smime recipient cert that is widely supported

All of these stem from the fact that x.509 certs are not properly integrated into dns. And those are the areas where I see big potential for creating a unique value for dnssec.

There are several million ssl cert owners already using crypto. They are the potential early adopter market. 

The point you are still not getting here is that the security of the system is measured from the point of view of the relying party. The relying party does not choose either the CA or the Registrar, but an attacker can. 

At present I can't even know who the validator in a dnssec chain is. The registrar does the work but the registrar does not even have a key. It's the registry that has the key. Dnssec architecture predates the registrar / registry split in .com.

The simple solution for this is to allow for certs in the dnssec trust path to validate KSKs. This would supplement the TLD signature if available. This allows the liability issues to be managed, moots the limitations of a single root of trust and allows for certain practical efficiency optimizations. We can then use dnssec for anything from opportunistic encryption all the way up to million dollar commercial transactions. 

Sent from my iPad

On Aug 19, 2010, at 2:05 AM, Steve Schultze <[email-masked]> wrote:

> 
> On Aug 19, 2010, at 1:33 AM, Phillip Hallam-Baker wrote:
>> But my security is affected by the place that mybank.com registers myemployer.com registers and so on.
> 
> mybank.com will gravitate toward more trustworthy registrars (because exclusivity promises actual increased security), rather than the cheapest option (which is what the current DV CA model encourages).
> 
>> If the ui does not tell the relying party who signed then the security of the system for the relying party is the security of the least diligent signer.
> 
> That is not true.  The security of the system for the relying party is the security of the signer that the domain owner chooses, and in a market in which the cost differential is negligible (the likely market) this will optimize for security of both parties (domain owner and relying party).
> 
>> As far as the registrar issue is concerned, There is a lot of complexity there. What the customer thinks is a registrar may be a reseller using an outsourced dns publisher. So that is three parties not one. 
> 
> Agreed, but the exclusive and public nature of DNS registration makes this much less significant.
> 
>> First possible line of attack is a Twitter style password reset request.
> 
> I'm not sure I understand what the attack vector is here in the DNS model.  In any event, it's far better security than thousands of trusted (and often undisclosed) CAs/SubCAs/RAs.
> 
>> Second is to claim a zone transfer.
> 
> If bankofamerica.com isn't worried about this today on a basic name-to-IP level, I think we have solved it to a significant degree.
> 
>> Then there are typo attacks 
> 
> Agreed.  Totally unsolvable on the DNSSEC layer and a great example of where CAs are still of critical importance in the domain-to-legal-entity chain.
> 
>> All entirely justifiable if all you are trying to do is to provide almost as good security as dv ssl certs.
> 
> No, _better_ than DV SSL certs (when it comes to domain-to-key mapping).
> 
>> But what I am saying is that there is no reason not to have the option of almost as good and very much better.
> 
> ]
> The "very much better" part is essential, but it relies on the ability of DNSSEC to ensure a superior domainname-to-owner mapping.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

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

<html><body bgcolor="#FFFFFF"><div>The reason I think we can do better is that we can block downgrade attack. Validating domain names is not the issue because I bank with a company, not a domain name.</div><div><br></div><div>At the moment the biggest holes in smime and ssl are</div><div><br></div><div>* there is no way to know if the web site uses ssl</div><div>* there is no way to know if the recipient can accept smime</div><div>* there is no way to find an smime recipient cert that is widely supported</div><div><br></div><div><br></div><div>All of these stem from the fact that x.509 certs are not properly integrated into dns. And those are the areas where I see big potential for creating a unique value for dnssec.</div><div><br></div><div>There are several million ssl cert owners already using crypto. They are the potential early adopter market.&nbsp;</div><div><br></div><div><br></div><div>The point you are still not getting here is that the security of the system is measured from the point of view of the relying party. The relying party does not choose either the CA or the Registrar, but an attacker can.&nbsp;</div><div><br></div><div>At present I can't even know who the validator in a dnssec chain is. The registrar does the work but the registrar does not even have a key. It's the registry that has the key. Dnssec architecture predates the registrar / registry split in .com.</div><div><br></div><div>The simple solution for this is to allow for certs in the dnssec trust path to validate KSKs. This would supplement the TLD signature if available. This allows the liability issues to be managed, moots the limitations of a single root of trust and allows for certain practical efficiency optimizations. We can then use dnssec for anything from opportunistic encryption all the way up to million dollar commercial transactions.&nbsp;</div><div><br></div><div><br>Sent from my iPad</div><div><br>On Aug 19, 2010, at 2:05 AM, Steve Schultze &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br><br></div><div></div><blockquote type="cite"><div><br><div><div>On Aug 19, 2010, at 1:33 AM, Phillip Hallam-Baker wrote:</div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; 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; ">But my security is affected by the place that<span class="Apple-converted-space">&nbsp;</span><a href="http://mybank.com/"><a href="http://mybank.com">mybank.com</a></a><span class="Apple-converted-space">&nbsp;</span>registers<span class="Apple-converted-space">&nbsp;</span><a href="http://myemployer.com/"><a href="http://myemployer.com">myemployer.com</a></a><span class="Apple-converted-space">&nbsp;</span>registers and so on.<br></span></blockquote><div><br></div><div><a href="http://mybank.com"><a href="http://mybank.com">mybank.com</a></a> will gravitate toward more trustworthy registrars (because exclusivity promises actual increased security), rather than the cheapest option (which is what the current DV CA model encourages).</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; 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; ">If the ui does not tell the relying party who signed then the security of the system for the relying party is the security of the least diligent signer.<br></span></blockquote><div><br></div><div>That is not true. &nbsp;The security of the system for the relying party is the security of the signer that the domain owner chooses, and in a market in which the cost differential is negligible (the likely market) this will optimize for security of both parties (domain owner and relying party).</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; 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; ">As far as the registrar issue is concerned, There is a lot of complexity there. What the customer thinks is a registrar may be a reseller using an outsourced dns publisher. So that is three parties not one.<span class="Apple-converted-space">&nbsp;</span><br></span></blockquote><div><br></div><div>Agreed, but the exclusive and public nature of DNS registration makes this much less significant.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; 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; ">First possible line of attack is a Twitter style password reset request.<br></span></blockquote><div><br></div><div>I'm not sure I understand what the attack vector is here in the DNS model. &nbsp;In any event, it's far better security than thousands of trusted (and often undisclosed) CAs/SubCAs/RAs.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; 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; ">Second is to claim a zone transfer.<br></span></blockquote><div><br></div><div>If <a href="http://bankofamerica.com"><a href="http://bankofamerica.com">bankofamerica.com</a></a> isn't worried about this today on a basic name-to-IP level, I think we have solved it to a significant degree.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; 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; ">Then there are typo attacks<span class="Apple-converted-space">&nbsp;</span><br></span></blockquote><div><br></div><div>Agreed. &nbsp;Totally unsolvable on the DNSSEC layer and a great example of where CAs are still of critical importance in the domain-to-legal-entity chain.</div><div><br></div><blockquote type="cite">All entirely justifiable if all you are trying to do is to provide almost as good security as dv ssl certs.</blockquote><div><br></div><div>No, _better_ than DV SSL certs (when it comes to domain-to-key mapping).</div><br><blockquote type="cite"> But what I am saying is that there is no reason not to have the option of almost as good and very much better.</blockquote></div><div>]</div><div>The "very much better" part is essential, but it relies on the ability of DNSSEC to ensure a superior domainname-to-owner mapping.</div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>keyassure mailing list</span><br><span><a href="mailto:[email-masked]">[email-masked]</a></span><br><span><a href="https://www.ietf.org/mailman/listinfo/keyassure">https://www.ietf.org/mailman/listinfo/keyassure</a></span><br></div></blockquote></body></html>
--Apple-Mail-3--1026977615--

From: Phillip Hallam-Baker <[email-masked]>
To: =?utf-8?Q?Ondřej_Surý?= <[email-masked]>
Date: Thu, 19 Aug 2010 08:31:52 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

Take out all the wording in the current charter entirely.

You don't have to say anything about trust models. Not unless you want to debate the merits of ICANN. You certainly don't have to make claims that the ICANN root is better than existing ssl schemes. 

Instead I would simply state that the purpose of the list is to discuss how to use information in the dns to enable applications to obtain keys.

I would then follow up with statements of high level objectives. One of these being enabling ubiquitous encryption which in turn requires that there be no additional out of pocket cost per server.

I would then add in preventing downgrade attack as a possible objective.

Dubious claims of fact have no place in a charter. DKIM demonstrates that it is quite possible to make useful use of keys in the dns without dnssec at all. It is also quite possible to make use of keys when only the local zone is signed without the upper zone signing the KSK. 

You have to be realistic when designing a security protocol. The only reason that a security protocol is necessary in the first place is that people do wrong things and bad things. If you want to propose a security scheme based on trusting one party to never do the wrong thing and then declare that one party off limits for examination, expect security people to be skeptical.

Just take out the unfounded claims about single trust roots and we don't need to discuss the fact that they are unfounded assumptions.

Sent from my iPad

On Aug 19, 2010, at 3:17 AM, Ondřej Surý <[email-masked]> wrote:

> On 18.8.2010 17:17, Phillip Hallam-Baker wrote:
>> I disagree with the statement in the proposed charter
> 
> Then propose alternative wording.  Or what to add or what to remove.
> 
>> We have a pki infrastructure that has certain capabilities and certain
>> limitations.  We have the expectation of a dnssec infrastructure with
>> other capabilities and limitations.
> 
> And there are some capabilities and limitations which are same and there are some capabilities which are superior in DNSSEC and some which are superior in PKIX.  So what are you trying to say?
> 
> DNSSEC will not be able to provide identity check.  But it keeps the security trust as close to infrastructure as possible.  You have to trust your DNS and keep it secure.
> 
> It was already discussed and my feeling is that the general consensus is that DV-certs are as at the same or lower level than "DNSSEC-certs".  I propose to not discuss this again, since this is not the purpose of the mailing list.  The purpose is to create solution to be able to establish secure TLS connection out of DNS data.
> 
>> I am not too interested in just re-doing the features already
>> supported in existing pki at lower out of pocket expense
> 
> And there are many people who are interested also in that.
> 
>> I want to make EV certs work well with Dnssec as an option. If 100% of
>> Internet traffic is encrypted, people may start to see the value of
>> the service that CAs really provide.
> 
> We had this in mind when we wrote:
> 
> "The DNSSEC root trust anchor can also be used for additional validation during the current path validations. By validating that the  certificate presented is the certificate identified by the DNS, we can provide additional confidence that the client is connecting to the intended server - this helps alleviate concerns that a valid certificate has been obtained by an attacker (for example from a CA not used by the victim)."
> 
>> I don't agree with the idea that a single root of trust is desirable
>> or provides any advantage whatsoever. It is one of the features we
>> need to fix. The Internet is a network of peers, not serfs. The Icann
>> scheme has it's uses but it does not have to be the only scheme people
>> are allowed to use.
> 
> There is no single root of trust in the dnssec model.  There are as much trust roots as you configure to validate.  DNSSEC signed root just makes things more easy to implement.
> 
>> As a practical matter we can't escape from x.509 entirely. Ssl is set
>> up to use certs. We will do much better to put certs or cert hashes in
>> the dns than raw keys. If we use raw keys we then have to do much More
>> drastic revision to ssl libraries. We have to recode both the client
>> and the server rather than just the client. I hate asn1 as much as
>> anyone, but it's no real pain to wrap a key as a self signed cert.
>> 
>> 
>> We should look to make the best system we can, not simply replicate
>> what already exists for cheap.
> 
> This is much in contrary with what you said in previous paragraph.  The best system could require as to change not even our thinking, but also the ssl libraries, clients and servers.  Let's not close this option.
> 
> Ondrej
> -- 
> Ondřej Surý
> vedoucí výzkumu/Head of R&D department
> -------------------------------------------
> CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
> Americka 23, 120 00 Praha 2, Czech Republic
> mailto:[email-masked]    http://nic.cz/
> tel:+420.222745110       fax:+420.222745112
> -------------------------------------------
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Thu, 19 Aug 2010 09:17:33 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On 18.8.2010 17:17, Phillip Hallam-Baker wrote:
> I disagree with the statement in the proposed charter

Then propose alternative wording.  Or what to add or what to remove.

> We have a pki infrastructure that has certain capabilities and certain
> limitations.  We have the expectation of a dnssec infrastructure with
> other capabilities and limitations.

And there are some capabilities and limitations which are same and there 
are some capabilities which are superior in DNSSEC and some which are 
superior in PKIX.  So what are you trying to say?

DNSSEC will not be able to provide identity check.  But it keeps the 
security trust as close to infrastructure as possible.  You have to 
trust your DNS and keep it secure.

It was already discussed and my feeling is that the general consensus is 
that DV-certs are as at the same or lower level than "DNSSEC-certs".  I 
propose to not discuss this again, since this is not the purpose of the 
mailing list.  The purpose is to create solution to be able to establish 
secure TLS connection out of DNS data.

> I am not too interested in just re-doing the features already
> supported in existing pki at lower out of pocket expense

And there are many people who are interested also in that.

> I want to make EV certs work well with Dnssec as an option. If 100% of
> Internet traffic is encrypted, people may start to see the value of
> the service that CAs really provide.

We had this in mind when we wrote:

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

> I don't agree with the idea that a single root of trust is desirable
> or provides any advantage whatsoever. It is one of the features we
> need to fix. The Internet is a network of peers, not serfs. The Icann
> scheme has it's uses but it does not have to be the only scheme people
> are allowed to use.

There is no single root of trust in the dnssec model.  There are as much 
trust roots as you configure to validate.  DNSSEC signed root just makes 
things more easy to implement.

> As a practical matter we can't escape from x.509 entirely. Ssl is set
> up to use certs. We will do much better to put certs or cert hashes in
> the dns than raw keys. If we use raw keys we then have to do much More
> drastic revision to ssl libraries. We have to recode both the client
> and the server rather than just the client. I hate asn1 as much as
> anyone, but it's no real pain to wrap a key as a self signed cert.
>
>
> We should look to make the best system we can, not simply replicate
> what already exists for cheap.

This is much in contrary with what you said in previous paragraph.  The 
best system could require as to change not even our thinking, but also 
the ssl libraries, clients and servers.  Let's not close this option.

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: Thu, 19 Aug 2010 09:05:08 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On 19.8.2010 05:38, David Conrad wrote:
> [Just joined this list and may not be staying long if this is
> typical subject matter]

David,

I would like you to stay.

>> They may be called a non profit but they certainly pay some
>> handsome salaries.
>
> So... keyassure is an yet another ICANN-bashing list?

No, it's not.  And I'll try to make sure it stays on topic as much I as 
will be able to do so.

> O joy, O rapture. What does the salary ICANN pays have to do with
> anything relevant to what I thought this list was going to be
> discussing?

Please all, keep on topic.  Stay out of attacking other people just 
because your opinion isn't heard.

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: Thu, 19 Aug 2010 09:02:08 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

[moderator hat on]
This is entirely outside the topic of this mailing list.  Either please 
explain how is this related to the proposed problem statement or take it 
elsewhere.  This is not a list to discuss ICANN policies.
[/moderator hat off]

On 19.8.2010 07:39, Phillip Hallam-Baker wrote:
> The charging issue is what the domain name owner is expected to pay
> to have dnssec once this monopoly provider infrastructure is
> deployed. ICANN extracts a rent on every domain name as does VeriSign
> in .com. Do we have any guarantee that this rent will not increase in
> either case?
>
> I would have thought that quite obvious but instead you pose
> hypotheticals about how much ICANN is going to charge VeriSign, as if
> that would be a concern for anyone.
>
> Sent from my iPad
>
> On Aug 18, 2010, at 11:51 PM, David Conrad<[email-masked]>
> wrote:
>
>> On Aug 18, 2010, at 7:51 PM, Steve Schultze wrote:
>>>> In the SSL cert case we do have an actual single root, the
>>>> WebTrust auditors.
>>> No, we have a single standard (well, two... one for EV and
>>> another for everything else) which leaves huge areas of ambiguity
>>> and latitude for browser/OS vendors to interpret compliance and
>>> tremendous holes when it comes to god-like delegation after
>>> approval.
>>
>> And, of course, WebTrust auditors could never be bribed...
>>
>>> Are they charging anything for signing TLD DS records?
>>
>> Likely a rhetorical question, but just in case:  no, ICANN does not
>> charge for accepting DS records (or anything else) from TLDs.
>> VeriSign similarly does not charge for accepting authorized root
>> zone change requests from ICANN, generating, signing, and
>> transmitting the root zone to the root server operators.  And, of
>> course, the root server operators do not charge for serving the
>> root zone on their servers.
>>
>> Regards, -drc
>>
>> _______________________________________________ keyassure mailing
>> list [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
> _______________________________________________ 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
  -------------------------------------------

Date: Thu, 19 Aug 2010 09:00:00 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On 19.8.2010 04:26, Phillip Hallam-Baker wrote:
> I want to use dnssec without the ICANN root.

You are free to do so.  The way how you configure your DNSSEC validating 
resolver is entirely up to you.

And please note that I would like to discuss things like which RR type 
to use and how to secure the last mile.

The "How trustworthy is ICANN" discussion is outside the topic of this 
mailing list.  So please all keep that in mind.

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

From: Steve Schultze <[email-masked]>
Date: Thu, 19 Aug 2010 02:05:24 -0400
To: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

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

On Aug 19, 2010, at 1:33 AM, Phillip Hallam-Baker wrote:
> But my security is affected by the place that mybank.com registers myemployer.com registers and so on.

mybank.com will gravitate toward more trustworthy registrars (because exclusivity promises actual increased security), rather than the cheapest option (which is what the current DV CA model encourages).

> If the ui does not tell the relying party who signed then the security of the system for the relying party is the security of the least diligent signer.

That is not true.  The security of the system for the relying party is the security of the signer that the domain owner chooses, and in a market in which the cost differential is negligible (the likely market) this will optimize for security of both parties (domain owner and relying party).

> As far as the registrar issue is concerned, There is a lot of complexity there. What the customer thinks is a registrar may be a reseller using an outsourced dns publisher. So that is three parties not one. 

Agreed, but the exclusive and public nature of DNS registration makes this much less significant.

> First possible line of attack is a Twitter style password reset request.

I'm not sure I understand what the attack vector is here in the DNS model.  In any event, it's far better security than thousands of trusted (and often undisclosed) CAs/SubCAs/RAs.

> Second is to claim a zone transfer.

If bankofamerica.com isn't worried about this today on a basic name-to-IP level, I think we have solved it to a significant degree.

> Then there are typo attacks 

Agreed.  Totally unsolvable on the DNSSEC layer and a great example of where CAs are still of critical importance in the domain-to-legal-entity chain.

> All entirely justifiable if all you are trying to do is to provide almost as good security as dv ssl certs.

No, _better_ than DV SSL certs (when it comes to domain-to-key mapping).

> But what I am saying is that there is no reason not to have the option of almost as good and very much better.

]
The "very much better" part is essential, but it relies on the ability of DNSSEC to ensure a superior domainname-to-owner mapping.
--Apple-Mail-14--1051953627
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 19, 2010, at 1:33 AM, Phillip Hallam-Baker wrote:</div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; 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; ">But my security is affected by the place that<span class="Apple-converted-space">&nbsp;</span><a href="http://mybank.com/">mybank.com</a><span class="Apple-converted-space">&nbsp;</span>registers<span class="Apple-converted-space">&nbsp;</span><a href="http://myemployer.com/">myemployer.com</a><span class="Apple-converted-space">&nbsp;</span>registers and so on.<br></span></blockquote><div><br></div><div><a href="http://mybank.com">mybank.com</a> will gravitate toward more trustworthy registrars (because exclusivity promises actual increased security), rather than the cheapest option (which is what the current DV CA model encourages).</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; 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; ">If the ui does not tell the relying party who signed then the security of the system for the relying party is the security of the least diligent signer.<br></span></blockquote><div><br></div><div>That is not true. &nbsp;The security of the system for the relying party is the security of the signer that the domain owner chooses, and in a market in which the cost differential is negligible (the likely market) this will optimize for security of both parties (domain owner and relying party).</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; 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; ">As far as the registrar issue is concerned, There is a lot of complexity there. What the customer thinks is a registrar may be a reseller using an outsourced dns publisher. So that is three parties not one.<span class="Apple-converted-space">&nbsp;</span><br></span></blockquote><div><br></div><div>Agreed, but the exclusive and public nature of DNS registration makes this much less significant.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; 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; ">First possible line of attack is a Twitter style password reset request.<br></span></blockquote><div><br></div><div>I'm not sure I understand what the attack vector is here in the DNS model. &nbsp;In any event, it's far better security than thousands of trusted (and often undisclosed) CAs/SubCAs/RAs.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; 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; ">Second is to claim a zone transfer.<br></span></blockquote><div><br></div><div>If <a href="http://bankofamerica.com">bankofamerica.com</a> isn't worried about this today on a basic name-to-IP level, I think we have solved it to a significant degree.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; 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; ">Then there are typo attacks<span class="Apple-converted-space">&nbsp;</span><br></span></blockquote><div><br></div><div>Agreed. &nbsp;Totally unsolvable on the DNSSEC layer and a great example of where CAs are still of critical importance in the domain-to-legal-entity chain.</div><div><br></div><blockquote type="cite">All entirely justifiable if all you are trying to do is to provide almost as good security as dv ssl certs.</blockquote><div><br></div><div>No, _better_ than DV SSL certs (when it comes to domain-to-key mapping).</div><br><blockquote type="cite"> But what I am saying is that there is no reason not to have the option of almost as good and very much better.</blockquote></div><div>]</div><div>The "very much better" part is essential, but it relies on the ability of DNSSEC to ensure a superior domainname-to-owner mapping.</div></body></html>
--Apple-Mail-14--1051953627--

From: Phillip Hallam-Baker <[email-masked]>
To: David Conrad <[email-masked]>
Date: Thu, 19 Aug 2010 01:39:32 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

The charging issue is what the domain name owner is expected to pay to have dnssec once this monopoly provider infrastructure is deployed. ICANN extracts a rent on every domain name as does VeriSign in .com. Do we have any guarantee that this rent will not increase in either case? 

I would have thought that quite obvious but instead you pose hypotheticals about how much ICANN is going to charge VeriSign, as if that would be a concern for anyone.

Sent from my iPad

On Aug 18, 2010, at 11:51 PM, David Conrad <[email-masked]> wrote:

> On Aug 18, 2010, at 7:51 PM, Steve Schultze wrote:
>>> In the SSL cert case we do have an actual single root, the WebTrust auditors.
>> No, we have a single standard (well, two... one for EV and another for everything else) which leaves huge areas of ambiguity and latitude for browser/OS vendors to interpret compliance and tremendous holes when it comes to god-like delegation after approval.
> 
> And, of course, WebTrust auditors could never be bribed...
> 
>> Are they charging anything for signing TLD DS records?  
> 
> Likely a rhetorical question, but just in case:  no, ICANN does not charge for accepting DS records (or anything else) from TLDs.  VeriSign similarly does not charge for accepting authorized root zone change requests from ICANN, generating, signing, and transmitting the root zone to the root server operators.  And, of course, the root server operators do not charge for serving the root zone on their servers.
> 
> Regards,
> -drc
> 
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Phillip Hallam-Baker <[email-masked]>
To: Steve Schultze <[email-masked]>
Date: Thu, 19 Aug 2010 01:33:37 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

The point is that I get to choose where to register hallambaker.com
But my security is affected by the place that mybank.com registers myemployer.com registers and so on.

If the ui does not tell the relying party who signed then the security of the system for the relying party is the security of the least diligent signer.

People are asserting that the dnssec design as it stands addresses this problem when it does not. But that does not mean that we can't add in some pieces so that it does. 

As far as the registrar issue is concerned, There is a lot of complexity there. What the customer thinks is a registrar may be a reseller using an outsourced dns publisher. So that is three parties not one. 

First possible line of attack is a Twitter style password reset request.

Second is to claim a zone transfer.

Then there are typo attacks 

All entirely justifiable if all you are trying to do is to provide almost as good security as dv ssl certs. But what I am saying is that there is no reason not to have the option of almost as good and very much better.

There are holes we need to plug in pkix as well. 

Sent from my iPad

On Aug 19, 2010, at 12:53 AM, Steve Schultze <[email-masked]> wrote:

> On Aug 19, 2010, at 12:49 AM, Phillip Hallam-Baker wrote:
>> I can choose the most diligent registrar in the world. But that won't do anything to improve the quality of the information I have to rely on
> 
> I don't believe you are correct, but I would welcome your clarification if I misunderstand.
> 
> Once a domain is registered, even if BadGuy goes to EvilRegistrar, he can't obtain control of that zone.  What is your exploit that makes this possible?
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Phillip Hallam-Baker <[email-masked]>
To: "Perry E. Metzger" <[email-masked]>
Date: Thu, 19 Aug 2010 01:10:39 -0400
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

Perry 

It has taken fifteen years to get to this point. A large part of the reason for that delay was the refusal to consider real world constraints that did not fit the abstract technical model

It took eight years to fix the opt in issue. It took five years to fix the eu privacy directive issue. Both took too long because people didn't want to accept the possibility of a problem.

We have a proposed charter that asserts that the benefit of dnssec lies in having a single root of trust because that means fewer points of failure. I am pointing out that these claims are not actually true. If people don't want to argue the point then delete the unnecessary claims from the charter.

Don't forget that in the originally proposed and deployed ssl model that there was a single root of trust. It didn't stay that way for long. It was an unstable condition.

Sent from my iPad

On Aug 18, 2010, at 10:59 PM, "Perry E. Metzger" <[email-masked]> wrote:

> On Wed, 18 Aug 2010 22:21:32 -0400
> Phillip Hallam-Baker <[email-masked]> wrote:
>> Ok let's look at what the trust path is for DNSSEC
>> 
>> Take www.example.com
>> 
>> ICANN is accountable to whom?
>> 
>> VeriSign as the registry is maybe accountable to ICANN but not to the
>> example.com domain name owner
> 
> In the current CA model, every single CA disclaims all
> liability. There is thus no reduction in function there.
> 
> In any case, if you dislike the idea, you are not obligated to use
> it. I would leave the people who want to do such things alone to get
> their work done.
> 
> Perry

From: Steve Schultze <[email-masked]>
Date: Thu, 19 Aug 2010 00:53:17 -0400
To: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On Aug 19, 2010, at 12:49 AM, Phillip Hallam-Baker wrote:
> I can choose the most diligent registrar in the world. But that won't do anything to improve the quality of the information I have to rely on

I don't believe you are correct, but I would welcome your clarification if I misunderstand.

Once a domain is registered, even if BadGuy goes to EvilRegistrar, he can't obtain control of that zone.  What is your exploit that makes this possible?

From: Phillip Hallam-Baker <[email-masked]>
To: David Conrad <[email-masked]>
Date: Thu, 19 Aug 2010 00:49:29 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

You make a big mistake here when you talk about choosing a registrar wisely

You are looking at the problem from the point of view of someone putting keys in. The correct way to look at the issue if you want to make the comparison to ssl CAs is from the point of view of someone who is relying on the keys. And there they have no way to control who the registrar is. Unlike in ssl you don't even know who did the validation if at all.

I can choose the most diligent registrar in the world. But that won't do anything to improve the quality of the information I have to rely on

On Aug 18, 2010, at 11:38 PM, David Conrad <[email-masked]> wrote:

> [Just joined this list and may not be staying long if this is typical subject matter]
> 
> On Aug 18, 2010, at 7:21 PM, Phillip Hallam-Baker wrote:
>> ICANN is accountable to whom?
> 
> Depends on which part of ICANN you're looking at.  In the case of anything having to do with the IANA function (which managing the KSK is deemed), ICANN is accountable to the U.S. Dept. of Commerce, National Telecommunications and Information Administration, via the IANA functions contract (actually, the contract is with NOAA, but it is NTIA that cares.  Deeply).
> 
>> VeriSign as the registry is maybe accountable to ICANN but not to the example.com domain name owner
> 
> Accountability for what exactly?  VeriSign is contractually obligated to ICANN to be accountable for various things.
> 
>> Then we have the box which people are naively labeling "the" registrar
> 
> Yes.  Choose your registrar wisely.  Caveat emptor and all that.
> 
>> And we are not finished yet since the actual operations of many of those registrars is in turn outsourced to a dns hosting specialist. Which is good in some ways because there are fewer of those than there are registrars.
> 
> If you want to fully trust the contents of your domain, you sign it yourself. Period.
> 
>> All told we have several thousand parties who could potentially touch a DNS record. Names are transferred between these registrars on a continuous basis. 
> 
> So you, as the admin of example.com, give your DS to your registrar to have it inserted into the COM zone.  You chose your registrar poorly and they mangle your DS in a nefarious attempt to seize control of your zone (or something).  Your evil registrar updates the .COM zone and (eventually, when is a bit indeterminate at least currently), VeriSign publishes the updated zone.
> 
> And you don't notice that the DS that was supplied doesn't match what showed up in the .COM zone and stamp your foot petulantly (or something)?  How does that work again?
> 
>> I won't defend how some CAs issue certs. But what I won't accept is the idea that the ICANN scheme is intrinsically superior.
> 
> It is superior in the sense that you have a _much_ more limited set of players and the selection of players (that is, who can be a registry) is typically a bit more public.
> 
>> ICANN has enough difficulty ejecting registrars being run by organized crime.
> 
> I'd suggest not choosing a registrar run by organized crime.
> 
>> They are suddenly going to acquire the expertise to run a global PKI better than the existing scheme and do so for free?
> 
> ICANN maintains the KSK for the root of the DNS.  It has demonstrated the expertise to do this (at least IMNSHO).  The fact that some folks believe an alternate PKI can be established using DNSSEC with a trusted root signed by VeriSign (not ICANN) is somewhat unrelated to the fact that ICANN signs VeriSign's ZSKs with the KSK they maintain.
> 
> And yes, ICANN does maintain the KSK for the root of the DNS "for free".  That is, if you consider the fees imposed by ICANN on the registries and registrars to be completely inconsequential.
> 
>> Since when has ICANN done anything for free? They charge $50,000 to merely apply for a tld that they may well reject.
> 
> Actually, it is $185,000 last I looked.
> 
>> They may be called a non profit but they certainly pay some handsome salaries. 
> 
> So... keyassure is an yet another ICANN-bashing list?  O joy, O rapture. What does the salary ICANN pays have to do with anything relevant to what I thought this list was going to be discussing?
> 
> Regards,
> -drc
> 

From: David Conrad <[email-masked]>
Date: Wed, 18 Aug 2010 20:51:03 -0700
To: Steve Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On Aug 18, 2010, at 7:51 PM, Steve Schultze wrote:
>> In the SSL cert case we do have an actual single root, the WebTrust auditors.
> No, we have a single standard (well, two... one for EV and another for everything else) which leaves huge areas of ambiguity and latitude for browser/OS vendors to interpret compliance and tremendous holes when it comes to god-like delegation after approval.

And, of course, WebTrust auditors could never be bribed...

> Are they charging anything for signing TLD DS records?  

Likely a rhetorical question, but just in case:  no, ICANN does not charge for accepting DS records (or anything else) from TLDs.  VeriSign similarly does not charge for accepting authorized root zone change requests from ICANN, generating, signing, and transmitting the root zone to the root server operators.  And, of course, the root server operators do not charge for serving the root zone on their servers.

Regards,
-drc

From: David Conrad <[email-masked]>
Date: Wed, 18 Aug 2010 20:42:15 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On Aug 18, 2010, at 7:26 PM, Phillip Hallam-Baker wrote:
> I want to use dnssec without the ICANN root. 

Feel free.  There are (currently) only about 300 TLD trust anchors you'll have to keep track of if all the TLDs started signing. ICANN says they'll be adding no more than about 1000/year. You'll have to figure out a way of securely fetching the trust anchors from the TLD admins who sign their zones to install into your validating resolver, but that's a minor detail.

A single root of trust _can be_ better since there are less parties to vet and audit (1 versus many).  However, as I said, if you don't want to trust ICANN, VeriSign, and the US Government, you don't have to.

Regards,
-drc

From: David Conrad <[email-masked]>
Date: Wed, 18 Aug 2010 20:38:07 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

[Just joined this list and may not be staying long if this is typical subject matter]

On Aug 18, 2010, at 7:21 PM, Phillip Hallam-Baker wrote:
> ICANN is accountable to whom?

Depends on which part of ICANN you're looking at.  In the case of anything having to do with the IANA function (which managing the KSK is deemed), ICANN is accountable to the U.S. Dept. of Commerce, National Telecommunications and Information Administration, via the IANA functions contract (actually, the contract is with NOAA, but it is NTIA that cares.  Deeply).

> VeriSign as the registry is maybe accountable to ICANN but not to the example.com domain name owner

Accountability for what exactly?  VeriSign is contractually obligated to ICANN to be accountable for various things.

> Then we have the box which people are naively labeling "the" registrar

Yes.  Choose your registrar wisely.  Caveat emptor and all that.

> And we are not finished yet since the actual operations of many of those registrars is in turn outsourced to a dns hosting specialist. Which is good in some ways because there are fewer of those than there are registrars.

If you want to fully trust the contents of your domain, you sign it yourself. Period.

> All told we have several thousand parties who could potentially touch a DNS record. Names are transferred between these registrars on a continuous basis. 

So you, as the admin of example.com, give your DS to your registrar to have it inserted into the COM zone.  You chose your registrar poorly and they mangle your DS in a nefarious attempt to seize control of your zone (or something).  Your evil registrar updates the .COM zone and (eventually, when is a bit indeterminate at least currently), VeriSign publishes the updated zone.

And you don't notice that the DS that was supplied doesn't match what showed up in the .COM zone and stamp your foot petulantly (or something)?  How does that work again?

> I won't defend how some CAs issue certs. But what I won't accept is the idea that the ICANN scheme is intrinsically superior.

It is superior in the sense that you have a _much_ more limited set of players and the selection of players (that is, who can be a registry) is typically a bit more public.

> ICANN has enough difficulty ejecting registrars being run by organized crime.

I'd suggest not choosing a registrar run by organized crime.

> They are suddenly going to acquire the expertise to run a global PKI better than the existing scheme and do so for free?

ICANN maintains the KSK for the root of the DNS.  It has demonstrated the expertise to do this (at least IMNSHO).  The fact that some folks believe an alternate PKI can be established using DNSSEC with a trusted root signed by VeriSign (not ICANN) is somewhat unrelated to the fact that ICANN signs VeriSign's ZSKs with the KSK they maintain.

And yes, ICANN does maintain the KSK for the root of the DNS "for free".  That is, if you consider the fees imposed by ICANN on the registries and registrars to be completely inconsequential.

> Since when has ICANN done anything for free? They charge $50,000 to merely apply for a tld that they may well reject.

Actually, it is $185,000 last I looked.

>  They may be called a non profit but they certainly pay some handsome salaries. 

So... keyassure is an yet another ICANN-bashing list?  O joy, O rapture. What does the salary ICANN pays have to do with anything relevant to what I thought this list was going to be discussing?

Regards,
-drc

Date: Wed, 18 Aug 2010 22:59:22 -0400
From: "Perry E. Metzger" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On Wed, 18 Aug 2010 22:21:32 -0400
Phillip Hallam-Baker <[email-masked]> wrote:
> Ok let's look at what the trust path is for DNSSEC
> 
> Take www.example.com
> 
> ICANN is accountable to whom?
> 
> VeriSign as the registry is maybe accountable to ICANN but not to the
> example.com domain name owner

In the current CA model, every single CA disclaims all
liability. There is thus no reduction in function there.

In any case, if you dislike the idea, you are not obligated to use
it. I would leave the people who want to do such things alone to get
their work done.

Perry

From: Steve Schultze <[email-masked]>
Date: Wed, 18 Aug 2010 22:51:46 -0400
To: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

> On Aug 18, 2010, at 4:32 PM, Paul Hoffman <[email-masked]> wrote:
> 
>> At 3:55 PM -0400 8/18/10, Phillip Hallam-Baker wrote:
>>> With DNSSEC alone we have a domain linkage, but no accountability for it.
>> 
>> This is completely incorrect. The accountability is to "the same person who gave you the A record that you are about to use to go to the site".

On Aug 18, 2010, at 10:21 PM, Phillip Hallam-Baker wrote:
> First off there are a few hundred ICANN registered registrars. [etc...]

The architecture is exclusive, and in the case where there are possible nefarious means for gaining control of someone else's zone such shenanigans are highly detectable (they are inherently public) and dispute processes are well-established and have been relied upon by everyone using the web for a long time.

> Definitely less than is required to operate a CA where there is a WEbTrust audit requirement.

As a nitpick, WebTrust is not a requirement for CA approval (ETSI and ANSI standards are also accepted by the major vendors).  The standards for who can conduct audits are somewhat arbitrary (why CPAs?) and aged (the non-EV standards were designed to be provisional and never updated).

But the more important reasons why the DNS approach provides advantages are the reasons I gave above (exclusivity and publicity).

That is not to say of course that WebTrust-audited CAs don't have a critical role going forward... especially when it comes to EV and the like.  Their role is complimentary.  However, the domain linkage function of DNSSEC-validated assertions is as good as (well, better than) today's DV certs.

> I won't defend how some CAs issue certs. But what I won't accept is the idea that the ICANN scheme is intrinsically superior. It has more moving parts, more potential points of failure and huge areas of ambiguity.

With respect to domain validation, it has fewer points of failure.  The points of failure are each node down the hierarchy (and only one path down is allowed).  The points of failure in CA DV certs are 300+ CAs plus thousands of Subordinate CAs (often undisclosed) plus thousands more RAs (also undisclosed).

> In the SSL cert case we do have an actual single root, the WebTrust auditors.

No, we have a single standard (well, two... one for EV and another for everything else) which leaves huge areas of ambiguity and latitude for browser/OS vendors to interpret compliance and tremendous holes when it comes to god-like delegation after approval.

> ICANN has enough difficulty ejecting registrars being run by organized crime. They are suddenly going to acquire the expertise to run a global PKI better than the existing scheme and do so for free?

Exclusivity allows site operators to choose the most trustworthy registrar... hopefully initiating a race to the top instead of today's CA DV race to the bottom.

> Since when has ICANN done anything for free? They charge $50,000 to merely apply for a tld that they may well reject. They may be called a non profit but they certainly pay some handsome salaries. 

Are they charging anything for signing TLD DS records?  That's the only relevant question in this context.

From: Phillip Hallam-Baker <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Date: Wed, 18 Aug 2010 22:26:06 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

People are constantly asserting something that is not true.

If you want to make statements asserting how the single root of trust is better. Then expect to hear the opposite point of view.

We have a proposed charter making tendentious statements on this topic, so they are certainly in scope. You can't expect to take swipes at people and then cry uncle when they defend themselves.

I want to use dnssec without the ICANN root. 

Sent from my iPad

On Aug 18, 2010, at 4:43 PM, Andrew Sullivan <[email-masked]> wrote:

> On Wed, Aug 18, 2010 at 04:18:25PM -0400, Paul Wouters wrote:
>> But really, the discussion of whether I can trust a TLD operator more then
>> a CA operator is outside the scope of this list. I believe what is desired
>> here is a way to use the TLD operator without a CA operator. We already have
>> the reverse case for those interested in that.
> 
> Hear, hear.  We don't need to debate whether one approach is better
> than the other.  We're not writing signature-style-choices-bcp.  The
> point is to write something that works interoperably provided that you
> accept the premise that what you want to use is DNSSEC.
> 
> A
> 
> -- 
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Date: Wed, 18 Aug 2010 22:21:32 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

Ok let's look at what the trust path is for DNSSEC

Take www.example.com

ICANN is accountable to whom?

VeriSign as the registry is maybe accountable to ICANN but not to the example.com domain name owner

Then we have the box which people are naively labeling "the" registrar

First off there are a few hundred ICANN registered registrars. Some of which are outright criminal. And beyond that you have an even greater number of resellers that the key holder thinks is their registrar but is simply a reseller

And we are not finished yet since the actual operations of many of those registrars is in turn outsourced to a dns hosting specialist. Which is good in some ways because there are fewer of those than there are registrars.

All told we have several thousand parties who could potentially touch a DNS record. Names are transferred between these registrars on a continuous basis. 

Forget accountability, I don't think anyone could claim to have a comprehensive enumeration. Certainly the authentication required to get ICANN credentials is not very great, arguably not even as serious as the requirement to get an EV certain. Definitely less than is required to operate a CA where there is a WEbTrust audit requirement.

I won't defend how some CAs issue certs. But what I won't accept is the idea that the ICANN scheme is intrinsically superior. It has more moving parts, more potential points of failure and huge areas of ambiguity. In the SSL cert case we do have an actual single root, the WebTrust auditors. Can anyone give a reason for why the ICANN system won't fail in precisely the same way?

ICANN has enough difficulty ejecting registrars being run by organized crime. They are suddenly going to acquire the expertise to run a global PKI better than the existing scheme and do so for free?

Since when has ICANN done anything for free? They charge $50,000 to merely apply for a tld that they may well reject. They may be called a non profit but they certainly pay some handsome salaries. 

Sent from my iPad

On Aug 18, 2010, at 4:32 PM, Paul Hoffman <[email-masked]> wrote:

> At 3:55 PM -0400 8/18/10, Phillip Hallam-Baker wrote:
>> With DNSSEC alone we have a domain linkage, but no accountability for it.
> 
> This is completely incorrect. The accountability is to "the same person who gave you the A record that you are about to use to go to the site".
> 
> --Paul Hoffman, Director
> --VPN Consortium

Date: Thu, 19 Aug 2010 01:13:12 +0100
From: Stephen Farrell <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Key linkage draft, -00 edition

Quick question: did you consider DKIM key records for this?
(With a new "s=" value in the TXT RR.)

If so, why don't they rate a mention? If not, maybe worth a
look?

S.

On 18/08/10 15:45, Paul Hoffman wrote:
> Greetings again. A gang of us created a draft that pulls together some of the many ideas that have been floating around. There are multiple options for some features, so we chose one option in each category and started an appendix to document the choices.
> 
> <http://www.ietf.org/id/draft-hoffman-keys-linkage-from-dns-00.txt>
> 
> Discussion is welcome. Please don't assume that any of the options are set in stone, although note that changing some options might also require changing other options at the same time. In particular, I think my idea of listing ports is going to go away, given that few sites run services on different ports but keep the same domain name.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
> 

Date: Wed, 18 Aug 2010 16:42:28 -0700
To: Paul Wouters <[email-masked]>, Peter Saint-Andre <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

At 6:46 PM -0400 8/18/10, Paul Wouters wrote:
>On Wed, 18 Aug 2010, Peter Saint-Andre wrote:
>
>>>Perhaps some clarification could be made. Perhaps some container formats of
>>>PKIX might be used, but not the trust model of external CA's? (If you would
>>>do that, this would just become a repeat of RFC 4398)
>>
>>Ah, what I meant is that just because you use DNSSEC to get information
>>out of DNS doesn't mean you can't use PKIX certificates during TLS
>>negotiation with an application service.
>
>Oh sure. you could do BTNS channel binding too an upgrade some TLS connection
>to a more trusted state based on external authentication. But that is all
>outside the scope of what to put in a new type of DNS RR record. And we
>should not limit a new RR type to REQUIRE external authentication.

If you want to do something that requires a protocol change to TLS at the same time (instead of just a processing policy change), sure. Such a requirement is not the only choice, however. Our draft leaves the PKIX cert in TLS as-is, but adds an external binding of the key to the domain name by the same organization that is telling you other information about the domain name, such as the IP address.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 18 Aug 2010 18:46:28 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On Wed, 18 Aug 2010, Peter Saint-Andre wrote:

>> Perhaps some clarification could be made. Perhaps some container formats of
>> PKIX might be used, but not the trust model of external CA's? (If you would
>> do that, this would just become a repeat of RFC 4398)
>
> Ah, what I meant is that just because you use DNSSEC to get information
> out of DNS doesn't mean you can't use PKIX certificates during TLS
> negotiation with an application service.

Oh sure. you could do BTNS channel binding too an upgrade some TLS connection
to a more trusted state based on external authentication. But that is all
outside the scope of what to put in a new type of DNS RR record. And we
should not limit a new RR type to REQUIRE external authentication.

Paul

Date: Wed, 18 Aug 2010 16:32:29 -0600
From: Peter Saint-Andre <[email-masked]>
To: Paul Wouters <[email-masked]>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On 8/18/10 4:00 PM, Paul Wouters wrote:
> On Wed, 18 Aug 2010, Peter Saint-Andre wrote:
> 
>>> Hear, hear.  We don't need to debate whether one approach is better
>>> than the other.  We're not writing signature-style-choices-bcp.  The
>>> point is to write something that works interoperably provided that you
>>> accept the premise that what you want to use is DNSSEC.
>>
>> Which might mean using both DNSSEC and PKIX -- the choice is not
>> either-or.
> 
> I think previous attempts explicitely included PKIX, and the efforts
> died because of it.
> 
> I was not at the IETF in Maastricht, so I did not attend the BOF, but I
> don't
> think commiting to a CA/X.509 will be very useful. the PKIX people will
> (again)
> say "we already have CA's for that".
> 
> Perhaps some clarification could be made. Perhaps some container formats of
> PKIX might be used, but not the trust model of external CA's? (If you would
> do that, this would just become a repeat of RFC 4398)

Ah, what I meant is that just because you use DNSSEC to get information
out of DNS doesn't mean you can't use PKIX certificates during TLS
negotiation with an application service.

Peter

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

Date: Wed, 18 Aug 2010 18:00:39 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On Wed, 18 Aug 2010, Peter Saint-Andre wrote:

>> Hear, hear.  We don't need to debate whether one approach is better
>> than the other.  We're not writing signature-style-choices-bcp.  The
>> point is to write something that works interoperably provided that you
>> accept the premise that what you want to use is DNSSEC.
>
> Which might mean using both DNSSEC and PKIX -- the choice is not either-or.

I think previous attempts explicitely included PKIX, and the efforts
died because of it.

I was not at the IETF in Maastricht, so I did not attend the BOF, but I don't
think commiting to a CA/X.509 will be very useful. the PKIX people will (again)
say "we already have CA's for that".

Perhaps some clarification could be made. Perhaps some container formats of
PKIX might be used, but not the trust model of external CA's? (If you would
do that, this would just become a repeat of RFC 4398)

Paul

Date: Wed, 18 Aug 2010 15:39:06 -0600
From: Peter Saint-Andre <[email-masked]>
To: [email-masked]
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On 8/18/10 2:43 PM, Andrew Sullivan wrote:
> On Wed, Aug 18, 2010 at 04:18:25PM -0400, Paul Wouters wrote:
>> But really, the discussion of whether I can trust a TLD operator more then
>> a CA operator is outside the scope of this list. I believe what is desired
>> here is a way to use the TLD operator without a CA operator. We already have
>> the reverse case for those interested in that.
> 
> Hear, hear.  We don't need to debate whether one approach is better
> than the other.  We're not writing signature-style-choices-bcp.  The
> point is to write something that works interoperably provided that you
> accept the premise that what you want to use is DNSSEC.

Which might mean using both DNSSEC and PKIX -- the choice is not either-or.

Peter

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

Date: Wed, 18 Aug 2010 16:35:53 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Thanks for starting this - my wishlist :)
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Phillip and all,

-----Original Message-----
>From: Phillip Hallam-Baker <[email-masked]>
>Sent: Aug 18, 2010 2:08 PM
>To: [email-masked]
>Subject: Re: [keyassure] Thanks for starting this - my wishlist :)
>
>I agree with what Andrew is saying here. But this is a discussion that
>is in-charter for DNSEXT.
>
>Basically I am seeing people looking at DNSCURVE for last hop and
>there are certainly many people doing IPSEC. As a security specialist,
>I know that there are security capabilities I can provide in that
>model that are not possible through endpoint security alone.
>
>My view is that where the validation takes place is for applications
>and users to decide. It may even make sense to have no validation at
>all. I have argued for years that Web Browsers should not provide a
>warning when a site offers a self-signed cert, the browser should
>simply turn on the crypto and not tell the user about it at all. If
>the web browser will take the user to a site without any crypto
>without a warning it should accept imperfect crypto on the same basis.

In part I agree here.  However not telling the user of the use of a
cert, self-signed or not is not a good thing.  Indeed though there
is not such thing as 'perfict' crypto so accepting any of same is
or should be a user choice.
>
>In the medium term, neither IPSEC or DNSCURVE (or SSL) are ideal for
>this purpose. We can do better, but I won't elaborate the reasons why
>here.

Agreed strongly here as well...
>
>
>On Wed, Aug 18, 2010 at 2:06 PM, Andrew Sullivan <[email-masked]> wrote:
>> On Wed, Aug 18, 2010 at 10:34:08AM -0700, Nicholas Weaver wrote:
>>
>>> NOTHING I said implied that the application does the validating,
>>
>> Well, there were two ways I found to interpret your argument, and the
>> other one seemed to me to be the well-worn arguments about why
>> offloading to an upstream validator was a Bad Idea.  I didn't figure
>> you'd be hauling that argument to this list from another one, but I
>> guess I was wrong.  In the enterprise situation, we _have_ an
>> implementer who is using the AD bit and IPSEC for the last hop.  You
>> keep insisting that's a dangerous model, but in the enterprise
>> environment it isn't necessarily (and arguing from home-user-to-ISP
>> analogies is simply irrelevant).
>>
>> The trouble in the case of the AD bit is that it's too little
>> information.  But we don't get to dismiss that use case just because
>> we're currently not sure how to answer the query.  And we might have
>> an opportunity here to address such issues (I kinda doubt it, but
>> maybe).
>>
>>> to do the validating: the application NEEDS to tell the host to
>>> validate and how to treat validation failures (because the default
>>> will be wrong, no matter what the default is, unless the default is
>>
>> I think this is right.  It sounds to me like an API issue.  The
>> present one is likely the wrong list for that, though.  I wish I knew
>> what to suggest apart from dnssec-deployment.
>>
>>> And that using such an API for validating A records is useless,
>>> since any application thats smart enough to bother asking "is this A
>>> record validated" is smart enough to realize that the A record
>>> validation is meaningless [1]: a corrupted A record is just simply
>>> one of many possible MitM attacks, so focus on blocking MitM
>>> attacks, not A records: from an application viewpoint, there is no
>>> difference between a poisoned DNS entry, a poisoned ARP cache, BGP
>>> games, or a WiFi packet injector: a MitM is a MitM.
>>
>> So your argument is that if the DNSSEC validation comes back correct,
>> we still aren't sure routing hasn't been compromised, so this is all
>> useless?  Surely that's wrong.  Another way to do this would be to
>> offload the validation to a trusted DNS server and offload similar
>> validation for BGP &c. to something else, no?  I don't really want my
>> phone doing hundreds of DNSSEC validation calculations for every
>> cnn.com page view, do I?
>>
>>> And, frankly speaking, the "benefits" from DNSSEC only come when the
>>> application is aware of DNSSEC
>>
>> I happen to think it is an advantage if I push validation to some
>> layer (or system) I don't have to worry too much about, and then
>> simply get a failure when someone is spoofing the DNS answer.  I
>> cheerfully concede it's not a complete solution to every possible
>> problem; but if I were interested in solving world peace and hunger,
>> I'd be a diplomat or a missionary rather than a geek.  You appear to
>> be arguing that because DNSSEC validation successes do not prevent
>> attacks on the routing infrastructur, therefore DNSSEC validation does
>> no good.  That strikes me as a hard position to maintain.
>>
>>
>> --
>> Andrew Sullivan
>> [email-masked]
>> Shinkuro, Inc.
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>>
>
>
>
>-- 
>Website: http://hallambaker.com/
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

Date: Wed, 18 Aug 2010 16:24:49 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>, Andrew Sullivan <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Phillip and all,

  FWIW, I am not sure I would trust a cert signed
by Verisign right now given that recently their 
Cert database was hacked/breached and I have no
independant assurance that Verisign has 'fixed'
that breach adaquately and/or informed 'All' of its
Cert customers accordingly.  None the less, Verisign
produces good Certs, so the question than becomes 
is the user of that Cert now the correct one and
how does anyone know that for sure?

-----Original Message-----
>From: Phillip Hallam-Baker <[email-masked]>
>Sent: Aug 18, 2010 2:55 PM
>To: Andrew Sullivan <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications
>
>On Wed, Aug 18, 2010 at 12:39 PM, Andrew Sullivan <[email-masked]> wrote:
>>>
>>> 1 - DNSSEC can tell me who owns some DNS data, like an assertion about
>>> a hostname.  I don't think I know any more than that.  That's pretty
>>> important, but
>>>
>>> 2 - X.509 certificates could tell me a lot more about what I can expect
>>> from the transaction I am starting.  It can deliver a level of assurance
>>> attribute, a policy pointer of some kind that can lead to a complete
>>> disclosure of what this certificate means, and other attributes that
>>> describe what this certificate is supposed to permit or deny.  I don't
>>> think this is available in DNSSEC.  We can argue about the utility of
>>> some of this but that's not the issue.
>>>
>>> Another way of looking at it - this should be up the stack & closer to
>>> the application's viewpoint than DNS is (should be).  So perhaps
>>
>> It seems to me that this distinction is one on which we foundered
>> during the BOF, too.
>>
>> There are two completely different use cases for TLS, and we will get
>> nowhere if we assert that solutions for one are inadequate solutions
>> for the other.
>>
>> The goal in the current keys-linkage draft, as I read it, is simply to
>> gain some assurance that the PKIX cert in question is actually
>> associated with the domain it claims to be.  That is by no means any
>> kind of assurance that (say) the domain is actually operated by the
>> organization one thinks it is (i.e. it doesn't prove that
>> www.mybank.com is actually operated by My Bank, member FDIC).
>
>With DNSSEC alone we have a domain linkage, but no accountability for it.
>
>With DV we have a measure of accountability in that CAs that really
>screw up could in theory be dumped out of the browsers and we have
>defined and audited processes.
>
>With EV we have an industry standard assurance level and audited process.
>
>Now we could have a pointless discussion about whether DV is really
>more secure than DNSSEC, but I think thats pointless as I don't think
>anyone is willing to state that either is a sufficient basis for
>handing over your credit card number or doing banking. And so neither
>should merit a padlock icon.
>
>
>> The first of those is not too far from your (1) (but I think your
>> description doesn't quite capture the power of being able to guarantee
>> you got the right result from the DNS).  The second of these is
>> plainly related to your (2).
>>
>> The fact is that many people think (2) is a waste of time for many
>> purposes: many of the actual CAs simply don't do anything like the job
>> necessary to believe their assertions about identity and so on
>> embodied in the cert.  Therefore, the "utility of some of this" is not
>> the issue directly, but it certainly is a motivating factor in the
>> discussion.  I don't think we can dismiss it.  If the facilities that
>> are supposed to be offered by a technology don't work in practice,
>> then the lack of utility is relevant to rhe duscussion.  (This is not
>> to say the facilities are never useful.  But as general
>> infrastructure, they haven't worked out so well in terms of actually
>> identifying complete strangers to one anhother.)
>
>One big problem here, one that I did insist we deal with in EV was to
>actually show who is providing the certificate to the end user. A
>green bar from a VeriSign or a Comodo may not mean the same to the end
>user as a green bar from Bogocert CA they never heard of before.
>
>The importance of this distinction was just demonstrated in the UAE
>case. Perhaps people are not going to want to trust CAs in certain
>parts of the world for certain purposes. I would not accept code
>signed with a cert from a Nigerian, Sudanese or Russian CA.
>
>
>
>-- 
>Website: http://hallambaker.com/
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

Date: Wed, 18 Aug 2010 16:04:25 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Andrew Sullivan <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Andrew and all,

  Very much agreed!  >:)

-----Original Message-----
>From: Andrew Sullivan <[email-masked]>
>Sent: Aug 18, 2010 3:43 PM
>To: [email-masked]
>Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications
>
>On Wed, Aug 18, 2010 at 04:18:25PM -0400, Paul Wouters wrote:
>> But really, the discussion of whether I can trust a TLD operator more then
>> a CA operator is outside the scope of this list. I believe what is desired
>> here is a way to use the TLD operator without a CA operator. We already have
>> the reverse case for those interested in that.
>
>Hear, hear.  We don't need to debate whether one approach is better
>than the other.  We're not writing signature-style-choices-bcp.  The
>point is to write something that works interoperably provided that you
>accept the premise that what you want to use is DNSSEC.
>
>A
>
>-- 
>Andrew Sullivan
>[email-masked]
>Shinkuro, Inc.
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 294k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

Date: Wed, 18 Aug 2010 16:43:52 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On Wed, Aug 18, 2010 at 04:18:25PM -0400, Paul Wouters wrote:
> But really, the discussion of whether I can trust a TLD operator more then
> a CA operator is outside the scope of this list. I believe what is desired
> here is a way to use the TLD operator without a CA operator. We already have
> the reverse case for those interested in that.

Hear, hear.  We don't need to debate whether one approach is better
than the other.  We're not writing signature-style-choices-bcp.  The
point is to write something that works interoperably provided that you
accept the premise that what you want to use is DNSSEC.

A

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

Date: Wed, 18 Aug 2010 13:32:53 -0700
To: Phillip Hallam-Baker <[email-masked]>, Andrew Sullivan <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

At 3:55 PM -0400 8/18/10, Phillip Hallam-Baker wrote:
>With DNSSEC alone we have a domain linkage, but no accountability for it.

This is completely incorrect. The accountability is to "the same person who gave you the A record that you are about to use to go to the site".

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 18 Aug 2010 16:18:25 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote:

> With DNSSEC alone we have a domain linkage, but no accountability for it.

There is a path of accountability.

> With EV we have an industry standard assurance level and audited process.

EV only works because I cannot get it for $15. The internet is more then
just a few wealthy corporations that can afford to join an elite club.

> The importance of this distinction was just demonstrated in the UAE
> case. Perhaps people are not going to want to trust CAs in certain
> parts of the world for certain purposes. I would not accept code
> signed with a cert from a Nigerian, Sudanese or Russian CA.

Nor RealTek. or Microsoft. To name two compromised pieces of signed code.

But really, the discussion of whether I can trust a TLD operator more then
a CA operator is outside the scope of this list. I believe what is desired
here is a way to use the TLD operator without a CA operator. We already have
the reverse case for those interested in that.

Provided we use the security features DNSSEC offers us, how can we best
implement new record types to satisfy the needs of a variety of uses by
a variety of applications.

Paul

Date: Wed, 18 Aug 2010 15:55:44 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On Wed, Aug 18, 2010 at 12:39 PM, Andrew Sullivan <[email-masked]> wrote:
>>
>> 1 - DNSSEC can tell me who owns some DNS data, like an assertion about
>> a hostname. �I don't think I know any more than that. �That's pretty
>> important, but
>>
>> 2 - X.509 certificates could tell me a lot more about what I can expect
>> from the transaction I am starting. �It can deliver a level of assurance
>> attribute, a policy pointer of some kind that can lead to a complete
>> disclosure of what this certificate means, and other attributes that
>> describe what this certificate is supposed to permit or deny. �I don't
>> think this is available in DNSSEC. �We can argue about the utility of
>> some of this but that's not the issue.
>>
>> Another way of looking at it - this should be up the stack & closer to
>> the application's viewpoint than DNS is (should be). �So perhaps
>
> It seems to me that this distinction is one on which we foundered
> during the BOF, too.
>
> There are two completely different use cases for TLS, and we will get
> nowhere if we assert that solutions for one are inadequate solutions
> for the other.
>
> The goal in the current keys-linkage draft, as I read it, is simply to
> gain some assurance that the PKIX cert in question is actually
> associated with the domain it claims to be. �That is by no means any
> kind of assurance that (say) the domain is actually operated by the
> organization one thinks it is (i.e. it doesn't prove that
> www.mybank.com is actually operated by My Bank, member FDIC).

With DNSSEC alone we have a domain linkage, but no accountability for it.

With DV we have a measure of accountability in that CAs that really
screw up could in theory be dumped out of the browsers and we have
defined and audited processes.

With EV we have an industry standard assurance level and audited process.

Now we could have a pointless discussion about whether DV is really
more secure than DNSSEC, but I think thats pointless as I don't think
anyone is willing to state that either is a sufficient basis for
handing over your credit card number or doing banking. And so neither
should merit a padlock icon.

> The first of those is not too far from your (1) (but I think your
> description doesn't quite capture the power of being able to guarantee
> you got the right result from the DNS). �The second of these is
> plainly related to your (2).
>
> The fact is that many people think (2) is a waste of time for many
> purposes: many of the actual CAs simply don't do anything like the job
> necessary to believe their assertions about identity and so on
> embodied in the cert. �Therefore, the "utility of some of this" is not
> the issue directly, but it certainly is a motivating factor in the
> discussion. �I don't think we can dismiss it. �If the facilities that
> are supposed to be offered by a technology don't work in practice,
> then the lack of utility is relevant to rhe duscussion. �(This is not
> to say the facilities are never useful. �But as general
> infrastructure, they haven't worked out so well in terms of actually
> identifying complete strangers to one anhother.)

One big problem here, one that I did insist we deal with in EV was to
actually show who is providing the certificate to the end user. A
green bar from a VeriSign or a Comodo may not mean the same to the end
user as a green bar from Bogocert CA they never heard of before.

The importance of this distinction was just demonstrated in the UAE
case. Perhaps people are not going to want to trust CAs in certain
parts of the world for certain purposes. I would not accept code
signed with a cert from a Nigerian, Sudanese or Russian CA.

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

Date: Wed, 18 Aug 2010 15:38:45 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Thanks for starting this - my wishlist :)

On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote:

> In my view user keys do not belong in the DNS because the DNS is
> an infrastructure for locating network services, not network users.

I disagree. You are locating an identity. Currently, that is mostly done
based on an IP address and port. I'd hope tomorrow that would mostly be
done based on a public key or hash. Especially with mobile devices, IP's
are very volatile. To locate a service or user, we need the DNS.

Paul

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Wed, 18 Aug 2010 12:20:41 -0700
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Thanks for starting this - my wishlist :)

On Aug 18, 2010, at 12:06 PM, Andrew Sullivan wrote:

> On Wed, Aug 18, 2010 at 11:37:11AM -0700, Nicholas Weaver wrote:
>> EG, how many times is it WRONG to say "sure, I'll accept the self signed cert" in web browsing?
>> 
> 
> If you don't think that's a problem, then why do this work?  (That is,
> dope that I am, I don't even understand why you think this debate is
> worth joining if you think the whole thing a non-problem.)

My attitude towards DNSSEC is exactly why I think THIS group is valuable.  

DNSSEC for DNSSEC's sake is already happening thanks to various mandates, even if, for securing Name->Address mappings, it is a combined world of hurt and useless.  

But if this world is going to exist, I believe we should extract something very VERY useful out of that, which is using DNSSEC for Name->Key material mappings (or other data that is consumed directly by the client rather than simply being used to contact a remote host.)

Since I think DNSSEC is incredibly valuable for securing Name->Key Material mappings: providing, for nearly-free, certificates which flow along already existing trust relationships, and without the proliferating root of trust problems existing in SSL, the price gouging which exists in SSL for wildcard certs, or the leap-of-faith problems present in ssh, I think its very important to make sure that we actually have a good way of doing this.

Since this group is about developing ways to make sure that Name->Key Material bindings can happen and are useful, this group is exactly where I believe the emphasis should be.

Date: Wed, 18 Aug 2010 15:08:49 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Thanks for starting this - my wishlist :)

I agree with what Andrew is saying here. But this is a discussion that
is in-charter for DNSEXT.

Basically I am seeing people looking at DNSCURVE for last hop and
there are certainly many people doing IPSEC. As a security specialist,
I know that there are security capabilities I can provide in that
model that are not possible through endpoint security alone.

My view is that where the validation takes place is for applications
and users to decide. It may even make sense to have no validation at
all. I have argued for years that Web Browsers should not provide a
warning when a site offers a self-signed cert, the browser should
simply turn on the crypto and not tell the user about it at all. If
the web browser will take the user to a site without any crypto
without a warning it should accept imperfect crypto on the same basis.

In the medium term, neither IPSEC or DNSCURVE (or SSL) are ideal for
this purpose. We can do better, but I won't elaborate the reasons why
here.

On Wed, Aug 18, 2010 at 2:06 PM, Andrew Sullivan <[email-masked]> wrote:
> On Wed, Aug 18, 2010 at 10:34:08AM -0700, Nicholas Weaver wrote:
>
>> NOTHING I said implied that the application does the validating,
>
> Well, there were two ways I found to interpret your argument, and the
> other one seemed to me to be the well-worn arguments about why
> offloading to an upstream validator was a Bad Idea. �I didn't figure
> you'd be hauling that argument to this list from another one, but I
> guess I was wrong. �In the enterprise situation, we _have_ an
> implementer who is using the AD bit and IPSEC for the last hop. �You
> keep insisting that's a dangerous model, but in the enterprise
> environment it isn't necessarily (and arguing from home-user-to-ISP
> analogies is simply irrelevant).
>
> The trouble in the case of the AD bit is that it's too little
> information. �But we don't get to dismiss that use case just because
> we're currently not sure how to answer the query. �And we might have
> an opportunity here to address such issues (I kinda doubt it, but
> maybe).
>
>> to do the validating: the application NEEDS to tell the host to
>> validate and how to treat validation failures (because the default
>> will be wrong, no matter what the default is, unless the default is
>
> I think this is right. �It sounds to me like an API issue. �The
> present one is likely the wrong list for that, though. �I wish I knew
> what to suggest apart from dnssec-deployment.
>
>> And that using such an API for validating A records is useless,
>> since any application thats smart enough to bother asking "is this A
>> record validated" is smart enough to realize that the A record
>> validation is meaningless [1]: a corrupted A record is just simply
>> one of many possible MitM attacks, so focus on blocking MitM
>> attacks, not A records: from an application viewpoint, there is no
>> difference between a poisoned DNS entry, a poisoned ARP cache, BGP
>> games, or a WiFi packet injector: a MitM is a MitM.
>
> So your argument is that if the DNSSEC validation comes back correct,
> we still aren't sure routing hasn't been compromised, so this is all
> useless? �Surely that's wrong. �Another way to do this would be to
> offload the validation to a trusted DNS server and offload similar
> validation for BGP &c. to something else, no? �I don't really want my
> phone doing hundreds of DNSSEC validation calculations for every
> cnn.com page view, do I?
>
>> And, frankly speaking, the "benefits" from DNSSEC only come when the
>> application is aware of DNSSEC
>
> I happen to think it is an advantage if I push validation to some
> layer (or system) I don't have to worry too much about, and then
> simply get a failure when someone is spoofing the DNS answer. �I
> cheerfully concede it's not a complete solution to every possible
> problem; but if I were interested in solving world peace and hunger,
> I'd be a diplomat or a missionary rather than a geek. �You appear to
> be arguing that because DNSSEC validation successes do not prevent
> attacks on the routing infrastructur, therefore DNSSEC validation does
> no good. �That strikes me as a hard position to maintain.
>
>
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Wed, 18 Aug 2010 12:07:34 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Nicholas Weaver <[email-masked]>
Subject: Re: [keyassure] Thanks for starting this - my wishlist :)

On Aug 18, 2010, at 12:02 PM, Phillip Hallam-Baker wrote:

> I don't think either works.
> 
> We should be encouraging people to use a separate private key for each
> physical host. So we certainly should not be creating specs that make
> it hard to do that.

I'm not so sure about this.  So much of the Internet relies on LOGICAL host, being defined by hostname rather than IP, that separate key for logical host is what is done today, so it actually does fit well with DNSSEC.

Otherwise, if you want to store material on a physical host (approx by IP), you need to first get the logical host list and then do a reverse DNS lookup on the IP to get the key material.

But I can see that being worth supporting too: so you do a query for both

keymaterial for hostname
keymaterial for IP

and use the union of those two sets as the key material for the host you are commuinacting with.

Date: Wed, 18 Aug 2010 15:06:40 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [keyassure] Thanks for starting this - my wishlist :)

On Wed, Aug 18, 2010 at 11:37:11AM -0700, Nicholas Weaver wrote:
> EG, how many times is it WRONG to say "sure, I'll accept the self signed cert" in web browsing?
> 

If you don't think that's a problem, then why do this work?  (That is,
dope that I am, I don't even understand why you think this debate is
worth joining if you think the whole thing a non-problem.)

A

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

Date: Wed, 18 Aug 2010 15:02:26 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Thanks for starting this - my wishlist :)

I don't think either works.

We should be encouraging people to use a separate private key for each
physical host. So we certainly should not be creating specs that make
it hard to do that.

In the case of SSL the relying application has the certificate in hand
at the start of the validation process. It is thus possible to put an
attribute in the cert to say 'hey I have a DNS key chain' and to give
a prefix that can be used for distinguishing between certs.

There are two separate issues here

1) Validating keys
2) Determining what the security criteria are for a given app.

I would prefer to use the CERTHASH record I proposed in the other post
to do the first and separate out the second into a per-protocol
security options record that gives security related info. For example

_smtp._tcp.example.com OPTION "SSL=OFFERED KEYSERVER=LDAP,XKMS"
_submit._tcp.example.com OPTION "SSL=REQUIRED AUTH=REQUIRED"
_http._tcp.example.com OPTION "SSL=ALWAYS SRV=TRUE AUTH=YAFAP"

I see the elements in an OPTION record as being protocol specific.
There would have to be a draft written for each protocol to say what
the interpretation of the code points would be for that particular
protocol.

For some limited protocols, possibly only SSH and like protocols that
typically bind to specific hosts rather than abstract services, it
might even make sense to put the raw SSH key into an OPTION record.
But I see that as a special case, rather than the norm.

Note that for SMTP I specify two methods of obtaining user certs for
sending an encrypted message. This is where I see user keys coming
from. In my view user keys do not belong in the DNS because the DNS is
an infrastructure for locating network services, not network users. It
is of course the infrastructure that we use to locate the
infrastructure for locating users however.

On Wed, Aug 18, 2010 at 1:25 PM, Paul Wouters <[email-masked]> wrote:
> On Wed, 18 Aug 2010, Nicholas Weaver wrote:
>
>>> 1) Key packaging (eg using raw keys or using certificates or using usage
>>> bits)
>>
>> Or hashes of keys. �This would be my vote, as a hash allows
>
> Yes, hashes is what i meant with "raw key", sorry.
>
>>> 2) Try to make a new DNS record that can be used by more then just one
>>> �application (eg not SSHFP) to avoid spamming the apex.
>>> 3) Try to make the new DNS record specific enough that we can request
>>> specific
>>> �ones (eg I need the key for TLS over SMTP, not the ipsec or ssh key)
>>
>> Hmm, this would require some sort of subdomain scheme then, eg
>> KEYMATERIAL ssl.www.mydomain.com -> RR for SSL key
>> KEYMATERIAL ssh.www.mydomain.com -> RR for ssh key
>
> We could have sub typing instead. That would avoid ugly name space collison,
> eg if
> I have a server named ssl.mydomain.com.
>
>> Does that really make things better vs
>> KEYMATERIAL www.mydomain.com -> {ssl-fingerprint: X, ssh-fingerprint: Y}??
>
> that could get big with 10 different apps on a server?
>
>>> 6) Think about application requests, eg "I only want the A record when it
>>> was
>>> �DNSSEC validated"
>>
>> You example of this is worse than useless. �Any application smart enough
>> to ask that question should be smart enough to not need to trust the answer.
>
> The example was bad because it is actually covered by the AD bit, yes.
> Let's say "I only want the A record when you can get data through an
> anonymizer" We currently can only ask for "passed validation", which is
> limiting.
>
> Paul
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Wed, 18 Aug 2010 11:37:11 -0700
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Thanks for starting this - my wishlist :)

On Aug 18, 2010, at 11:06 AM, Andrew Sullivan wrote:
>> And that using such an API for validating A records is useless,
>> since any application thats smart enough to bother asking "is this A
>> record validated" is smart enough to realize that the A record
>> validation is meaningless [1]: a corrupted A record is just simply
>> one of many possible MitM attacks, so focus on blocking MitM
>> attacks, not A records: from an application viewpoint, there is no
>> difference between a poisoned DNS entry, a poisoned ARP cache, BGP
>> games, or a WiFi packet injector: a MitM is a MitM.
> 
> So your argument is that if the DNSSEC validation comes back correct,
> we still aren't sure routing hasn't been compromised, so this is all
> useless?  Surely that's wrong.  Another way to do this would be to
> offload the validation to a trusted DNS server and offload similar
> validation for BGP &c. to something else, no?  I don't really want my
> phone doing hundreds of DNSSEC validation calculations for every
> cnn.com page view, do I?

You're missing the point:  Against a man in the middle, it doesn't matter HOW they became a MitM, what matters is using end-to-end cryptography in the application/transport to prevent the MitM from doing any damage.

You don't try to block packet-injection based DNS forging, BGP forging, ARP poisoning, DHCP poisoning, WiFi packet injection, and the whole rest of the laundry list.  Its huge, and some can't be prevented without changing the layer 1/2 network completely.

Instead, you build the system to resist a MitM and don't worry how the attacker became a MitM.

And this is why I don't consider DNSSEC to secure DNS A records against a MitM productive, or validating on the not-the-end-host resolver: it only matters when the DNS MitM wouldn't be on the final application path MitM, which IS pretty much just the not-the-end-host resolver.

>> And, frankly speaking, the "benefits" from DNSSEC only come when the
>> application is aware of DNSSEC
> 
> I happen to think it is an advantage if I push validation to some
> layer (or system) I don't have to worry too much about, and then
> simply get a failure when someone is spoofing the DNS answer.  I
> cheerfully concede it's not a complete solution to every possible
> problem; but if I were interested in solving world peace and hunger,
> I'd be a diplomat or a missionary rather than a geek.  You appear to
> be arguing that because DNSSEC validation successes do not prevent
> attacks on the routing infrastructur, therefore DNSSEC validation does
> no good.  That strikes me as a hard position to maintain.

Except that this system, if not on the final end host IS both the adversary, and 99.9% (being charitable here, probably 100%) of the 'spoofing' detected by this system will not be spoofing, but someone messing up the key handling.

EG, how many times is it WRONG to say "sure, I'll accept the self signed cert" in web browsing?

Date: Wed, 18 Aug 2010 13:24:01 -0500
From: Anthony Iliopoulos <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Thanks for starting this - my wishlist :)

On Wed, Aug 18, 2010 at 02:06:28PM -0400, Andrew Sullivan wrote:
> On Wed, Aug 18, 2010 at 10:34:08AM -0700, Nicholas Weaver wrote:

[...]

> The trouble in the case of the AD bit is that it's too little
> information.  But we don't get to dismiss that use case just because
> we're currently not sure how to answer the query.  And we might have
> an opportunity here to address such issues (I kinda doubt it, but
> maybe).
> 
> > to do the validating: the application NEEDS to tell the host to
> > validate and how to treat validation failures (because the default
> > will be wrong, no matter what the default is, unless the default is
> 
> I think this is right.  It sounds to me like an API issue.  The
> present one is likely the wrong list for that, though.  I wish I knew
> what to suggest apart from dnssec-deployment.

What ever happened to draft-hayatnagarkar-dnsext-validator-api btw ? 
Perhaps this is now relevant enough to resurrect ?

Regards,
Anthony

Date: Wed, 18 Aug 2010 14:06:28 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [keyassure] Thanks for starting this - my wishlist :)

On Wed, Aug 18, 2010 at 10:34:08AM -0700, Nicholas Weaver wrote:

> NOTHING I said implied that the application does the validating,

Well, there were two ways I found to interpret your argument, and the
other one seemed to me to be the well-worn arguments about why
offloading to an upstream validator was a Bad Idea.  I didn't figure
you'd be hauling that argument to this list from another one, but I
guess I was wrong.  In the enterprise situation, we _have_ an
implementer who is using the AD bit and IPSEC for the last hop.  You
keep insisting that's a dangerous model, but in the enterprise
environment it isn't necessarily (and arguing from home-user-to-ISP
analogies is simply irrelevant).

The trouble in the case of the AD bit is that it's too little
information.  But we don't get to dismiss that use case just because
we're currently not sure how to answer the query.  And we might have
an opportunity here to address such issues (I kinda doubt it, but
maybe).

> to do the validating: the application NEEDS to tell the host to
> validate and how to treat validation failures (because the default
> will be wrong, no matter what the default is, unless the default is

I think this is right.  It sounds to me like an API issue.  The
present one is likely the wrong list for that, though.  I wish I knew
what to suggest apart from dnssec-deployment.

> And that using such an API for validating A records is useless,
> since any application thats smart enough to bother asking "is this A
> record validated" is smart enough to realize that the A record
> validation is meaningless [1]: a corrupted A record is just simply
> one of many possible MitM attacks, so focus on blocking MitM
> attacks, not A records: from an application viewpoint, there is no
> difference between a poisoned DNS entry, a poisoned ARP cache, BGP
> games, or a WiFi packet injector: a MitM is a MitM.

So your argument is that if the DNSSEC validation comes back correct,
we still aren't sure routing hasn't been compromised, so this is all
useless?  Surely that's wrong.  Another way to do this would be to
offload the validation to a trusted DNS server and offload similar
validation for BGP &c. to something else, no?  I don't really want my
phone doing hundreds of DNSSEC validation calculations for every
cnn.com page view, do I?

> And, frankly speaking, the "benefits" from DNSSEC only come when the
> application is aware of DNSSEC

I happen to think it is an advantage if I push validation to some
layer (or system) I don't have to worry too much about, and then
simply get a failure when someone is spoofing the DNS answer.  I
cheerfully concede it's not a complete solution to every possible
problem; but if I were interested in solving world peace and hunger,
I'd be a diplomat or a missionary rather than a geek.  You appear to
be arguing that because DNSSEC validation successes do not prevent
attacks on the routing infrastructur, therefore DNSSEC validation does
no good.  That strikes me as a hard position to maintain.

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

Date: Wed, 18 Aug 2010 13:52:05 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Nicholas Weaver <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Thanks for starting this - my wishlist :)

On Wed, 18 Aug 2010, Nicholas Weaver wrote:

> And that using such an API for validating A records is useless, since any application thats smart enough to bother asking "is this A record validated" is smart enough to realize that the A record validation is meaningless [1]: a corrupted A record is just simply one of many possible MitM attacks, so focus on blocking MitM attacks, not A records: from an application viewpoint, there is no difference between a poisoned DNS entry, a poisoned ARP cache, BGP games, or a WiFi packet injector: a MitM is a MitM.

Not all DNS entries are meant for A records. What if I have an OTR fingerprint record,
that I use further down whatever IM network I have access to (jabber, MSN, whatever)

> And, frankly speaking, the "benefits" from DNSSEC only come when the application is aware of DNSSEC: the benefits actually lie in the domain of this group: developing ways of using DNSSEC to validate key material or other data directly.

Yes, I was saying just the AD bit might not be enough, because we don't want applications to need to
do a lot of DNS(SEC) work on the error condition.

> [1] Assuming that the resolver has suitable protections against out of path adversaries, of course, or that the host contains its own recursive resolver.

My assumption is always the end node is running its own resolver. You can't really trust anything
else. So local validation+cache using a DHCP supplied forwarder when possible (using something like
unbound that has protection against DNSSEC stripping)

Paul

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Wed, 18 Aug 2010 10:34:08 -0700
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Thanks for starting this - my wishlist :)

NOTHING I said implied that the application does the validating, just that the application uses an API that does/indicates the need to do the validating: the application NEEDS to tell the host to validate and how to treat validation failures (because the default will be wrong, no matter what the default is, unless the default is to say 'sod DNSSEC'), and the validation does need to be done on the end host (see previous rants on what should be done with existing APIs and DNSSEC...).  

And that using such an API for validating A records is useless, since any application thats smart enough to bother asking "is this A record validated" is smart enough to realize that the A record validation is meaningless [1]: a corrupted A record is just simply one of many possible MitM attacks, so focus on blocking MitM attacks, not A records: from an application viewpoint, there is no difference between a poisoned DNS entry, a poisoned ARP cache, BGP games, or a WiFi packet injector: a MitM is a MitM.

And, frankly speaking, the "benefits" from DNSSEC only come when the application is aware of DNSSEC: the benefits actually lie in the domain of this group: developing ways of using DNSSEC to validate key material or other data directly.

[1] Assuming that the resolver has suitable protections against out of path adversaries, of course, or that the host contains its own recursive resolver.

On Aug 18, 2010, at 10:13 AM, Andrew Sullivan wrote:

> On Wed, Aug 18, 2010 at 09:58:20AM -0700, Nicholas Weaver wrote:
>>> 6) Think about application requests, eg "I only want the A record when it was
>>>  DNSSEC validated"
>> 
>> You example of this is worse than useless.  Any application smart enough to ask that question should be smart enough to not need to trust the answer.
>> 
> 
> That's insane.  What you're suggesting is that every application needs
> to have its own full, DNSSEC-aware validator inside it.  The answer to
> "the whole world has access to ring 0 on this operating system" is not
> to write a mini OS inside every application.  It's to make the OS
> secure enough so that applications running inside it can trust
> facilities offered by the OS.
> 
> If we need every application that wants DNSSEC benefits to have to
> understand DNS and DNSSEC, we will never get anywhere.  The platform
> needs to provide simple, easy access to sec_getaddrinfo() or whatever.
> Otherwise, application builders simply won't use that facility.  They
> have enough work to do.  Our job down in the DNS layer is not to make
> it impossible for higher-layer applications to use our facilities;
> it's to make the facilities easy and natural, so that the best things
> we can do are automatically available to application developers.
> 
> A
> 
> -- 
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Wed, 18 Aug 2010 13:32:08 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: [email-masked], Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On Wed, 18 Aug 2010, Ben Laurie wrote:

> Back when I worked on DNSSEC, I had a proposal to allow bilateral signing of DNSSEC keys. The general idea was that I
> would probably trust my own DNSSEC provider, so I could then retrieve the DNSSEC keys they trusted, and so on,
> recursively. Obviously I can choose wherever I like in this graph to start.

And related to that, you could keep the trust path from root to yourself. Then when doing
any kind of device syncing with a new device, you pass along each others trust path, and
it should hit a common trust anchor. This way phone.ben.laurie.org. can sync up with
phone.paul.xelerance.com without even *having* any kind of internet uplink.

This would be good to have in bonjour/avahi/whateveritiscalled today

Paul

Date: Wed, 18 Aug 2010 13:25:06 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Nicholas Weaver <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Thanks for starting this - my wishlist :)

On Wed, 18 Aug 2010, Nicholas Weaver wrote:

>> 1) Key packaging (eg using raw keys or using certificates or using usage bits)
>
> Or hashes of keys.  This would be my vote, as a hash allows

Yes, hashes is what i meant with "raw key", sorry.

>> 2) Try to make a new DNS record that can be used by more then just one
>>   application (eg not SSHFP) to avoid spamming the apex.
>> 3) Try to make the new DNS record specific enough that we can request specific
>>   ones (eg I need the key for TLS over SMTP, not the ipsec or ssh key)
>
> Hmm, this would require some sort of subdomain scheme then, eg
> KEYMATERIAL ssl.www.mydomain.com -> RR for SSL key
> KEYMATERIAL ssh.www.mydomain.com -> RR for ssh key

We could have sub typing instead. That would avoid ugly name space collison, eg if
I have a server named ssl.mydomain.com.

> Does that really make things better vs
> KEYMATERIAL www.mydomain.com -> {ssl-fingerprint: X, ssh-fingerprint: Y}??

that could get big with 10 different apps on a server?

>> 6) Think about application requests, eg "I only want the A record when it was
>>   DNSSEC validated"
>
> You example of this is worse than useless.  Any application smart enough to ask that question should be smart enough to not need to trust the answer.

The example was bad because it is actually covered by the AD bit, yes.
Let's say "I only want the A record when you can get data through an anonymizer" 
We currently can only ask for "passed validation", which is limiting.

Paul

Date: Wed, 18 Aug 2010 13:15:54 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On Wed, Aug 18, 2010 at 06:06:35PM +0100, Ben Laurie wrote:
> The WG carefully defined the problem s.t. this was not a solution :-)

Note that some of us who did the review of the proposals, however,
thought that the solution was a good idea worth pursuing, but not one
that would solve the particular problem as it was defined.  I'm still
interested in your proposal, because it seemed like a generally good
idea to me (especially in the current context, which is the sort of
thing I thought it'd be nice for),

A

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

Date: Wed, 18 Aug 2010 13:13:31 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Thanks for starting this - my wishlist :)

On Wed, Aug 18, 2010 at 09:58:20AM -0700, Nicholas Weaver wrote:
> > 6) Think about application requests, eg "I only want the A record when it was
> >   DNSSEC validated"
> 
> You example of this is worse than useless.  Any application smart enough to ask that question should be smart enough to not need to trust the answer.
> 

That's insane.  What you're suggesting is that every application needs
to have its own full, DNSSEC-aware validator inside it.  The answer to
"the whole world has access to ring 0 on this operating system" is not
to write a mini OS inside every application.  It's to make the OS
secure enough so that applications running inside it can trust
facilities offered by the OS.

If we need every application that wants DNSSEC benefits to have to
understand DNS and DNSSEC, we will never get anywhere.  The platform
needs to provide simple, easy access to sec_getaddrinfo() or whatever.
Otherwise, application builders simply won't use that facility.  They
have enough work to do.  Our job down in the DNS layer is not to make
it impossible for higher-layer applications to use our facilities;
it's to make the facilities easy and natural, so that the best things
we can do are automatically available to application developers.

A

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

Date: Wed, 18 Aug 2010 18:06:35 +0100
From: Ben Laurie <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

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

On 18 August 2010 16:17, Phillip Hallam-Baker <[email-masked]> wrote:

> I don't agree with the idea that a single root of trust is desirable
> or provides any advantage whatsoever. It is one of the features we
> need to fix. The Internet is a network of peers, not serfs. The Icann
> scheme has it's uses but it does not have to be the only scheme people
> are allowed to use.
>
> I am my own root of trust. And that is what everyone else should demand.
>

Back when I worked on DNSSEC, I had a proposal to allow bilateral signing of
DNSSEC keys. The general idea was that I would probably trust my own DNSSEC
provider, so I could then retrieve the DNSSEC keys they trusted, and so on,
recursively. Obviously I can choose wherever I like in this graph to start.

The WG carefully defined the problem s.t. this was not a solution :-)

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

<div class="gmail_quote">On 18 August 2010 16:17, Phillip Hallam-Baker <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I don&#39;t agree with the idea that a single root of trust is desirable<br>
or provides any advantage whatsoever. It is one of the features we<br>
need to fix. The Internet is a network of peers, not serfs. The Icann<br>
scheme has it&#39;s uses but it does not have to be the only scheme people<br>
are allowed to use.<br>
<br>
I am my own root of trust. And that is what everyone else should demand.<br></blockquote><div><br></div><div>Back when I worked on DNSSEC, I had a proposal to allow bilateral signing of DNSSEC keys. The general idea was that I would probably trust my own DNSSEC provider, so I could then retrieve the DNSSEC keys they trusted, and so on, recursively. Obviously I can choose wherever I like in this graph to start.</div>
<div><br></div><div>The WG carefully defined the problem s.t. this was not a solution :-)</div><div>�</div></div>

--001636b1462e8e0fa4048e1c16a3--

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Wed, 18 Aug 2010 09:58:20 -0700
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Thanks for starting this - my wishlist :)

On Aug 18, 2010, at 9:30 AM, Paul Wouters wrote:

> 
> Hi,
> 
> First of all, thanks for starting this list. I have been talking to various people to do precisely this....
> 
> As I see it, we have a few problems to resolve.
> 
> 1) Key packaging (eg using raw keys or using certificates or using usage bits)

Or hashes of keys.  This would be my vote, as a hash allows

a)  Efficient recording of data
b)  Sufficient information to validate the actual received data is legit in the existing protocol key exchange.

> 2) Try to make a new DNS record that can be used by more then just one
>   application (eg not SSHFP) to avoid spamming the apex.
> 3) Try to make the new DNS record specific enough that we can request specific
>   ones (eg I need the key for TLS over SMTP, not the ipsec or ssh key)

Hmm, this would require some sort of subdomain scheme then, eg
KEYMATERIAL ssl.www.mydomain.com -> RR for SSL key
KEYMATERIAL ssh.www.mydomain.com -> RR for ssh key

Does that really make things better vs
KEYMATERIAL www.mydomain.com -> {ssl-fingerprint: X, ssh-fingerprint: Y}??

Especially since if its hashes/fingerprints, the data is small (~256b/entry)

> 6) Think about application requests, eg "I only want the A record when it was
>   DNSSEC validated"

You example of this is worse than useless.  Any application smart enough to ask that question should be smart enough to not need to trust the answer.

Application requests for validation are essential, but the records being validated are key fingerprints or other material where it is the material itself that needs to be authentic, thus keystore records, TXT records, etc will be the ones validated.

This is also why I believe this group is essential if DNSSEC is to do ANY good what-so-ever.

Date: Wed, 18 Aug 2010 12:39:22 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

> 
> 1 - DNSSEC can tell me who owns some DNS data, like an assertion about 
> a hostname.  I don't think I know any more than that.  That's pretty
> important, but
> 
> 2 - X.509 certificates could tell me a lot more about what I can expect
> from the transaction I am starting.  It can deliver a level of assurance
> attribute, a policy pointer of some kind that can lead to a complete
> disclosure of what this certificate means, and other attributes that
> describe what this certificate is supposed to permit or deny.  I don't
> think this is available in DNSSEC.  We can argue about the utility of 
> some of this but that's not the issue.
> 
> Another way of looking at it - this should be up the stack & closer to
> the application's viewpoint than DNS is (should be).  So perhaps

It seems to me that this distinction is one on which we foundered
during the BOF, too.

There are two completely different use cases for TLS, and we will get
nowhere if we assert that solutions for one are inadequate solutions
for the other.

The goal in the current keys-linkage draft, as I read it, is simply to
gain some assurance that the PKIX cert in question is actually
associated with the domain it claims to be.  That is by no means any
kind of assurance that (say) the domain is actually operated by the
organization one thinks it is (i.e. it doesn't prove that
www.mybank.com is actually operated by My Bank, member FDIC).

The first of those is not too far from your (1) (but I think your
description doesn't quite capture the power of being able to guarantee
you got the right result from the DNS).  The second of these is
plainly related to your (2).

The fact is that many people think (2) is a waste of time for many
purposes: many of the actual CAs simply don't do anything like the job
necessary to believe their assertions about identity and so on
embodied in the cert.  Therefore, the "utility of some of this" is not
the issue directly, but it certainly is a motivating factor in the
discussion.  I don't think we can dismiss it.  If the facilities that
are supposed to be offered by a technology don't work in practice,
then the lack of utility is relevant to rhe duscussion.  (This is not
to say the facilities are never useful.  But as general
infrastructure, they haven't worked out so well in terms of actually
identifying complete strangers to one anhother.)

> There is also going to be a place for self-signed certificates
> whose integrity (not necessarily trust) is guaranteed by a relationship
> with DNSSEC-secured data.

Right.  My impression is that such is the thing this proposed WG would
aim at.  That's congruent with my reading of the Problem Statement
recently circulated.  Complete replacement of the entire X.509
functionality is obviously not needed.  Perhaps, however, a
supplementary way of anchoring CAs (better than "update your browser,
please"!) would be another nice thing for any WG to develop.  I regard
that as a sideshow, however.

A

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

Date: Wed, 18 Aug 2010 12:30:00 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: [email-masked]
Subject: [keyassure] Thanks for starting this - my wishlist :)

Hi,

First of all, thanks for starting this list. I have been talking to various 
people to do precisely this....

As I see it, we have a few problems to resolve.

1) Key packaging (eg using raw keys or using certificates or using usage bits)
2) Try to make a new DNS record that can be used by more then just one
    application (eg not SSHFP) to avoid spamming the apex.
3) Try to make the new DNS record specific enough that we can request specific
    ones (eg I need the key for TLS over SMTP, not the ipsec or ssh key)
4) Think about EDNS (secure?) signaling to reduce latency when asking for
    something that will contain an additional trust type record
5) Think about EDNS signaling to request "anonymity". This could be used by a
    browser to request a a local DNS server to not resolve itself, but to use a
    proxy/SOCKS/forwarding servce (eg tor) to aggregate or disguse DNS requests.
6) Think about application requests, eg "I only want the A record when it was
    DNSSEC validated"
7?) think about reducing the size of any new record as much as possible

One link that was missing from the summary send to the list before was the 
original KEY record. It did try to distinguish between applications/protocols
(just only DNSSEC was assigned)

ftp://ftp.rfc-editor.org/in-notes/rfc2535.txt

For instance, see section 3.1.3 The Protocol Octet that talks about application 
usage.  The RFC that then obsoleted application use is:

ftp://ftp.rfc-editor.org/in-notes/rfc3445.txt

I personally think that if we use the trust model of DNSSEC, we should
not have any CA's. However, we probably do need to have "usage bits",
which also exist within the X.509/ASN.1 space, so perhaps it is prudent
to re-use some of that?

I think the biggest immediate win, will be to get HTTPS raw keys in
DNSSEC, supported in a browser like firefox, reducing the 80% of warnings
from self-signed SSL certs that are out there right now.

A next logical step might be to see if we could use the DNS to see if we
should start out with HTTPS (and not HTTP) when connecting to site. Eg
the pressense of a bit or a flag that gives a preference on how to be
contacted. (eg HTTPS preferred pver HTTP, or HTTPS only)

Last, there *might* be a need to say "return even mangled stuff",
which could potentially be used when you're trying to get through a
hotspot/payportal location, where you send a DNS probe for the sole
reason of getting it mangled for portal access.

Paul

Date: Wed, 18 Aug 2010 12:26:28 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked], Carl Wallace <[email-masked]>
Subject: Re: [keyassure] to validate or not to validate?

I have been working on this problem for some time. The scheme I came
up with was:

1) Create a new RR for end entity cert disclosure with the following attributes:

* Digest algorithm + Digest value
* URL for retrieval of cert chain (optional)

* DNS record prefix for use in disambiguating multiple certs
associated with the same domain (optional).

2) Create an X.509v3 certificate extension for DNS path chain
validation. This takes as an attribute a prefix value.

If we are going to modify an application's use of DNS then lets not do
half measures. Lets do the job right and make the best use of DNS
features that we can. If a Web browser is going to be looking at the
DNS for keys, then lets take the time to take advantage of SRV as
well.

So lets imagine that we have a HTTP/SSL service that is served using 4
different servers. Each of which has its own certificate. This is
highly desirable regardless of the type of certificate.

The certificate can be self signed, it can be issued under a local CA
with a local trust root, it can be issued as Domain Validated or it
can even be an EV certificate.

Different relying parties may validate the same certificate along
different trust paths for different purposes. So it may be that in
some cases you would want to validate the cert along the X.509v3 path
alone, in others you would want to have the additional verification of
a DNSSEC validated path. For example, X.509v3 wildcard certificates
currently only support *.example.com. It would be nice for the subject
to be able to lock them down to specific domains.

Each server has their own key and thus their own cert. Each has a
DNSHASH extension as follows:

www1.example.com ->> DNSHASH (c1)
www2.example.com ->> DNSHASH (c2)
www3.example.com ->> DNSHASH (c3)
www4.example.com ->> DNSHASH (c4)

On the DNS side there is a round robin A record for backwards
compatibility and a series of SRV records.:

www.example.com A [10.0.0.1  10.0.0.2  10.0.0.3  10.0.0.4

_http._srv.example.com SRV 1 1 80 www1.example.com
_https._srv.example.com SRV 1 1 443 www1.example.com
_http._srv.example.com SRV 1 1 80 www2.example.com
_https._srv.example.com SRV 1 1 443 www2.example.com
_http._srv.example.com SRV 1 1 80 www3.example.com
_https._srv.example.com SRV 1 1 443 www3.example.com
_http._srv.example.com SRV 1 1 80 www4.example.com
_https._srv.example.com SRV 1 1 443 www4.example.com

www1.example.com A 10.0.0.1
www2.example.com A 10.0.0.1
www3.example.com A 10.0.0.1
www4.example.com A 10.0.0.1

_c1.example.com CERTH "h=SHA1:bd0e87ecc53c4d961ef55f3b4bb47dd06ff8c825"
_c2.example.com CERTH "h=SHA1:f55ad283945cdc4903bf8c22b04074ada5d20104"
_c3.example.com CERTH "h=SHA1:0f3ba85b555d74cfd653dabb74046220ccdc5ba1"
_c4.example.com CERTH "h=SHA1:160c9cd8877025be44c790653815b949986ebd54"

>From the relying party point of view:

1) Resolve www.example.com to obtain an A record for use with HTTP/TCP
2) Decide to use SSL
        [Will explain this in more detail in a later post]
3) Connect to the IP address with SSL
        [Require use of the domain extension]
4) Server pushes out its certificate -  Certificate specifies DNSHASH c3
5) Pull _c3.www.example.com CERTH
* Verify that CERTH specifies acceptably secure algorithm
* Verify digest value for acceptable algorithm matches cert.
* Verify the trust path on the CERTH RR.

From: Stephen Schultze <[email-masked]>
To: [email-masked]
Date: Wed, 18 Aug 2010 12:22:39 -0400
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On Aug 18, 2010, at 11:40 AM, Nicholas Weaver wrote:
> On Aug 18, 2010, at 8:17 AM, Phillip Hallam-Baker wrote:
>> I don't agree with the idea that a single root of trust is desirable
>> or provides any advantage whatsoever. It is one of the features we
>> need to fix. The Internet is a network of peers, not serfs. The Icann
>> scheme has it's uses but it does not have to be the only scheme  
>> people
>> are allowed to use.
>
> Yet at the same time you argue that the CA vendors provide  
> something?  This seems strange.  You MUST HAVE either a set of trust  
> roots (any PKI) or a notion of consensus (PGP) or a leap-of-faith  
> (ssh).
>
> DNSSEC and CA's are "trust root" models.  Face it, because its a  
> trust root model, you must have, well, a trust root.  You might be  
> able to hack a consensus model onto DNSSEC, but that would be  
> difficult, especially since normal DNS already has a trust root  
> model in operation.
>
> But if you are going to have a trust-root, you really only want a  
> single point or single possible path of trust, because of attacks on  
> the CA infrastructure itself.  With a gazillion roots of trust, and  
> roots of trust willing to delegate completely given enough money  
> (eg, the Verizon provided Etisalat * cert [1]), the system is weak.
>
> And thus the big advantage of DNSSEC over other PKIs, other than  
> cost (EG, CA vendors charge $150+ for *.mydomain wildcards, which is  
> just highway robbery) is that the trust path is limited: the trust  
> path for things in mydomain.com ONLY depend on mydomain.com, .com,  
> and .: there's no longer the case that MY ssl infrastructure is  
> trivially vulnerable because Verizon's division decided to sign a *  
> cert for the UAE.

It seems that you both can be right.  I certainly agree with PHB's  
statement that each system has its benefits and weaknesses, and the  
goal of keys-in-DNS is not to completely supplant the CA model.  The  
benefit of a DNSSEC-based model is that it provides trust in  
authenticating the controller of a domain name, at which point you can  
bootstrap to additional trust provided by CAs or others ad needed.   
One key advantage, as Nicholas observes, is excludability in the first  
step of trust.  PHB would like to also give flexibility to end-users  
to specify additional or alternative TAs within DNS.  Perhaps this  
will be useful for some entities that maintain large public zones, or  
their own internal zones, or for other purposes.  If users choose to  
add other TAs, it seems that should be permitted as a matter of  
technology and policy (we saw this with the DLV).  They do so with the  
conscious understanding that they are trusting an additional/different  
authority (either at the root or an intermediate node), which is far  
better than the current system in which arbitrary unknown SubCAs exist  
in the wild.

  I personally think it most likely that the vast majority of users  
will have just the one signed root TA for DNSSEC trust, but I don't  
see how it's productive to argue over whether this will be the case in  
general.

To: [email-masked]
Date: Wed, 18 Aug 2010 09:11:39 -0700
From: Mike Helm <[email-masked]>
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications
Reply-To: [email-masked]

Nicholas Weaver writes:
> On Aug 18, 2010, at 8:17 AM, Phillip Hallam-Baker wrote:
> > I don't agree with the idea that a single root of trust is desirable
> > or provides any advantage whatsoever. It is one of the features we
> > need to fix. The Internet is a network of peers, not serfs. The Icann
> 
> Yet at the same time you argue that the CA vendors provide something?  This seems strange.  You MUST HAVE either a set of trust roots (any PKI) or a notion of consensus (PGP) or a leap-of-faith (ssh).  

I see 2 (or maybe 3) problems, which themselves are probably
anchored in the interpretation of trust.  From the relying party
point of view, 

1 - DNSSEC can tell me who owns some DNS data, like an assertion about 
a hostname.  I don't think I know any more than that.  That's pretty
important, but

2 - X.509 certificates could tell me a lot more about what I can expect
from the transaction I am starting.  It can deliver a level of assurance
attribute, a policy pointer of some kind that can lead to a complete
disclosure of what this certificate means, and other attributes that
describe what this certificate is supposed to permit or deny.  I don't
think this is available in DNSSEC.  We can argue about the utility of 
some of this but that's not the issue.

Another way of looking at it - this should be up the stack & closer to
the application's viewpoint than DNS is (should be).  So perhaps

3 - SSL/TLS is bit trapped. Current best (or typical) practices for hosts
seem to be to focus on the domain owner to give permission for certificates
to be issued.   Sometimes this is very counterproductive - the domain owner
might be a network engineer largely univolved with the application that
needs TLS.  Skipping a long argument, we can liberate SSL/TLS from trying to take
the place of DNSSEC - DNSSEC can manage the host name accountability, 
& TLS / SSL certs can focus on managing the application accountability.
This is not going to be a perfect separation but it looks useful.

There is going to be a place for 3rd party certificate signers.
There is also going to be a place for self-signed certificates
whose integrity (not necessarily trust) is guaranteed by a relationship
with DNSSEC-secured data.

My perspective comes from the grid - academic research distributed computing
world where we need more of this flexibility.  (Say what you may about that.)

Thanks, =mwh
Michael Helm
ESnet/LBNL

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Wed, 18 Aug 2010 08:40:07 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications

On Aug 18, 2010, at 8:17 AM, Phillip Hallam-Baker wrote:
> I don't agree with the idea that a single root of trust is desirable
> or provides any advantage whatsoever. It is one of the features we
> need to fix. The Internet is a network of peers, not serfs. The Icann
> scheme has it's uses but it does not have to be the only scheme people
> are allowed to use.

Yet at the same time you argue that the CA vendors provide something?  This seems strange.  You MUST HAVE either a set of trust roots (any PKI) or a notion of consensus (PGP) or a leap-of-faith (ssh).  

DNSSEC and CA's are "trust root" models.  Face it, because its a trust root model, you must have, well, a trust root.  You might be able to hack a consensus model onto DNSSEC, but that would be difficult, especially since normal DNS already has a trust root model in operation.

But if you are going to have a trust-root, you really only want a single point or single possible path of trust, because of attacks on the CA infrastructure itself.  With a gazillion roots of trust, and roots of trust willing to delegate completely given enough money (eg, the Verizon provided Etisalat * cert [1]), the system is weak.

And thus the big advantage of DNSSEC over other PKIs, other than cost (EG, CA vendors charge $150+ for *.mydomain wildcards, which is just highway robbery) is that the trust path is limited: the trust path for things in mydomain.com ONLY depend on mydomain.com, .com, and .: there's no longer the case that MY ssl infrastructure is trivially vulnerable because Verizon's division decided to sign a * cert for the UAE.

[1] (https://www.eff.org/deeplinks/2010/08/open-letter-verizon)

Content-class: urn:content-classes:message
Date: Wed, 18 Aug 2010 11:34:55 -0400
From: "Carl Wallace" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>, <[email-masked]>
Subject: Re: [keyassure] to validate or not to validate?

<snip>
> >This may be cleaner if the key association comparison was performed
> first then PKIX validation checks enforced if required by the client.
> A client could then require the extra checks in some cases but not
all.
> 
> The current intent, which might not be reflected well in the
processing
> is:
> - If there is no DNS key association, do normal PKIX validation
> - If there is one or more key associations, make sure that one of them
> matches the key in the server certificate
> - If the server certificate looks like it is supposed to chain to a
> trust anchor, do the PKIX validation check and fail if it fails
> - If the server certificate does not look like it is supposed to chain
> to a trust anchor (generally: it is self-signed or signed by a CA that
> is not a trust anchor), don't bother doing the PKIX validation and
> accept it as-is
> 
> Expressing the fourth part is where we might have tripped up. A
> simplification could be to only check if it is self-signed, but I
think
> there is a real use-case for "I have a cert signed by my
organization's
> local authority that people in my organization use as a trust anchor
> but probably no one else does".

It's going to be tricky to define the condition that drives selection of
one of the last two bullets.  Simply checking for self-signed is
probably the safest option.  There are lots of sites with certificates
issued by a CA that is not a trust anchor, so including a check to see
if a certificate is signed by a TA is not a good option.  

More generally, it does not seem like a good idea to allow the key
association check to circumvent the client's trust anchor store.  I may
want to operate my browser with a very limited set of (ideally
constrained) TAs in some scenarios and a broader set in other scenarios.
Having the key association check as an additional check is good.  Having
the key association check serve as the only check is also good in some
cases, but not all, hence my suggestion that PKIX enforcement be at the
client's discretion.

Date: Wed, 18 Aug 2010 11:17:30 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Subject: [keyassure] Charter discussion - Use of DNSSEC in applications

I disagree with the statement in the proposed charter

We have a pki infrastructure that has certain capabilities and certain
limitations. We have the expectation of a dnssec infrastructure with
other capabilities and limitations

I am not too interested in just re-doing the features already
supported in existing pki at lower out of pocket expense

What we should do here is to work out how we can use dnssec plus pki
to move beyond current capabilities. In particular.

* ubiquitous encryption
* downgrade attack prevention
* best possible security

Of course getting rid of the out of pocket expense is a necessary
condition for ubiquitous crypto. But you are only going to get a
limited amount of security for free.

I want to make EV certs work well with Dnssec as an option. If 100% of
Internet traffic is encrypted, people may start to see the value of
the service that CAs really provide.

I don't agree with the idea that a single root of trust is desirable
or provides any advantage whatsoever. It is one of the features we
need to fix. The Internet is a network of peers, not serfs. The Icann
scheme has it's uses but it does not have to be the only scheme people
are allowed to use.

I am my own root of trust. And that is what everyone else should demand.

As a practical matter we can't escape from x.509 entirely. Ssl is set
up to use certs. We will do much better to put certs or cert hashes in
the dns than raw keys. If we use raw keys we then have to do much More
drastic revision to ssl libraries. We have to recode both the client
and the server rather than just the client. I hate asn1 as much as
anyone, but it's no real pain to wrap a key as a self signed cert.

We should look to make the best system we can, not simply replicate
what already exists for cheap.

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

Date: Wed, 18 Aug 2010 08:02:14 -0700
To: "Carl Wallace" <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] to validate or not to validate?

At 9:10 AM -0400 8/18/10, Carl Wallace wrote:
>Content-Type: multipart/alternative;
>	boundary="----_=_NextPart_001_01CB3ED6.B0FD9F6D"
>Content-class: urn:content-classes:message
>
>In section 3, it is difficult to ascertain the relationship between the two bullets.  The first clause of the each bullet requires the client to determine if the TLS server's certificate is signed by a CA trusted by the client.  This is typically done by applying "PKIX validation checks", which are only applied in the first bullet after making this determination.  It's not clear to me if a failed PKIX validation check coupled with a key association match is a success case or a failure case.  Is the intent to do full path processing with the issuer's certificate as the end entity before deciding which option to invoke?
> 
>This may be cleaner if the key association comparison was performed first then PKIX validation checks enforced if required by the client.  A client could then require the extra checks in some cases but not all.

The current intent, which might not be reflected well in the processing is:
- If there is no DNS key association, do normal PKIX validation
- If there is one or more key associations, make sure that one of them matches the key in the server certificate
- If the server certificate looks like it is supposed to chain to a trust anchor, do the PKIX validation check and fail if it fails
- If the server certificate does not look like it is supposed to chain to a trust anchor (generally: it is self-signed or signed by a CA that is not a trust anchor), don't bother doing the PKIX validation and accept it as-is

Expressing the fourth part is where we might have tripped up. A simplification could be to only check if it is self-signed, but I think there is a real use-case for "I have a cert signed by my organization's local authority that people in my organization use as a trust anchor but probably no one else does".

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 18 Aug 2010 07:45:46 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: [keyassure] Key linkage draft, -00 edition

Greetings again. A gang of us created a draft that pulls together some of the many ideas that have been floating around. There are multiple options for some features, so we chose one option in each category and started an appendix to document the choices.

<http://www.ietf.org/id/draft-hoffman-keys-linkage-from-dns-00.txt>

Discussion is welcome. Please don't assume that any of the options are set in stone, although note that changing some options might also require changing other options at the same time. In particular, I think my idea of listing ports is going to go away, given that few sites run services on different ports but keep the same domain name.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 18 Aug 2010 09:10:10 -0400
From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Subject: [keyassure] to validate or not to validate?

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB3ED6.B0FD9F6D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In section 3, it is difficult to ascertain the relationship between the
two bullets.  The first clause of the each bullet requires the client to
determine if the TLS server's certificate is signed by a CA trusted by
the client.  This is typically done by applying "PKIX validation
checks", which are only applied in the first bullet after making this
determination.  It's not clear to me if a failed PKIX validation check
coupled with a key association match is a success case or a failure
case.  Is the intent to do full path processing with the issuer's
certificate as the end entity before deciding which option to invoke?

This may be cleaner if the key association comparison was performed
first then PKIX validation checks enforced if required by the client.  A
client could then require the extra checks in some cases but not all.

------_=_NextPart_001_01CB3ED6.B0FD9F6D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="&#1;" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=WordSection1>

<p class=MsoNormal>In section 3, it is difficult to ascertain the relationship
between the two bullets.&nbsp; The first clause of the each bullet requires the
client to determine if the TLS server&#8217;s certificate is signed by a CA trusted
by the client.&nbsp; This is typically done by applying &#8220;PKIX validation
checks&#8221;, which are only applied in the first bullet after making this
determination.&nbsp; It&#8217;s not clear to me if a failed PKIX validation
check coupled with a key association match is a success case or a failure case.&nbsp;
Is the intent to do full path processing with the issuer&#8217;s certificate as
the end entity before deciding which option to invoke?<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>This may be cleaner if the key association comparison was performed
first then PKIX validation checks enforced if required by the client.&nbsp; A
client could then require the extra checks in some cases but not all.<o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01CB3ED6.B0FD9F6D--

Date: Wed, 18 Aug 2010 09:50:29 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: [keyassure] You want to read this :) (Was: Welcome to the mailing list, and possible charter.)

Just to add some reading material to the mailing list archive...

You may want to read:

New I-D by Jakob, Paul, Warren and Adam:
http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-00.txt

Slightly older CERT RR (which we already have):
http://tools.ietf.org/html/rfc4398

And various older proposals which didn't make it:

(Jakob's)
http://stupid.domain.name/ietf/draft-schlyter-pkix-dns-02.txt

(RR TYPE request I did)
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg00421.html

This is just to summarize the ideas which were floating around for some 
time.  The basis on our work will be in the most recent I-D.

On 17.8.2010 19:21, Warren Kumari wrote:
> Hello all,
>
> We are investigating starting a working group to leverage the DNSSEC
> trust anchor as a trust anchor for various other protocols. We are
> initially focusing on TLS, but are also interested in other
> protocols.
>
> Just so that we are all level set, here is our initial (draft)
> problem statement.
>
> Problem Statement:
>
> The DNS Security Extensions are a collection of resource records and
> protocol modifications that provide source authentication for the
> DNS.
>
> The DNSSEC signed root infrastructure provides a single, well
> published trust-anchor and a method to build a chain of trust from an
> individual resource record (RR)  to that TA. By leveraging this
> infrastructure we can securely bind information (such as a public
> key, certificate identifier, etc) to a DNS name.
>
> Increasingly people would like to be able to take advantage of the
> confidentiality and identity validation provided by protocols such as
> TLS. There are numerous barriers to this, including cost, ease of
> use, complexity, certificate management, etc. By allowing users to
> securely publish public key information we can allow users to easily
> and securely make use of self-signed certificates.
>
> Currently, one of the issues limiting the use of self-signed
> certificates is the difficulty in key-distribution - it is infeasible
> to distribute a key binding at the web scale. By providing a means to
> publish (and securely validate) this information in the DNS, we allow
> for users to attest to the validity of keying information and
> establish trust in the published public key.
>
> The DNSSEC root trust anchor can also be used for additional
> validation during the current path validations. By validating that
> the  certificate presented is the certificate identified by the DNS,
> we can provide additional confidence that the client is connecting to
> the intended server - this helps alleviate concerns that a valid
> certificate has been obtained by an attacker (for example from a CA
> not used by the victim).

-- 
  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: IETF Secretariat <[email-masked]>
To: IETF Announcement list <[email-masked]>
Date: Tue, 17 Aug 2010 11:36:02 -0700 (PDT)
Cc: [email-masked]
Subject: [keyassure] New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC

A new IETF non-working group email list has been created.

List address: [email-masked]
Archive:
http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html
To subscribe: https://www.ietf.org/mailman/listinfo/keyassure

Description: This list is for discussion relating to using
DNSSEC-protected DNS queries to get greater assurance for keys and
certificates that are passed in existing IETF protocols. The main idea is
that a relying party can get additional information about a domain name to
eliminate the need for using a certificate in a protocol, to eliminate the
need for sending certificates in the protocol if they are optional, and/or
to assure that the certificate given in a protocol is associated with the
domain name used by the application. In all three cases, the
application associates the key or key fingerprint securely retrieved from
the DNS with the domain name that was used in the DNS query. 

For additional information, please contact the list administrators.

From: Warren Kumari <[email-masked]>
Date: Tue, 17 Aug 2010 13:21:49 -0400
To: [email-masked]
Subject: [keyassure] Welcome to the mailing list, and possible charter.

Hello all, 

We are investigating starting a working group to leverage the DNSSEC trust anchor as a trust anchor for various other protocols. We are initially focusing on TLS, but are also interested in other protocols.

Just so that we are all level set, here is our initial (draft) problem statement.

Problem Statement:

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

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

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

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

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

Warren