[Bug 25607] Need to advise authors about security considerations

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607

--- Comment #24 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Rich Salz from comment #23)
> If there's too much technical detail it will go over the heads of those who
> most need guidance.  If you want such detail, see the link in comment 9.

Well, this doesn't really set out who your target audience is for this, which
is one of the criteria we'd need to actually, objectively, keep this up to
date.

> 
> As for avoiding a 'living spec' kind of thing, that's the problem with
> security: it's all about trade-offs.  You can have a document for the ages
> that will never be wrong, but if absent advice of the moment can lead people
> astray. If that's what the WG wants, so be it. Others (see comment 7 for
> example) would disagree.
> 
> As for the criteria of which algorithms get marked and which don't: I based
> it on the advice of Paterson, Graham, Rogaway, NIST, and similar
> authorities. Backed up by the papers listed in the would-be security
> references section. If the WG wants to make more conservative choices, more
> power to them.

This again has problems. It lacks an objective criteria, other than "It's what
would satisfy Rich's formal objection", which seems a very unfortunate state,
for many reasons. All of the issues I mentioned have similar papers from
similarly respected cryptographers, or which have similar nuance and caveats to
the papers you referenced (which is not captured in the proposed language).
This isn't about making "more conservative" choices - a statement which itself
implies that there is a some criteria that you believe is neither
"conservative" nor "liberal" - it's about trying to establish a set of
objective criteria.

Without such criteria, I fear that every proposed algorithm would have to pass
the "Rich Salz" test, which I doubt is your goal or intent, so you can see the
benefit in establishing some criteria. I'm happy to dig up citations for you,
but my point was to show that everything is with caveats, including things that
are "in vogue" (e.g. the discussion of curves with respect to NIST, which
itself has respected cryptographers on either side arguing about the relative
security merits of the selected parameters)

If we don't have some way to cut this gordian knot of security considerations,
we run the risk of being steered by the whim of every contributor, which is why
I'm so adamant on the need to establish some criteria, and for proposals of
language to have some criteria for which the proposals can be measured against,
and for which the criteria - rather than the language - can be discussed on its
merits.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 1 July 2014 03:32:46 UTC