On Wed, Jul 5, 2017 at 1:12 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> On Wed, Jul 05, 2017 at 05:30:49PM +0100, Jim Reid wrote: > > > 3) Something should be said about algorithm agility. We can be reasonably > > sure web browsers, DNS servers, smart phones and so on will generally > have > > up-to-date DNSSEC validators and/or TLS code. Some TLS clients -- fire > > and forget embedded systems, IoT devices, etc -- might never get updated > > once they're deployed. If these clients use their own DNSSEC validators, > > they will be screwed when/if DNSSEC drops SHA1 signatures (say) or adds > > a new flavour of ECC or even an all-new signing protocol. > > SHA2 is already defined and widely used for DS records. The X25519 > and X448 EC algorithms are already defined (or will be by the time > this draft becomes an RFC). RFC 8080, defining Ed25519 and Ed448 for DNSSEC, is already published. There are already some early implementations (PowerDNS and NLnet Labs' Unbound; maybe others). > So there's not much churn on the > immediate horizon. Devices doing all the validation locally will > need software updates roughly once a decade (DNS parameters change > slowly). A secure channel to a *trusted* resolver would avoid the > problem, but trustworthy off-device resolvers are very unlikely to > be ubiquitous. > Regarding churn, I expect we'll have several post quantum signature algorithms for DNSSEC in the 5 to 10 year horizon. -- Shumon Huque
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
