Use CRA and CRI parameters for CASE and PASE session establishment

[pan-apple]

Problem

A device can override MRP timeouts by advertising CRA and CRI as part of DNSSD records. The peer devices must override the default MRP timeouts with the advertised values. This override is critical for ideal functioning of battery operated devices. These override values must be used while exchange messages for PASE and CASE session establishments.

PASE and CASE session establishment messages can optionally provide further overrides of MRP parameters via PBKDFParamRequest/PBKDFParamResponse and Sigma1/Sigma2 messages. If overrides are provided, the message exchanges, that are using the secure channels established via these CASE/PASE sessions, must override their MRP parameters with the provided values.

[kkasperczyk-no]

@pan-apple @tcarmelveilleux from what I understand it may happen that the default MRP parameters or the one set based on discovered CRA/CRI values are overridden by the values provided in PASE/CASE messages. So those session values have kind of higher priority than the one advertised in the DNS-SD records and it should not happen that MRP parameters values will be overridden in the opposite situation (the discovered ones will override session values), right?

I was wondering what should happen if the session was established and we've got MRP parameter values provided by it, but then accessory device by some reason changed sleep intervals and updated advertised CRI/CRA values. Can we end in the situation when the data provided in the session became obsolete, but we can't update it, because of the lower discovered data priority?

[tcarmelveilleux]

I was wondering what should happen if the session was established and we've got MRP parameter values provided by it, but then accessory device by some reason changed sleep intervals and updated advertised CRI/CRA values. Can we end in the situation when the data provided in the session became obsolete, but we can't update it, because of the lower discovered data priority?

• Devices should not change the values over time during a same boot. The mechanism of CRA/CRI was not designed to support this. There are bigger issues in that the spec does not make CRA/CRI mandatory anyway, and any data obtained with DNS-SD is already not fully trustworthy (can be tampered).
• If they do anyway, and the new values don't work, the sessions will die at some point on errors, and the new values obtained on re-establishment

[kkasperczyk-no]

Devices should not change the values over time during a same boot.

Why is that? It's true that spec doesn't say anything about it, but it also doesn't say it's not allowed. I don't really have a strong need to use it in any example, but isn't it the valid case and some product vendors could benefit from it (e.g. to change poll intervals of the device depending on its battery state or some device operation state)?

There are bigger issues in that the spec does not make CRA/CRI mandatory anyway

That's true, but as far as I remember Skip from Infineon (sorry can't find the name on a github to mark him) proposed spec changes and he wanted to make advertising CRA/CRI mandatory for the sleepy end devices.

any data obtained with DNS-SD is already not fully trustworthy (can be tampered).

I was not aware of such statement. Actually we already have implemented in the code updating the DNS-SD services on SED polling interval changes (https://github.com/project-chip/connectedhomeip/blob/master/src/app/server/Dnssd.cpp#L63), so it could be used by the controller to keep MRP parameter values up to date with the SED configuration.

I believe it was discussed on the synchronization meeting regarding SED support and also in this issue: #11040, so if it seems not appropriate maybe we should discuss it once again and somehow figure out common direction to go?

[SkipAshton]

I think there are some basics we need to agree to as we try and close this out.

1. Sleepy devices SHALL include CRA/CRI values in their DNS and in any PASE or CASE setup exchanges. Sending devices SHALL assume those devices with non-default CRA/CRI values are sleepy devices.
2. If a sleepy device updates its CRA/CRI during operation it SHALL update its DNS and include the new values in any PASE or CASE setup exchanges.
3. If a device sending to a sleepy has one set of CRA/CRI from DNS and another from a PASE or CASE session - it SHOULD use the PASE or CASE established values. (These are more likely to be up to date since DNS entry could be old and I can always start a new CASE session)

@turon was going to make spec changes to incorporate this in his items 4651, 4652 and 4653 in the spec github

[turon]

Per discussion: use last values heard either via mDNS or CASE/PASE.

Allows dynamic values.

If mDNS is hacked, IP address can be changed anyway, so parameter hacking isn't the first-order attack.