Re: [Dots] Secdir last call review of draft-ietf-dots-signal-channel-30

[Stephen Farrell <[e-mail]>]

Hiya,

Just on two bits below...

I'm happy to chat more but also fine that you and the ADs can
sort this out according to however the ADs see this.

On 14/03/2019 16:17, [e-mail] wrote:

>> I think there's one issue with this draft that'd be well worth
>> discussion and/or fixing:
>> 
>> - p12: Why does the cuid need to be so static? I would have thought
>> that an identifier that can change more often than a key pair would
>> have been better, esp if this could be used in a CPE. (Creating a
>> new long-lived identifier for a CPE seems like a bad plan if it's
>> not really needed.) For example, one could use both the SPKI and a
>> timestamp as input for a recommended way to generate a cuid and
>> that should be as unique, but much more easily changed.  That could
>> also mitigate the possible TLS1.2 client-cert snooping issue
>> mentioned on p90.
> 
> [Med] cuid is used for avoidance detection but also as a stable key
> to identify resources at the server side. Any change of the cuid will
> lead to a failure in accessing the resources. Furthermore, this
> identifier is used to "glue" the signal and data channels.
> 
> The spec does not forbid the clients to change its cuid, but to do
> so, the client will need to manage state migration.

Yep, I get that. But the current alg that's described for
cuid calculation has the effect of creating an identifier
with the same lifetime as a key pair. Assuming keys are
harder to change than cuids it seems better to encourage
clients to not make such a tight linkage between cuid and
keys, esp. if the client is on a CPE. (And it avoids the
TLS1.2 snooping issue as noted.)

I'd encourage you to consider maybe saying some more about
how clients can change cuid, but even if not, to provide
a cuid calculation example that doesn't link only to the
key pair.

>> - Couldn't a bad actor in control of an authorised DOTS client
>> colluding with the controller of a DDoS attack use this to probe
>> the system to see how their attack is going and change the attack
>> to be more effective?
> 
> [Med] The client will only see the reports for attacks it detected
> and signaled. That bad actor won't signal the attack in the first
> place!

Perhaps I wasn't clear. ISTM that all clients can get information
about how an attack is being seen at other clients, isn't that
right? (The spec does talk about that IIRC.) The colluding client
might or might not be under attack but non-compromised clients will
presumably ask for the attack to be mitigated. So the colluding
client could use this protocol to probe and see how well or badly
the DDoS-mitigation infrastructure is handling an ongoing attack.
I'm basically saying that that may be noteworthy as a security
consideration.

Cheers,
S.


> 
> I don't
>> think any protocol change could help there, but perhaps you could
>> give some guidance to implementers to try catch such cases (e.g.,
>> if the probing DOTS client's local n/w doesn't actually appear to
>> be under attack).
>> 
>