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

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

BTW, a more general thought & suggestion, while at it:

One basic limitation of the IETF as a platform for standardizing security
of protocols is that the IETF traditionally shies away from standardizing
APIs that are “internal to endpoints”. However, it is hard to  meaningfully
discuss the security of protocols/ components without pinpointing  these very same
internal APIs: Need to define how other components provide inputs to the analyzed component, how
they obtain outputs from the analyzed component, and what other forms of
information exchange exist between the analyzed component and the rest of
the endpoint system (eg, shared databases). Without such determination, one cannot
meaningfully make a statement of the sort “An IETF standard is secure".
(Indeed, TLS1.* is a quintessential case where such specifications are
sorely missing from the standard.)


The CFRG is a good place to change (or, rather, complement) that - and
the current discussion on PAKE protocols is a good a place to start:
let's ask that PAKE standards (and proposals) specify how  they interact with the other relevant components within each
party, down to the API. This includes the APIs with TLS, with the secure session protocol,
with HTTPS, with the long-term signature module, with the password
store(s), etc etc…


Best, Ran