Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

[Stephane Bortzmeyer <[e-mail]>]

On Tue, Jul 04, 2017 at 11:42:56AM -0400,
 Shumon Huque <[e-mail]> wrote 
 a message of 108 lines which said:

> We've posted a new draft on algorithm negotiation which we're hoping to
> discuss at IETF99

For the discussion on thursday:

> In contrast, many other security protocols, like TLS, IKE, SSH and
> others, support an algorithm or cipher suite negotiation mechanism

TLS and SSH are end-to-end. Not the DNS, and it makes things more
complicated (see section 6).

> because fragments are often blocked by network security devices.

by STUPID AND BROKEN network security devices. Otherwise, you do not
put the blame where it belongs.

> As can be readily seen from the RSA to ECDSA transition, very few
> zones have transitioned from RSA to ECDSA,

True, but not for the reasons of the response size. Both for my
employer's zones and for my own personal zones, the big issue is the
lack of support in tools like HSMs, the difficulty of algorithm
rollover, and the fact that tools like OpenDNSSEC don't make it
easy. So, we have apparently a disagreement on the basic diagnostic.

> the resolver has selectively cached signatures of a subset of
> algorithms supported by the zon

How does it know? I mean, in the response from the authoritative
server, nothing indicates if the signatures are a subset or
not. Suppose I send the list ECDSA;RSA, and I receive only ECDSA
signatures. How the resolver/cache would now if it was a complete
list?

> but prefers algorithms known to be supported for the name,

Again, where does this knowledge come from?