Re: Anyone at Cryptography Forum Research Group at IETF 86?

Harry,

What you refer to as "broken crypto" is *not* a universal. For example, MD5
hashing is problematic, but HMAC-MD5 is not (though not recommended, its
hardly "broken").

Likewise, modes like AES-CBC by itself is problematic, but when combined
with a MAC (and when properly using encrypt-then-mac), CAN be used securely.

These are just two examples of the many, many nuances that we *SHOULD NOT*
be specifying. Nor is it reasonable, I think, to insist that we hold
publication until such a time as another group takes on that Sisyphean
task. Further, I would even go as far as to suggest that doing so, in this
API (directly or even as an informational reference) would be *actively
harmful* to the development community, as it would be seen as an
endorsement for the design of new cryptographic protocols by unskilled
cryptographers.

This API *must* support the use case of allowing existing protocols to be
implemented, and flexible enough to allow implementations of new protocols
like JOSE, but we must not pretend like we are encouraging a free for all
or naively trying to suggest that if you just knew X and Y, you could
design some new and arbitrary protocol and have it be secure. This is
exactly the message I feel your proposal will send, because it will be by
definition incomplete, which is why I continue to object to making this a
requirement.
On Mar 15, 2013 1:10 PM, "Harry Halpin" <hhalpin@w3.org> wrote:

> On 03/15/2013 06:06 PM, Ryan Sleevi wrote:
>
>> On Fri, Mar 15, 2013 at 10:02 AM, Harry Halpin <hhalpin@w3.org> wrote:
>>
>>> On 03/15/2013 05:52 PM, Ryan Sleevi wrote:
>>>
>>>> David,
>>>>
>>>> I understand you weren't able to make it to the Security Area Activity
>>>> Group (SAAG) meeting at this past IETF 86 in Orlando, where I gave a
>>>> presentation on the W3C Web Crypto API -
>>>> https://datatracker.ietf.org/**meeting/86/agenda/saag/<https://datatracker.ietf.org/meeting/86/agenda/saag/>. The minutes for
>>>> SAAG are not up yet, but this will include copies of the presentation
>>>> given, which discusses the present API, the problems it presently
>>>> tries to solve, and some of the concerns and non-concerns with the
>>>> API, as well as active points of discussion within the WG.
>>>>
>>>> Harry's point of including security considerations on a per-algorithm
>>>> level is, respectfully, not one I agree with. While I am certainly
>>>> passionate for better security, I think that the set of API security
>>>> considerations, which this group is tasked with delivering, are very,
>>>> very distinct from a set of algorithm considerations. Further, in my
>>>> experience, it has never been sufficient to simply understand
>>>> individual algorithm considerations, but it must be examined how the
>>>> overall protocol works and combines algorithms, and the assumptions
>>>> made and attacks anticipated. This is why I view Harry's request as
>>>> not being a reasonable request - there are too many combinations and
>>>> protocols that may be used, and their security only comes from
>>>> understanding the overall goals of the system. The expectation that
>>>> including individual considerations leads to better code is, in
>>>> practical terms, not realistic.
>>>>
>>>
>>> Note that I am not asking for a complete security guide - that's
>>> obviously
>>> unreasonable. However, I also think it's equally unreasonable to
>>> hand-wave
>>> about security concerns without giving users of the API a place to even
>>> go
>>> to for answering their questions about security concerns.. Giving WebApp
>>> developers the right set of links to learn more is useful and a service
>>> to
>>> the vast majority of web app developers who may want to use crypto.
>>>
>>> The official CFRG review said "please don't ship broken crypto." I agree
>>> with Ryan that determining security considerations on a per algorithm
>>> basis
>>> is both 1) complex and 2) out of scope for the Web Crypto WG. However, if
>>> another group like CFRG wished to tackle this, I think it would be good
>>> to
>>> point to such a CFRG document. While sometimes things are complex,
>>> sometimes
>>> (ala hashing functions MD5,SHA-1, not rocket science) they are not. The
>>> feedback from CFRG already went into in the algorithms available in the
>>> API,
>>> but that was not a public and maintained document.
>>>
>>> Again, Ryan - please do not mix this up - I am *not* asking for the
>>> security
>>> considerations to be done in the Web Crypto Spec.  Security
>>> considerations
>>> should *not* be done in the Web Crypto API document itself.
>>>
>> Respectfully, I disagree. Our spec MUST deliver security
>> considerations - but of the API.
>>
>
> That is a separate topic from the per-algorithm considerations, but yes,
> if someone feels they can draft that adequately, I'm sure no-one in the WG
> would disagree with having something included about algorithm
> considerations.
>
>>
>> Security considerations about algorithms should not be in the spec, I
>> think we both agree. However, I think normatively referencing other
>> documents is a bad idea, because there is no comprehensive set. It
>> would be as if WebGL attempted to normatively reference performance
>> guidelines for 3D operations, or the HTML spec for forms attempting to
>> describe CSRF.
>>
>
> I was not talking about "normatively" referencing other specs, but
> *informatively*. That was mentioned earlier in email and makes a big
> difference. Right now we say "please look at wider cryptographic
> literature" :)
>
> Normatively referencing something that can change is not a good idea, so
> thus we won't do it. Informatively referencing is in general a good idea
> and relatively easy to do.
>
>
>
>> That is, I view the security of algorithms to be a piece of domain
>> specific knowledge relevant to the development of applications, and
>> NOT an intrinsic property or requirement of the API to deliver or
>> reference.
>>
>
> Again, this is very domain specific but there are well known "broken
> crypto" that our API is supporting as the CFRG noted in their review, and
> thus being clear about this in a link to informative document I think is
> enough to satisfy their review and that relatively common criticism. I hope
> :)
>
>>
>>  Instead, we
>>> could point to another document that can be kept up-to-date by *another*
>>> group, if such a group can be fund that has the time and energy. So far,
>>> it
>>> is pretty clear such a document does not exist and thus we cannot be
>>> blamed
>>> for not pointing to it as an informative reference.
>>>
>>>
>>>
>>>  This view of combinatorial complexity - and how security concerns
>>>> apply to both combinations and individual algorithms - is a similar
>>>> view that was expressed by a number of participants during the IETF
>>>> JOSE WG during IETF 86, in the discussion of using AES-CBC + HMAC in
>>>> an AEAD mode, as well as the discussion of KDFs. Understanding
>>>> algorithms in isolation is useful, but security considerations really
>>>> come through their combination - and this API allows for a number of
>>>> combinations - out of necessity of supporting a number of applications
>>>> and security considerations.
>>>>
>>>> A full treatise of the topic begins to look something like Ross
>>>> Anderson's excellent "Security Engineering" book (
>>>> http://www.cl.cam.ac.uk/~**rja14/book.html<http://www.cl.cam.ac.uk/~rja14/book.html>), in which whole systems are
>>>> examined - and then broken down by their attacks and weaknesses. And
>>>> begins to look as thick - and as complex.
>>>>
>>>> On Fri, Mar 15, 2013 at 9:31 AM, David McGrew (mcgrew) <
>>>> mcgrew@cisco.com>
>>>> wrote:
>>>>
>>>>> Hi Ryan and Harry,
>>>>>
>>>>> On 3/15/13 11:35 AM, "Ryan Sleevi" <sleevi@google.com> wrote:
>>>>>
>>>>>  In discussions with others at IETF, this is not something that the
>>>>>> CFRG tries to provide.
>>>>>>
>>>>>> That is, the CFRG helps provide input and design, particularly around
>>>>>> the design of *new* protocols. This is not a suitable overlap with
>>>>>> what you want - which is development guidance for the use of
>>>>>> particular algorithms.
>>>>>>
>>>>>> The CFRG cipher catalog, which you have previously requested to
>>>>>> reference, is entirely in the context of discussion of ciphers *in use
>>>>>> by standard protocols*. You do not, for example, see discussions of
>>>>>> OTR/mpOTR.
>>>>>>
>>>>> Focusing on ciphers defined in IETF documents, or referenced in IETF
>>>>> documents, was a good way to keep the scope of the cipher catalog
>>>>> document
>>>>> from getting too big.
>>>>>
>>>>>  Respectfully, a "how to be a cryptographer" is not a good activity.
>>>>>>
>>>>>> On Fri, Mar 15, 2013 at 8:10 AM, Harry Halpin <hhalpin@w3.org> wrote:
>>>>>>
>>>>>>> If so, it may be useful to discuss with them their feedback (via
>>>>>>> Zooko)
>>>>>>> to
>>>>>>> the API.
>>>>>>>
>>>>>>> I have thought, and this came up in an OECD discussion with the IETF
>>>>>>> chair,
>>>>>>> that per-algorithm security considerations *in a separate RFC* might
>>>>>>> be
>>>>>>> a
>>>>>>> good idea. Note this is a separate conversation than the registry,
>>>>>>> but
>>>>>>> would
>>>>>>> address their comments by putting the ball back in their court, so to
>>>>>>> speak.
>>>>>>>
>>>>>>> Then our API can point to their RFC, which they can then keep updated
>>>>>>> as
>>>>>>> long as the CFRG runs. Did the CFRG discuss this, or the API, at all?
>>>>>>>
>>>>>> As CFRG co-chair, I would welcome input and questions from webcrypto,
>>>>> either as a presentation to an upcoming meeting, or as an internet
>>>>> draft.
>>>>>    We need to keep things scoped, of course, but discussion of crypto
>>>>> APIs
>>>>> seems worthwhile to me.   At least, it seems to me that it should be
>>>>> possible to come up with a presentation/discussion on that topic that
>>>>> would be of broad interest to the Internet crypto community.   What do
>>>>> you
>>>>> think?
>>>>>
>>>>> In my opinion, it would be useful to have an API for authenticated
>>>>> encryption that is higher level than RFC5116, which hides as many
>>>>> implementation details as possible from the user.  This effort could
>>>>> potentially be aligned with the CAESER submissions
>>>>> http://competitions.cr.yp.to/   I am not sure how well this lines up
>>>>> with
>>>>> the needs of webcrypto, though.   And for sure it just focuses on a
>>>>> small
>>>>> subset of the API security issues.
>>>>>
>>>>> Copied Kevin (CFRG co-chair).
>>>>>
>>>>> David
>>>>>
>>>>>       cheers,
>>>>>>>         harry
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>