Melinda, On 01/02/2014 03:39 AM, Melinda Shore wrote: > On 1/1/14 6:11 PM, Ted Lemon wrote: >> On Jan 1, 2014, at 6:07 PM, Melinda Shore <melinda.shore@xxxxxxxxx> >> wrote: >>> I'm sorry, but when we get to the point where we need to point to >>> an RFC to stop progress on a document that has obvious >>> vulnerabilities, our brains have fallen out. >> >> This is counterfactual. We used to routinely handwave about >> security. > > We still routinely handwave about security. It's an afterthought > in entirely too many cases. Drafts are adopted by working groups > while still having security considerations sections that consist > in their entirety of "TBD." 3552's impacts have been, I think, > on how documents are reviewed more than on how documents are > developed. Agreed. > > One of the reasons I'm somewhat annoyed about the wave of > gasbaggery and pontification that has followed truly disturbing > revelations about the extent to which the US government has > undermined privacy and compromised security technologies is > that work which might have helped provide tools to mitigate > some of the soft spots in IETF work has been backburnered in > favor of no small amount of unfocused grandiosity that doesn't > actually change much. I think the above is gasbaggery and, to me at least, quite annoying. I should update [1] but its a list of what's being done that was up to date in mid Nov. [1] https://down.dsg.cs.tcd.ie/misc/perpass.txt Feel free to join in those discussions some more. > At any rate this draft is not RFC3552. 3552 provides very specific > guidelines for what needs to be considered in > writing^H^H^H^H^H^H^H^Hreviewing security considerations. When'd you last re-read 3552? Is has all sorts of MUSTs that we routinely do not and should not force draft authors to conform to, for example: Authors of internet standards MUST describe which denial of service attacks their protocol is susceptible to. This description MUST include the reasons it was either unreasonable or out of scope to attempt to avoid these denial of service attacks. Is that still reasonable? I think not, there are too many DoS vectors in the world now. The non-normative parts of 3552 are very good though, but I think many of the normative instructions are outdated. That BCP would have been better with far fewer or no references to 2119 IMO. And so with this one - stating only the high level requirement is the right thing to do for now. Leaving the high-level requirement unstated would mean that a lot of IETF work in the coming years would not address this attack. > It is tempting to just let this through last call in hopes that > once it's done we can come back around to prioritizing work like > fixing PKI but I'd be very sorry indeed to see this published as a > BCP. "Fixing" PKI is neither terribly relevant here nor being ignored. For TEMPORA PKI seems mostly irrelevant. For QUANTUMINSERT et al some of the active attacks do depend on problems with the Web PKI but I'd guess mixed-content is much more important in terms of successful attacks than are PKI abuses, for now at least. On the latter point, there is a wpkops WG that could do with more help. We have also started discussion about chartering a CT WG. And the uta WG might make some recommendations about TLS that help there too. And the httpbis WG have seriously debated TLS for HTTP/2.0 (that debate's not over but is real). If you have other ideas for "fixing" PKI then I'd be glad to hear about them and to try help make 'em happen, as appropriate. On the whole I think your criticism is, to use your words, gasbaggery and annoying. And wrong. S. > > Melinda > >