Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt

["Peterson, Jon" <[e-mail]>]

I’ve been coming at this from the wrong angle. I’ve been assuming we want to stop (or at least, detect) modification of A. But in fact, what you’re saying is you want to permit modification _as long as it can be canonicalised to the same thing_. Is that correct?

Right, more or less. We can't prevent the modification of A whether we want to or not - and detecting that something has been changed is only helpful if you know that changing things is a problem - and for the kinds of changes we observe in the wild, it usually isn't a problem. What we're trying to resist in the design is the temptation to invent an A-prime with the delusional assumption that it would be safe to give A-prime integrity protection, because we intermediaries will modify A but spare A-prime. As long as there are SBCs, we have to admit the possibility that anything in the message might be modified. But yes, we want to permit A to be modified, and we do just assume that the modifications performed will permit relying parties to canonicalize the eventual value of A to the same bit-exact string (the "real" A) that the creator of the PASSporT canonicalized it to.

In which case I get this - I think.

However, the cases where this would be useful are surely limited. This requires the verifier to know and understand modifications that could be applied along the path by non-STIR-aware entities.

The verifier doesn't have to anticipate or understand the modifications performed by intermediaries, it just needs to be able to look at the end result of those modifications and perform a canonicalization procedure.

This is the basically the same discussion we were previously having on the list about the value of canonicalization. I submit, anyway, that the sorts of modifications that are practically applied by non-STIR-aware entities will still result in call signaling being routable, and that in those conditions the canonicalization we've detailed will work. We can of course imagine that entities will do weird things to telephone numbers that will make canonicalization impossible, but in those cases calls probably won't route or work well anyway. There was a chorus of voices on this list saying things to the effect that operators have dealt with this since time immemorial. I don't think there's a practical problem here. It'll work when it works, and in cases where it doesn't work, identity shouldn't be verifiable.

“Full form”, being base64 encoded, gets around a simple search/replace here, which is probably an improvement.

I don't think that would be material. If this would fix it, then we could have used the original "canon" parameter and rot13'd it. The policies are the problem, not the encoding.

Jon Peterson
Neustar, Inc.


Regards,
Alan