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

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.

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 16:52:37 UTC