Re: [stir] Secdir last call review of draft-ietf-stir-passport-rcd-21

["Murray S. Kucherawy" <[e-mail]>]

Hi,

Thanks for the follow-up.  I'm going to mark this one "Revised I-D Needed"
based on this feedback.  We can send it to the IESG once a new version
appears.  The embargo against revisions ends Monday.

-MSK

On Sun, Oct 16, 2022 at 4:58 PM Chris Wendt <[e-mail]>
wrote:

> Hi Vincent,
>
> Thanks for the review, responses inline:
>
> > On Oct 12, 2022, at 9:13 AM, Vincent Roca via Datatracker <
> [e-mail]> wrote:
> >
> > Reviewer: Vincent Roca
> > Review result: Not Ready
> >
> > Hello,
> >
> > I have reviewed this document as part of the security directorate’s
> ongoing
> > effort to review all IETF documents being processed by the IESG. These
> > comments were written primarily for the benefit of the security area
> > directors. Document editors and WG chairs should treat these comments
> just
> > like any other last call comments.
> >
> > Summary: not ready
> >
> > Globally, the security considerations section addresses all topics that
> come to
> > my mind, given my understanding. The only comment I have is WRT the last
> > paragraph of section 18.1. The wording: "Excluding this claim", seems
> ambiguous
> > to me since I don't understand if it refers to the "rcdi claim" or "an
> entry in
> > mustExclude". Also, I don't understand the core problem (why does a
> mustExclude
> > tag compromize integrity protection). I think the issue deserves more
> details.
> > Finally, isn't "MUST NOT" more appropriate than "SHOULD NOT" since the
> > consequences of not following this rule are major.
>
> So i do agree this last paragraph is confusing where its essentially meant
> to be a stating the obvious type of comment.  I believe it was actually
> written when RFC9118 was created specifically to address Section 18 related
> security concerns.  My proposal is to just remove that paragraph.  There is
> nothing preventing someone from using mustExclude for ‘rcdi’ which is why i
> didn’t say MUST NOT. This scenario simply would not make much sense since
> injecting an ‘rcdi’ is an extremely ineffective form of attack by the
> nature of the claim. I think it just refers to what would be essentially
> the logical conclusion of any implementer of the spec. I think the former
> paragraph in 18.1 covers what is required for general guidance around the
> use of JWTClaimConstraints to maintain integrity and constraint of the
> content of the claims via the certificate.
>
> >
> > A few, minor, additional comments:
> > - Section 18, 1st sentence: s/its identities/it is identities/
>
> Fixed with ’the identities'
>
> > - Section 18, 2nd paragraph: I don't understand "over in a using
> protocol",
> > please fix typo. -
>
> Fixed with 'Baseline PASSporT has no particular confidentiality
> requirement, as the information it signs in many current base
> communications protocols, for example SIP, is information that carried in
> the clear anyway.'
>
> > Section 18, 3rd paragraph: s/availbility/availability/
>
> Fixed
>
> >
> > Cheers,
> >
> > Vincent
> >
> >
> >
>
>