Subject: [secdir] Secdir telechat review of draft-ietf-dots-signal-channel-31

From: Stephen Farrell via Datatracker <[email-masked]>
Date: Mon, 15 Apr 2019 05:21:22 -0700

Reviewer: Stephen Farrell
Review result: Has Issues

I took a look at the changes between -30 and -31 and at the mail
following my earlier review of -30.

To explain the "has issues" status for this review: Generally, I
think this is probably ok, but I (still) have the concerns listed
below that the ADs might wanna think about. The authors already
responded on each of these points, and made some corresponding
changes, so I guess they reckon these are non-issues. (Which is of
course fine - even if I don't quite agree, I'm often wrong:-)

- p13: The cuid still seems to me to be too static (there's a
SHOULD saying to tie it to the client certificate public key
or an equivalent).  I still think recommending a way to generate
an identifier that isn't tied to a key pair would be 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 without mapping 1:1 to possibly long-lived key
pairs. (-31 does say some more about how to change cuid, but still
has the same SHOULD/RECOMMENDED way to generate cuid values.)

- I wondered if a bad actor in control of an authorised DOTS
client colluding with the controller of a DDoS attack could use
this protocol to probe the network to see how their attack is
going and change the attack to be more effective.  In mail, the
authors stated that this isn't possible, and added text saying
that to -31. That may be true, but I'm not sure (given the
complexity of the protocol).

A nit:

- p91: The mention of TCP-AO seems to require suspension of
disbelief (given the lack of deployment of TCP-AO).  If we don't
think it'll be used, it'd be better to not pretend it might get
used.

---

From: <[email-masked]>
Date: Mon, 15 Apr 2019 13:16:35 +0000

Hi Stephen, all, 

Please see inline for the first item. 

Cheers,
Med

> -----Message d'origine-----
> De : Stephen Farrell via Datatracker [mailto:[email-masked]]
> Envoyé : lundi 15 avril 2019 14:21
> À : [email-masked]
> Cc : [email-masked]; [email-masked];
> [email-masked]
> Objet : Secdir telechat review of draft-ietf-dots-signal-channel-31
> 

[Med] This is a feature not a bug. This scheme is particularly useful to recover state, for example, upon reboot or crash of a DOTS client.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Apr 2019 14:25:43 +0100

Hiya,

On 15/04/2019 14:16, [email-masked] wrote:
> [Med] This is a feature not a bug. This scheme is particularly useful
> to recover state, for example, upon reboot or crash of a DOTS client.
> 

Well, fair enough, but FWIW I'm not convinced that a
client that can keep state (the private key and other
dots stuff) couldn't also as easily keep a cuid value.
And ISTM there should also be equally good ways to
recommend for generating a cuid that don't have that
1:1 mapping to a key pair. All that said, it's not me
needs to be convinced, but the IESG, so probably best
to wait and see if they think this is worth changing
or not before doing so.

S.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 15 Apr 2019 14:38:01 +0000

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of Stephen Farrell
> Sent: Monday, April 15, 2019 6:56 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31
> 
> 
> Hiya,
> 
> Well, fair enough, but FWIW I'm not convinced that a client that can keep state
> (the private key and other dots stuff) couldn't also as easily keep a cuid value.
> And ISTM there should also be equally good ways to recommend for generating
> a cuid that don't have that
> 1:1 mapping to a key pair. All that said, it's not me needs to be convinced, but
> the IESG, so probably best to wait and see if they think this is worth changing or
> not before doing so.

The advantage of the 1:1 mapping is the DOTS servers can validate the DOTS client is not using the 'cuid' of another client. 

-Tiru

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Apr 2019 15:57:49 +0100

On 15/04/2019 15:38, Konda, Tirumaleswar Reddy wrote:
>> -----Original Message----- From: Dots <[email-masked]> On
>> Behalf Of Stephen Farrell Sent: Monday, April 15, 2019 6:56 PM To:
>> [email-masked]; [email-masked] Cc:
>> [email-masked]; [email-masked];
>> [email-masked] Subject: Re: [Dots] Secdir telechat review of
>> draft-ietf-dots-signal-channel-31
>> 
>> 
>> Hiya,
>> 
>>> [Med] This is a feature not a bug. This scheme is particularly
>>> useful to recover state, for example, upon reboot or crash of a
>>> DOTS client.
>>> 
>> 
>> Well, fair enough, but FWIW I'm not convinced that a client that
>> can keep state (the private key and other dots stuff) couldn't also
>> as easily keep a cuid value. And ISTM there should also be equally
>> good ways to recommend for generating a cuid that don't have that 
>> 1:1 mapping to a key pair. All that said, it's not me needs to be
>> convinced, but the IESG, so probably best to wait and see if they
>> think this is worth changing or not before doing so.
> 
> The advantage of the 1:1 mapping is the DOTS servers can validate the
> DOTS client is not using the 'cuid' of another client.

So that'd be "an" advantage, if it is one;-)

But given the servers are supposed to authenticate
the client via TLS client-auth (or else the server
doesn't see the public key), I don't see the need.
Nor do I recall that the server is supposed to compare
the key to the cuid - if that check is to be done,
then that'd need to be in the spec or a client that
re-keys would have to make a new cuid. (Apologies
if that's in the spec and I've forgotten it.)

Cheers,
S.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 15 Apr 2019 15:18:40 +0000

> From: Stephen Farrell <[email-masked]>
> Sent: Monday, April 15, 2019 8:28 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> [email-masked]; [email-masked]
> >>> useful to recover state, for example, upon reboot or crash of a DOTS
> >>> client.
> >>>
> >>
> >> Well, fair enough, but FWIW I'm not convinced that a client that can
> >> keep state (the private key and other dots stuff) couldn't also as
> >> easily keep a cuid value. And ISTM there should also be equally good
> >> ways to recommend for generating a cuid that don't have that
> But given the servers are supposed to authenticate the client via TLS client-auth
> (or else the server doesn't see the public key), I don't see the need.

The above validation helps defend against a compromised DOTS client using the 'cuid' of another DOTS client. 

-Tiru

> Nor do I recall that the server is supposed to compare the key to the cuid - if
> that check is to be done, then that'd need to be in the spec or a client that re-
> keys would have to make a new cuid. (Apologies if that's in the spec and I've
> forgotten it.)
> 
> Cheers,
> S.
> 
> 
> >
> > -Tiru
> >
> >>
> >> S.
> >>
> >