Subject: [Dots] clarification questions from the hackathon

From: kaname nishizuka <[email-masked]>
Date: Thu, 28 Mar 2019 19:37:44 +0900

Hi,

I'd like to continue discussion of these topics in the ML.

#1: Questions about signal-control-filtering
  1. Should a mitigation request create a mitigation before doing a PUT + acl-list [{acl-name, activation-type}] against the active mitigation, or is a ‘PUT + acl-list [{acl-name, activation-type}]’ allowed to create a new mitigation?
  2. Should the response to a GET (or Observed GET) include the acl-list [{acl-name, activation-type}] if the PUT included it?
  3. Does the response to the PUT (the echoed back response payload of the PUT representation https://tools.ietf.org/html/rfc7252#section-5.9.1.1 ) include the acl-list (if defined) or not?
  4. Is the activation change to the ACL a permanent change to the ACL (so a GET on the data channel returns the new type)?
  5. Does the activation change to the ACL count as an ACL refresh (pending-lifetime update)?
  6. Is CBOR activation –type comprehension-required or comprehension-optional?

Regarding with the 1st point, we got feedbacks from Med and Tiru that both should be allowed.
If ‘PUT + acl-list [{acl-name, activation-type}]’ allowed to create a new mitigation, it should be treated as this is a request in "attack-time".

(#2: Data Channel Implicit protocol number was addressed clearly by Med's comment.)

#3: (D)TLS session lifetime
 From the view point of DOTS server, when to expire the old (D)TLS session is implementation specific though, I'd like to hear from experts about preferable setting (timer or something else...?)

thanks,
Kaname

---

From: Olli Vanhoja <[email-masked]>
Date: Thu, 28 Mar 2019 11:47:36 +0100

Some additional questions.

I saw somewhere a probably outdated spec with a version ned URL
/.well-known/dots/v1/mitigate
This was however dropped from the draft:
/.well-known/dots/mitigate

Why is this? Wouldn't it be a good idea to allow versioning somewhere,
either in the request path or the request body?

Was there any consideration about PKI and/or key distribution? Or
should implementors and users solve this?

---

From: <[email-masked]>
Date: Thu, 28 Mar 2019 13:38:52 +0000

Re-, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de kaname nishizuka
> Envoyé : jeudi 28 mars 2019 11:38
> À : [email-masked]
> Objet : [Dots] clarification questions from the hackathon
> 
> Hi,
> 
>   1. Should a mitigation request create a mitigation before doing a PUT +
> acl-list [{acl-name, activation-type}] against the active mitigation, or is a
> ‘PUT + acl-list [{acl-name, activation-type}]’ allowed to create a new
> mitigation?

[Med] Both are currently allowed in the draft. I don't still a valid reason to restrict this. 

>   2. Should the response to a GET (or Observed GET) include the acl-list
> [{acl-name, activation-type}] if the PUT included it?

[Med] The current spec says "no". That's said, what would be the value in returning it? Then, why not allowing to return the references to all ACLs that are enabled during the mitigation time?

>   3. Does the response to the PUT (the echoed back response payload of the
> PUT representation https://tools.ietf.org/html/rfc7252#section-5.9.1.1 )
> include the acl-list (if defined) or not?

[Med] It doesn't as we don't change the behavior of the base spec.

>   4. Is the activation change to the ACL a permanent change to the ACL (so a
> GET on the data channel returns the new type)?

[Med] Yes. The draft will be updated to make this clearer. 

>   5. Does the activation change to the ACL count as an ACL refresh (pending-

[Med] Yes. Some text will be added to clarify the refresh point. That's said, as discussed in the data-channel, the dots client may need to send a GET after an attack for sync purposes.

>   6. Is CBOR activation –type comprehension-required or comprehension-

[Med] This is a comprehension-required attribute (already discussed in the draft).

> If ‘PUT + acl-list [{acl-name, activation-type}]’ allowed to create a new
> mitigation, it should be treated as this is a request in "attack-time".

[Med] I confirm.

>  From the view point of DOTS server, when to expire the old (D)TLS session is
> implementation specific though, I'd like to hear from experts about
> preferable setting (timer or something else...?)
> 

[Med] For me, this is implementation-specific.  

> thanks,

[Med] Many thanks for sharing the feedback from the hackathon. Much appreciated. 

> Kaname
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Thu, 28 Mar 2019 13:56:42 +0000

Hi Olli,

Please see inline. 

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de Olli Vanhoja
> Envoyé : jeudi 28 mars 2019 11:48
> À : kaname nishizuka
> Cc : [email-masked]
> Objet : Re: [Dots] clarification questions from the hackathon
> 

[Med] That change was made to reflect a change in the requirements I-D with regards to versioning. The spec relies on two sets of attributes (comprehension-required, comprehension-optional) to extend the protocol by adding new features instead of bumping the version number. 

> should implementors and users solve this?

[Med] This is left to deployments. Existing specs do only say the following:

   A key challenge to deploying DOTS is the provisioning of DOTS
   clients, including the distribution of keying material to DOTS
   clients to enable the required mutual authentication of DOTS agents.
   Enrollment over Secure Transport (EST) [RFC7030] defines a method of
   certificate enrollment by which domains operating DOTS servers may
   provide DOTS clients with all the necessary cryptographic keying
   material, including a private key and a certificate to authenticate
   themselves.  One deployment option is DOTS clients behave as EST
   clients for certificate enrollment from an EST server provisioned by
   the mitigation provider.  This document does not specify which EST or
   other mechanism the DOTS client uses to achieve initial enrollment.

Having deployment guidelines would be helpful, though.