Hi Brian! Thanks for the response and sorry for the delay. More inline ...
> -----Original Message----- > From: iesg <[email protected]> On Behalf Of Brian Trammell (IETF) > Sent: Thursday, September 7, 2023 7:29 AM > To: Roman Danyliw <[email protected]> > Cc: The IESG <[email protected]>; [email protected]; taps- > [email protected]; [email protected]; [email protected] > Subject: Re: [Taps] Roman Danyliw's Discuss on draft-ietf-taps-interface-22: > (with DISCUSS and COMMENT) > > hi Roman! > > Thanks for the questions. Points not addressed inline below will be tracked at > https://github.com/ietf-taps/api-drafts/issues, but there’s a DISCUSS here, so > let’s discuss. :) > > > On 5 Sep 2023, at 19:50, Roman Danyliw via Datatracker <[email protected]> > wrote: > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > ** Section 6.3. I’m having trouble understanding the level of > > abstraction used to specify the SecurityParameter API if the desired > > outcome is an interoperable solution. My top-line concern is around > > what are the defined security parameters are where are they formally > > defined. The API examples seem to suggest they are “identity, > > server-certificate, client-certificate, key-pair, supported-group, > > ciphersuite, > signature-algorithm, and pre-shared-key.” > > This is an artifact of trying to balance between two sometimes-opposing goals > with the TAPS interface work: > > (1) The interface specification has to be malleable enough to fit with the > existing “built environment” of the platforms that will implement it; concepts > that are ancillary to a transport services implementation should be left > undefined so that system implementors can build TAPS into their platforms > without completely changing how the platform works. IOW we’re not going to > define your PKI for you, or your interfaces for managing protocol selection > policy, because you should already have these things, because it’s not useful > for > the purposes of application interoperability to do so, and because we need to > set the boundaries of scope somewhere if we want to be done in the ‘20s. > > (2) The interface specification has to be rigid enough to be usefully > interoperable; i.e., two different applications of TAPS on the same platform > using the interface in the same way should result in indistinguishably- > equivalent communications, while an application using TAPS on one platform > that is minimally ported to a different platform should result in > unsurprisingly- > equivalent communications (the distinction here being that different Transport > Services system implementations might differ in meaningful-to-the-platform > ways, i.e. in terms of the policy priorities in racing or indeed in the set of > underlying stacks implemented). > > Basically what we’re doing here is guessing (educatedly, but still) about the > minimum-interference shape with how existing systems do X (in this case, > security property management), under the assumption that these platforms get > it right. I think we got this balance mostly right everywhere, but security > is the > hardest place to do so, precisely because of the rigidity and the formality > required in the security space pushes toward an imbalance on the latter. Thanks for explaining the goal and the intent. The tensions between those goals is clear. [snip] > I do think we need to make some changes to the doc to address these points. > I’d suggest the following: > > - Define the highest usable level of abstraction for these parameters > - Reiterate the principle that the exact set of values for available > enumerations > and the exact data formats for each security parameter are platform- > dependent. > > If this would be an acceptable resolution to the DISCUSS, I’ll file the issue > and > put together the PR. The above plan makes sense. Thanks for laying out. I would also recommend that the text calibrate the expectations of an "abstract API" and degree of expected interoperability. Inspirationally, the abstract notes that this API is "intended to replace the BSD sockets API as the common interface to the transport layer, in an environment where endpoints could select from multiple interfaces and potential transport protocols." That's a very helpful touchstone. If I squint at the BSD socket API, I see two key differences from what's presented in the current text. Because one could read the .h file, the BSD sockets interface was clear on: (a) data structures and data types. This draft introduces complicated abstractions with limited definition or underlying representation (e.g., "identity", "ciphersuite"). Additionally, there is no sense of where enumerated values would come from. (b) function prototypes. This draft has illustrative examples of pseudo-code, but the canonical list of functions and their associated prototypes isn't clear. Per the goals you outlined in (1) and (2) above, it is clear how this ambiguity serves goals (1), but it seems to impede (2). Thanks, Roman _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
