Subject: Reviving RSA/SHA256

From: Jelte Jansen <[email-masked]>
Date: Tue, 11 Sep 2007 20:53:13 +0200

Hi,

last year I wrote an I-D describing a way to use RSA/SHA256 DNSKEYs and
RRSIGS for DNSSEC. The group consensus was that it wasn't needed at the
time and the draft expired.

Today I have been asked to revive it, since people are phasing out
SHA-1, and I am willing to do that. So I have a few questions for the group;

Do descriptions of new algorithms fit the new charter of DNSEXT?

And if so, is the group willing to take up work on this?

If so, I'll submit it again and we can start discussing some of the
finer points of the draft.

Jelte Jansen
NLnet Labs

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Scott Rose <[email-masked]>
Date: Tue, 11 Sep 2007 15:13:15 -0400

Jelte Jansen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Hi,
> 

To add to this - I'm one of the folks looking to revive the draft. 
There is a push to migrate from the use of SHA-1 in some crypto usages* 
to the use of SHA-256 by 2010.  Since RSA/SHA-1 is the only mandatory to 
implement algorithm for RRSIGs, and no SHA-256 option, this makes 
deployment difficult in the .gov TLD.

I'm willing to work with Jelte to get the draft moving.

Scott

*I'm no crypto expert, but I've been told by those that are that TSIG 
using HMAC-SHA1 is still fine beyond 2010, but use of SHA-1 to generate 
RRSIGs and NSEC3 hashed names might be a problem.

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Tue, 11 Sep 2007 15:51:32 -0400

>Do descriptions of new algorithms fit the new charter of DNSEXT?

depends on how you read the charter :-)
Yes, this is fine as this is a straight forward specification needed to keep
up with the times.

NO, because this is new work causing interoperabilty issues.

>And if so, is the group willing to take up work on this?

This proposed work needs to pass one of the following thresholds:
#1 Sufficient number WG members say this is important and needed
#2 Security Area Director(s) tells us this is going to be needed soon
         thus we need to specify now in order for code to be deployed.

>finer points of the draft.
Expired version:
http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-rsasha256-01
         Olafur

---

From: [email-masked]
Date: Wed, 12 Sep 2007 00:13:48 +0200

> Do descriptions of new algorithms fit the new charter of DNSEXT?

I guess it fits, but in any case, I think it is good to revive this draft. 

> And if so, is the group willing to take up work on this?

You have my vote.

> finer points of the draft.

Bring it on :-)

Roy

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 12 Sep 2007 10:02:18 +0200

Hello Olafur,

Allow me to turn 'pain in the butt' :-)

> NO, because this is new work causing interoperabilty issues.

I do not understand what you mean. DNSSEC-bis has been build with  
protocol agility in mind. There will be operational "interoperability  
issues" in the sense that resolvers need an upgrade to recognize the  
new protocol as secure, but that is not a protocol problem; we knew  
that.

> #1 Sufficient number WG members say this is important and needed
agreed.
For the 'running code part': this message acts as a commitment to  
implement this in the DNSSEC related software that NLnet Labs produces.

>         thus we need to specify now in order for code to be deployed.

Hmmm... I would think that given the time it would take for the new  
implementation to percolate into deployed resolvers the argument one  
would not like to make this a 'last minute' job. Given that there  
seems to be a clear operational requirement (.gov by 2010, --- I  
realize that you may not have seen that when you wrote your response)  
I think the SA thumbs up is not that relevant. Early involvement of  
the SA is off course important but I am not sure if that should be a  
threshold for bringing new work in general and in particular when  
there is a clear requirement from the industry.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Wed, 12 Sep 2007 10:52:05 -0400

Reading this message over I may sound more political than technical but that
is intentional to be facilitate discussions in the working group on an issue
that is not just technical but also tactical.

>Allow me to turn 'pain in the butt' :-)

Et tu, Olaf ;-)

>new protocol as secure, but that is not a protocol problem; we knew

Fair point,
The question more accurately is
          "when do we want this interoperabilty problem ?"
         in the next 2 years or in 5 years ?

>implement this in the DNSSEC related software that NLnet Labs produces.

Good, +1 for adopting this work?

>there is a clear requirement from the industry.

Well the point is:
         when there is sufficient security concern "we need to jump"
         like we did with DS SHA2 specification.

I know there is are groups that want to phase out SHA1 soon, but for the
record they need to speak up. I as chair need backing before trying to
convince AD that this is needed, given that the new WG charter aim is to:
         defend DNS against further enhancements of questionable value.

Speaking as chair the picture I want to present to the world is:
         "DNSSEC specification work has reached an end, deploy!!!"

So the tactical question is:
         will RSA/SHA265 work item cause confusion, i.e. that DNSSEC
         protocol is not done?

We know that RSA/SHA256 is maintenance work but what will the
outside world see?

         Olafur

---

From: Scott Rose <[email-masked]>
Date: Wed, 12 Sep 2007 13:46:43 -0400

>         defend DNS against further enhancements of questionable value.
As mentioned before, the US gov't IT is one of those groups.  The aim is 
to transition from the use of SHA-1 to the use of SHA-256 in all 
protocols.  Seeing the use of SHA-1 with no SHA-256 option give some 
people a reason not to deploy in the .gov domain.

> We know that RSA/SHA256 is maintenance work but what will the
I may be naive, but I'd like to think that most people would recognize 
"working on transition of crypto algorithms" as maintenance work and not 
a sign that DNSSEC is still not fully cooked.  I hope I'm right ;)

Other applications have had to make similar transitions from weaker to 
stronger security features.

Scott

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 12 Sep 2007 14:30:18 -0400

Ha ha!

I suspected that "Who controls the process controls the outcome" was the 
untold motto among some wg chairs.

On a technical perspective, the interoperability question reveal a 
"small" difficulty in having concurrently a mandatory algorithm and an 
optional-and-most-recommended one. Although envisioned early in DNSSEC 
design, such configuration is perhaps not currently well supported in 
resolver software, secure delegation provisioning systems, and the like. 
So, the small difficulty lies in the operational aspects -- i.e. outside 
of dnsext I guess.

My main point is: I don't think Ólafur can control the understanding of 
DNSSEC by "the world". But yes, he might act in ways that delay adoption 
of RSA/SHA256.

Perhaps a better service should be offered to those who whish to advance 
the DNSSEC protocol suite in a direction that was clearly envisioned, 
and now in demand. Please just handle the IETF process smoothly.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 12 Sep 2007 20:48:25 +0200

> Et tu, Olaf ;-)

LOL

(...)

> Good, +1 for adopting this work?

Yep, in fact putting my (or better Lab's) money, where my mouth is,  
to make sure it gets implemented too and is not just a paper exercise.

>         defend DNS against further enhancements of questionable value.

fair enough... in that sense a message from the SA about the value of  
migrating from SHA1 to SHA256 might help to build an argument (either  
way).

> We know that RSA/SHA256 is maintenance work but what will the

I share the concern the perception of the 'outside world'. Seems  
we've need to do our best to explain that this _is_ maintenance work  
that will _need_ to happen one time or another.

--Olaf

---

From: Michael StJohns <[email-masked]>
Date: Wed, 12 Sep 2007 15:04:39 -0400

I have no opinion on whether this work item should be adopted.

But, if this goes forward, I'd like to suggest splitting the DNSSEC algorithm registry into a keytype registry and a signature type registry.  

[>>> I'd also like to suggest redefining the algorithm octet in the RRSIG record into a combination of a hash type and sig type but given the definition currently includes 3 high-number values (252-254) it may not be doable - at least easily.  ]

Instead of requiring specifically SHA256 - suggest instead as requiring the complete SHA2 suite - which includes the complete set of hashes covering 224, 256, 384 and 512 bits.

Also suggest defining at least two EC signature methods as standards at the 224 or 256 levels in this go around as well.  

[Continuing on the idea of splitting the algorithm byte - assign the upper 4 bits as hash type as follows:
  0 - SHA1
  1 - MD5
  2 - SHA224
  3 - SHA256
  4 - SHA384
  5 - SHA512

deprecate alg 1 - RSA/MD5 - replace it with the combined value hash:1/alg (RSA): 5 -> 21
that makes RSA/SHA224 - 37, RSA/256 -> 53,  RSA384-> 69 and RSA/512 ->85, EC/SHA224 -> 36, EC/SHA256 -> 52, and EC/SHA1 is 4 as currently defined
]

At 13:46 9/12/2007, Scott Rose wrote:
>As mentioned before, the US gov't IT is one of those groups.  The aim is to transition from the use of SHA-1 to the use of SHA-256 in all protocols.  Seeing the use of SHA-1 with no SHA-256 option give some people a reason not to deploy in the .gov domain.
>
>I may be naive, but I'd like to think that most people would recognize "working on transition of crypto algorithms" as maintenance work and not a sign that DNSSEC is still not fully cooked.  I hope I'm right ;)
>
>Other applications have had to make similar transitions from weaker to stronger security features.
>
>Scott
>
>>        Olafur
>>
>>--

---

From: [email-masked]
Date: Fri, 14 Sep 2007 14:24:14 +0100

Ólafur Gu*mundsson /DNSEXT chair <[email-masked]> wrote on 11/09/2007 

> >Do descriptions of new algorithms fit the new charter of DNSEXT?

I hope so.

> >And if so, is the group willing to take up work on this?

Working on this has my support.

> #1 Sufficient number WG members say this is important and needed

I do.

BTW - I agree with Michael StJohns that we should consider requiring the 
whole SHA2 suite.

John

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Mon, 24 Sep 2007 10:01:47 -0400

Dear Colleagues

So far I have counted in support:
Jelte Jansen (ed.), Olaf Kolkman, Scott Rose, Roy Arends, John Dickinson.

Mike StJohns wants to use this as an opportunity to rationalize
how new hashes are added to existing Signature Algorithms.
Mike also raises the issue of truncated SHA-256 hashes.

Other posters did not express support or argue against adopting
the work, are there others that have an opinion on the adoption of
this work please speak up before Oct 1'st 2007.

         Olafur

---

From: Edward Lewis <[email-masked]>
Date: Mon, 24 Sep 2007 11:18:23 -0400

>this work please speak up before Oct 1'st 2007.

Ok, I'll ask...but I don't have an opinion (yet).

>         in the next 2 years or in 5 years ?

What are the "interoperability issues"/"this 
interoperability problem"?  Why was this bounced 
before (please don't respond with a "go look at 
the archives" - the archives aren't very user 
friendly).

My presumption is that there's no problem 
defining the new algorithm as an individual 
document, I don't understand the issue upon which 
I should form an opinion.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

---

From: Doug Barton <[email-masked]>
Date: Mon, 24 Sep 2007 11:20:56 -0700 (PDT)

> Jelte Jansen (ed.), Olaf Kolkman, Scott Rose, Roy Arends, John Dickinson.

Add one more vote. I said (speaking only for myself) several years ago 
that we would be better off getting the pain out of the way sooner (the 
exact words I used were "before DNSSEC is widely adopted," which seemed to 
ruffle feathers at the time) than later, since SHA-1 will probably be 
"broken" in our lifetime, and SHA-256 probably will not. To clarify my 
position further, I think support for SHA-256 should be mandatory.

> Mike also raises the issue of truncated SHA-256 hashes.

I agree with Mike that it would be good to have a more general mechanism 
for adding hashes, etc. I don't think that mandating support for the 
truncated SHA-256 hashes is a good idea, but I'm ambivalent about making 
it optional. My gut feeling is that limiting the problem set to just full 
SHA-256 would be a good way to add functionality without sacrificing 
meaningful flexibility, but I wouldn't argue strenuously against adding 
more hashes.

> this work please speak up before Oct 1'st 2007.

hth,

Doug

- -- 

 	If you're never wrong, you're not trying hard enough

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Mon, 24 Sep 2007 14:47:40 -0400

At 11:18 24/09/2007, Edward Lewis wrote:
>the archives" - the archives aren't very user friendly).
>
>document, I don't understand the issue upon which I should form an opinion.

Sorry for not always being crystal clear in my writing.

One of the issues raised when the chairs asked about adopting this document
(a year and a half ago) was that some members of the WG wanted as few as
possible combinations for algorithm selection while DNSSEC was/is
being rolled out.

Start of thread:
http://psg.com/lists/namedroppers/namedroppers.2006/msg00613.html

Summary of discussion: 
http://psg.com/lists/namedroppers/namedroppers.2006/msg00723.html

It is for the WG members to use their best judgement, how the possible
security or interoperabilty issues affect their support or opposition
to this work item. As a chair all I can to is to point out the
relevant issues that I think they should be aware before answering
the question.

         Olafur

PS: As some conspiracy inclined people think I'm biased ,in this case,
I will only count the opinions that are posted to the list, or
are cc'ed to a neutral third party, any volunteer?

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Mon, 24 Sep 2007 11:00:46 -0400

I support reviving RSA/SHA256. I believe we should also think about extending to an orthogonal specification of the public key algorithm, hash algorithm, and possibly truncation, but I wouldn't do it by splitting the current octet. Perhaps the first octet of the "signature" specifying the hash algorithm.

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ólafur Guðmundsson /DNSEXT chair
Sent: Monday, September 24, 2007 10:02 AM
To: [email-masked]
Subject: Call for consensus: Re: Reviving RSA/SHA256

Dear Colleagues

         Olafur

---

From: [email-masked]
Date: Tue, 25 Sep 2007 09:51:15 +0000

> this work please speak up before Oct 1'st 2007.

	i support this.  Mike has valid concerns tht should be addressed
	but i would do that as other work.

--bill

---

From: [email-masked]
Date: Tue, 25 Sep 2007 17:00:04 +0200

Donald Eastlake wrote on 09/24/2007 05:00:46 PM:

> I support reviving RSA/SHA256. I believe we should also think about 
> extending to an orthogonal specification of the public key algorithm, 
> hash algorithm, and possibly truncation, but I wouldn't do it by 
> splitting the current octet. Perhaps the first octet of the 
> "signature" specifying the hash algorithm.

Specifying the hash algorithm in the signature will cause signed message 
to be downgradeable to unsigned. It is trivial to send the victim a 
signature with a yet unspecified hash type, causing the validator to treat 
the message as unsigned. The validator could treat the message as bogus, 
but that way, we can't gracefully introduce new hash types.

The main thing to keep in mind with DNSKEY algorithm agility is that it 
needs to be verifiable unknown, so that the validator can safely 
downgrade. Hence we could actually specify it somewhere in the dnskey 
record, for instance the "Public Key" field. We have agility back, since 
the DS record digest field contains a hash over the DNSKEY record, and 
we're back to verifiable. 

On the whole, though, this gets very nasty very quick.

It seems that signature algorithms get rolled less than hash-algorithms, 
and with sha2 we seem to be able to run again for a few years. I don't 
think we will run out of space really soon. If we keep the current sig-alg 
and hash binding in place, we only need to use the latest and greatest 
hash function for a new signature scheme. I just can't imagine when we go 
to from RSA to NEW, that we need to specify it with sha1.

Just my thoughts.

Roy

---

From: Douglas Otis <[email-masked]>
Date: Tue, 25 Sep 2007 10:03:36 -0700

On Sep 25, 2007, at 8:00 AM, [email-masked] wrote:
>
> The main thing to keep in mind with DNSKEY algorithm agility is  
> that it needs to be verifiable unknown, so that the validator can  
> safely downgrade. Hence we could actually specify it somewhere in  
> the dnskey record, for instance the "Public Key" field. We have  
> agility back, since the DS record digest field contains a hash over  
> the DNSKEY record, and we're back to verifiable.

Protecting against downgrade attack offers justification to support a  
WG draft that clarifies how a DNSSEC algorithm is to be safely  
upgraded.  This work should not focus only on SHA-256.

One would hope such changes will not become so frequently as to  
justify signature and hash fields now be treated separately.  Such an  
approach may make specification of supported signature and hash  
combinations difficult to determine, and will increases the size of  
responses indicating the supported algorithm.  The current strategy  
keeps overhead to a minimum.

Once the draft protecting against a DNSSEC downgrade attacks is in  
place, then create a draft that details SHA-256 use.  Once the  
downgrade attack draft has been accepted, any draft changing the the  
signature algorithm can focus on just the specifics of the algorithm.

I would support a two draft approach.

-Doug

---

From: Paul Vixie <[email-masked]>
Date: Mon, 24 Sep 2007 15:44:38 +0000

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

> Jelte Jansen (ed.), Olaf Kolkman, Scott Rose, Roy Arends, John Dickinson.

add me.

> Mike also raises the issue of truncated SHA-256 hashes.

opposed.  rationalizing dnssec would make no sense.  we can burn additional
algid's for quite a few years, many of which will have the same signature
alg but a different hash alg as an existing algid, before we run out of
algid's.

---

From: [email-masked]
Date: Tue, 25 Sep 2007 22:59:16 +0200

> I would support a two draft approach.

I don't think we need a 'downgrade attack' draft per se. Maybe we should 
"clarify" algorithm agility, and the concept of "verifiably unknown" 
(apologies for my lack of better wording), in an informational brief.

Though vfy unknown is never specified explicitly in the dnssec drafts, the 
concept is used in both the nsec3 draft and the experiments draft. The 
concept is well known, and is the only way to bypass DNSSEC's "bogus" 
state from the view of older validators encountering newly deployed 
algorithms.

Roy

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Sep 2007 18:12:16 -0400

>state from the view of older validators encountering newly deployed

 From this it sounds like we need quite a bit of documentation on the 
topic.  NSEC3 and the experiments work are by far the least mature 
parts of DNSSEC (given that the mainstream has already appeared in 
three RFC sets, etc.) and I would venture that the fine details are 
well known by those working on NSEC3 and less well studied by those 
(like me) that have not been developing NSEC3.

(I'm not sure if NSEC3/Experiments are the cause of the discussion or 
just happen to be the work that uncovered the issue.)

I am questioning if the "concept" is "well known" in the sense that 
"does a large group of people understand it satisfactorily well" (as 
opposed to a small group of people deeply comprehending it)?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Florian Weimer <[email-masked]>
Date: Wed, 26 Sep 2007 06:39:45 +0200

> time and the draft expired.

I strongly doubt that SHA256 is the final word in the sense that it
will last longer than 2010 or so.  But the RSA/SHA256 revival probably
helps to test *buzz* algorithm agility.

---

From: [email-masked]
Date: Wed, 26 Sep 2007 13:12:30 +0200

> just happen to be the work that uncovered the issue.)

NSEC3/Experiments makes use of the language in RFC 4035 that allows for 
this kind of extendability. 

In a sense, an algorithm upgrade or protocol extention needs to be 
possible without the current deployed infrastructure being unusable. 

> opposed to a small group of people deeply comprehending it)?

Yeah, I was overstating that. What I should have said is that the concept 
is not new. It would be good if something is written about this.

I'll leave it to the WG chair to gain consensus if this is work the WG 
should/wants-to do. 

Roy

---

From: Edward Lewis <[email-masked]>
Date: Wed, 26 Sep 2007 11:37:04 -0400

At 10:01 -0400 9/24/07, Ólafur Guðmundsson /DNSEXT
>Jelte Jansen (ed.), Olaf Kolkman, Scott Rose, Roy Arends, John Dickinson.

I think the work should be (re)written up.  I 
looked at the retired draft and would suggest 
that in somewhere it suggest that if a validator 
is able to make the choice between hashes, it 
chooses the strongest one.  (What if the strong 
fails and the weak fails? - discuss...)

Given that the group is alleged to be moribund, 
this work could be just individual except for the 
face that the WG bounced this before it died. 
Not sure what the ethical answer is here - and 
what does it mean for the WG to now give it a 
go-ahead?

>Mike also raises the issue of truncated SHA-256 hashes.

I'd like to see that written up before passing 
judgement - the hundred flowers sense.

>this work please speak up before Oct 1'st 2007.

From what I gather from crypto experts, crypto 
has a short half-life.  There are going to be 
needs to update crypto stuff well into the 
future.  So, do we keep a  WG on life support for 
this?  Or do we just say "go ahead and build, use 
the IANA registry to record the definitions" as 
the protocol "framework" is done?  Is the right 
answer from the WG's grave to "go forth and 
multiply, tell IANA, we've taken care of all the 
other rules already?"  Or does the WG have to 
process and stamp all of this?

BTW, what's up with the RFC2929bis?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Michael StJohns <[email-masked]>
Date: Wed, 26 Sep 2007 13:29:09 -0400

>Mike also raises the issue of truncated SHA-256 hashes.

Actually, what I suggested was including the complete set of SHA2 hashes - not just SHA256.  I believe that's different from "truncated hashes".  NIST has specified how hash strengths should be paired with key strengths for both RSA and EC.  I'd rather not have to revisit this simply because we want to move from RSA2048 to RSA3072 (or probably more useful - from ECC224 to ECC256 to ECC384)

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Sep 2007 09:35:25 +1000

> At 10:01 -0400 9/24/07, =D3lafur Gu=F0mundsson /DNSEXT
>   chair wrote:
> >Dear Colleagues
> >
> I think the work should be (re)written up.  I=20
> looked at the retired draft and would suggest=20
> that in somewhere it suggest that if a validator=20
> is able to make the choice between hashes, it=20
> chooses the strongest one.  (What if the strong=20

	DNSSEC already answers that.  If any signature matches then
	then the answer validates.
 
> Given that the group is alleged to be moribund,=20
> this work could be just individual except for the=20
> face that the WG bounced this before it died.=20
> Not sure what the ethical answer is here - and=20
> what does it mean for the WG to now give it a=20
> go-ahead?
> 
> I'd like to see that written up before passing=20
> =46rom what I gather from crypto experts, crypto=20
> has a short half-life.  There are going to be=20
> needs to update crypto stuff well into the=20
> future.  So, do we keep a  WG on life support for=20
> this?  Or do we just say "go ahead and build, use=20
> the IANA registry to record the definitions" as=20
> the protocol "framework" is done?  Is the right=20
> answer from the WG's grave to "go forth and=20
> multiply, tell IANA, we've taken care of all the=20
> other rules already?"  Or does the WG have to=20
> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 26 Sep 2007 22:21:09 -0400

>	then the answer validates.

But local policy always trumps what "DNSSEC" says.  Perhaps it would 
be good to recommend a local policy (or new default policy) that says 
something like "distrust when a higher powered protection says no bt 
a weaker says yes" when defining a higher crypto-bar.

Remember that the policy for "DNSSEC" was written my DNS protocol 
folks, not necessarily by folks with a deep understanding of the 
cryptographic arms race condition of that kind of software.  I'm not 
saying but I'm just saying...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Sep 2007 12:36:27 +1000

> saying but I'm just saying...

	Leave this change to local policy.  We have reasonable default
	rules.  If we recommend a new policy default then everyone has
	to go implement it.

	Add new algorithms is relatively easy compared to adding new
	policy knobs.

	Mark