From nobody Thu Sep 7 04:29:23 2023 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA4CC14CF1E for ; Thu, 7 Sep 2023 04:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.105 X-Spam-Level: X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trammell.ch Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw68zLxKLO-0 for ; Thu, 7 Sep 2023 04:29:16 -0700 (PDT) Received: from smtp-bc0d.mail.infomaniak.ch (smtp-bc0d.mail.infomaniak.ch [45.157.188.13]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58BBC15109A for ; Thu, 7 Sep 2023 04:29:15 -0700 (PDT) Received: from smtp-2-0000.mail.infomaniak.ch (unknown [10.5.36.107]) by smtp-2-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4RhH7s5dMvzMqfXZ; Thu, 7 Sep 2023 11:29:13 +0000 (UTC) Received: from unknown by smtp-2-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4RhH7s2lmLzMppDh; Thu, 7 Sep 2023 13:29:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=trammell.ch; s=20191114; t=1694086153; bh=4arK8Hk20yonqtM5wv8Nbrmwhxv2JH1n3tyhoK/L+RA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=zffsgJ0os5SVA8uowfCwyRnSYQK1htIVLhRcn8WyIXSVlhcM1WFa//TLkGe8i/DP5 CgUfpYfjrxz9RrAGG3VEn1tMo4JHMLKu4ywTIk33C3ximdv+2wPtg5NSdBqRPz5xtf hZB6ATCPoRe+pGTrGajtaKt2C0Uy7jm77zH0+jLk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) From: "Brian Trammell (IETF)" In-Reply-To: <169393624961.57527.10448223141659236366@ietfa.amsl.com> Date: Thu, 7 Sep 2023 13:29:02 +0200 Cc: The IESG , draft-ietf-taps-interface@ietf.org, taps-chairs@ietf.org, taps@ietf.org, anna.brunstrom@kau.se Content-Transfer-Encoding: quoted-printable Message-Id: <02AC9951-CD5A-46AB-9B82-01B434FC5131@trammell.ch> References: <169393624961.57527.10448223141659236366@ietfa.amsl.com> To: Roman Danyliw X-Mailer: Apple Mail (2.3731.700.6) X-Infomaniak-Routing: alpha Archived-At: Subject: Re: [Taps] Roman Danyliw's Discuss on draft-ietf-taps-interface-22: (with DISCUSS and COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2023 11:29:21 -0000 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=E2=80= =99s a DISCUSS here, so let=E2=80=99s discuss. :) > On 5 Sep 2023, at 19:50, Roman Danyliw via Datatracker = wrote: >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > ** Section 6.3. I=E2=80=99m 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 =E2=80=9Cidentity, server-certificate, = client-certificate, key-pair, > supported-group, ciphersuite, signature-algorithm, and = pre-shared-key.=E2=80=9D 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 =E2=80=9Cbuilt environment=E2=80=9D 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=E2=80=99re 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=E2=80=99s 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 =E2=80=9820s. (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=E2=80=99re 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.=20 All of that said, to the details: > A few examples of this ambiguity: >=20 > -- =E2=80=9CSecurityParameters.Set(identity, myIdentity)=E2=80=9D: = What is the =E2=80=9Cidentity=E2=80=9D > 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 =E2=80=94 the server or = client certificate (chain) as well as the associated keys. > -- Per =E2=80=9CSecurityParameters.Set(server-certificate, = myCertificate)=E2=80=9D and > =E2=80=9CSecurityParameters.Set(client-certificate, myCertificate)=E2=80= =9D, 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).=20 > -- What is in =E2=80=9CmyCertficate=E2=80=9D: Excellent question. > o can it be a certificate chain? Almost certainly, in that I can=E2=80=99t think of an implementation of = this interface that would forbid chains being useful. Let=E2=80=99s 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 =E2=80=9CmyCertificate=E2= =80=9D (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 =E2=80=9Csupported-group=E2=80=9D, =E2=80=9Cciphersuit= e=E2=80=9D and =E2=80=9Csignature-algorithm=E2=80=9D > all appear to be enumerated values. Where do those come from? =46rom 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=E2=80=99d 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=E2=80=99ll = file the issue and put together the PR. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you to Sean Turner for the SECDIR review. questions left out here will go to github issues, but there=E2=80=99= s one worth discussing here: > ** Section 6 of draft-ietf-taps-arch-18 said: > =3D=3D[ snip ]=3D=3D > However, a Transport > Services implementation can race different security protocols, e.g., > if the application explicitly specifies that it considers them > equivalent. > =3D=3D[ snip ]=3D=3D >=20 > How does one use the API described in this document to convey = equivalence? That=E2=80=99s an excellent question. I=E2=80=99m 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=E2=80=99s the latter, as the former is probably (far) = too prone to accident. I=E2=80=99ll file an issue to make this change in = architecture. Cheers, Brian