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(_dot_)shore(_at_)gmail(_dot_)com>
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