Hi Roman, Paul, Thanks again for your reviews — just a quick reminder to please take a look at the updates, and let us know if there’s anything else that needs to be addressed to clear your DISCUSS.
Best, Tommy > On Nov 14, 2023, at 8:22 AM, Brian Trammell (IETF) <[email protected]> wrote: > > 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
