Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation

[Alec Fenichel <[e-mail]>]

Hey Chris,

 

I don’t feel that after reading the proposed text an originating service provider would properly implement verification. Maybe further details should be added in IP-NNI not here, but I think they need to be somewhere.

 

Sincerely,

 

Alec Fenichel

Senior Software Architect

[e-mail]

[phone]

TransNexus

 

From: Chris Wendt <[e-mail]>
Date: Monday, October 25, 2021 at 14:27
To: Jack Rickard <[e-mail]>
Cc: Alec Fenichel <[e-mail]>, Ben Campbell <[e-mail]>, IETF STIR Mail List <[e-mail]>, Russ Housley <[e-mail]>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation

I will be submitting a new draft very soon, but here is the paragraph i added to the verification section (without modifying the existing text)  Hopefully this is a good compromise, I sort of think it is and captures what everyone has been discussing, but let me know.  

 

-Chris

 

"In some middle box scenarios, a relying party may not have the need to validate content that is referenced by URIs (e.g. only wanting to validate base PASSporT info like "orig" and "dest" or other "rcd" info like "nam" or "apn"). In these scenarios, this proceedure while not considered a full verification, can be performed without verifying the full integrity checks of URI referenced content."

On Oct 25, 2021, at 1:38 PM, Jack Rickard <jack.rickard=[e-mail]> wrote:

 

I’d also lean towards SHOULD NOT, for the same reasons. Anyone who wants to check the digests is only going to cause harm unless they are in a very odd situation.

 

Jack 

 

From: stir <[e-mail]> On Behalf Of Alec Fenichel
Sent: 25 October 2021 17:41
To: Ben Campbell <[e-mail]>
Cc: IETF STIR Mail List <[e-mail]>; Jack Rickard <jack.rickard=[e-mail]>; Russ Housley <[e-mail]>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation

 

Ben,

 

I am flexible on the strength of the language in the spec. I just think we need to be very clear in the spec that the OSP verifying the integrity is all but useless. Resources are going to be cached. I would expect that just like certificates, the cache hit ratio will be extremely high (we see 99.99%+). So it is likely that one or both parties are just checking their cached copy of the resources, not the actual resources. So the OSP checking that the integrity matches does not indicate that it will match when the dereferencing entity checks the integrity.

 

 

 

> I think some of the big OSPs might choose not to send RCD claims at all if they cannot fully verify them at the time of transmission.

 

This check provides a false sense of security not any actual security. I just think we need to make sure that is understood.

 

 

 

> Local policy? Again, I suspect some operators will have a local policy of “send nothing I can’t be sure of”, even if that means “don’t send the other parts that might be fine."

 

They can’t be sure of it even if they check. Again, I think it is important that we make sure everyone understands that the OSP checking does not mean, or even imply, it will match when the dereferencing entity checks.

 

 

 

> No expectation to dereference is different than an expectation not to dereference. I support the former, not the latter, at least in the IETF spec.

 

I’m good with either so long as we make it clear what checking the integrity accomplishes (or in the OSP case, does not accomplish).

 

 

 

> But in any case, I’m not going to die on this hill. I prefer ‘MAY, or even just not saying anything. But If others want “SHOULD NOT”, I can live with it.

 

If we just say that the OSP MAY check, then this may be interpreted as something that is optional but provides better security, which it does not. So if we say MAY, then I think it is important to explain how checking doesn’t accomplish anything.

 

 

Sincerely,

 

Alec Fenichel

Senior Software Architect

[e-mail]

[phone]

TransNexus

 

From: Ben Campbell <[e-mail]>
Date: Monday, October 25, 2021 at 12:10
To: Alec Fenichel <[e-mail]>
Cc: Jack Rickard <jack.rickard=[e-mail]>, IETF STIR Mail List <[e-mail]>, Russ Housley <[e-mail]>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation

Hi, see inline:

 

On Oct 25, 2021, at 10:45 AM, Alec Fenichel <[e-mail]> wrote:

 

I think SHOULD NOT is what we want.

 

What happens if the integrity check fails? I would argue the OSP should still send it downstream including inserting it into their “shaken” PASSporT. So dereferencing the resources just adds post dial delay if the outcome of checking the integrity doesn’t change the expected behavior.

 

I think some of the big OSPs might choose not to send RCD claims at all if they cannot fully verify them at the time of transmission. I recognize that is not ideal from an end-to-end trust model for RCD and delegate certs, but the current status quo is OSPs don’t send RCDl, and I get the impression that some operators are nervous about the idea of doing it in the first place.

 

I do suspect that, when they fully understand the cost of verifying RCDi for every call, they will choose not to do so. But I think that is their choice to make,

 

 

 

Also, there could be a dozen resources (logos of various sizes). What if one of them failed to download (server 404) but the rest worked? How do you handle a partial failure? I think we want to avoid having to address this scenario.

 

Local policy? Again, I suspect some operators will have a local policy of “send nothing I can’t be sure of”, even if that means “don’t send the other parts that might be fine."

 

 

We should make it clear that there is absolutely no expectation that the OSP dereferences the resources. The OSPs simply passes what they receive (assuming all of the other validation checks pass).

 

No expectation to dereference is different than an expectation not to dereference. I support the former, not the latter, at least in the IETF spec. (I could imagine IP-NNI strengthening the requirement to the latter). 

 

But in any case, I’m not going to die on this hill. I prefer ‘MAY, or even just not saying anything. But If others want “SHOULD NOT”, I can live with it.

 

Ben.

 

 

Sincerely,

 

Alec Fenichel

Senior Software Architect

[e-mail]

[phone]

TransNexus

 

From: Ben Campbell <[e-mail]>
Date: Monday, October 25, 2021 at 11:29
To: Alec Fenichel <[e-mail]>
Cc: Jack Rickard <jack.rickard=[e-mail]>, IETF STIR Mail List <[e-mail]>, Russ Housley <[e-mail]>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation

Do you mean the second sentence to have the strength of a SHOULD NOT? I can imagine an OSP that might prefer not to transmit any RCD content without confirming it is valid at the time of transmission. Perhaps for liability or contractual reasons. Would we want to strongly discourage that, or just leave it as local policy? 

 

One particular use case I can imagine is an OSP that copies RCD claims into it's SHAKEN certificate to be signed with its own credentials. While that might not really require them to verify integrity if they include the RCDi claim, they may well have an aversion to signing something that they haven’t completely verified.  (Assuming they don’t also rehost the external content as part of this, in which case they would need to verify integrity)

 

Thanks!

 

Ben.

 

 

On Oct 25, 2021, at 10:18 AM, Alec Fenichel <[e-mail]> wrote:

 

Another way of putting it: the entity dereferencing the resource must verify that the resource matches the supplied integrity. The resource should not be dereferenced for the sake of verifying the integrity.

 

Sincerely,

 

Alec Fenichel

Senior Software Architect

[e-mail]

[phone]

TransNexus

 

From: stir <[e-mail]> on behalf of Ben Campbell <[e-mail]>
Date: Monday, October 25, 2021 at 11:07
To: Jack Rickard <jack.rickard=[e-mail]>
Cc: IETF STIR Mail List <[e-mail]>, Russ Housley <[e-mail]>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation

(as individual)

 

I think I agree with you in general. To paraphrase the conclusions:

 

The VS MUST verify the passport signature and the claim constraints. That verifies that the claim values are correct has signed by the  AS, for example that the value in the rcdi is the correct value. Any party that uses RCD claims that are covered by an rcdi hash MUST verify that hash before trusting that content. Other parties MAY verify it according to local policy.

 

Does that match your thoughts?

 

On Oct 20, 2021, at 6:37 AM, Jack Rickard <jack.rickard=[e-mail]> wrote:

 

Hi all,

 

To clarify things, and hopefully reduce the number of rounds of review, this is a write-up of my position (and hopefully some alternative positions) on rcdi validation.

 

rcdi is a mechanism to ensure the integrity of the rcd information, and so any entity that retrieves/uses the rcd information clearly must validate that information against the rcdi digests, otherwise it could not trust what it had downloaded.

 

However, any verification service that does not need to retrieve the RCD information, cannot and possibly should not always retrieve and validate it, for a few reasons:

1. There isn’t enough time – downloading and validating all the data (or in fact any data) takes a prohibitively long time, especially as an intermediate verification service does not know which bits of data are going to be used.
2. The data could change – even if an intermediate does perform the validation, the end entity must repeat this as the information it retrieves could very well be different to what the intermediate validated.

1. There was discussion in the meeting of a TSP that rehosted the RCD information, in that case it is the end entity in this discussion and realistically needs its own integrity mechanism on what it has rehosted.

3. An intermediate could reject something that the end entity would accept – downloading information from the internet is not perfectly reliable, there could be firewall issues, or just temporary server issues that cause an intermediate validator to not be able to get the RCD information, in which case it would fail to validate the passport and throw out all the rcd information (and potentially all the STIR information). An end entity does not have to do this, it might be able to retrieve items the intermediate cannot, it might not want all the information in the first place, and in the worst case it can gracefully degrade the rcd information it cannot access.

 

Taking all of that, I believe that the rcd and rcdi information should be treated as “valid” in the context of PASSporT verification if the data in the PASSporT is correct (this would include checking JWTClaimConstraints), but not depend on any of the referenced information’s integrity.

 

There is a question there about “/rcd”,”/nam”, and “/apn” digests, for the sake of simplicity I’d suggest they also aren’t required to be checked by the verifier, but I don’t believe it matters.

 

There are some issues with this approach though:

1. Security is more complicated – this split validation model introduces extra complexity to the security of RCD information in PASSporTs. As far as I can tell, this wouldn’t introduce any new attack vectors, but does place a greater burden on the end entity doing things correctly.
2. This introduces a new entity – I don’t believe any previous documents have made a distinction between the end entity and verification services, just focusing on authentication services and verification services. This introduces actions that this end entity must perform for the system to conform to the standard.

 

 

Those issues are not enough to change my mind; however, I welcome different opinions and there are almost certainly more I haven’t thought of or weren’t discussed.

 

Thanks,

Jack Rickard 
he/him 
Software Engineer 
[e-mail] 

<Picture (Device Independent Bitmap) 1.jpg>

 

 

 

 

_______________________________________________
stir mailing list
[e-mail]
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Calec.fenichel%40transnexus.com%7C29d6fc72c9434eb3744908d997e50673%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C637707832646354119%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=pY3iF6dbE3XqXX68PSzQnji46KyiQx2G%2BGcfLrFHyEs%3D&reserved=0" rel="nofollow">https://www.ietf.org/mailman/listinfo/stir

 

_______________________________________________
stir mailing list
[e-mail]
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Calec.fenichel%40transnexus.com%7C29d6fc72c9434eb3744908d997e50673%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C637707832646364107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=22%2F38PtcLawBT%2FKqEqw3ZxLH5kKJKYCuHjbCVU9DLSQ%3D&reserved=0" rel="nofollow">https://www.ietf.org/mailman/listinfo/stir