On Wed, 21 Jan 2015, David Conrad wrote:
Thanks very much for this note. The issue of the ZSK length is something that
has popped up on various radars on various occasions and given the recent
publicity over at imperialviolet and sockpuppet on 1024 bit RSA, it'd be good
to explore this in more detail to see what level of nightmare we'd be
inflicting upon ourselves (if any).
I think it was a bigger problem when the root was signed at first.
In other words, which ever clients cannot handle a root ZSK of 2048
already has a severe problem with DNS. I don't think we would be adding
much of a problem by just switching to 2048 today.
While I tend to agree, this assumes the clients would notice, which obviously
depends on the names being looked up. Do you have any idea of (say) the
popularity of the names behind large RRsets (e.g., their Alexa ranking or
something similar)?
No, I don't. Someone at a big caching server would be in a much better
position to get that data.
Of course, once you believe we can do a ZSK of 2048, there is no urgency
to move to ECDSA and we can wait on the CRFG to come up with a non-DSA
ECC algorithm for us.
Yep. I'd really like to go to ECDSA, but it doesn't look like there is enough
support out there for it (at least for root purposes).
Some people would like to skip ECDSA for a more modern ECC variant.
I guess a larger question is "do we care?". I'll be honest and say I'm
increasingly concerned that broken middleware-driven ossification is getting in the way
of fixing serious problems.
And those middle boxes already have a fallback - don't query with DO.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
