Ben Kaduk's Invariants Comment 2

[LPardue]

@kaduk said:

Section 5.3

In the discussion of DTLS 1.2 connection IDs we had a fair bit of
discussion about what "opaque" means, whether any internal structure
(e.g., when variable-length CIDs are used) must be self-delineating,
which endpoint(s) need to know the self-delineating format, etc.. This
was largely in the context of what data is used as input to the MAC for
non-AEAD cipher modes (in the document as sent to the IESG by the WG,
the party that does not know the CID structure could be convinced to
generate a MAC using a modified CID and create a MAC value that would be
valid for a different plaintext, leading to a change in where the
cid_length field is placed in the input), and I don't expect the topics
we discussed to lead to any change in the text here. The only possible
thing I could think of is that the field is "opaque" at the protocol
level but may have internal structure known to the endpoint that chooses
it (but that's arguably self-evident).

[martinthomson]

So I think that the high-level "opaque" is correct and the subsequent discussion of purpose makes it clear.

One thing that is important in this document is to avoid over-indexing on semantics, so this definition is deliberately vague.

Separately, Fernando Gont suggests that we need more text regarding connection ID construction, which I disagree with. Whatever the outcome of that discussion, I don't think that this document is where the outcome would be captured, it's something that would be version-specific (so -transport instead).

[kaduk]

Thanks. I propose close with no change.