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

[[e-mail]]

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.