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

[Nicolas Williams]

On Mon, Jun 18, 2007 at 01:47:03PM -0700, Caitlin Bestler wrote:
> This draft makes many assumptions about the execution environment.
> Far too many, in my opinion, for anything beyond an informational RFC.

Such as?

> In particular the requirements that the objects be "opaque" and
> non-copyable are problematic in embedded and/or virtualized
> environments.

As long as interfaces are provided for copying opaque objects that may
need to be copied that should suffice to address the concern.

> 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?

Some RFCs that define APIs never described fork- or thread-safety.  For
any interface like this one, however, I think that fork- and thread-
safety must be addressed, even if to say that it is undefined.

> 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 think discussions about the propriety of the IETF doing API work are
outside the scope of this WG.

> 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.

Opaqueness, IMO, can (and in this case should) cover the "size" of the
object in memory -- the application need not know; as fas as it's
concerned the object has a pointer- or integer-sized handle and that's
that.

> 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?

I think swapping and paging are out of scope here.  How many APIs do you
know of that are not swap-safe?!

Migration should be like suspend/resume: a socket may become
disconnected, a connection latch may be broken, etc...

> 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.

I agree with the first sentence; most API details are local details, not
protocol details.  I disagree with the rest.

Nico
--