Subject: Re: Fwd: [dnsext] draft-crocker-dnssec-algo-signal-03 -- more time please!

From: Andrew Sullivan <[email-masked]>
Date: Wed, 2 Sep 2009 12:11:56 -0400

Dear colleagues,

On Thu, Aug 27, 2009 at 06:18:29AM +0200, Patrik Fältström wrote:
>
> - what the impact *really* is on DNSSEC deployment if we have multiple  
> algorithms
> - how an algorithm change is to handled
> - how to handle the selection process of preferred (plural) algorithms  
> (one main, and one secondary that is rolled in or out?)
>
> Given this, we can talk about how to do the wording in documents that  
> talk about how to register/signal algorithms.

If I read this correctly, then either the candidate draft that Paul
Hoffman has offered to the WG, possibly with some additions or
changes, or something with the same topic is a necessary condition for
adopting draft-crocker-dnssec-algo-signal; and if such a document is
adopted and published, then draft-crocker-dnssec-algo-signal would
also be a good idea.  Am I reading correctly?

Best regards,

A

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

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 3 Sep 2009 00:20:03 +0200

> also be a good idea.  Am I reading correctly?

Yes, that was my reading of what people told me (~10 people) after the  
Stockholm meeting. People where nervous that, although it is very good  
to have registration and signalling of algorithms, having those  
mechanisms would increase the number of algorithms to a point which it  
has impact on interoperability (and therefore usability) of DNSSEC.

If I am wrong in my findings, or if 10 people actively looking me up  
is a too small group to impact the work of this wg (I was suprised  
over such *high* number), let the chairs know.

    Patrik

---

From: Steve Crocker <[email-masked]>
Date: Thu, 3 Sep 2009 01:55:48 -0400

Patrik,

Thanks for taking on this task.  I am a bit confused about what you're  
reporting.  I understand there is controversy about whether the WG  
should be more or less permissive in the admission of new algorithms,  
but our proposal is neutral with respect to that issue.  We propose to  
include signalling in the query in order to facilitate the phase out  
of old algorithms when newer ones are being fielded.

It some are arguing that the very existence of the signalling  
mechanism may open the door to too many algorithms, I want to push  
back vigorously.  We did not create this proposal in order to  
facilitate the adoption of more algorithms.  At least some new  
algorithms are clearly coming, e.g. SHA256 and ECC, so there's no  
question that we will face one or more transitions.  If there is to be  
a linkage between our proposal and Paul Hoffman's, it should be in the  
other direction.  Our proposal should be adopted in all cases.  His  
proposal should not be adopted unless ours is too.

The only detail that might be affected by future policy is how many  
algorithm identifiers to anticipate.  I believe we can signal which of  
256 different algorithms are known to the requester.  If this is  
insufficient, then the field that encodes that subset needs to be  
adjusted.  But I sincerely hope we're not going to come anywhere close  
to that number in the foreseeable future.

So, can you clarify if you really did get input that tended to push  
against our proposal because it might be seen as permissive toward  
admitting new algorithms?

Thanks,

Steve

On Sep 2, 2009, at 6:20 PM, Patrik Fältström wrote:

> Yes, that was my reading of what people told me (~10 people) after  
> the Stockholm meeting. People where nervous that, although it is  
> very good to have registration and signalling of algorithms, having  
> those mechanisms would increase the number of algorithms to a point  
> which it has impact on interoperability (and therefore usability) of  
> DNSSEC.
>

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 3 Sep 2009 11:06:57 +0200

On 3 sep 2009, at 07.55, Steve Crocker wrote:

> Thanks for taking on this task.  I am a bit confused about what  
> you're reporting.  I understand there is controversy about whether  
> the WG should be more or less permissive in the admission of new  
> algorithms, but our proposal is neutral with respect to that issue.   
> We propose to include signalling in the query in order to facilitate  
> the phase out of old algorithms when newer ones are being fielded.
>
> question that we will face one or more transitions.  If there is to  
> be a linkage between our proposal and Paul Hoffman's, it should be  
> in the other direction.  Our proposal should be adopted in all  
> cases.  His proposal should not be adopted unless ours is too.
>
> algorithm identifiers to anticipate.  I believe we can signal which  
> of 256 different algorithms are known to the requester.  If this is  
> adjusted.  But I sincerely hope we're not going to come anywhere  
> close to that number in the foreseeable future.
>

Well, I do not want to use the wording "push back", more that people  
very much wanted more clear text about the fact one such registration  
mechanism (that is good) is NOT opening the flood gates. Having a  
registration mechanism does of course not by itself imply any changes  
in how easy or hard it is to start using a new algorithm.

So, my feeling was that people to feel more comfortable would like to  
see a companion document that clarify this thing, and looks at  
"interoperability issues with multiple encryption algorithms".

They where not against your document per se.

More clear?

    Patrik