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

[Colin Perkins <[e-mail]>]

> On 13 Oct 2019, at 06:52, Canetti, Ran <[e-mail]> wrote:
> 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…

Sure - but being clear that while CFRG can describe PAKE schemes, and how they need to interact with the broader ecosystem to be secure, it’s the IETF that then translates them into standards.

-- 
Colin Perkins
https://csperkins.org/