W3C home > Mailing lists > Public > public-webcrypto@w3.org > March 2013

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

From: Harry Halpin <hhalpin@w3.org>
Date: Fri, 15 Mar 2013 18:02:03 +0100
Message-ID: <5143540B.3080604@w3.org>
To: Ryan Sleevi <sleevi@google.com>
CC: "David McGrew (mcgrew)" <mcgrew@cisco.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, "kmigoe@gmail.com" <kmigoe@gmail.com>
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/ . 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. 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 ), 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
>>>>
>>>>
>>>>
Received on Friday, 15 March 2013 17:02:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:15 UTC