On 28/04/2025 15:32, Fries, Steffen wrote:
Hi Gorry,
Sorry for the delay in answering, the Easter holidays …
To get back to your comments, I included some further updates with [stf]
I put an updated version with the indicated changes on github:
https://github.com/anima-wg/anima-brski-prm
Best regards
Steffen
That all seems good now, many thanks Steffan,
Gorry
*From:*Gorry Fairhurst <go...@erg.abdn.ac.uk>
*Sent:* Thursday, April 17, 2025 8:21 AM
*To:* Fries, Steffen (FT RPD CST) <steffen.fr...@siemens.com>; Michael
Richardson <mcr+i...@sandelman.ca>; Gorry Fairhurst
<go...@erg.abdn.ac.uk>; The IESG <i...@ietf.org>;
draft-ietf-anima-brski-...@ietf.org; anima-cha...@ietf.org;
anima@ietf.org; i...@kovatsch.net; t...@cs.fau.de
*Subject:* Re: discuss comments from Gorry
On 15/04/2025 17:25, Fries, Steffen wrote:
Hi Gorry,
Thank you for your comments. I put the reaction inline marked with [stf].
@mcr, thank you for pushing the email out.
We will incorporate the changes as indicated below in the next version. The intermediate
version is available onhttps://github.com/anima-wg/anima-brski-prm. We will incorporate the
changes into this version likely tomorrow. Diff with version
18:https://author-tools.ietf.org/diff?doc_1=draft-ietf-anima-brski-prm&url_2=https://raw.githubusercontent.com/anima-wg/anima-brski-prm/refs/heads/main/draft-ietf-anima-brski-prm.txt
<https://author-tools.ietf.org/diff?doc_1=draft-ietf-anima-brski-prm&url_2=https://raw.githubusercontent.com/anima-wg/anima-brski-prm/refs/heads/main/draft-ietf-anima-brski-prm.txt>.
Best regards
Steffen
Please see bcomments elow after reading rev -19.
-----Original Message-----
From: Michael Richardson<mcr+i...@sandelman.ca>
<mailto:mcr+i...@sandelman.ca>
Sent: Tuesday, April 15, 2025 5:23 PM
To: Gorry Fairhurst<go...@erg.abdn.ac.uk> <mailto:go...@erg.abdn.ac.uk>; The
IESG<i...@ietf.org> <mailto:i...@ietf.org>; draft-
ietf-anima-brski-...@ietf.org;anima-cha...@ietf.org;anima@ietf.org;
i...@kovatsch.net;t...@cs.fau.de
Subject: discuss comments from Gorry
https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/ballot/
The comments from Gorry did not get to the mailing list and are not in
the
archives.
We were confused by this, until we saw that it says "Not sent" in the
upper corner.
I didn't know that was an option, or a thing, and I'm guessing maybe
Gorry didn't either. I wondered perhaps if the plumbing failed, but I
guess
intentional.
Here they are for the purposes "of the tape" (archive) his comments:
----
Thank you for preparing this document. I have the following four
questions where
I'd appreciate more clarity in the text:
1. The text says: “SHOULD NOT provide information beneficial to an
attacker”.
I don’t understand the RFC 2119 SHOULD recommendation. To me, the
current
text does not say what actually has to be done, or what ought not to be
done (e.g.
citing some suitable RFCs to help clarify what is needed). Also I do
wonder
whether this be a “MUST”? (i.e., under what conditions is it considered
good to
provide information to benefit an attacker?). Could this just be wisdom
-
e.g.”needs to avoid”, rather than a protocol requirement?
[stf] correct finding, the normative language is wrong here. Proposal to
replace
OLD
SHOULD NOT provide information beneficial to an attacker
NEW
should not provide information beneficial to an attacker
OK - Thanks, I see this was included, I have removed this item from my
ballot.
2. “TLS 1.2 MAY be used”, please could you explain why this is only
"MAY"
rather than being stronger, noting draft-ietf-uta-require-tls13 and RFC
9325, which
asserts that TLS 1.3 is in widespread use.
[stf] Discussion to that already started on UTA and ANIMA WG list. Main
motivation in BRSKI-PRM as extension to BRSKI, is to keep backward
compatibility and provide the same requirements as the RFC 8995 and also the
availability of TLS 1.3 in existing frameworks.
I don't think was addressed by text in the draft. I also see another
DISCUSS relating to this topic.
[stf] yes, we are in discussion in the ANIMA Design Team on how to go
forward with it.
3. I could not understand the protocol action of the “MUST” requirement
below (i.e.
what does “available” mean for a RFC2119 requirement?:
“if the certificate chain
is not included in the x5c Header Parameter, it MUST be available
at the domain registrar for verification”
Please consider changing this text, for instance text like the
following could be
helpful:
“if the certificate chain is available at the domain registrar for
verification, it MAY be omitted from the x5c Header Parameter“.
[stf] okay, understood. The intention was to underline that if the
information is not available in the response, it must be available at the
registrar to enable validation of the response.
Your reply explains what is needed, but it did not really address the
use of the RFC2119 requirement, becuase the current text only states
this needs to be present, rather than what action is needed when it is
not present.
I expected a formulation more like:
<< XXX needs to be available at the domain registrar for verification...
... If X is not available, the domain registrar MUST YYYY>>
Where YYY is the protocol action that you require.
I have updated this item from my ballot.
[stf] All occurrences of this have been replaced with a different
formulation in version 20:
OLD
if the certificate chain is not included in the x5c Header Parameter,
it MUST be available at the domain registrar for verification”
NEW
The certificate chain MUST be available for certificate verification.
If it is not contained in the x5c Header Parameter it is provided to
the relying party by other means such as configuration.
4. Please update the text to explain/clarify:
“The registrar MAY consider ignoring any but the newest PER
artifact from the same pledge in case the registrar has at any point
in time more than one pending PER from the pledge?"
I don't understand the requirement from the text, please explain: For
example, could this perhaps be a RFC2119 requirememnt: "MAY ignore"
.. and
then add text to describe when this is allowed (or not).
[stf] agreed, will be updated accordingly
OK - Thanks, I have removed this item from my ballot.
Comment (2025-04-10) Not sent
1. There appears to be some slight format problem with the bullets I
saw listed in
my rendering:
“such as: * Avoid
logging personally identifiable information unless unavoidable. *
Anonymize or
pseudonymize data where possible.”
[stf] agreed, will be repaired
Done, thanks.
2. I did not understand the list of three security considerations at
the start of
section 12. At least, it would be very helpful to explain these in
sufficient detail to
understand each, and also helpful to understand the implications for
users of each.
Some words to clarify would be very helpful.
[stf] It was intended as an intro to the following subsections. Proposal to
update from
OLD
Further security aspects are considered here related to:
NEW
Further security aspects considered in the following subsections related to:
Thanks.
3. Please could you add text to explain “no transport layer security
between
Registrar-Agent and pledge..” e.g., please explain: Is this something
that users
ought to add to a design? how? why? is it a desirable property? Why?
... or is this intended to be explained more in the next subsections?
... Especially since 7.1 speaks of optional use of TLS.
[stf] We tried to explain the optional usage of TLS in section 7.1 and
section 11 to underline that it is recommended to be used if there are privacy
requirements to be addressed. The utilized self-contained objects are integrity
protected but still readable. If there is sensitive information included (user
names, etc.) confidentiality is likely desired and can be provided using TLS.
My problem here is I don't understand what :"no transport layer
security between...:" actually refers to. I think the text needs
explained more. A reference to section 7.1 would be helpful also.
[stf] okay, understood, I included the following at the beginning of
the security considerations:
OLD
* no transport layer security between Registrar-Agent and pledge and
the impact on transport of sensitive information.
NEW
* no usage of TLS between Registrar-Agent and pledge and the resulting
impact on transport of sensitive information (see also Section 7.1
regarding optional use of TLS to protect the communication between the
Registrar-Agent and the pledge)
4. Please update the text to clarify what is intended by: “Pledges MAY
support
both initiator and responder mode.” Is this MAY intended to permit
*both* of the modes, or *either* of the modes, or something else?
[stf] good point, this is more a pledge capability question and not
intended as normative may. Proposal to change from
OLD
Pledges MAY support both initiator and responder mode.
NEW
Pledges may support both initiator and responder mode.
OK
5. Please consider updating the text:
“503 Service Unavailable: if a simple retry of the Registrar-Agent
request might lead to a successful response; this error response
SHOULD include the Retry-After response header field with an
appropriate value”
- Why is this not a MUST, if there is a reason, please explain the
alternative and when this is a suitable response.
[stf] Good point. Proposal to change to MUST.
I didn't see this change.
[stf] I only addressed the first occurrence in the draft, but not the
second one. I repaired that in the draft available on github.
Best wishes,
Gorry
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
