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

[Alec Fenichel <[e-mail]>]

Agreed!

 

Sincerely,

 

Alec Fenichel

Senior Software Architect

[e-mail]

[phone]

TransNexus

 

From: stir <[e-mail]> on behalf of Jack Rickard <jack.rickard=[e-mail]>
Date: Wednesday, October 20, 2021 at 08:30
To: IETF STIR Mail List <[e-mail]>, Russ Housley <[e-mail]>
Subject: Re: [stir] draft-ietf-stir-passport-rcd-13 rcdi validation

You don't often get email from jack.rickard=[e-mail]. http://aka.ms/LearnAboutSenderIdentification" rel="nofollow">Learn why this is important

An additional thing I’ve just thought of: it’s ~impossible for a verification service to know which URLs in the jCard need an rcdi entry (for example, a link to your website doesn’t need one), but it’s very easy for the end entity, it needs an rcdi entry for any URL it dereferences.

 

From: stir <[e-mail]> On Behalf Of Jack Rickard
Sent: 20 October 2021 12:37
To: IETF STIR Mail List <[e-mail]>; Russ Housley <[e-mail]>
Subject: [EXTERNAL] [stir] draft-ietf-stir-passport-rcd-13 rcdi validation

 

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]