IRSG Review (Dave Oran): Security considerations

[renghardt]

From the IRSG review by Dave Oran:

Where you say “…or be able to verify the authenticity, integrity, and correctness…” it isn’t clear what might constitute verification and what entity might do it. Would it help to say “independently verify”? I admit to being somewhat confused, even after a bit of pondering, what is the logic behind the statement “Properties related to confidentiality, integrity, and trust are orthogonal to the path terminology and path properties defined in this document.” Do you really mean they are orthogonal, and hence not candidates to be represented in path properties, or rather that simply you didn’t consider them in this document and placed them out of scope of what the document tries to accomplish. If the latter, then perhaps just say that. If the former, the logic seems based on the later statement that “the path is typically oblivious to them” and “confidentiality, integrity, and trust describe what function the communicating parties apply to packets”. I’m pretty much a proven non-expert in security, so let me pose a test case. A user cares whether his packet headers are exposed to path elements on the path as this could leak information that’s sensitive. He can’t simply encrypt the headers before transmitting the packet on the path, since it’s these headers which are used (at least by the entry and exit nodes of the path) to forward the packet over the path. Therefore would a useful path property be the confidentiality of packet headers for packets sent over a given path?

[renghardt]

Where you say “…or be able to verify the authenticity, integrity, and correctness…” it isn’t clear what might constitute verification and what entity might do it. Would it help to say “independently verify”?

Yes, that's what we mean here.

To the other question:

We left path properties related to confidentiality, integrity, and trust out of scope for this document for multiple reasons. One, the document aims to answer question 1 in RFC9217, and trust comes up only in question 2, which seemed like a whole additional dimension. Two, RFC9049 agrees that trustworthiness of properties between nodes tends to turn up a "minefield full of dragons", therefore, I would not consider such properties as good examples for this document.

So I'd say that, by "orthogonal", we mostly mean that this document is answering a different question. That said, I also have a hunch that defining a "confidentiality" path property might require extending our definition of path property. A property is currently defined as a trait of (a flow with respect to) one or a sequence of path elements, but for confidentiality, we'd have to also define it with respect to an entity such as an observer who may or may not have the required keys to decrypt the data. I think that's what we mean by the latter statement, but I'll let @cyrill-k correct me if I'm wrong.

[daveoran]

You night want to ask more broadly (i.e. not just me) about the statement "Such properties are tied to the communicating nodes and the protocols they use (e.g., client and server using HTTPS, or client and remote network node using VPN) as well as additional context such as keying material and who has access to this context. In contrast, the path as defined in this document is typically oblivious to these aspects."

The fact that there are configuration parameters and state held by the entity establishing and maintaining a path element doesn't for me argue persuasively that certain security-related properties of the path element (e.g. what is integrity protected and how, what is confidentiality protected and how) to not be exposed as path properties. For a non-security related example, whether certain compression techniques make the path element more amenable to certain data patterns might be a path element property despite the creator/maintainer of the path element needing information like compression dictionaries or initialization parameters. One could argue those are pretty similar to keying or integrity hash information.

As I've said, I'm far from the best person to delve into this, but I'd feel more comfortable if some more eyes were on this.

[renghardt]

I remember having discussions about security properties at PANRG meetings, e.g., at IETF 106 related to the transparency definition. In my mind, everyone agreed that it's an interesting and really hard question, and nobody wanted to propose a definitive answer of how these should be handled. And I already mentioned RFC9049 calling it a "minefield full of dragons". So I don't know if we as a Research Group have a good definitive answer on this. Maybe it's better to say less here.

That said, I'm happy to have an additional reviewer look at this, and/or ask the Research Group, e.g., in an email thread. @boucadair as the document shepherd, what do you think is the right course of action?

[daveoran]

I mentioned the alternative of simply saying something along the lines of "the need for, and potential definition of, security and privacy related path properties are the subject of ongoing discussion and research (e.g. in RFC9049) and hence too immature for inclusion in the document at this time."

[boucadair]

@daveoran's proposal makes sense to me. I would simply add that sentence to the document. Thanks, @theri.

[renghardt]

Yes, makes sense, thank you. I also marked some of our statements as more of a discussion point, rather than a clear and undisputed discussion outcome or fact. Please let me know your thoughts, either here or on the PR.