Re: [Cfrg] Including "internal APIs" in CFRG security analysis

["Canetti, Ran" <[e-mail]>]

Thanks Carsten for raising this point.  Indeed API is a confusing  and overloaded term.

As you say,  the concern is not the precise syntax  but rather the  flow of information, within each participant  in the protocol,  between the analyzed component and the rest of the local system.  Still, in order to provide concrete and meaningful bounds on this information flow  one must formulate some minimal syntax.    This is especially important given that we would like to consider the case where some of the components that our analyzed component is interacting with  are faulty or even malicious.

And indeed, pinpointing  such minimal syntax that allows for meaninful security analysis and is still not overly restrictive or cumbersome is an important part of the security analysis.    (Can think of the UC SIDs as an attempt at such a syntax point.)

Not sure what a good term might be here. "security API" could have been good except that it's used already for something somewhat different.      Perhaps  "Semantic Interface"?

Best, Ran



On 10/13/2019 2:52 AM, Carsten Bormann wrote:

Hi Ran,



On Oct 13, 2019, at 07:52, Canetti, Ran <[e-mail]><mailto:[e-mail]> wrote:

the IETF traditionally shies away from standardizing
APIs that are “internal to endpoints”.



I agree that this is a long-standing tradition of the IETF.
I also see that it is often misunderstood in the way that you describe.

An API is about mapping an interface to the specifics and idiosyncrasies of a programming language (platform, …).  The IETF is indeed shying away from standardizing those aspects for good reasons.

However, what you are (rightly) concerned about is not that aspect of the API, but the information flows themselves.

Executing a protocol between two peer entities is *meaningless* without those “local” information flows.  These have to be specified, or the execution of the protocol remains ambiguous.

In the IETF, we usually do not supply information about these information flows explicitly, but leave the reader with the task to piece them together from the protocol description.  We make sure that we use wording for describing the protocol messages that lead the reader on the desired path, but we often fail to obtain the necessary precision (in particular, it is hard to verify consensus on implicitly conveyed information).

Sometimes we make feeble attempts to talk about those information flows.  E.g., Section 6.2.1 of RFC 5246 (I did not find the equivalent text in RFC 8446) says:

   Client
   message boundaries are not preserved in the record layer (i.e.,
   multiple client messages of the same ContentType MAY be coalesced
   into a single TLSPlaintext record, or a single message MAY be
   fragmented across several records).

It does not say that the receiving end also does not hand through the record layer boundaries to the application; you are supposed to infer this from the above.  While standardizing a protocol on top of TLS, I met at least one accomplished expert with several RFCs in the area of TLS that didn’t understand the implications of that.

If CFRG can be a spearhead for properly dealing with the information flows going into and emanating from protocol execution, I would be delighted.

Grüße, Carsten