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

From: "Canetti, Ran" <[email-masked]>
Date: Sun, 13 Oct 2019 05:52:03 +0000

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

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 13 Oct 2019 08:52:29 +0200

Hi Ran,

> On Oct 13, 2019, at 07:52, Canetti, Ran <[email-masked]> 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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 13 Oct 2019 11:24:25 +0000

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 <[email-masked]> On Behalf Of Canetti, Ran
Sent: Sonntag, 13. Oktober 2019 07:52
To: cfrg <[email-masked]>
Subject: [Cfrg] Including "internal APIs" in CFRG security analysis

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.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 13 Oct 2019 11:29:03 +0000

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 <[email-masked]> wrote:
> 
> Hi Ran,
>  
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 13 Oct 2019 12:19:03 +0000

Reading Ran’s text I was thinking about APIs from Global Platform used to communicate between the normal world and the secure world on Cortex A class devices, the Platform Security Architecture (PSA) APIs introduced for M-class devices (for attestation, crypto and secure storage). Those would be applicable to the TEEP, RATS, and the SUIT work.

The information flow on modern devices tends to be somewhat complex given all layers of privilege isolation going on.

From: Blumenthal, Uri - 0553 - MITLL <[email-masked]>
Sent: Sonntag, 13. Oktober 2019 13:29
To: Hannes Tschofenig <[email-masked]>
Cc: Canetti, Ran <[email-masked]>; cfrg <[email-masked]>
Subject: Re: [Cfrg] Including "internal APIs" in CFRG security analysis

IMHO, it served us well.
Regards,
Uri

Sent from my iPhone

On Oct 13, 2019, at 07:25, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ran,

Ciao
Hannes

From: Cfrg <[email-masked]<mailto:[email-masked]>> On Behalf Of Canetti, Ran
Sent: Sonntag, 13. Oktober 2019 07:52
To: cfrg <[email-masked]<mailto:[email-masked]>>
Subject: [Cfrg] Including "internal APIs" in CFRG security analysis

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
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg
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.

---

From: "Canetti, Ran" <[email-masked]>
Date: Sun, 13 Oct 2019 17:18:31 +0000

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 <[email-masked]><mailto:[email-masked]> wrote:

   Client

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 13 Oct 2019 21:40:41 +0200

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

Uri’s proposal “Abstract service interface” (ASI) works for me, at least for protocols that would enable the use of the 40-year-old protocol/service paradigm [1].  “Semantic interface” may be going into the area of semantics too much (RDF, anyone?), and this misses the aspect of abstraction (from the specific interface).

The next step for me would be to collect some considerations/examples for how a good ASI description looks like.

Grüße, Carsten

[1]: https://dl.acm.org/citation.cfm?id=2286038

---

From: Ira McDonald <[email-masked]>
Date: Sun, 13 Oct 2019 18:06:16 -0400

Hi Carsten and Ran,

You might start by looking at Architecture for Describing SNMP Management
Frameworks (RFC 3411), chapter 4 Abstract Service Interfaces:

https://tools.ietf.org/html/rfc3411#page-30

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Sun, Oct 13, 2019 at 3:41 PM Carsten Bormann <[email-masked]> wrote:

> > 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"?
>
> Uri’s proposal “Abstract service interface” (ASI) works for me, at least
> for protocols that would enable the use of the 40-year-old protocol/service
> paradigm [1].  “Semantic interface” may be going into the area of semantics
> too much (RDF, anyone?), and this misses the aspect of abstraction (from
> the specific interface).
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 14 Oct 2019 09:57:12 +0100

> On 13 Oct 2019, at 06:52, Canetti, Ran <[email-masked]> wrote:
> 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/