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

[Donald Eastlake <[e-mail]>]

Hi Med,

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

Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

On Thu, May 27, 2021 at 8:48 AM <[e-mail]> wrote:
>
> 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:[e-mail]]
> > Envoyé : jeudi 27 mai 2021 06:43
> > À : Donald Eastlake <[e-mail]>
> > Cc : BOUCADAIR Mohamed TGI/OLN <[e-mail]>;
> > [e-mail]; [e-mail]; draft-ietf-dots-rfc8782-
> > [e-mail]; secdir <[e-mail]>
> > 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...
> >
> > 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 <[e-mail]>
> > wrote:
> > > > Hi Donald,
> > > >
> > > >...
> > > >
> > > > De : Donald Eastlake [mailto:[e-mail]] Envoyé : mardi 23
> > > > mars 2021 05:53 À : [e-mail]; [e-mail] Cc :
> > > > [e-mail]; secdir
> > <[e-mail]>
> > > > 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
>
> _________________________________________________________________________________________________________________________
>
> 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.
>