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. All of that said, to the details: > A few examples of this ambiguity: > > -- “SecurityParameters.Set(identity, myIdentity)”: What is the “identity” > parameter? What would be passed here? This is intended as an abstraction around the entire set of information needed to identify and authenticate an endpoint — the server or client certificate (chain) as well as the associated keys. > -- Per “SecurityParameters.Set(server-certificate, myCertificate)” and > “SecurityParameters.Set(client-certificate, myCertificate)”, assuming > myCertificate is an X.509 certificate, what format would that be passed in > (e.g., PEM, DER)? This is explicitly left undefined (see point 1 above). > -- What is in “myCertficate”: Excellent question. > o can it be a certificate chain? Almost certainly, in that I can’t think of an implementation of this interface that would forbid chains being useful. Let’s say yes. > o in the case of client-auth or a server, is this a bundle with both an X.509 > and a private key? Bundle would be most useful. Which actually makes “myCertificate” (which itself encapsulates an identity) the same thing as identity above. i.e. here I think you found a point where we changed the level of abstraction in the middle of the document. > -- The parameters “supported-group”, “ciphersuite” and “signature-algorithm” > all appear to be enumerated values. Where do those come from? From the groups, ciphers, and signatures supported by the platform, with the enumerations they already support. 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. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you to Sean Turner for the SECDIR review. <snip> questions left out here will go to github issues, but there’s one worth discussing here: > ** Section 6 of draft-ietf-taps-arch-18 said: > ==[ snip ]== > However, a Transport > Services implementation can race different security protocols, e.g., > if the application explicitly specifies that it considers them > equivalent. > ==[ snip ]== > > How does one use the API described in this document to convey equivalence? That’s an excellent question. I’m actually wondering whether the text in the architecture document is correct: is it the application that makes the equivalence determination, or the system policy? I think it’s the latter, as the former is probably (far) too prone to accident. I’ll file an issue to make this change in architecture. Cheers, Brian _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
