Re: [Cfrg] Proposed Informational Note: Security Guidelines for Cryptographic Algorithms in the W3C Web Cryptography API

[Harry Halpin <[e-mail]>]

On 11/20/2014 07:09 PM, Watson Ladd wrote:
> On Nov 20, 2014 9:49 AM, "Yaron Sheffer" <[e-mail]> wrote:
>>
>> Hi Harry,
>>
>> The draft makes for fascinating reading for CFRG folks, as can be seen by
> the mailing list discussion. But I think it does not make any sense to
> "developers" (programmers who typically have next to no understanding of
> crypto, and certainly none at all of formal security models/proofs). They
> simply would not understand 90% of the text.

Agreed. However, we do hope they look at the table that has simple
"YES/NO" recommendations when choosing algorithms. We also need to keep
that table reasonably up to date in the future.

We initially thought we should keep such a table in the spec, but the
editor and others rightfully noted that this advice belongs somewhere
else as spec will stabilize and should focus on JS-specific concerns,
not keeping up with the crypto research landscape (which seems more CFRG
territory).

> 
>>
>> So it may be fine as a rationale for the selected list of algorithms. It
> may be fine for a few star crypto developers. But IMHO, not for the general
> population of people who'll be coding to your API.
> 
> Should people who don't know anything about cryptography write code that
> uses it? We've already mentioned that protocol design is hard, but that
> will force a lot of other choices, so it's not clear what is actually
> addressed by these recommendations.

We try to address this in the "introduction", encouraging people not to
write new protocols. What is addressed is algorithms that we should
encourage for future use. For example, many web developers may just want
a "hash" and thus default to SHA-1 unless we tell them otherwise.

> 
> Unlike TLS this is not about properly configuring an implementation.  It's
> a case where the developers have unbounded creativity, and so can mess it
> up in unexpected ways, which no list of negative commandments can cover.
> 
> The right approach is to design misuse resistant primitives on top of the
> ones in Webcrypto, and tell programmers to use them.

That is also a separable and equally difficult problem the WebCrypto WG
discussed. Instead, we released a "kitchen sink" approach of low-level
primitives and are hoping "the market" produces some good easy-to-use JS
libraries. If that doesn't happen in short order, I'm sure the W3C would
be interested in helping, and we'd want CFRG's advice in that matter as
well.

   cheers,
       hary

> 
> Sincerely,
> Watson Ladd
> 
>>
>> I am a co-author of the TLS BCP (
> http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-06). It certainly has its
> share of flaws, but what we did right is to clearly mark recommendations
> vs. rationale, and to simplify recommendations as much as we could.
>>
>> Thanks,
>>         Yaron
>>
>>
>>
>>>
>>> Everyone,
>>>
>>> As the W3C Web Cryptography API gets ready to move to Candidate
>>> Recommendation, we wanted to address the concerns brought up by Rich
>>> Salz and others for better security guidelines for developers, given
>>> that the API exposes a variety of algorithms. I've taken Graham Steel's
>>> excellent write-up, which is in a large part based on Smart et al.'s
>>> magisterial ENISA report,  and have turned it into a draft CFRG note.
>>>
>>> We'd like to see the security guidelines below discussed here, and if
>>> there's no objections after discussion, move this onwards. W3C commits
>>> to maintaining this note as much as possible.
>>>
>>> Links to draft:
>>>
>>> TXT:
>>>
> http://www.w3.org/2012/webcrypto/draft-irtf-cfrg-webcrypto-algorithms-00.txt
>>> HTML:
>>>
> http://www.w3.org/2012/webcrypto/draft-irtf-cfrg-webcrypto-algorithms-00.html
>>>
>>> cheers,
>>>      harry
>>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/cfrg
> 
> 
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>