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

Carsten Bormann <cabo@tzi.org> Sun, 13 October 2019 06:52 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8809120025 for <cfrg@ietfa.amsl.com>; Sat, 12 Oct 2019 23:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1TGwQsmngem for <cfrg@ietfa.amsl.com>; Sat, 12 Oct 2019 23:52:32 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E1FF1200CE for <cfrg@irtf.org>; Sat, 12 Oct 2019 23:52:32 -0700 (PDT)
Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46rXSG2zVKzySP; Sun, 13 Oct 2019 08:52:30 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <e9043999-6015-d010-b023-4cb784d4d7b9@bu.edu>
Date: Sun, 13 Oct 2019 08:52:29 +0200
Cc: cfrg <cfrg@irtf.org>
X-Mao-Original-Outgoing-Id: 592642347.6143661-0f70eb9eefdb2632acee01c17d31a0b8
Content-Transfer-Encoding: quoted-printable
Message-Id: <52084CD0-845A-41C0-B0ED-355A059A6037@tzi.org>
References: <e9043999-6015-d010-b023-4cb784d4d7b9@bu.edu>
To: "Canetti, Ran" <canetti@bu.edu>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/LZhZSC6T-RwjyTt4U5TgK4RH6rA>
Subject: Re: [Cfrg] Including "internal APIs" in CFRG security analysis
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Oct 2019 06:52:35 -0000

Hi Ran,

> On Oct 13, 2019, at 07:52, Canetti, Ran <canetti@bu.edu> 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