Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt

Paul,

There is a subtle point that may be helpful to recall.  The primary purpose of advertisement of which algorithms are understood by the resolver is to provide a measure of the adoption of new algorithms.  In the broad, slow cycle of introduction of new algorithms and the presumed phasing out of old algorithms, operators on the signing side of the equation will be choosing when to sign with a new algorithm and when to stop signing with an old algorithm.  They can sign with a new algorithm whenever they feel ready to do so, but they cannot rationally stop signing with the old algorithm until they have evidence that essentially all of the resolvers understand the new algorithm.  Thus, as I said, the primary purpose of this protocol extension is to provide measurable assessment of the uptake of a new algorithm.  From this perspective, the order of the algorithms within the resolver's advertisement is irrelevant.

Subordinate to this primary purpose is the potential for also advertising a preference.  Whether the responding system pays attention to the order is up to the responding system.  Also, as you suggest, the querying system may or may not have a real preference.  I don't think we have enough information to say one way or the other, and the perfect is the enemy of the good.  Let's move this forward and revisit your concern when there is some implementation and deployment experience to examine.  I hope is that this is the worst issue we will have to deal with.

Steve

On Jul 17, 2012, at 12:23 PM, Paul Hoffman wrote:

> On Jul 17, 2012, at 6:00 AM, Patrik Fältström wrote:
> 
>> As this was announced on June 14, 2012, and Scott Rose immediately followed up with an announcement (http://www.ietf.org/mail-archive/web/dnsext/current/msg12514.html) and there have been exactly zero comments I am a bit shy of declaring victory.
>> 
>> Can I get please at least three people that have seen this version, read it, and support it moving forward (part from myself and the authors of the document?
> 
> I have read the document and think it may be ready for IETF review, but it also might not. Section 3 still says:
>   The
>   validating end-system resolver sets the value(s) in the order of
>   preference, with the most preferred algorithm(s) first as described
>   in section 2.
> It does not say how a resolver choses the order of preference, probably because they have no frigging idea how to measure that. How can one express a preference between RSA and ECDSA, for example, without knowing the RSA key length? Worse, how can you even have a preference when what you really have is a list of algorithms that you fully accept and a list that you fully reject?
> 
> My preference remains the same: get rid of this ordering, stop pretending that people who run resolvers care about this as much as security geeks do, and stop suggesting to people that they should care about something they do not understand. But if the WG wants to leave this in, no significant harm will be done.
> 
> --Paul Hoffman
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext