Subject: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC

From: Paul Hoffman <[email-masked]>
Date: Sun, 23 Aug 2009 11:32:30 -0700

Greetings again. At the WG meeting in Stockholm, I agreed to write this document to allow crypto algorithms in non-standards-track RFCs to get allocations from the IANA registry. I incorporated a variety of ideas from different folks, including a review of the new policy long before the registry gets full. The document also gives the motivations for the proposed change.

Please consider adopting this short document as a WG work item.

--Paul Hoffman

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>	Title           : Cryptographic Algorithm Identifier Allocation for DNSSEC
>	Author(s)       : P. Hoffman
>	Filename        : draft-hoffman-dnssec-alg-allocation-00.txt
>	Pages           : 4
>	Date            : 2009-08-23
>
>This document specifies how DNSSEC cryptographic algorithm
>identifiers in the IANA registries are allocated.  It changes the
>rule from "standard required" to "RFC required".
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-hoffman-dnssec-alg-allocation-00.txt

---

From: Basil Dolmatov <[email-masked]>
Date: Wed, 26 Aug 2009 00:06:37 +0400

Paul Hoffman пишет:

I think that the ideas presented in this document are quite reasonable
and the solution it proposes is properly addressing most of the issues
which were discussed considering algorithm number allocations.

I support adoption of this document as a WG  work item.

Basil Dolmatov

==========

Cryptocom Ltd.

--Paul Hoffman

---

From: Dan Simon <[email-masked]>
Date: Wed, 26 Aug 2009 03:38:26 +0000

As far as I can tell, the only purpose for this draft is to make it easier for new algorithms to be introduced into DNSSEC without any WG vetting.  I honestly can't imagine why on earth the WG would want that.

There are some obvious *dis*advantages to the proliferation of unvetted cryptographic algorithms in DNSSEC.  It increases the likelihood that DNS clients will be unable to verify signed DNS records.  It increases the likelihood that at least some DNSSEC signatures will be insecure (i.e., forgeable).  It increases the likelihood that DNS clients will have to use and integrate software from multiple sources, including possibly unreliable or even untrustworthy software, in order to verify DNS signatures.  And it increases the likelihood that the algorithm identifier space will be used up at some point in the future, when security considerations actually require large-scale conversion to new, safer algorithms.

Those are some of the disadvantages.  What are the advantages?  The draft offers two:  governments might wish to impose--er, introduce new, unevaluated algorithms, and someone might want to introduce an intellectual property rights-encumbered algorithm.  To me, these seem like great arguments *against* this proposal.  Put them together, in fact, and we have what I consider the ultimate nightmare scenario:  a government imposes a proprietary, IPR-encumbered algorithm on its ccTLD, requiring clients all over the world to install and run software supplied by that government in order to validate that country's DNS records.  Why on earth would this WG want to facilitate such an outcome?

                                Baffled,

                                Dan Simon
                                Microsoft Corp.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Sunday, August 23, 2009 11:33 AM
To: [email-masked]
Subject: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 26 Aug 2009 00:33:44 -0400

No hat.  I want to emphasise that the below are questions, and not
rhetorical devices.  They're leading questions on purpose, because I
want to explore a particular possibility.  I don't have a
well-formulated position on any of this at the moment.

On Wed, Aug 26, 2009 at 03:38:26AM +0000, Dan Simon wrote:

> seem like great arguments *against* this proposal.  Put them
> together, in fact, and we have what I consider the ultimate
> nightmare scenario: a government imposes a proprietary,
> IPR-encumbered algorithm on its ccTLD, requiring clients all over
> the world to install and run software supplied by that government in
> order to validate that country's DNS records.

Do you think it is possible that nobody -- or, more exactly, a tiny
subset of the world community -- will actually do what that government
wants, such that the government's actions not only fail to achieve the
desired action, but embarrass the government in question into
recognising that interoperability is more important than whatever it
was they wanted from their algorithm?  If so, does that countervailing
consideration affect your view about this topic?

A

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

---

From: Dan Simon <[email-masked]>
Date: Wed, 26 Aug 2009 05:21:04 +0000

Andrew, it's certainly *possible* that a government trying to shove its software down every DNS client's throat via a proprietary DNSSEC algorithm might fail miserably.  In fact, I have absolutely no idea how likely it would be to succeed in its attempt.  Presumably, a lot would depend on the particular government in question, and the degree to which the world comes to rely on DNSSEC, among other factors.

But however low or high such a government's a priori odds of success, those odds--and therefore its likelihood of attempting such a move in the first place--could only be increased, and quite possibly dramatically so, by the prospect of its proprietary algorithm having the imprimatur of the IETF and IANA, as an official part of the DNSSEC standard.

Why on earth would we want to give it that imprimatur by default, automatically and without even the opportunity for review?  Again, what conceivable benefit does the DNSSEC community stand to get in return for that heightened risk?

                                Still baffled,

                                Dan Simon
                                Microsoft Corp.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
Sent: Tuesday, August 25, 2009 9:34 PM
To: [email-masked]
Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC

A

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

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 26 Aug 2009 05:18:29 -0700

On Aug 25, 2009, at 10:21 PM, Dan Simon wrote:

> Andrew, it's certainly *possible* that a government trying to shove  
> its software down every DNS client's throat via a proprietary DNSSEC  
> algorithm might fail miserably.  In fact, I have absolutely no idea  
> how likely it would be to succeed in its attempt.  Presumably, a lot  
> would depend on the particular government in question, and the  
> degree to which the world comes to rely on DNSSEC, among other  
> factors.

>
> But however low or high such a government's a priori odds of  
> success, those odds--and therefore its likelihood of attempting such  
> a move in the first place--could only be increased, and quite  
> possibly dramatically so, by the prospect of its proprietary  
> algorithm having the imprimatur of the IETF and IANA, as an official  
> part of the DNSSEC standard.

A related case would be WiFi encryption, where China attempted to do  
just this with WAPI.

Although unsuccesfull in forcing WAPI on the rest of the world, it is  
a data point that governments will attempt such moves.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Aug 2009 07:44:19 -0700

At 3:38 AM +0000 8/26/09, Dan Simon wrote:
>As far as I can tell, the only purpose for this draft is to make it easier for new algorithms to be introduced into DNSSEC without any WG vetting.

Actually, that scenario is not one of the ones that are covered in the draft. There were other scenarios that *are* covered in the draft, so it is unclear why you would think this was "the only purpose".

The WG does not only work on standards-track documents. It is common for WGs in the IETF to produce both Informational and Experimental RFCs.

Does this help?

>There are some obvious *dis*advantages to the proliferation of unvetted cryptographic algorithms in DNSSEC. 

Let's look at them, remembering that DNSSEC is the only (or maybe one of the only) security protocol in the IETF that has the restriction that identifiers can only be issued for standards-track RFCs.

>It increases the likelihood that DNS clients will be unable to verify signed DNS records. 

The same is true for every other IETF protocol, yet in practice, this has not been a problem. The market  completely trumps any power-hoarding done by the IETF.

>It increases the likelihood that at least some DNSSEC signatures will be insecure (i.e., forgeable). 

That assumes that the WG will quickly put on standards track the best possible signature algorithms. Recent evidence does not support that claim.

>It increases the likelihood that DNS clients will have to use and integrate software from multiple sources, including possibly unreliable or even untrustworthy software, in order to verify DNS signatures. 

What does *have to* mean? In every other security protocol in the IETF, no one has felt a need to add validating software for algorithms that had identifiers, but for which the software didn't care. Not to pick on dol@, but I have not seen S/MIME software that does GOST, even though the Informational RFCs have been out for many years.

In other words: what makes DNSSEC systems different than those of TLS, IPsec, S/MIME, SSH, and so on, none of which have felt the need to implemet every registered algorithm?

>And it increases the likelihood that the algorithm identifier space will be used up at some point in the future, when security considerations actually require large-scale conversion to new, safer algorithms.

Hm. I'm getting the feeling that you didn't actually read the draft; this is explicitly covered.

>Those are some of the disadvantages.  What are the advantages?  The draft offers two:  governments might wish to impose--er, introduce new, unevaluated algorithms, and someone might want to introduce an intellectual property rights-encumbered algorithm. 

Funny, I don't see the word "impose" or "unevaluated" in the document. There are plenty of algorithms that are not mandatory that have been widely evaluated that are not on standards track.

>To me, these seem like great arguments *against* this proposal.  Put them together, in fact, and we have what I consider the ultimate nightmare scenario:  a government imposes a proprietary, IPR-encumbered algorithm on its ccTLD, requiring clients all over the world to install and run software supplied by that government in order to validate that country's DNS records.

Stop right there. How does the government of some country *require* the clients used in some other country to do anything? No one has to be able to verify all zones. In fact, we already are in the situation where some signatures using standards-track DNSSEC algorithms might not be allowed to be verified. (Will your software verify an RSA-SHA1 signature with a 256-bit key? Should it?) This proposal doesn't change the situation at all.

>  Why on earth would this WG want to facilitate such an outcome?

It wouldn't, of course. Why on earth do you think that outcome is possible?

--Paul Hoffman, Director
--VPN Consortium

---

From: Basil Dolmatov <[email-masked]>
Date: Wed, 26 Aug 2009 14:22:26 +0400

Dan Simon пишет:

Put them together, in fact, and we have what I consider the ultimate
nightmare scenario:

  a government imposes a proprietary, IPR-encumbered algorithm on its
ccTLD, requiring clients all over the world to install and run software
supplied

by that government in order to validate that country's DNS records.

> 
> Baffled,
> 
> Dan Simon Microsoft Corp.
This is exactly that was made with RSA/SHA, moreover it is supposed to
be used in order to validate _all_other_countries_ DNS records.

Looks like dual-standard approach, heh?

dol@

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 26 Aug 2009 04:01:58 -0400

> In other words: what makes DNSSEC systems different than those of TLS, IPsec, S/MIME, SSH, and so on, none of which have felt the need to implemet every registered algorithm?
Because the institutional dedication to have a single root deployed. The 
DNS is a critical infrastructure and I see the point made by Dan as an 
attempt to keep it manageable once DNSSEC is deployed. None of the other 
uses of public key cryptography are similarly tied to a single focal 
point of governance.

If you have multiple roots subjected to diverse DNSSEC deployment 
policies, then market forces would play as in other PK deployment fronts.

My 0.02 cents ...

- Thierry Moreau

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Aug 2009 08:58:31 -0700

>But however low or high such a government's a priori odds of success, those odds--and therefore its likelihood of attempting such a move in the first place--could only be increased, and quite possib…

The "imprimatur" of an IANA value? That seems a bit far-fetched, given the same imprimatur is granted for other security protocols which are basically never heard from again. To use your company's products as an example, I do not believe that your web clients, nor your IIS server, implements all of the TLS ciphersuites in the range 0xC001 through 0xC019. Those have the imprimatur of IANA, and are defined in RFC 4492, which is an Informational RFC. However, I believe that your company has implemented some of them.

But, more importantly, the supposed government *does not need an RFC today*. They could demand that their zones are signed with DNSSEC algorithm 254 and an OID that is controlled by the government. We already allow that in the DNSSEC standard. In such a situation, would your company feel obligated to be able to verify those signatures, use the proprietary software demanded by that government, and so on? Of course not.

>Why on earth would we want to give it that imprimatur by default, automatically and without even the opportunity for review? 

Because we already are.

>Again, what conceivable benefit does the DNSSEC community stand to get in return for that heightened risk?

The benefit of better interoperability for algorithms that for whatever reason could not be on standards track. This is the same benefit that other IETF security protocols have been using for over a decade.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Aug 2009 09:31:51 -0700

At 4:01 AM -0400 8/26/09, Thierry Moreau wrote:
>Because the institutional dedication to have a single root deployed. The DNS is a critical infrastructure and I see the point made by Dan as an attempt to keep it manageable once DNSSEC is deployed. None of the other uses of public key cryptography are similarly tied to a single focal point of governance.

This is a valid point, but not one that is affected by the proposal at hand. I would expect the root to only sign with algorithms that they believe everyone can validate; we just had that discussion with respect to RSA-SHA256.

The question is what do other zones further down the hierarchy want to sign with. Some might say "we will only sign with algorithms that not everyone will validate", and then need to deal with the effects of their zone rendering bogus for some queries. Others will dual-sign with an algorithm that they trust more than the universally-implemented algorithms, and require that some people validate only the non-universal signature but allow others to still validate with the universal one.

>If you have multiple roots subjected to diverse DNSSEC deployment policies, then market forces would play as in other PK deployment fronts.

Fortunately, we are not talking about multiple roots.

--Paul Hoffman, Director
--VPN Consortium

---

From: Basil Dolmatov <[email-masked]>
Date: Wed, 26 Aug 2009 23:25:39 +0400

Thierry Moreau пишет:
> Paul Hoffman wrote:
>> In other words: what makes DNSSEC systems different than those of 
>> TLS, IPsec, S/MIME, SSH, and so on, none of which have felt the need 
>> to implemet every registered algorithm?
Diverse algorithms have been implemented _already_ in TLS, S/MIME 
(consult the corresponding RFCs), work is in progress on IPSec, and 
approach is made to SSH too, being the most rigid and inflexible, though.

So, one can say: nothing makes DNSSec different in _this_ aspect from 
these protocols. ;)

dol@

> Because the institutional dedication to have a single root deployed. 
> The DNS is a critical infrastructure and I see the point made by Dan 
> as an attempt to keep it manageable once DNSSEC is deployed. None of 
> the other uses of public key cryptography are similarly tied to a 
> single focal point of governance.
>

---

From: Basil Dolmatov <[email-masked]>
Date: Wed, 26 Aug 2009 23:34:17 +0400

> What does *have to* mean? In every other security protocol in the IETF, no one has felt a need to add validating software for algorithms that had identifiers, but for which the software didn't care…
Yes. You have no need to use it. But we _are_using it for all these 
years. ;)
And that is good (IMHO), that this operations are documented in RFCs.

This definitely follows the general IETF idea about "rough concensus and 
running code" (c).
We have a running code and the auditory of possible users of this code 
in several dozens of millions of Russian Internet users is worth be 
considered a solid ground for _rough_ concensus (IMHO), even if Dan and 
Microsoft are not supporting it (unfortunately, because Windows users 
here are forced to install additional software in order to get necessary 
algorithm support ;), nevertheless it does not affect algorithm usage at 
whole ;)

dol@

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 26 Aug 2009 17:25:43 -0400

At 15:25 26/08/2009, Basil Dolmatov wrote:
>Thierry Moreau пишет:
>>Paul Hoffman wrote:
>>>In other words: what makes DNSSEC systems 
>>>different than those of TLS, IPsec, S/MIME, 
>>>SSH, and so on, none of which have felt the 
>>>need to implemet every registered algorithm?
>Diverse algorithms have been implemented 
>_already_ in TLS, S/MIME (consult the 
>corresponding RFCs), work is in progress on 
>IPSec, and approach is made to SSH too, being 
>the most rigid and inflexible, though.
>
>So, one can say: nothing makes DNSSec different 
>in _this_ aspect from these protocols. ;)

<no-hat>
All the protocols you mention are handshake protocols, DNSSEC is a
broadcast protocol.
In the first case the two parties (client and server) can check if they
support a common protocol and then use it. The server will be able to
log the event that a client connected that it did not have any mechanism
in common with.

In Broadcast protocols there is no feedback mechanism for clients
to advertise that alg X is supported. Thus there is no way for DNS publisher
to determine if by signing by algorithm Y some significant portion of
the Internet can not validate her data.

         Olafur

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Aug 2009 15:08:20 -0700

At 5:25 PM -0400 8/26/09, Olafur Gudmundsson wrote:
>>Thierry Moreau ®¢¿®¢¸Ñ–®¢µÑ’:
>>>Paul Hoffman wrote:
>>Diverse algorithms have been implemented _already_ in TLS, S/MIME (consult the corresponding RFCs), work is in progress on IPSec, and approach is made to SSH too, being the most rigid and inflexible, though.
>>
>>So, one can say: nothing makes DNSSec different in _this_ aspect from these protocols. ;)
>
><no-hat>

S/MIME, used as email, is *far* from a handshake protocol. If I send you signed email, I have no idea if you can verify it. For example, even though you could verify the signature yesterday on your desktop computer running a proper S/MIME client, you might be receiving the message on your Gmail account today. The fancy footwork the S/MIME community does with the SMIMECapabilities extension to make it look like a handshake protocol is humorous, but ultimately mostly futile.

>the Internet can not validate her data.

The out-of-band feedback in DNSSEC ("why is your domain bogus?") will be infinitely more effective than the out-of-band feedback for signature failures in TLS or S/MIME. Really: the market will truly count here.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dan Simon <[email-masked]>
Date: Thu, 27 Aug 2009 00:17:51 +0000

Basil, as far as I know, RSA/SHA is (1) not intellectual property rights-encumbered anywhere, and (2) not required--legally or otherwise--to be used with DNSSEC in the US or anywhere else.  (If I'm mistaken on either count, please let me know.)  RSA used to be IPR-encumbered, and my impression is that the IETF back then was very leery about incorporating it into Internet standards, for precisely that reason.     

					Dan Simon
					Microsoft Corp.

-----Original Message-----
From: Basil Dolmatov [mailto:[email-masked]] 
Sent: Wednesday, August 26, 2009 3:22 AM
To: Dan Simon
Cc: 'Paul Hoffman'; [email-masked]
Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC

Dan Simon пишет:

dol@

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 26 Aug 2009 13:52:30 -0400

Paul Hoffman wrote:
> S/MIME, used as email, is *far* from a handshake protocol. If I send you signed email, I have no idea if you can verify it. For example, even though you could verify the signature yesterday on your desktop computer running a proper S/MIME client, you mi
> ght be receiving the message on your Gmail account today. The fancy footwork the S/MIME community does with the SMIMECapabilities extension to make it look like a handshake protocol is humorous, but ultimately mostly futile.
>
>   
"My domain is not bogus, please have your resolver updated to support 
the DNSSEC compliant signature algorithm XYZ recently endorsed by IANA 
(... under a contract with the US government ...)."

If there are too many algorithms in the DNS zone hierarchy, the market 
signal may be "no, thanks" to DNSSEC deployment. I think that the draft 
allows too many algorithms in the DNS zone hierarchy and thus makes 
seamless DNSSEC validation harder to deploy, without a say from the IETF wg.

- Thierry Moreau

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 27 Aug 2009 06:13:01 +0200

On 27 aug 2009, at 00.08, Paul Hoffman wrote:

> The out-of-band feedback in DNSSEC ("why is your domain bogus?")  
> will be infinitely more effective than the out-of-band feedback for  
> signature failures in TLS or S/MIME. Really: the market will truly  
> count here.

The feedback will not be "why is your domain bogus". Your feedback,  
when you try to access a website, and you can not, is to call your own  
ISP and say "why is your DNS server broken". And the ISP then have two  
choices: Bite their tongue and calm the customer down, or stop  
verifying DNSSEC signed responses.

We can _not_ risk having non-interoperability of DNSSEC globally by  
having everyone picking their own crypto algorithm.

    Patrik

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 Aug 2009 05:25:19 +0000

> We can _not_ risk having non-interoperability of DNSSEC globally by having
> everyone picking their own crypto algorithm.
> 
>    Patrik

how will we prevent this, other than with local policy in validators that
says, treat unknown algos as indeterminate (which effectively means, treat
them as unsigned data).  if a national government decides to use their own
crypto on their own names, the ietf's only recourse against such (assuming
the ietf would act against such) is to refuse to allocate a code point and
refuse to publish an rfc -- all of which seems terribly unlikely to me.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Aug 2009 16:41:07 +1000

In message <[email-masked]>, =?ISO-8859-1?Q?Pat
> having everyone picking their own crypto algorithm.

Please go read how DNSSEC work before more mis-information is spread.

If a validator doesn't understand any of the algorithms then the zone
is treated as insecure.

You only get bogus when:
1. The validator knows one or more of the algorithms used to sign the zone and
2. All the signatures for the algorithms fail or you don't get then
   necessary proofs supplied with the response.

Bogus indicates validation failed, not you can't validate the answer because
you don't understand the algorithm.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Basil Dolmatov <[email-masked]>
Date: Thu, 27 Aug 2009 10:46:25 +0400

Dan,

keywords were "a government imposes" and not any IPR-related words.

Where "a" means "some".

dol@

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Aug 2009 17:07:24 +1000

In message <[email-masked]>, Dmitry Burkov writes:
> 
> Dan Simon wrote:
> > Basil, as far as I know, RSA/SHA is (1) not intellectual property rights-en
> cumbered anywhere, and (2) not required--legally or otherwise--to be used wit
> h DNSSEC in the US or anywhere else.  (If I'm mistaken on either count, pleas
> e let me know.)  RSA used to be IPR-encumbered, and my impression is that the
>  IETF back then was very leery about incorporating it into Internet standards
> , for precisely that reason.
> >    
> Dan,
> 
> just short comment,
> seems you missed another side of the deployment problem.
> 
> What's about
> http://www.bis.doc.gov/encryption/default.htm ?
> 
> Do you think that it will be possible to import/export HSMs(just, for 
> example) to/from any country and legally use it?
> You simply can check current situation in your company Export Regulation 
> Office(or Department).
> 
> regards,
> Dmitry

You don't need to use HSM's to do DNSSEC, 99.999% of RSA operations
for DNSSEC will be done without using a HSM.  All HSM's do is make
it harder for the private part of the key pair to be seen by someone
who shouldn't see it.  HSM's often slow down the crypto so you
really only want to use them for signing where keeping the private
part of the key safe is more important than the time to sign is.

Given how some HSM's I've seen implemented work any compentent
computer geek could build one from a standard PC.

Mark

---

From: Jim Reid <[email-masked]>
Date: Thu, 27 Aug 2009 08:39:44 +0100

On 27 Aug 2009, at 06:25, Paul Vixie wrote:

>> having

If a country decides to choose their own algorithm for DNSSEC, they're  
not going to care what the IETF says or does. And there's nothing the  
protocol police can do about that. Allocating a code point for such an  
algorithm is benign. If anything all it does is prevent collisions.  
IMO, the only focus should be on the algorithm(s) that are mandatory  
to implement (ie ensure interoperability). If/when something else is  
chosen, that would be analagous to using RFC1918 addressing: fine  
behind closed doors between consenting adults but useless for  
communicating with the rest of the world.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 27 Aug 2009 09:38:58 +0200

> refuse to publish an rfc -- all of which seems terribly unlikely to  

We can not prevent this, just like we can not prevent anything by  
"just" writing an RFC. But we can write the correct words on what the  
impact is, and that way help with some input to the decision making  
process people go though before they choose arguments to their key  
generation function of their choice.

There are of course other input as well, but people seem (the ones  
that have contacted me) to want a description that contain a warning  
message.

    Patrik

---

From: Jim Reid <[email-masked]>
Date: Thu, 27 Aug 2009 08:46:52 +0100

On 27 Aug 2009, at 05:21, Dmitry Burkov wrote:

> Do you think that it will be possible to import/export HSMs(just,  
> for example) to/from any country and legally use it?

Dima, it is not necessary to use HSMs to deploy DNSSEC. If someone  
chooses to use HSM, it's up to them to figure out how to do so in a  
way that complies with the prevailing law or regulation. [The same  
holds for DNSSEC deployment in general.] A discussion about that is  
probably out of scope for this WG. I doubt anyone where is a lawyer  
specialising in the import or export of crypto.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 27 Aug 2009 09:52:27 +0200

On 08/27/2009 08:41 AM, Mark Andrews wrote:
> before more mis-information is spread.
> 

+1

Best regards,
   Wouter

---

From: Jelte Jansen <[email-masked]>
Date: Thu, 27 Aug 2009 11:38:30 +0200

>> http://www.ietf.org/internet-drafts/draft-hoffman-dnssec-alg-allocation-00.txt

while i do have some problems with the current text (unrelated to the ongoing
discussion btw, will post about it later), i do support that this be taken up as
a wg work item, and i am willing to review.

Jelte

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 27 Aug 2009 13:56:00 +0200

On Wed, Aug 26, 2009 at 05:25:43PM -0400,
 Olafur Gudmundsson <[email-masked]> wrote 
 a message of 32 lines which said:

> broadcast protocol. [...] In Broadcast protocols there is no
> feedback mechanism for clients to advertise that alg X is supported.

What if draft-crocker-dnssec-algo-signal were adopted? Do you think it
would address your concerns?

Abstract

   The DNS Security Extensions (DNSSEC) was developed to provide origin
   authentication and integrity protection for DNS data by using digital
   signatures.  These digital signatures can be generated using
   different algorithms.  Each digital signature added to a response
   increases the size of the response, which could result in the
   response message being truncated.  This draft sets out to specify a
   way for validating end-system resolvers to signal to a server which
   cryptographic algorithms they prefer in a DNSSEC response by defining
   an EDNS option to list a client's preferred algorithms.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 27 Aug 2009 11:26:40 -0400

Dear colleagues,

> Please consider adopting this short document as a WG work item.

The draft has inspired some significant discussion, and that is good;
but it is important to remember that what we are deciding is still
primarily whether the draft is to be a work item for this WG.  I
imagine that the strenuous debate indicates a willingness to review
the draft, but it would be helpful if you stated where you stand on
that exact question as well.

Thanks,

Andrew (for the Chairs)

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 27 Aug 2009 17:38:08 +0200

On Sun, Aug 23, 2009 at 11:32:30AM -0700,
 Paul Hoffman <[email-masked]> wrote 

> Please consider adopting this short document as a WG work item.

I believe it would be a good idea to have the WG work on this
document. In the next years, there will certainly have non-futile
demands for new algorithms (such as elliptic curve algorithms). I'm
not yet stable about some ideas like the allocation of temporary
identifiers for testing but it does not prevent us to start working.

I volunteer for review, too.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Aug 2009 09:12:35 -0700

>If a validator doesn't understand any of the algorithms then the zone

My apologies for using the term "bogus" in my earlier responses. You are right, we are talking about zones being insecure.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Aug 2009 09:58:58 -0700

I have updated the draft to include clarifications from the recent thread. The new version is at:

http://www.ietf.org/internet-drafts/draft-hoffman-dnssec-alg-allocation-01.txt

The added text is:

3.  Expectations For Implementations

   It is important to note that, according to RFC 4034, DNSSEC
   implementations are not expected to include all of the algorithms
   listed in the IANA registry; in fact, RFC 4034 and the IANA registry
   list an algorithm that implementations should not include.  This
   document does nothing to change the expectation that there will be
   items listed in the IANA registry that need not be (and in some
   cases, should not be) included in all implementations.

   There are many reasons why a DNSSEC implementation might not include
   one or more of the algorithms listed, even those on Standards Track.
   In order to be compliant with the RFC 4034, an implementation only
   needs to implement the algorithms listed as mandatory to implement in
   the that standard, or updates to that standard.  This document does
   nothing to change the list of mandatory to implement algorithms in
   RFC 4034.

I hope this helps allay fears and repeat what is already in RFC 4034 that remains unchanged. I also hope it helps gain interest in this becoming a WG document.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dan Simon <[email-masked]>
Date: Thu, 27 Aug 2009 17:51:08 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Wednesday, August 26, 2009 3:08 PM

>The out-of-band feedback in DNSSEC ("why is your domain bogus?") will be infinitely more effective than the out-of-band feedback for signature failures in TLS or S/MIME. Really: the market will trul…

DNSSEC is supposed to secure DNS, and DNS is supposed to be a single, global name resolution infrastructure service for the Internet--not an individual competitor in a broad free market for Internet name resolution services.  That's why there's so much political involvement in root administration, ccTLD management, and DNSSEC--including by countries that want their preferred algorithms used for DNS record signatures.  Nobody's making a big deal about what algorithms are used by the umpteenth CA to set itself up for business signing SSL/TLS certificates.  But with DNSSEC it's different, because there's only one DNS.

					Dan Simon
					Microsoft Corp.

---

From: Dan Simon <[email-masked]>
Date: Thu, 27 Aug 2009 17:50:37 +0000

From: Paul Hoffman [mailto:[email-masked]] 
Sent: Wednesday, August 26, 2009 8:59 AM

[snip]

>But, more importantly, the supposed government *does not need an RFC today*. They could demand that their zones are signed with DNSSEC algorithm 254 and an OID that is controlled by the government. We already allow that in the DNSSEC standard. 

Great--so there's no need for your draft, then.  Right?

>The benefit of better interoperability for algorithms that for whatever reason could not be on standards track. This is the same benefit that other IETF security protocols have been using for over a…

How does your draft achieve "better interoperability" for such algorithms, given the already-existing solution you described above?  The only improvement your draft offers, as far as I can tell, is precisely the one I described:  the imprimatur of inclusion in the DNSSEC standard, along with an assigned IANA algorithm number, would encourage and facilitate wider deployment of those "algorithms that for whatever reason could not be on standards track".  And in your draft, you're quite specific about what "for whatever reason" means:  government-promoted algorithms with insufficient expert evaluation, and IPR-encumbered algorithms.  I don't see why anyone would want this WG to alter the DNSSEC standard for no other purpose than to make it a better vehicle through which to promote the deployment of unevaluated and/or IPR-encumbered algorithms.

				Dan Simon
				Microsoft Corp.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 27 Aug 2009 14:03:05 -0400

> Great--so there's no need for your draft, then.  Right?

I should note that the draft was the result of discussion at the
Stockholm DNSEXT meeting; the Chairs asked for an inital draft, and
Paul volunteered.  We Chairs have heard several requests lately to
alter the current rules about assigning algorithm identifiers.  

Note that the RSA/SHA2 effort has been somewhat frustrated by the
difficulty of getting adequate WG review, our process rules, and so
on.  That state of affairs means (among other things) that discussion
of using SHA-256 to sign the root from the beginning runs immediately
into the simple problem that there are no interoperating
implementations today, because the code point doesn't exist.

Best regards,

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Aug 2009 11:27:12 -0700

>Great--so there's no need for your draft, then.  Right?

If you don't care about interoperability, that correct. Many of us do care about it, however. That's why IANA exists.

>How does your draft achieve "better interoperability" for such algorithms, given the already-existing solution you described above?

The IANA registry would contain an accurate view of the algorithms that are documented in RFCs.

>  The only improvement your draft offers, as far as I can tell, is precisely the one I described:  the imprimatur of inclusion in the DNSSEC standard, along with an assigned IANA algorithm number, would encourage and facilitate wider deployment of those "algorithms that for whatever reason could not be on standards track".

As I stated before, we disagree on the "imprimatur" of being included in a registry. The imprimatur, if any, comes from the standards level of the algorithm and the amount of deployment.

>  And in your draft, you're quite specific about what "for whatever reason" means:  government-promoted algorithms with insufficient expert evaluation, and IPR-encumbered algorithms.  I don't see why anyone would want this WG to alter the DNSSEC standard for no other purpose than to make it a better vehicle through which to promote the deployment of unevaluated and/or IPR-encumbered algorithms.

Nor do I: that's why the document doesn't say that. You made that up yourself.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dan Simon <[email-masked]>
Date: Thu, 27 Aug 2009 18:32:47 +0000

Thanks for the clarification, Andrew.  I have no objection to a draft that clarifies the WG's procedure for adding new algorithms to the DNSSEC algorithm list, if its purpose is to address the problems facing efforts to add new, well-vetted, widely deployable algorithms as the currently popular algorithms gradually become more suspect.  I just don't see the need for a draft whose primary stated purpose is to ease the incorporation of unevaluated and/or IPR-encumbered algorithms into DNSSEC.

				Dan Simon
				Microsoft Corp.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
Sent: Thursday, August 27, 2009 11:03 AM
To: [email-masked]
Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC

Best regards,

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

---

From: Paul Wouters <[email-masked]>
Date: Thu, 27 Aug 2009 14:42:19 -0400 (EDT)

> http://www.ietf.org/internet-drafts/draft-hoffman-dnssec-alg-allocation-01.txt

Looks good to me. One minor point I was thinking about. Since we briefly saw a
proposal that would suggest a crypto preference based on the order/number of the
algorithm, and saw that most people did not like that implication, perhaps we
can explicitely state that the order of algorithms in the registry does not
signify or imply cryptographic strength or preference.

Paul

---

From: Basil Dolmatov <[email-masked]>
Date: Thu, 27 Aug 2009 23:41:46 +0400

> >
>
>  Looks good to me. One minor point I was thinking about. Since we
>  briefly saw a proposal that would suggest a crypto preference based
>  on the order/number of the algorithm, and saw that most people did
>  not like that implication, perhaps we can explicitely state that the
>  order of algorithms in the registry does not signify or imply
>  cryptographic strength or preference.
Seconded on that.

dol@

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 27 Aug 2009 13:47:41 -0400

> My apologies for using the term "bogus" in my earlier responses. You are right, we are talking about zones being insecure.

Thanks to Andrew and Paul for this clarification, which is indeed 
unambiguous from the DNSSEC protocol and security design.

So, the question is whether the DNSSEC wg should work on a document that 
facilitates the allocation of algorithm identifiers which, once 
allocated, are potentially used, either by themselves (leading to the 
"insecure" validation status in the case of slow adoption, despite the 
zone being DNSSEC compliant) or in parallel with established algorithms 
(leading to larger DNS responses). My answer is no, i.e. the wg should 
indicate that algorithm homogeneity is important to DNSSEC overall 
security services and thus standards-track RFC is the appropriate IANA 
criteria. No need to add a wg work item for to reach this wg position.

Going back to the "insecure" status reported by a DNSSEC validator not 
supporting a newcomer algorithm, this leads to an interesting hacker 
playground: once the users are trained to have greater confidence in 
DNSSEC compliant zones, here comes a new type of DNSSEC compliant zones, 
from which "insecure" status is returned from resolver "A" (say at home) 
while "secure" is observed from resolver "B" (at the office). Now try to 
explain the cause and subtle consequences to the user ... But be sure 
the hackers will see the gap in perceived vs actual DNS data integrity 
protection.

(In essence, this is an instance or a variant of the very first failure 
root cause for digital signature applications: the relying party is 
ignoring the failure of a signature verification result.)

Something in the security foundation of DNSSEC is shaken by this 
seemingly innocuous draft.

- Thierry Morea

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 27 Aug 2009 17:56:07 -0400

On Thu, Aug 27, 2009 at 06:32:47PM +0000, Dan Simon wrote:

> Thanks for the clarification, Andrew.  I have no objection to a
> draft that clarifies the WG's procedure for adding new algorithms to
> the DNSSEC algorithm list, if its purpose is to address the problems
> facing efforts to add new, well-vetted, widely deployable algorithms
> as the currently popular algorithms gradually become more suspect.

So let's be even more clear: the proposal is to move the identifier
assignment requirement from "standard required" to "RFC required".
To expand on that, the current rule is that the WG come to an
agreement to publish a standards-track RFC making the change.  The new
rule would allow any RFC published by any means to be enough to permit
the assignment of an identifier.  

Now, the new identifier assignment regime would not require
"well-vetted, widely deployable, &c."  It is by no means plain to me,
however, that the _current_ regime requires that either, since this WG
is not full to the brim with cryptographers and therefore is not the
WG one would ask about the suitability of a given algorithm for this
or that purpose.

I am neither claiming that the current procedure does or does not
resulted in the well-vetted &c. algorithms.  I am merely pointing out
that there is no such formal requirement at the moment, since
standards action by this WG does not entail such vetting &c.

Best,

A

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Aug 2009 09:58:53 +1000

> implementations today, because the code point doesn't exist.

There is really nothing new in RSA/SHA2.  It's just a code point.
NSEC3 is already used in DNS. SHA2 is already used in DNS.  RSA is
already used in DNS.  It was a bolt together exercise which took
1/2 a day, all it is waiting on is the code point.  It would have
taken less if we didn't cleanup some of the code at the same time
to make adding new algorithms even easier.

I really don't expect interoperability problems.  This is like
adding a new RR in terms of difficultly.

If IANA wants to facilitate a interop test on a randomly choosen
code point I'm sure that most of the vendors could supply test code
relatitively easily with the usual sorts of caveats.
 
Mark

---

From: Dan Simon <[email-masked]>
Date: Thu, 27 Aug 2009 18:32:47 +0000

Dan Simon
				Microsoft Corp.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
Sent: Thursday, August 27, 2009 11:03 AM
To: [email-masked]
Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC

Best regards,

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Aug 2009 09:58:58 -0700

The added text is:

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 27 Aug 2009 11:26:40 -0400

Dear colleagues,

Thanks,

Andrew (for the Chairs)

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Aug 2009 10:44:54 +1000

In message <[email-masked]>, Stephane Bortzmeyer writes:
>  Paul Hoffman <[email-masked]> wrote=20

I don't think we need test algorithm id's.  Interop testing can be
done by the testers choosing a unallocated algorithm amongst
themselves for the duration of the test.  Testbed implementations
should never be used in production systems, this is not to say the
testbed can't be in the public namespace, just that the servers are
only being used to participate in the test.  There really isn't the
need for this to do lots of testing for new cryptographic hashes
or public key cryptographic algorithms.  It either works or it
doesn't and most of that can be determined with a single implementation.

The worst that will happen is that answers from the old testbed
zones won't validate but no one will be looking up things in those
zones anyway.

We arn't doing cryptographic research.  We are testing if we can
pass all the information required to validate a RRset from a
authoritative server to a validating resolver.  i.e. are all the
inputs the validator requires in the DNSKEY/RRSIG pair.  This is
not hard to check at the paper stage.

Changing the fundementals of how DNSSEC works, like adding NSEC3
was required more work.  If we need a test algorithm for this sort
of work then we can request one if we need one.  Mind you we got way
without needing one for the NSEC3 testbeds.

Mark

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Aug 2009 09:12:35 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 28 Aug 2009 07:51:52 +0200

On 27 aug 2009, at 18.12, Paul Hoffman wrote:

> My apologies for using the term "bogus" in my earlier responses. You  
> are right, we are talking about zones being insecure.

I have rechecked the DNSSEC spec (thanks to some people on this list  
for offline help) and I see now the following four situations:

1. Query is for a signed domain, where the signature verifies correctly.

Response is sent back to client with data.

2. Query is for a signed domain, where the algorithm is known, but the  
signature verification fails.

Response is sent back, but the response has SERVFAIL status and no data.

3. Query is for a signed domain, where the algorithm is not known, and  
can because of that not be verified.

A normal reply of the data, without the signatures and so on. Like it  
was an unsigned domain.

4. Query for signed domain, the algorithm not known. But the answer is  
forged.

This forged answer is sent to the client without checking. Just like  
for an unsigned domain when the answer is forged.

For me, this implies (specifically as I in this discussion screwed up  
and did not really understand at first) we need to write something  
about how important it is to agree on what crypto algorithms will be  
in use, or else we will get cases 3 and 4 "too often", when people  
believe case 1 or 2 are in use.

    Patrik

---

From: Basil Dolmatov <[email-masked]>
Date: Fri, 28 Aug 2009 12:16:44 +0400

Patrik Fältström пишет:
> I have rechecked the DNSSEC spec (thanks to some people on this list for 
> offline help) and I see now the following four situations:
> 
> This forged answer is sent to the client without checking. Just like for 
> an unsigned domain when the answer is forged.
> 
> and did not really understand at first) we need to write something about 
> how important it is to agree on what crypto algorithms will be in use, 
> or else we will get cases 3 and 4 "too often", when people believe case 
> 1 or 2 are in use.
> 
The situation with algorithms is the same "opt-in" from the client side 
as with DNSSec as a whole.

If one wants to be sure that the DNSSec-signed data are correct, he has 
_the_option_ to deploy DNSSec and start checking DNSSec info.
If one wants to be sure that the data from specific domain (country) are 
correct, he has _the_option_ to install necessary algorithms and start 
checking this particular flavor of DNSSec info.

And distribution of these _options_ will be driven by market demand, as 
Paul correctly said.
If noone overseas will be interested in checking DNSSec info from the 
given country, then these specific algorithms will have only local 
meaning, and that is normal state of affairs.

If, for example, you have no need to read Chinese, then you will have no 
Chinese drivers on your computer and Chinese text will be undecipherable 
for you, but that does not mean that does not mean that Chinese encoding 
should not be present in global list of possible encodings.

dol@

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 28 Aug 2009 10:25:03 +0200

On 28 aug 2009, at 10.16, Basil Dolmatov wrote:

> If one wants to be sure that the DNSSec-signed data are correct, he  
> has _the_option_ to deploy DNSSec and start checking DNSSec info.
> If one wants to be sure that the data from specific domain (country)  
> are correct, he has _the_option_ to install necessary algorithms and  
> start checking this particular flavor of DNSSec info.

The problem is the reverse as well. If I sign my domain, I do not want  
people that verify dnssec signatures to get a response if the  
signature do not validate.

   Patrik

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Aug 2009 19:02:04 +1000

What we will get is a situation like we have with TSIG.  Microsoft
went ahead and designed GSS-TSIG but failed to implement basic TSIG
so there was no interoperability.  This did and still does cause
operational pain.

I, at least, don't want to see similar issues with DNSSEC which is
where this appears to be heading.

I would like to be able to say you can only get a code point when
it provides a significant improvement over what already exists and
if there is consensus amongst the crypto geeks that this is the
case you get the code point.  Everyone else gets to use the domain
name escape path if they feel they must use their own crypto.

Vendors would be encoraged to implement algorithms with their own
code points.

Mark

---

From: [email-masked]
Date: Fri, 28 Aug 2009 11:10:04 +0000

> signature do not validate.

	really?  I'd thought you would want them to get a response that
	sez; "Cant validate".

--bill

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 28 Aug 2009 15:58:41 +0200

> 	really?  I'd thought you would want them to get a response that

Old clients can not understand new messages. You propose a new message.

    paf

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 28 Aug 2009 10:12:04 -0400

No hat.

On Fri, Aug 28, 2009 at 10:25:03AM +0200, Patrik Fältström wrote:
> people that verify dnssec signatures to get a response if the signature 
> do not validate.

Too bad.  The protocol is not designed to give you that assurance, and
never was.  

That one can introduce a new algorithm without the old algorithm being
supported everywhere is supposed to be a feature.  Now, if you want
to be fairly confident that your zone will be validatable by the
largest possible set of validators, then you will use algorithms that
are widely supported.  But you cannot be sure, even today, that if you
are using sane algorithms someone who is validating is also using
those algorithms.

The IETF has a long history of saying, "X is bad for interoperability,
so we won't 'permit' it."  The result is inevitably that people go
away and do things they were going to do anyway, only in a way even
worse for interoperation because either (1) they're confined to the
portion of the protocol intended for expermentation &c., or else (2)
they choose to overload some part of the protocol that may in fact be
used for something else.  Elsewhere in this thread we had an
implementer suggesting that it's ok to use unassigned code points for
a little while, during the testing phase; the result of having
actually done that recently is that we have deployed versions of
software which disagree (today!) about what certain algorithm numbers
mean.

The DNS community has another example of the previous difficulty of
getting code points and what it meant: RRTYPEs remain in practice hard
to deploy; the unknown type is not universally supported; and other
protocol writers, when looking to do something (particularly something
tactical) in the DNS inevitably are thrown back on the "TXT with
underscore label" strategy, because that is known to work widely.  As
a community, we sowed that wind, and now we are reaping: it was once
very very hard to get a code point, and so people routed around the
damage.  We can say all we want that there are now easy mechanisms to
do what people want, but we trained the rest of the world to think it
would be hard, they built their systems accordingly, and now our easy
mechanisms don't work as we would like.

None of this is to say that we should or should not adopt the
strategies in Paul's draft.  It is rather to say that the
"interoperation" argument cuts more than one way, and we don't get to
ignore the part of the argument that entails that easier access to
identifier numbers may help interoperation.

Best,

A

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

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 28 Aug 2009 16:25:47 +0200

> identifier numbers may help interoperation.

I agree with this.

    Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 28 Aug 2009 10:40:44 -0400

No hat.

> offline help) and I see now the following four situations:

I think there are more than these four.  First, you are discounting
the case where the end node does its own validation.  In this case, it
has more information on which to base decisions, which alone might be
a useful state of affairs (I don't know: I'm conscious of the problems
that, for instance, have resulted from self-signed certs and the way
that's been dealt with historically in web browsers).  Second,

> A normal reply of the data, without the signatures and so on. Like it  

There are two policies available here, and it's important to remember
what they are.  If a security-aware, non-validating stub talks to a
validating resolver via a secure path, then it can in fact use the AD
bit to tell whether a response was signed.  I know that many people
think the AD bit under this circumstance is just a debugging aid, but
at least one implementation has decided to use it as a basis for
making decisions.  One decision is, "Use this DNS answer," but the
other one is, "Treat this answer as suspect."  Today it would probably
be insane to refuse to follow an answer were it not secured, but the
same may not be true in the future, and it seems to me one could
legitmately pick a policy, "I will not use unvalidated answers,
period," especially in certain kinds of applications.

Under such deployment conditions, of course, there is even greater
pressure to pick one of a small number of well-supported algorithms
for at least one of the signing algorithms for a zone.  That, however,
seems to me to be policy and not protocol, and therefore to be on
topic in another WG.

> an unsigned domain when the answer is forged.

See above.  And, as I noted in another message, you have this problem
today.  It could get worse when SHA-2 is deployed (assuming we ever
manage to complete the standards action necessary for that), because
people in a fit of panic about the strength of SHA-1 may disable the
latter.  Certainly worse foot-guns have been handed around by well
meaning "security officers" in the past.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 28 Aug 2009 10:45:12 -0400

No hat.

> There is really nothing new in RSA/SHA2.  It's just a code point.

Exactly.  And yet draft-ietf-dnsext-dnssec-rsasha256-00 appeared in
Feb of 2006 and we still don't have a code point, because getting a
code point is a heavyweight operation involving a standards action.

> adding a new RR in terms of difficultly.

I note that adding a new RR is even easier now: we do it with expert
review.  Are you arguing for that route instead of RFC required?

Best,

A

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

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 28 Aug 2009 07:46:54 -0700

> 	really?  I'd thought you would want them to get a response that

What you want is for the client itself to go and generate its own  
recursive request...

Seriously.  There is no point in relying on the recursive resolver for  
validation.  Validation at the recursive resolver level adds mostly  
illusionary security.

The real point of someone deploying DNSSEC as an authority and on the  
end host is because they don't trust the recursive resolvers.  And  
well they shouldn't: the recursive resolvers themselves have proven  
untrustworthy: between nxdomain wildcarding for ANYTHING.mydomain, to  
MitMing Google (yes, at least one ISP does this using DNS), etc etc  
etc...

All this talk about recursive resolver validation strikes me as,  
frankly, silly:  Your asking the most proven-untrustworthy component,  
and the major component thats not in-path for final data, to do your  
cryptography and just trust the results?  WTF?

Also, it really depends on WHAT is being validated, what the policy  
should be, and that policy can only be determined at the stub resolver.

If its a name->IP mapping, who cares if the signature fails, if the  
stub resolver did its own iterative lookup rather than using an  
external recursive resolver?

This means the attack path for DNS to be basically the attack path for  
the final protocol, so you become dependent on the security for the  
final protocol, rather than final protocol + recursive resolver.

If its a name->keydata mapping (DNSSEC as an alternative PKI), the end  
application/library needs to do the signature validation and then  
perform some application-dependent behavior on failure.

In neither case should the recursive resolver really do anything but  
pass data unchanged!

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 28 Aug 2009 11:29:12 -0400

On Fri, Aug 28, 2009 at 10:12:04AM -0400, Andrew Sullivan wrote:

> supported everywhere is supposed to be a feature.

That should read, of course, "…without the new algorithm…" Apologies
for the confusion.

A

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

---

From: Mark Andrews <[email-masked]>
Date: Sat, 29 Aug 2009 08:07:03 +1000

> review.  Are you arguing for that route instead of RFC required?

	No.  You were complaining about the lack of interop testing
	due to there being no code point.  I believe none of the
	vendors are particularly worried about this because there
	is nothing *new* with rsasha256.  We don't have vendors
	interop test new rdata at the DNS level before deploying.
	This is all the interop testing of rsasha256 would be.

	Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 31 Aug 2009 14:21:03 -0400

On Sat, Aug 29, 2009 at 08:07:03AM +1000, Mark Andrews wrote:
> 	due to there being no code point.

If I left that impression, I apologise.  That wasn't what I was
complaining about.  I was complaining that even uncontroversial code
point additions, like SHA 256, take a very long time because the
entire IETF WG consensus machinery comes into play.  We need a lot of
review, there's a tendency for side issues to get explored, and so on.

If we had a lighter weight procedure, it wouldn't be so costly and it
might therefore happen faster.

A

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Sep 2009 10:55:18 +1000

> might therefore happen faster.

SHA256 was special because we had to teach the working group that
new signature algorithms need to support both NSEC and NSEC3.  SHA256
should not be seen as representative of the time it will take in
future.

DNSEXT goes from one extreme to the other.  RR allocation was a
example of that.  New procedures were defined and people complained
that RR's take too long without even trying the new procedures.

I don't think we need new procedures for DNSSEC algorithm assignments.
Nobody has really demonstrated that there is a problem with the
current procedure.  DNSSEC is too new operationaly to have any
evidence that there is a problem.  Things are always slower when
they are new.

Mark