Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 28 Aug 2009 14:38:58 -0500 (GMT-05:00)

Andrew and all,

  Good points here IMO.  As such it would seem logical to me that a
decision has to be made as to whether or not interoperation is more
important than supported algo's.  I would say it is, for what that's worth.
Some or perhaps many would disagree and for some good reasons as well.

  So this to me anyway leaves the question as to what algo's are going to
be supported and by whom when?  NIST isn't god almighty for sure, and
neither is the IETF for that matter.  But it would be my preference and I
believe eventually mosts preference that as many algo's be supported
as possible, documented fully or not.  Otherwise multipul DNS'es will
become prevalent and as such somewhat defeat the larger purpose of
DNSSEC.

-----Original Message-----
>From: Andrew Sullivan <[email-masked]>
>Sent: Aug 28, 2009 9:12 AM
>To: [email-masked]
>Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for	DNSSEC
>
>No hat.
>
>On Fri, Aug 28, 2009 at 10:25:03AM +0200, Patrik Fältström wrote:
>>
>> 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.
>
>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.
>
Regards,

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

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

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

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 28 Aug 2009 16:45:23 -0400

> become prevalent and as such somewhat defeat the larger purpose of

Somehow, there are two control points: the IANA function for those 
algorithm identifiers and the DNS root zone management for support at 
the root. You infer from Andrew's interesting perspective that entry 
barriers at the IANA function would trigger alternate roots (i.e. bypass 
the DNS root zone management control point). My point is that if you 
lower the criteria at the IANA control point, you may get even more 
pressure at the DNS root zone management (algorithm XYZ is used in 15 
TLDs and thus should be included in the root, otherwise we are 
legitimized to run a parallel DNS root).

Why not just making it easier to get standards-track IETF RFCs for those 
digital signature schemes that deserve it? Are you IETF'ers so uncertain 
about the effectiveness potential of IETF processes that you run? The 
basic mission of the IETF is to come up with high quality specification 
documents. It should not be unrealistic to expect quality in the digital 
signature schemes adopted for use in portions of the DNS hierarchy, 
given that every resolver operators are interested in seamless operations.

The unique centralized nature of the Internet DNS command this level of 
IETF dedication, as I understand it.

- Thierry, i.e. just me!