hi Roman, (inline per tradition)
> On 28 Sep 2023, at 23:01, Roman Danyliw <[email protected]> wrote: > > Hi Brian! > > Thanks for the response and sorry for the delay. More inline ... > >> -----Original Message----- >> From: iesg <[email protected] <mailto:[email protected]>> On Behalf >> Of Brian Trammell (IETF) >> Sent: Thursday, September 7, 2023 7:29 AM >> To: Roman Danyliw <[email protected] <mailto:[email protected]>> >> Cc: The IESG <[email protected] <mailto:[email protected]>>; >> [email protected] >> <mailto:[email protected]>; taps- >> [email protected] <mailto:[email protected]>; [email protected] >> <mailto:[email protected]>; [email protected] <mailto:[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). I believe that the changes in -23 (just submitted), among (many) other things, implement this (specifically https://github.com/ietf-tapswg/api-drafts/pull/1430); please take a look. (+Paul — this change also addresses the points you raised in your DISCUSS re: security properties) Thanks, cheers, Brian
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
