Simon, thanks for all the comments, I have now culled all the context usage from the draft and the git version should be up to date and ready for -2 upload.
Cheers, Ondrej -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: "Simon Josefsson" <si...@josefsson.org> > To: "Daniel Migault" <daniel.miga...@ericsson.com> > Cc: "curdle" <cur...@ietf.org>, "dnsop" <dnsop@ietf.org> > Sent: Thursday, 3 November, 2016 22:01:38 > Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 > Daniel Migault <daniel.miga...@ericsson.com> writes: > >> Hi, >> >> This message starts a Working Group Last Call (WGLC) for >> draft-ietf-curdle-dnskey-eddsa-01. >> >> The version to be reviewed is >> https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 > > Hello again. Since my last review of -01, I have re-read the document > again, and noticed the text regarding signature contexts. I believe the > use of contexts is in general ill-advised, and its presence in the > document highlights a need for a security consideration to address the > problem that context attempts to mitigate but does not succeed with: > don't re-use private keys for other purposes. If this best practice > advice is followed, contexts is unwanted complexity instead of something > good. If a private key is used for other purposes, contexts won't save > you -- DJB explained this on the CFRG list some time ago in a way that > convinced me. > > Thus, allow me to suggest that > > 1) The draft is modified to not use signature contexts. > > 2) The security consideration has a new paragraph that reads: > > A private key used for a DNSSEC zone MUST NOT be used for any other > purpose than for that zone. Otherwise cross-protocol or > cross-application attacks are possible. > > Perhaps this text is better suited in the Introduction section, but it > bears repeating in the security consideration anyway. > > /Simon > > _______________________________________________ > Curdle mailing list > cur...@ietf.org > https://www.ietf.org/mailman/listinfo/curdle _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
