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

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

From: Ryan Sleevi <sleevi@google.com>
Date: Fri, 15 Mar 2013 10:06:29 -0700
Message-ID: <CACvaWvbowxBj0YQ_E3xFZZB_wyY9gr11p13izMWhn=VbPtsJnA@mail.gmail.com>
To: Harry Halpin <hhalpin@w3.org>
Cc: "David McGrew (mcgrew)" <mcgrew@cisco.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, "kmigoe@gmail.com" <kmigoe@gmail.com>
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/ . 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.

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.

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.

> 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:06:57 UTC

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