Subject: Re: [stir] draft-ietf-stir-passport-rcd-14 rcdi for "/jcd"

From: Jack Rickard <[email-masked]>
Date: Mon, 21 Feb 2022 16:58:27 +0000

I think I agree, although it's a bit of shame to move away from the "hash the body of the HTTP response" model. Although, on that note please make sure that it's clear whether for "jcl" whether the digest should be:

  *   The hash of the body of the HTTP response
  *   The hash of the properly formatted JSON in the response (i.e. you have to parse it and canonicalize it first)
I'd prefer the first for a minor security improvement (you don't have to parse completely untrusted JSON) but it being clear is much more important.

From: stir <[email-masked]> On Behalf Of Chris Wendt
Sent: 21 February 2022 15:44
To: Jack Rickard <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>
Subject: [EXTERNAL] Re: [stir] draft-ietf-stir-passport-rcd-14 rcdi for "/jcd"

I am just thinking it's better to keep the mechanism and if best practices ends up being to not do digest for direct content, so be it, but rather be in that position than to go back and have to retrofit it back later.

On Feb 21, 2022, at 10:28 AM, Jack Rickard <[email-masked]<mailto:[email-masked]>> wrote:

Hi Chris,

I agree that there's a non-obvious trade-off between size of the cert and complexity of the standard. From my point of view, I think that keeping the ability to create digests over direct claims is fine, but it still shouldn't affect verification, just like the rest of rcdi.

Thanks,
Jack

From: stir <[email-masked]<mailto:[email-masked]>> On Behalf Of Chris Wendt
Sent: 21 February 2022 15:15
To: Jack Rickard <[email-masked]<mailto:[email-masked]>>
Cc: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-14 rcdi for "/jcd"

Hi Jack, All,

As i'm working through text, I did come up with, i think, a valid justification for why you may want to keep "rcdi" digest for direct claim referenced content.  This has to do with size of claim and whether for more sizable claims you may want to simply constrain the rcdi digest (which would often be more compact) vs the content itself.

I'd be curious to hear opinions on whether the size of the JWTClaimConstraint is something to be concerned about or not. There is very realistic future of having multiple "rcd" variations in the constraints, so size may get large and be a potential issue depending how things work out.

I'm also wondering if it's ok to keep the ability to create digests over direct claim content as optional.  I think we are concerned about error cases of what happens if someone does include a digest for direct content, does that "fail" verification? And i think closing the door completely vs keeping the option to do it open won't cause too much harm for those using either approach.  Is that an ok compromise?

-Chris

On Jan 27, 2022, at 2:04 PM, Jack Rickard <[email-masked]<mailto:[email-masked]>> wrote:

Hi Chris,

I think I agree with everything you've said there, and it sounds sensible.

I do have one thing that I think worth mentioning, but I don't care all that much about it and it isn't an obvious win.
If we removed the possibility of having a rcdi covering something that wasn't a URL, then we could substantially simplify the digest creation process by specifying that you just hash the raw bytes of the HTTP body. That would get rid of the requirement to mess about with canonicalizing the JSON. It would simplify the logic required by the end user and would validate that it's trusted before they have to parse it which feels like a security win, however it would force JWT claims constraints to be over rcd and rcdi rather than just rcdi.

Thanks,
Jack

From: Chris Wendt <[email-masked]<mailto:[email-masked]>>
Sent: 27 January 2022 14:47
To: Jack Rickard <[email-masked]<mailto:[email-masked]>>
Cc: Jack Rickard <jack.rickard=[email-masked]<mailto:jack.rickard=[email-masked]>>; IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-14 rcdi for "/jcd"

Hi Jack,

So, was trying to reorient a few of the moving parts here that led to where we ended up.  With the help of some discussion with Jon, i think I can hopefully explain a bit more comprehensively and propose what i think we can do going forward.

So, there are a few things we are trying to accommodate, compact form, call-info, PASSporT claim ordering rules and integrity rules.

We obviously want to make sure that the rules are explicit about when rcd and specifically jcard data appears in the rcd claim or in the call-info or both. I think we want those to be explicitly the same, but for the purposes of PASSporT rules and related to the rcdi rules, the serialization procedures should result in explicitly the same thing.  I think where we got to the rule that /jcd had to be included as part of the JSON pointer set of digests is something we say in the document in 6.1:

"For the use of JSON pointer in "jcd" and because array indexes are dependent on the order of the elements in the jCard, the digest for the "/jcd" corresponding to the entire jCard array string MUST be included to avoid any possibility of substitution or insertion attacks that may be possible to avoid integrity detection."

So, we were concerned about whether there was potential for insertion attack that used order of JSON and digest pointers to play tricks.

I think, as you point out, and if implementations enforce the serialization/lexiographic rules of PASSporT, this should not be a concern.

So, i will review the text, and agree that we do not need to include /jcd or any directly included claim content in any of the JSON pointer digests.  /jcl of course will need that, but i think there is agreement about that.

-Chris

On Jan 19, 2022, at 10:09 AM, Jack Rickard <[email-masked]<mailto:[email-masked]>> wrote:

Hi Chris,

You can use JWT Claims Constraints to directly constrain the value of the rcd claim, as outlined in section 6.2 of the current draft (I think, JWT Claims Constraints doesn't appear to apply directly to claims whose value isn't a string). I can see that constraining rcdi would (usually) lead to smaller certificates than constraining rcd, but choosing between smaller certificates and fewer hashes feels like a decision that I don't want to have to worry about.

Thanks,
Jack

From: stir <[email-masked]<mailto:[email-masked]>> On Behalf Of Chris Wendt
Sent: 18 January 2022 21:54
To: Jack Rickard <jack.rickard=[email-masked]<mailto:jack.rickard=[email-masked]>>
Cc: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-14 rcdi for "/jcd"

Hi Jack,

I think you are missing the primary use-case we are trying to protect with "rcdi", this is where the party that is authoritative over the certificate that has JWT Constraints for the specific "rcdi" for the party (explicitly different than the authoritative party) that is authoring the "rcd" PASSporT does not have the ability to try to author different contents than what have been authorized for them to include in the JSON or in the linked data as constrained by the certificate.

If the authoritative party and party signing the PASSporT is one in the same, yes there is some unnecessary hashing occurring, but I think consistency is the better path than trying to have multiple "rcdi" flavors or constraints procedures in this case.

-Chris

On Jan 14, 2022, at 1:49 PM, Jack Rickard <jack.rickard=[email-masked]<mailto:jack.rickard=[email-masked]>> wrote:

Hi all,

I've been mulling over RCD over Christmas, and you'll be glad to know that I'm mostly happy with where it is (or will be once the rcdi changes are made). However, there is one part that is still bothering me that I'd like to ask about. Specifically, this paragraph of the spec:
   For the use of JSON pointer in "jcd" and because array indexes are
   dependent on the order of the elements in the jCard, the digest for
   the "/jcd" corresponding to the entire jCard array string MUST be
   included to avoid any possibility of substitution or insertion
   attacks that may be possible to avoid integrity detection.  Each URI
   referenced in the jCard array string MUST have a corresponding JSON
   pointer string key and digest value.

I don't think this does any harm however I also don't think it does any good; anyone who could modify the "jcd" could just as easily modify the "rcdi" entry. In fact, I don't think there's any point providing digests for anything that isn't a URI to remote content (e.g. nam and apn). Now, performing a few extra hashes per call probably won't have an impact on anything, but I'm not a fan of requiring people to do something they don't need to, and only supporting checking the hash of data from a URL could simplify some implementations.

Thanks,
Jack Rickard
he/him
Software Engineer
[email-masked]<mailto:[email-masked]>

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cjackrickard%40microsoft.com%7C1f2192d196c74b57e6b108d9f550ff8a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637810550553536864%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OeTg9KzErxCTwBsCbtOFNXkGP1ILYAVx2kjgob0b49I%3D&reserved=0>

---

From: Alec Fenichel <[email-masked]>
Date: Tue, 22 Feb 2022 15:13:04 +0000

Option 1, we should use option 1: “The hash of the body of the HTTP response”.

Sincerely,

Alec Fenichel

Chief Technology Officer

TransNexus

[email-masked]

+1 (404) 369-2407

From: stir <[email-masked]> on behalf of Jack Rickard <jackrickard=[email-masked]>
Date: Tuesday, February 22, 2022 at 10:00
To: Chris Wendt <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-14 rcdi for "/jcd"

You don't often get email from jackrickard=[email-masked]. Learn why this is important

I think I agree, although it’s a bit of shame to move away from the “hash the body of the HTTP response” model. Although, on that note please make sure that it’s clear whether for “jcl” whether the digest should be:

The hash of the body of the HTTP response

The hash of the properly formatted JSON in the response (i.e. you have to parse it and canonicalize it first)

I’d prefer the first for a minor security improvement (you don’t have to parse completely untrusted JSON) but it being clear is much more important.

I am just thinking it’s better to keep the mechanism and if best practices ends up being to not do digest for direct content, so be it, but rather be in that position than to go back and have to retrofit it back later.

On Feb 21, 2022, at 10:28 AM, Jack Rickard <[email-masked]> wrote:

Hi Chris,

I agree that there’s a non-obvious trade-off between size of the cert and complexity of the standard. From my point of view, I think that keeping the ability to create digests over direct claims is fine, but it still shouldn’t affect verification, just like the rest of rcdi.

Thanks,

Jack

Hi Jack, All,

As i’m working through text, I did come up with, i think, a valid justification for why you may want to keep “rcdi” digest for direct claim referenced content.  This has to do with size of claim and whether for more sizable claims you may want to simply constrain the rcdi digest (which would often be more compact) vs the content itself.

I’d be curious to hear opinions on whether the size of the JWTClaimConstraint is something to be concerned about or not. There is very realistic future of having multiple “rcd” variations in the constraints, so size may get large and be a potential issue depending how things work out.

I’m also wondering if it’s ok to keep the ability to create digests over direct claim content as optional.  I think we are concerned about error cases of what happens if someone does include a digest for direct content, does that “fail” verification? And i think closing the door completely vs keeping the option to do it open won’t cause too much harm for those using either approach.  Is that an ok compromise?

-Chris

On Jan 27, 2022, at 2:04 PM, Jack Rickard <[email-masked]> wrote:

Hi Chris,

I think I agree with everything you’ve said there, and it sounds sensible.

I do have one thing that I think worth mentioning, but I don’t care all that much about it and it isn’t an obvious win.

If we removed the possibility of having a rcdi covering something that wasn’t a URL, then we could substantially simplify the digest creation process by specifying that you just hash the raw bytes of the HTTP body. That would get rid of the requirement to mess about with canonicalizing the JSON. It would simplify the logic required by the end user and would validate that it’s trusted before they have to parse it which feels like a security win, however it would force JWT claims constraints to be over rcd and rcdi rather than just rcdi.

Thanks,

Jack

From: Chris Wendt <[email-masked]>
Sent: 27 January 2022 14:47
To: Jack Rickard <[email-masked]>
Cc: Jack Rickard <jack.rickard=[email-masked]>; IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-14 rcdi for "/jcd"

Hi Jack,

-Chris

On Jan 19, 2022, at 10:09 AM, Jack Rickard <[email-masked]> wrote:

Hi Chris,

You can use JWT Claims Constraints to directly constrain the value of the rcd claim, as outlined in section 6.2 of the current draft (I think, JWT Claims Constraints doesn’t appear to apply directly to claims whose value isn’t a string). I can see that constraining rcdi would (usually) lead to smaller certificates than constraining rcd, but choosing between smaller certificates and fewer hashes feels like a decision that I don’t want to have to worry about.

Thanks,

Jack

To: Jack Rickard <jack.rickard=[email-masked]>

Hi Jack,

I think you are missing the primary use-case we are trying to protect with “rcdi”, this is where the party that is authoritative over the certificate that has JWT Constraints for the specific “rcdi” for the party (explicitly different than the authoritative party) that is authoring the “rcd” PASSporT does not have the ability to try to author different contents than what have been authorized for them to include in the JSON or in the linked data as constrained by the certificate.

If the authoritative party and party signing the PASSporT is one in the same, yes there is some unnecessary hashing occurring, but I think consistency is the better path than trying to have multiple “rcdi” flavors or constraints procedures in this case.

-Chris

On Jan 14, 2022, at 1:49 PM, Jack Rickard <jack.rickard=[email-masked]> wrote:

Hi all,

I’ve been mulling over RCD over Christmas, and you’ll be glad to know that I’m mostly happy with where it is (or will be once the rcdi changes are made). However, there is one part that is still bothering me that I’d like to ask about. Specifically, this paragraph of the spec:

I don’t think this does any harm however I also don’t think it does any good; anyone who could modify the “jcd” could just as easily modify the “rcdi” entry. In fact, I don’t think there’s any point providing digests for anything that isn’t a URI to remote content (e.g. nam and apn). Now, performing a few extra hashes per call probably won’t have an impact on anything, but I’m not a fan of requiring people to do something they don’t need to, and only supporting checking the hash of data from a URL could simplify some implementations.

Thanks,

Jack Rickard
he/him
Software Engineer
[email-masked]

_______________________________________________
stir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

---

From: Chris Wendt <[email-masked]>
Date: Wed, 23 Feb 2022 08:27:05 -0500

HI Jack,

I’ll admit i didn’t fully grok what you were trying to say, now i do.  So just to clarify even more, you are saying the body is the string of a JSON object, it’s just that you may or may not serialize it according to rcd/PASSporT rules, it’s up to you as the host of the URI resource?

-Chris

> On Feb 21, 2022, at 11:58 AM, Jack Rickard <[email-masked]> wrote:
> 
> On Feb 21, 2022, at 10:28 AM, Jack Rickard <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Chris,
>  
> From: stir <[email-masked] <mailto:[email-masked]>> On Behalf Of Chris Wendt
> To: Jack Rickard <[email-masked] <mailto:[email-masked]>>
> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> On Jan 27, 2022, at 2:04 PM, Jack Rickard <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Chris,
>  
> From: Chris Wendt <[email-masked] <mailto:[email-masked]>> 
> To: Jack Rickard <[email-masked] <mailto:[email-masked]>>
> Cc: Jack Rickard <jack.rickard=[email-masked] <mailto:jack.rickard=[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> On Jan 19, 2022, at 10:09 AM, Jack Rickard <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Chris,
>  
> From: stir <[email-masked] <mailto:[email-masked]>> On Behalf Of Chris Wendt
> To: Jack Rickard <jack.rickard=[email-masked] <mailto:jack.rickard=[email-masked]>>
> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> On Jan 14, 2022, at 1:49 PM, Jack Rickard <jack.rickard=[email-masked] <mailto:jack.rickard=[email-masked]>> wrote:
>  
> Hi all,
>  
> [email-masked] <mailto:[email-masked]> 
> 
>  
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cjackrickard%40microsoft.com%7C1f2192d196c74b57e6b108d9f550ff8a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637810550553536864%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OeTg9KzErxCTwBsCbtOFNXkGP1ILYAVx2kjgob0b49I%3D&reserved=0>