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

From: Yaron Sheffer <[email-masked]>
Date: Thu, 20 Nov 2014 19:48:45 +0200

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.

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.

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
>

---

From: Watson Ladd <[email-masked]>
Date: Thu, 20 Nov 2014 10:09:11 -0800

On Nov 20, 2014 9:49 AM, "Yaron Sheffer" <[email-masked]> 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.

> 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.

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.

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.
>>
>> cheers,
>>      harry
>>
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: Harry Halpin <[email-masked]>
Date: Thu, 20 Nov 2014 19:17:40 +0100

> 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).

> 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.

> 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

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 20 Nov 2014 20:20:28 +0200

On 11/20/2014 08:09 PM, Watson Ladd wrote:
>
> On Nov 20, 2014 9:49 AM, "Yaron Sheffer" <[email-masked]
> <mailto:[email-masked]>> 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.
>
>  >
>  > 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
> 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.
>
> Sincerely,
> Watson Ladd
>

I mostly agree with you, but this document was introduced to the group 
as "better security guidelines for developers". I'm afraid it is not.

Thanks,
	Yaron

---

From: Harry Halpin <[email-masked]>
Date: Thu, 20 Nov 2014 19:30:56 +0100

> recommendations vs. rationale, and to simplify recommendations as much

Yaron,

For developers, I imagine the important part will be the table, so we
want extra eyes on that.

We of course cannot fit in a course in cryptography and protocol design
in an informational document, but we do need to cite the right sources.
We're also looking for important attacks and proofs we may have missed.

I do agree some kind of "warning, possible hard to understand
justifications" before we go into per-algorithm justifications, so
developers are warned. However, if you have any way to justify or
simplify any of the justifications or the more developer-facing table,
we'd be very appreciative.

However, I would note the first few uses of Web Crypto did use AES-CBC
with RSAES-PKCS1-v1_5  :)

   cheers,
      harry