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

Back in the days of SNMPv3, faced with a similar problem, we introduced a concept of ASI (Abstract Service Interface) that defined what input and output each architecture component used, and what the expected/allowed reaction was.

IMHO, it served us well.

Regards,
Uri

Sent from my iPhone

> On Oct 13, 2019, at 07:25, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
> 
> Hi Ran,
>  
> I agree with you that it would be super useful to consider APIs that are internal to endpoints in security assessments.
> Sometimes it may be useful to even standardize such endpoint internal APIs.
>  
> I do, however, wonder how many people in the IETF/IRTF have insight into endpoint internal implementation details (or want to be exposed to those details). Acquiring this knowledge requires a lot of time. 
> In practice, this will be a showstopper.
>  
> I believe statements like “An IETF standard is secure" is in general of little value because you still have to implement a spec, test the spec, configure the implementation, and then put it into a larger system. The IETF does not help with any of these tasks.
>  
> Ciao
> Hannes
>  
> From: Cfrg <cfrg-bounces@irtf.org> On Behalf Of Canetti, Ran
> Sent: Sonntag, 13. Oktober 2019 07:52
> To: cfrg <cfrg@irtf.org>
> Subject: [Cfrg] Including "internal APIs" in CFRG security analysis
>  
>  
> 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
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg

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

Attachment: smime.p7s