Subject: Re: [secdir] SECDIR Review draft-ietf-dots-rfc8782-bis-05

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 May 2021 21:42:40 -0700

Hi Donald,

First off, thanks for the review, and thanks to Med for the updates in
response.  Continuing inline...

On Sat, Mar 27, 2021 at 11:42:56PM -0400, Donald Eastlake wrote:
> Hi,
> 
> Thanks for adopting so many of my suggestions.
> 
> See below where I have trimmed to points where we disagree that I
> think I have something to add.
> 
> On Tue, Mar 23, 2021 at 9:51 AM <[email-masked]> wrote:
> > Hi Donald,
> >
> >...
> >
> > De : Donald Eastlake [mailto:[email-masked]]
> > Envoyé : mardi 23 mars 2021 05:53
> > À : [email-masked]; [email-masked]
> > Cc : [email-masked]; secdir <[email-masked]>
> > Objet : SECDIR Review draft-ietf-dots-rfc8782-bis-05
> >
> > ...
> >
> > Minor Issues / Nits:
> >
> >...
> >
> > General/Global: All six occurrences of "as a reminder" should be
> > deleted from the draft. They just add useless words.
> >
> > [Med] Except the one about IPv4/IPv6, those were added to address comments that we received in the past. I prefer to maintain them.
> 
> Perhaps I was not clear. I have no problem with the substantive
> material you have included AFTER the words "as a reminder,". I was
> mearly suggesting that the literal three word sequence "as a reminder"
> is three superfluous words that should be removed.

Thanks for reiterating the intent of the suggestion.
I think I am okay leaving them in for now, and seeing if the rest of the
IESG has an opinion.

> >
> > ...
> >
> > Section 4.4.1:
> >
> > The following draft text uses "the trailing "=" " which implies that a
> > base 64 encoding ends with exactly one equal sign. But I believe there
> > can be zero, one, or two equal signs. I suggest the following:
> > OLD
> >          The truncated output is
> >          base64url encoded (Section 5 of [RFC4648]) with the trailing
> >          "=" removed from the encoding, and the resulting value used as
> >          the 'cuid'.
> > NEW
> >          The truncated output is
> >          base64url encoded (Section 5 of [RFC4648]) with any trailing
> >          equal signs ("=") removed from the encoding, and the
> >          resulting value used as the 'cuid'.
> >
> > [Med] We meant “any trailing”. Fixed by updating to “two trailing "="”
> 
> That still seems wrong to me. The initial wording ("the trainling
> "="") implied exactly one equal sign. The new wording ("the two
> training "="") implies exactly two equal signs. But there can be zero,
> one, or two. If you mean "any training "="", which would be good, why
> don't you say that (or, alternatively, "all trailing")?

In this case the quantity in question is always a 16-byte binary quantity
that's being base64-encoded, so there always will be two padding characters
to remove.

> >
> >...
> >
> > Section 7.3: Since the PMTU can change and could be lower that the
> > values suggested to be assumed in the first paragraph of Section 7.3,
> > it is essentially impossible to conform to the first sentence as
> > written. I suggest the following change:
> > OLD
> >    To avoid DOTS signal message fragmentation and the subsequent
> >    decreased probability of message delivery, DOTS agents MUST ensure
> >    that the DTLS record fits within a single datagram.
> >
> > [Med] We are echoing the following from Section 4.1.1 of 6347:
> >
> > “Each DTLS record MUST fit within a single datagram.”
> 
> I don't agree that you are "echoing" RFC 6347. If you were, you would say
> 
> "To avoid DOTS signal message fragmentation and the subsequent
> decreased probability of message delivery, the DTLS records MUST fit
> within a single datagram."
> 
> If you had said that, I would not have complained. It is a true
> statement of the bad effects DTLS records not fitting in a datagram.

I think I see your point.  Since RFC 6347 already has a "MUST fit"
requirement, we could just rely on that and avoid using new normative
language (I think your point is that "MUST ensure" is not something that
can reliably be achieved, since the DOTS agent may not know about MTU
changes).  Perhaps we can say something like:

  To avoid DOTS signal message fragmentation and the subsequent
  decreased probability of message delivery, the DLTS records need to
  fit within a single datagram [RFC6347].

> > NEW
> >    To avoid DOTS signal message fragmentation and the subsequent
> >    decreased probability of message delivery, DOTS agents MUST NOT
> >    send datagrams exceeding the limits discussed in this Section.
> >
> > ...
> >
> > The way this sentence talks about moving around "mitigation efficacy"
> > reads very strangely to me. I suggest the following re-wording:
> > OLD
> >    A compromised DOTS client can collude with a DDoS attacker to send
> >    mitigation request for a target resource, get the mitigation efficacy
> >    from the DOTS server, and convey the mitigation efficacy to the DDoS
> >    attacker to possibly change the DDoS attack strategy.
> > NEW
> >    A compromised DOTS client can be commanded by a DDoS attacker to
> >    abuse mitigation requests for a target resource. This could use the
> >    "mitigation" abilities of the DOTS server for the benefit of the
> >    attacker possibly leading to a changed and more effective DDoS
> >    attack strategy.
> >
> > [Med] Thanks. I prefer the OLD wording.
> 
> I think I understand what you mean by "efficacy" more clearly now but
> I still think you should fix the grammar by changing "request" in the
> 2nd line to "requests" (or, if you really mean this to be singular,
> change the wording to "a mitigation request").

(I think it's supposed to be singular.  Yes, there's a cardinality
mismatch.)

Thanks again,

Ben

---

From: <[email-masked]>
Date: Thu, 27 May 2021 12:48:26 +0000

Hi Ben, Donald, 

I think this is now fixed in: 

https://www.ietf.org/rfcdiff?url1=draft-ietf-dots-rfc8782-bis-06&url2=draft-ietf-dots-rfc8782-bis-07 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : jeudi 27 mai 2021 06:43
> À : Donald Eastlake <[email-masked]>
> Cc : BOUCADAIR Mohamed TGI/OLN <[email-masked]>;
> [email-masked]; [email-masked]; draft-ietf-dots-rfc8782-
> [email-masked]; secdir <[email-masked]>
> Objet : Re: SECDIR Review draft-ietf-dots-rfc8782-bis-05
> 
> Hi Donald,
> 
> First off, thanks for the review, and thanks to Med for the updates
> in response.  Continuing inline...
> 
> > > De : Donald Eastlake [mailto:[email-masked]] Envoyé : mardi 23
> > > mars 2021 05:53 À : [email-masked]; [email-masked] Cc :
> > > [email-masked]; secdir
> <[email-masked]>
> > > [Med] Except the one about IPv4/IPv6, those were added to address
> comments that we received in the past. I prefer to maintain them.
> >
> I think I am okay leaving them in for now, and seeing if the rest of
> the IESG has an opinion.
> 
> > >
> > > ...
> > >
> > > Section 4.4.1:
> > >
> > > The following draft text uses "the trailing "=" " which implies
> that
> > > a base 64 encoding ends with exactly one equal sign. But I
> believe
> > > there can be zero, one, or two equal signs. I suggest the
> following:
> > > OLD
> > >          The truncated output is
> In this case the quantity in question is always a 16-byte binary
> quantity that's being base64-encoded, so there always will be two
> padding characters to remove.
> 
> > >
> > >...
> > >
> > > values suggested to be assumed in the first paragraph of Section
> > > 7.3, it is essentially impossible to conform to the first
> sentence
> > > as written. I suggest the following change:
> > > OLD
> > I don't agree that you are "echoing" RFC 6347. If you were, you
> would
> > say
> >
> language (I think your point is that "MUST ensure" is not something
> that can reliably be achieved, since the DOTS agent may not know
> about MTU changes).  Perhaps we can say something like:
> 

_________________________________________________________________________________________________________________________

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: Donald Eastlake <[email-masked]>
Date: Thu, 27 May 2021 10:25:57 -0400

Hi Med,

Thanks for the additional changes. I consider all my comments to have
been adequately addressed.

Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]