[anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt

[caitlinb at broadcom.com (Caitlin Bestler)]

This draft makes many assumptions about the execution environment.
Far too many, in my opinion, for anything beyond an informational RFC.

In particular the requirements that the objects be "opaque" and
non-copyable are problematic in embedded and/or virtualized
environments.
Not allowing the client to copy the object to another location in the
same process, or to an entirely different process is quite reasonable.
But can the process itself be migrated? Are these objects expected
to work after a Unix style fork? What if the entire IP host is
migrated to another physical machine?

These types of issues are exactly the sort of implementation details
that are best not dealt with by the IETF, but the plain reading of
the draft could seem to apply to all of them.

I see no problem with requiring that the API MUST NOT require
the application to directly manipulate the object. You could
mention that applications SHOULD NOT manipulate the object
by other means, but that belongs in to "application SHOULD
NOT zero-out random portions of physical memory" category.

What needs to be stated is what expectations there are about
this memory. Are normal operations on the entire memory space,
such as swap-out/swap-in and virtualization migration, compatible
with these objects or not?

My hunch is that from a security perspective, the host is the host
and it really does not matter to the remote peer how opaque and/or
protected any specific data object is. These concepts merely promote
robust and readable code. Writing robust wonderful code is of course
to be encouraged, but I don't think we can make it a MUST.