Hi Roman, After the discussion in the ANIMA Design Team I have to correct my answer to the internationalization question below. Sorry for sending the email to early.
Best regards Steffen > -----Original Message----- > From: Fries, Steffen <steffen.fr...@siemens.com> > Sent: Tuesday, April 15, 2025 4:01 PM > To: Roman Danyliw <r...@cert.org>; The IESG <i...@ietf.org> > Cc: draft-ietf-anima-brski-...@ietf.org; anima-cha...@ietf.org; > anima@ietf.org; > i...@kovatsch.net; t...@cs.fau.de > Subject: RE: Roman Danyliw's Discuss on draft-ietf-anima-brski-prm-18: (with > DISCUSS and COMMENT) > > Hello Roman, > > Thank you for your comments. I put my comments inline, marked with [stf] We > will > address the points listed in the next version of the draft. We have > intermediate > versions already incorporating several comments received on > https://github.com/ > %2Fanima-wg%2Fanima-brski- > prm&data=05%7C02%7Csteffen.fries%40siemens.com%7C8145368f33f446b2f748 > 08dd7c260332%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6388032 > 24875618569%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl > YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 > C0%7C%7C%7C&sdata=UUXVIzjO%2BQddZTjI%2FG%2FjTvL8zXfAK5Z9bgXb5 > %2BeRu4g%3D&reserved=0 > (diff with version 18: > https://author-/ > tools.ietf.org%2Fdiff%3Fdoc_1%3Ddraft-ietf-anima-brski- > prm%26url_2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fanima- > wg%2Fanima-brski-prm%2Frefs%2Fheads%2Fmain%2Fdraft-ietf-anima-brski- > prm.txt&data=05%7C02%7Csteffen.fries%40siemens.com%7C8145368f33f446b2f > 74808dd7c260332%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6388 > 03224875646332%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 > D%7C0%7C%7C%7C&sdata=AnAT4VWLeMVmfD9THyLA4VzGVHqeDihanA6U9 > %2Bd2%2F0c%3D&reserved=0) > > Best regards > Steffen > > > -----Original Message----- > > From: Roman Danyliw via Datatracker <nore...@ietf.org> > > Sent: Monday, April 14, 2025 11:59 PM > > To: The IESG <i...@ietf.org> > > Cc: draft-ietf-anima-brski-...@ietf.org; anima-cha...@ietf.org; > > anima@ietf.org; i...@kovatsch.net; t...@cs.fau.de; i...@kovatsch.net > > Subject: Roman Danyliw's Discuss on draft-ietf-anima-brski-prm-18: > > (with DISCUSS and COMMENT) > > > > Roman Danyliw has entered the following ballot position for > > draft-ietf-anima-brski-prm-18: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > > this introductory paragraph, however.) > > > > > > Please refer to > > https://www/. > > > ietf.org%2F&data=05%7C02%7Csteffen.fries%40siemens.com%7C8145368f33f44 > > > 6b2f74808dd7c260332%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C > 63880 > > > 3224875666636%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > sIlYiOiIw > > > LjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7 > C%7C > > > %7C&sdata=eGb7bfvXUUV5cPRsAqqSvm%2Fs2EWoqZWBoPyFkSV6h%2B0%3 > D&reserved= > > 0 > > %2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot- > > > positions%2F&data=05%7C02%7Csteffen.fries%40siemens.com%7C4583723db6 > 6 > > > 744933d3008dd7b9f900a%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > > > 7C638802647448242206%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO > n > > > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% > 3 > > D > %3D%7C0%7C%7C%7C&sdata=cjnj2TcCo%2FpAySc7GyFqZjN2f1gJZYe9J%2F > w > > yTOxXQK8%3D&reserved=0 > > for more information about how to handle DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://data/ > > > tracker.i%2F&data=05%7C02%7Csteffen.fries%40siemens.com%7C8145368f33f4 > > > 46b2f74808dd7c260332%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7 > C6388 > > > 03224875687301%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > UsIlYiOiI > > > wLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0% > 7C%7 > > > C%7C&sdata=eqIr%2B4c%2FNgu2bXg2AOW7%2BxGY9%2BS0XR41KBc%2Bh > WI5b1A%3D&re > > served=0 > > etf.org%2Fdoc%2Fdraft-ietf-anima-brski- > > > prm%2F&data=05%7C02%7Csteffen.fries%40siemens.com%7C4583723db667449 > > > 33d3008dd7b9f900a%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63 > > > 8802647448303370%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > W > > > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 > D > > % > 7C0%7C%7C%7C&sdata=z9SfJVUCjCxdUtBFZiDFTyRn7AeC%2BkWfnLGK4%2F > d > > GbgA%3D&reserved=0 > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > ** Section 6.1.2 > > In the absence of a more general discovery as defined in > > [I-D.ietf-anima-brski-discovery] the Registrar-Agent MUST use > > > > The way this sentence is constructed makes > > [I-D.ietf-anima-brski-discovery] a normative reference. Put more > > generally, it reads "If <A> then <B> MUST be used". To know that <B> > > applies, one needs to fully understand <A>. I don't think that is the > > intent. > [stf] Thanks for spotting that. It was not intended. Actually the other way > around. > Proposal to reverse that to OLD In the absence of a more general discovery as > defined in [I-D.ietf-anima-brski-discovery] the Registrar-Agent MUST use NEW > For discovery the Registrar-Agent MUST use ... if it does not support a more > general discovery as defined in [I-D.ietf-anima-brski-discovery]. > > > > > ** Section 7.6.2.1 > > * reason: contains a human-readable message; SHOULD NOT provide > > information beneficial to an attacker > > > > Per the requirement in Section 4.2 of RFC2277 that the "Protocols that > > transfer text MUST provide for carrying information about the language > > of that text", what is the recommended approach here? > [stf] We used the same approach here as in RFC 8995 stating human readable > message. Should we include a statement about appropriate language tagging > like: > NEW > According to [RFC2277], human-readable information must contain information > about the language of the text. Consequently, the utilized language is > indicated at > the beginning of the human readable information. [stf] Correction after ANIMA Design Team meeting: The pledge is not localized at this point in time so the pledge is not aware of the language to select. English is taken as a default here for this diagnostic messages. The internationalization of text is expected to be done on another level. > > > > Same question for pvs-details in reason-context and pbs-details in > > reason-context ( > > > > ** Section 7.6.2.1 > > * reason: contains a human-readable message; SHOULD NOT provide > > information beneficial to an attacker > > > > ... > > * reason-context: contains a JSON object that provides additional > > information specific to a failure; in contrast to Section 5.7 of > > [RFC8995], MUST be provided; SHOULD NOT provide information > > beneficial to an attacker > > > > When is it acceptable to provide information beneficial to the attacker? > [stf] Well, likely never, but sometimes information on errors can be > beneficial for > an attacker to learn certain behavior and better target attacks. > Would is be less irritating to delete that part resulting in the following: > OLD > reason-context: contains a JSON object that provides additional > information specific to a failure; in contrast to Section 5.7 of > [RFC8995], MUST be provided; SHOULD NOT provide information > beneficial to an attacker > NEW > reason-context: contains a JSON object that provides additional > information specific to a failure; in contrast to Section 5.7 of > [RFC8995], MUST be provided > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank you to Paul Kyzivat for the GENART review. > > > > ** Section 4. > > > > * The use of authenticated self-contained objects addresses both, > > the TLS challenges and the technology stack challenge. > > > > What are "technology stack challenges"? > [stf] We saw also challenges for instance when using BTLE or other near-field > technologies or the communication between the registrar-agent and the > pledge.The intension was to keep the security approach transport agnostic. > > > > ** Section 6.1 > > Alternatively, the registrar EE > > certificate MAY be provided via configuration or a repository > > > > What is a "repository" and how is that difference than "configuration"? > [stf] It is certainly sufficient to state configuration. What I had in mind > are two > ways of configuration one, were the device will be configured (some kind of > push) > and one were the device fetches the information from a database (some kind of > pull). But this distinction is likely not necessary here proposal to change > from OLD > Alternatively, the registrar EE certificate MAY be provided via configuration > or a > repository NEW Alternatively, the registrar EE certificate MAY be provided via > configuration > > > > ** Section 6.1 > > Further, the Registrar-Agent SHOULD have synchronized time. > > > > What is the impact of not having synchronized time? > [stf] When the registrar-agent has no synchronized time it may not be able to > validate the EE certificate of the registrar during the TLS handshake if the > time > drift is too big. As we recommend to utilize short-term certificates we may > provide > additional information. Proposal: > NEW > In case the registrar-agent does not have synchronized time, it may not be > able to > verify the registrar EE certificate during the TLS handshake. As the > registrar- > agent is recommended to utilize short-lived certificates in Section 12.3, a > registrar-agent may use the valid from time of its short-lived certificate > for time > synchronization. > > > > > ** Section 6.1.2 > > Note that this goes against the naming recommendation of [RFC6763]. > > The _brski-pledge._tcp service, however, targets machine-to-machine > > discovery. > > > > What in RFC6763 suggests a scope that would exclude > > "machine-to-machine discovery" to provide justification for not following > > its > recommendation? > [stf] We interpreted section 7 RFC 6763 > (https://www.rfc-/ > editor.org%2Frfc%2Frfc6763%23page- > 19&data=05%7C02%7Csteffen.fries%40siemens.com%7C8145368f33f446b2f7480 > 8dd7c260332%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63880322 > 4875702814%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlY > iOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 > C0%7C%7C%7C&sdata=wi0zgVXRTUdX%2BxNUj5%2BlOvOoN4ZbOIKb966Jiks > gCiE%3D&reserved=0) as application centric, but that may be misleading. The > statement that the usage of the service name goes against the definition > merely > comes from the statement that "_tcp" is the second label. In the way the > service > name is constructed in BRSKI-PRM (<product-serial-number>._brski- > pledge._tcp.local to discover a specific instance of the pledge, it becomes > the > third label. Would the following reformulation be better suited? > OLD > Note that this goes against the naming recommendation of [RFC6763]. The > _brski-pledge._tcp service, however, targets machine-to-machine discovery. > NEW > Note that the service name definition is not fully inline with the naming > recommendation of [RFC6763]. However, the definition allows to discover > specific > instances of a pledge. > > > > ** Section 6.1.2 > > For Ethernet, > > it is provided by simply connecting the network cable. > > > > Isn't this an oversimplification? What if it there is local policy > > which manages the behavior of the interface? What about provisioning > > that might need to occur on a switch? > [stf] Understood. Pledges, not identifiable may be put into a quarantine VLAN > until > bootstrapped. We did not want to address network connectivity in the document > and set it out of scope and merely provided some examples, but no > specification. > Proposal to enhance the statement from OLD For Ethernet, it is provided by > simply connecting the network cable. > NEW > For Ethernet, network connectivity can be provided, e.g., via a switch to an > operational network or to a specific VLAN for bootstrapping, depending on an > operators security policy. > > > > > ** Section 6.1.2 > > How to gain network > > connectivity is out of scope of this document. > > > > If this is the case, why is there discussion of WiFi, Ethernet, > > references to [I-D.richardson-emu-eap-onboarding], and 6LoWPAN. > [stf] We intended them as illustrative examples to provide further pointers. > If the > text as such is irritating, should we provide a statement before that to > underline > that these points are examples and not intended as normative? > > > > ** Section 6.3 > > Overall, this may have > > operational implications when the registrar is part of a scalable > > framework as described in Section 1.3.1 of > > [I-D.richardson-anima-registrar-considerations]. > > > > If these operational implications are important, why are they an > > informative reference in an unadopted I-D? > [stf] We are currently in the process to adopt the document in the ANIMA WG as > WG items. Both documents provide operational considerations applicable for > BRSKI and variants as BRSKI-PRM, BRSKI-AE, and cBRSKI. > > > > ** Section 6.3.1 > > This may be supported by a specific naming in the SAN (subject > > alternative name) component of the Registrar-Agent EE certificate, > > which allows the domain registrar to explicitly detect already in the > > TLS session establishment that the connecting client is a Registrar- > > Agent. > > > > What is the standardized approach for this naming scheme to enable > > interoperability? Is this out of scope? > [stf] There are no specific requirements to the SAN. The intention was to > allow the > registrar upon TLS connection establishment to detect a registrar-agent is > connecting and not a pledge based on the provided used client certificate, > which is > useful for registrars supporting BRSKI and BRSKI-PRM (using a co-located > registrar-agent). > > > > ** Section 7.1.1.1.1 > > The serial-number member SHALL contain the product-serial-number of > > the pledge with which the Registrar-Agent assumes to communicate as > > string. > > > > Is this the same serial number as emitted in in mDNS in Section 6.1.2? > [stf] Yes, that was the intention. Should we provide a statement in section > 6.1.2 > that this is the serial number contained? > > > > ** Section 7.1.1.1.2. are there any MTI "alg"s to support to ensure > > interoperability? > [stf] Good point! A proposal is to rely on RFC7518 and consequently include a > statement that for algorithm support BRSKI-PRM relies on RFC 7518. > NEW (for the sections related to JWS signature: > Algorithms supported for JWS signatures MUST support ES256 as recommended > in [RFC 7518] and MAY support further algorithms. > > > > > ** Section 7.3 > > The registrar SHOULD verify the TLS client authentication of the > > Registrar-Agent, in particular if the TLS session is used to obtain > > the Registrar-Agent EE certificate (see Section 6.3). > > > > Why wouldn't the client authentication be verified? When is this > > acceptable to do? > [stf] we also got the comment from Deb. The text ready odd and needs fixture. > Since we already require mutual authentication between registrar--agent and > registrar the complete abstract can be deleted. > > > > ** Section 9 > > Besides the above, also consider the existing documents on > > operational modes for > > * BRSKI registrars in > > [I-D.richardson-anima-registrar-considerations] > > > > * BRSKI MASA in [I-D.richardson-anima-masa-considerations] > > > > What does it mean to "consider" these documents? Are they relevant > > operational considerations? > [stf] Both documents provide insights into the operational handling of the > registrar > and the MASA and are intended as supporting documents or guidelines. Both > documents are currently in the process of WG adoption. > _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
