Subject: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 6 Oct 2020 14:43:04 +0300

Hi,

this message starts a two-week working group last call for draft-ietf-dots-rfc8782-bis-01,
which will end on Wednesday, October 21. Please, review the draft carefully and
send your comments to the mailing list.

Regards,
Frank & Valery.

---

From: Yasuaki Morita <[email-masked]>
Date: Tue, 6 Oct 2020 12:01:44 +0000

Hi all,

Let me point out two things about the draft.

First, lifetime is defined to be an optional leaf on the Yang tree diagram.
But lifetime is mandatory as other parts of the draft and I believe
that `lifetime?` in the tree should be replaced by `lifetime`.

Here is an excerpt from the tree-diagram:

      structure dots-signal:
        +-- (message-type)?
           +--:(mitigation-scope)
           |  +-- scope* []
           ...(snip)...
           |     +-- lifetime?                     union

>From the description of lifetime:

   lifetime:  Lifetime of the mitigation request in seconds.
      ...(snip)...
      The DOTS server MUST always indicate the actual lifetime in the
      response and the remaining lifetime in status messages sent to the
      DOTS client.
      This is a mandatory attribute.

Second, I guess that the attribute `:(client-to-server-only)` for
attack-status in the tree diagram is redundant or confusing.
I believe that the clients should be able to obtain its current
attack-status from the server, but `:(client-to-server-only)` seems
like forbidding it.
There is no reason to restrict the server sending attack-status to the clients.
So I suggest that we simply write

           |        +-- attack-status?
           |                iana-dots-signal:attack-status

instead of

           |        +--:(client-to-server-only)
           |           +-- attack-status?
           |                   iana-dots-signal:attack-status

Best regards
Yasuaki

On Tue, 6 Oct 2020 at 11:43, Valery Smyslov <[email-masked]> wrote:
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Tue, 6 Oct 2020 12:48:54 +0000

Hi Yasuaki, 

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Yasuaki Morita [mailto:[email-masked]]
> Envoyé : mardi 6 octobre 2020 14:02
> À : Valery Smyslov <[email-masked]>
> Cc : [email-masked]; [email-masked]; draft-ietf-dots-rfc8782-
> [email-masked]
> Objet : Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01
> 
> Hi all,
> 

[Med] I confirm.

> But lifetime is mandatory as other parts of the draft

[Med] It is mandatory in a request and an accepted mitigation response, but not in a conflict response for instance.

The structure applies of the mitigation independently whether this a request, response, conflict, efficacy update, etc.  

 and I believe
> attack-status from the server, but `:(client-to-server-only)` seems

[Med] "attack-status" is an attribute that is sent by a client to share its view on the attack with the server. The server manipulates "status" to report the status as seen at the server side. 

The server does not include the "attack-status" (received from the client) in a GET.

> There is no reason to restrict the server sending attack-status to

[Med] What would be the use case if that constraint was relaxed?

> > this message starts a two-week working group last call for
> > draft-ietf-dots-rfc8782-bis-01, which will end on Wednesday,
> October
> > 21. Please, review the draft carefully and send your comments to
> the mailing list.
> >
> > Regards,
> > Frank & Valery.
> >

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Yasuaki Morita <[email-masked]>
Date: Tue, 6 Oct 2020 14:58:22 +0000

Hi Med

Thank you for your reply.

> The structure applies of the mitigation independently whether this a request, response, conflict, efficacy update, etc.

I see, I understand.

> > There is no reason to restrict the server sending attack-status to

Perhaps this is something I didn't understand correctly about the use
of "attack-status" in RFC8782 (not bis), which defines "attack-status"
as the following.

           |     +--rw attack-status?          iana-signal:attack-status

> [Med] What would be the use case if that constraint was relaxed?

I can explain the use case but I am not sure it is meaningful.
Let a client send a PUT mitigation request to the server, and another
client program send a GET request to obtain that mitigation request.
In this case, the latter client might get more information if the GET
response includes attack-status.

---

From: <[email-masked]>
Date: Wed, 7 Oct 2020 06:24:01 +0000

Hi Yasuaki, 

Thank you for clarifying. 

> Let a client send a PUT mitigation request to the server, and
> another client program send a GET request to obtain that mitigation
> request.
> In this case, the latter client might get more information if the
> GET response includes attack-status.

(Putting aside how the information will be used by the second client: anomaly detect among clients of the same domain(?))

This assumes that the server maintains two mitigation requests with conflicting scopes and which are issued by distinct clients of the same domain. This is not allowed in the current spec. When such mitigations are received, is likely to maintain only one of them active. 

So even if the constraint is relaxed to echo "attack-status" by a server, only the client that communicated the parameter can access it ... but I don't see why we need to do that.  

Cheers,
Med

> Envoyé : mardi 6 octobre 2020 16:58
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : Valery Smyslov <[email-masked]>; [email-masked]; dots-
> [email-masked]; [email-masked]
> > [Med] It is mandatory in a request and an accepted mitigation
> response, but not in a conflict response for instance.
> > The structure applies of the mitigation independently whether this
> a request, response, conflict, efficacy update, etc.
> 
> I see, I understand.
> 
> > [Med] "attack-status" is an attribute that is sent by a client to
> share its view on the attack with the server. The server manipulates
> "status" to report the status as seen at the server side.
> > > There is no reason to restrict the server sending attack-status
> to
> > > the clients.
> 
> Perhaps this is something I didn't understand correctly about the
> use of "attack-status" in RFC8782 (not bis), which defines "attack-
> status"
> as the following.
> 
> Let a client send a PUT mitigation request to the server, and
> another client program send a GET request to obtain that mitigation
> request.
> In this case, the latter client might get more information if the
> GET response includes attack-status.
>

---

From: Yasuaki Morita <[email-masked]>
Date: Wed, 7 Oct 2020 11:49:30 +0000

Hi,

> So even if the constraint is relaxed to echo "attack-status" by a server, only the client that communicated the parameter can access it ... but I don't see why we need to do that.

I assumed that multiple entities share and use cuid, once it is created.
Say, when one of the entities creates cuid and PUT mitigation, and
distributes its cuid and mid to the rest of them, so that they can
request GET and check the status (or attack-status),
it makes a bit of a difference regarding the presence of
"attack-status" in GET responses.

But now I understand the original use of attack-status.
I think it has been clarified in bis better than the original RFC8782.
Any doubts about ":(client-to-server)" have been resolved.

Thank you.

---

From: <[email-masked]>
Date: Mon, 12 Oct 2020 11:20:53 +0000

Hi all,

We are considering making this change in Section 7.2 (when TLS1.3 is supported):

==
NEW:
   (D)TLS 1.3 has support for PKI certificate compression
   [I-D.ietf-tls-certificate-compression] which can reduce the initial
   setup time when using PKI.  The DOTS peers MUST negotiate this
   extension as per Section 3 of [I-D.ietf-tls-certificate-compression].
==

Please note that:
* I-D.ietf-tls-certificate-compression will be published as RFC8879
* I-D.ietf-tls-certificate-compression has a dependency on draft-kucherawy-rfc8478bis which is in the RFC Editor queue as well but with a state set to "IESG". After checking with Murray, it seems that the issue will be cleared soon and the document will be back to the AUTH48 state. See https://www.rfc-editor.org/auth48/rfc8878 

Comments are welcome.

Cheers,
Med

> De : Valery Smyslov [mailto:[email-masked]]
> Envoyé : mardi 6 octobre 2020 13:43
> À : [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : WGLC for draft-ietf-dots-rfc8782-bis-01
> 
> Hi,
> 
> this message starts a two-week working group last call for draft-
> ietf-dots-rfc8782-bis-01, which will end on Wednesday, October 21.
> Please, review the draft carefully and send your comments to the
> mailing list.
> 
> Regards,
> Frank & Valery.

---

From: <[email-masked]>
Date: Mon, 12 Oct 2020 12:55:33 +0100

Hi Med,

I am not convinced that we can use MUST as in "peers MUST negotiate" as this
has not been significantly adopted yet in the major TLS libraries (I have
only found one TLS library in my searches) and so wonder if it should be a
SHOULD.

Regards

Jon

> -----Original Message-----
> From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
> Sent: 12 October 2020 12:21
> To: Valery Smyslov; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01
> 
> Hi all,
> 
> * I-D.ietf-tls-certificate-compression has a dependency on
draft-kucherawy-
> rfc8478bis which is in the RFC Editor queue as well but with a state set
to
> "IESG". After checking with Murray, it seems that the issue will be
cleared
> soon and the document will be back to the AUTH48 state. See
> https://www.rfc-editor.org/auth48/rfc8878
> 
> Comments are welcome.
> 
> Cheers,
> Med
> 
> ___________________________________________________________________
> ______________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> If you have received this email in error, please notify the sender and
delete
> this message and its attachments.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 12 Oct 2020 14:54:47 -0700

> only found one TLS library in my searches) and so wonder if it should be a

It does seem a pretty significant change for what was originally just going
to be a small bis.

-Ben

P.S. I had heard last week that draft-kucherawy-rfc8478bis was supposed to
be in AUTH48-DONE just waiting on IANA to complete their actions, so it was
surprising to see it was in state 'IESG'!

---

From: <[email-masked]>
Date: Tue, 13 Oct 2020 05:24:39 +0000

Hi Ben,

Fair point. 

If this is deviating from our initial plan for preparing the bis, I'm with making no such change.
 
Cheers,
Med

> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : lundi 12 octobre 2020 23:55
> À : [email-masked]
> Cc : BOUCADAIR Mohamed TGI/OLN <[email-masked]>;
> 'Valery Smyslov' <[email-masked]>; [email-masked]; dots-
> > I am not convinced that we can use MUST as in "peers MUST
> negotiate"
> > as this has not been significantly adopted yet in the major TLS
> > libraries (I have only found one TLS library in my searches) and
> so
> > wonder if it should be a SHOULD.
> 
> It does seem a pretty significant change for what was originally
> just going to be a small bis.
> 
> -Ben
> 
> P.S. I had heard last week that draft-kucherawy-rfc8478bis was
> supposed to be in AUTH48-DONE just waiting on IANA to complete their
> actions, so it was surprising to see it was in state 'IESG'!

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 22 Oct 2020 11:42:08 +0300

Hi,

the WGLC for draft-ietf-dots-rfc8782-bis-01 is over.
We received no objections to publish this document.

Regards,
Frank & Valery.