Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th Part)

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: [e-mail]
> <[e-mail]>
> Sent: Thursday, January 17, 2019 5:44 PM
> To: Konda, Tirumaleswar Reddy <[e-mail]>;
> Benjamin Kaduk <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: RE: AD review of draft-ietf-dots-signal-channel-25 (5th Part)
> 
> 
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[e-mail]]
> > Envoyé : jeudi 17 janvier 2019 11:34
> > À : BOUCADAIR Mohamed TGI/OLN; Benjamin Kaduk; draft-ietf-dots-signal-
> > [e-mail] Cc : [e-mail] Objet : RE: AD review of
> > draft-ietf-dots-signal-channel-25 (5th Part)
> >
> > > -----Original Message-----
> > > From: Dots <[e-mail]> On Behalf Of
> > > [e-mail]
> > > Sent: Thursday, January 17, 2019 12:21 PM
> > > To: Benjamin Kaduk <[e-mail]>; draft-ietf-dots-signal-
> > > [e-mail]
> > > Cc: [e-mail]
> > > Subject: Re: [Dots] AD review of draft-ietf-dots-signal-channel-25
> > > (5th
> > Part)
> > >
> > > This email originated from outside of the organization. Do not click
> > > links
> > or
> > > open attachments unless you recognize the sender and know the
> > > content is safe.
> > >
> > > Hi Ben,
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Benjamin Kaduk [mailto:[e-mail]] Envoyé : mercredi 16
> > > > janvier 2019 01:14 À : [e-mail]
> > > > Cc : [e-mail]
> > > > Objet : AD review of draft-ietf-dots-signal-channel-25
> > > >
> > > > Section 7.2
> > > >
> > > > The TLS 1.3 handshake with 0-RTT diagram needs to be
> > > > revisited/refreshed, as RFC 8446 does not look like that.
> > > > Additionally, the usage of PSK as well as a certificate is not
> > > > defined until draft-housley-tls-tls13-cert-with-extern-psk is published.
> > > > I also note that in the diagram as presented, the client is not
> > > > yet known to be authenticated when the server sends its initial
> > > > (0.5-RTT) DOTS signal message.
> > > >
> > >
> > > [Med] Noted. Thanks.
> >
> > The DOTS signal channel draft is discussing PSK with (EC)DHE key
> > establishment explained in RFC8446, and I don't see the need to refer
> > to draft-housley-tls-tls13-cert-with-extern-psk-00.
> > The 0-RTT diagram is a simplified version of 0-RTT just like the
> > Figure 1 in https://tools.ietf.org/html/draft-ietf-quic-tls-17.
> >
> > The only correction required to the diagram is end_of_early_data must
> > be sent along with the client Finished message.
> >
> > >
> > > > Section 7.3
> > > >
> > > > This whole section seems to only be relevant for UDP usage, so
> > > > probably the "If UDP is used" clause can be dropped and an
> > > > introductory statement added earlier on.
> > >
> > > [Med] Will consider that.
> > >
> > > >
> > > >                               Path MTU MUST be greater than or equal to
> > > >    [CoAP message size + DTLS overhead of 13 octets + authentication
> > > >    overhead of the negotiated DTLS cipher suite + block padding]
> > > >    (Section 4.1.1.1 of [RFC6347]).  If the request size exceeds the path
> > > >    MTU then the DOTS client MUST split the DOTS signal into separate
> > > >    messages, for example the list of addresses in the 'target-prefix'
> > > >    parameter could be split into multiple lists and each list conveyed
> > > >    in a new PUT request.
> > > >
> > > > (DTLS 1.3 will have a short header for some packets, that is less
> > > > than
> > > > 13 octets.)
> > >
> > > [Med] The text is more about 1.2. We can add a 1.3 note if you think
> > > it is useful for the discussion.
> >
> > We should say "DTLS 1.2 overhead of 13 octets"
> > In DTLS 1.3 DTLSCiphertext structure is variable length (full header
> > is of size 6 octets).
> >
> > >
> > > >
> > > > Section 8
> > > >
> > > > We've got some requirements in here about limiting behavior of
> > > > clients/servers when talking to gateways; is knowing about the
> > > > presence of a gateway something that's required to happen out of
> > > > band or is there an in-band way to identify that the peer is a gateway?
> > >
> > > [Med] An agent does not necessary know that it peer is gateway. A
> > > gateway is seen as a server for the client, and a client for a server.
> > >
> > > >
> > > >    messages from an authorized DOTS gateway, thereby creating a two-
> link
> > > >    chain of transitive authentication between the DOTS client and the
> > > >    DOTS server.
> > > >
> > > > This seems to ignore the possibility of setups that include both
> > > > client-domain and server-domain gateways.
> > >
> > > [Med] I updated the text to mention this is only an example.
> > >
> > > >
> > > >                  DOTS client certificate validation MUST be performed as
> > > >    per [RFC5280] and the DOTS client certificate MUST conform to the
> > > >    [RFC5280] certificate profile.  [...]
> > > >
> > > > This seems to duplicate a requirement already stated in Section
> > > > 7.1; it's probably best to only have normative language in one
> > > > location, even if we need to mention the topic in multiple locations.
> > > > Similarly for the mutual authentication requirement, which we
> > > > duplicate in the second and fourth paragraphs of this section.
> > >
> > > [Med] Good point. Fixed.
> > >
> > > >
> > > > If we don't want to use example.com vs. example.net as sample
> > > > domains, we can also use whateverwewant.example, per RFC 6761.
> > >
> > > [Med] Will maintain the ones already in the draft. Thanks.
> > >
> > > >
> > > > Section 9
> > > >
> > > > We should mention the media-type allocation in the top-level section.
> > >
> > > [Med] Will fix that.
> > >
> > > >
> > > > "mappings to CBOR" feels confusing to me, since it leaves empty
> > > > what we are mapping from.  Perhaps just talking about a registry
> > > > of "CBOR map keys" would be better, both here and in the Section 9.3
> intro.
> > > >
> > >
> > > [Med] Unless there is an objection, I can use "CBOR Map Keys".
> >
> > I don't see "CBOR Map Keys" defined or used anywhere in the draft.
> >
> 
> [Med] The proposal was to add it in -17. In my local copy I have
> implemented "CBOR Key Values". Better?

Yes, thanks.

> 
> > >
> > > > Section 9.3
> > > >
> > > > I suggest being very explicit about whether new requests for
> > > > registration should be directed to the mailing list or to IANA, as
> > > > we've had some confusion about this elsewhere.
> > > >
> > > > The criteria used by the experts also just lists things they
> > > > should consider, but does not provide full clarity on which answer
> > > > to the question is more likely to be approved.  (And yes, I know
> > > > that this text is largely copied from already published RFCs, but
> > > > we can still do
> > > > better.)
> > >
> > > [Med] Will check this.
> > >
> > > >
> > > > Section 9.3.1
> > > >
> > > > If we want the value 0 to be reserved we need to say so.
> > >
> > > [Med] 0 is not part of the allocation range.
> > >
> > > > Do we want to say anything about the usage of negative integers as
> > > > map keys?
> > > >
> > > > I suggest not mentioning the postal address, given the recent
> > > > (e.g.) GDPR requirements.
> > >
> > > [Med] Good point. Done.
> > >
> > > >
> > > > Section 9.3.2
> > > >
> > > > It may be worth mentioning Table 4 here as well.
> > >
> > > [Med] OK.
> > >
> > > >
> > > > Section 9.5.1
> > > >
> > > > We need to specify which range of values we are asking for an
> > > > allocation from.
> > >
> > > [Med] Added a mention to 0-255 range.
> >
> > As per https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml the
> > allowed range is 23-255.
> 
> [Med] Ben was referring to 9.5.1 which is now 9.4.1 in -26. So the range I
> indicated is the correct one.

Got it.

> 
> >
> > >
> > > >
> > > > Section 9.6.1
> > > >
> > > > As above, specify what range we're asking about.
> > >
> > > [Med] OK.
> >
> > The range is already defined in section 9.6.1.1
> >
> 
> [Med] Ben was referring to 9.6.1 of -25, which is now 9.5.1 in -26. The
> comment from Ben is a valid one.

Okay.

Thanks,
-Tiru

> 
> > Cheers
> > -Tiru
> >
> > >
> > > >
> > > > I expect the current text to get some IESG (or directorate)
> > > > feedback that the Data Item and Semantics descriptions are repetitive
> and banal.
> > > >
> > > > Section 9.7
> > > >
> > > > IIUC, IANA is going to ask if we want this module to be
> > > > "maintained by IANA", so it would be good to have an answer ready
> > > > even if we don't put it in the document text.
> > >
> > > [Med] This is discussed in -26.
> > >
> > > >
> > > >    Rate-limiting DOTS requests, including those with new 'cuid' values,
> > > >    from the same DOTS client defends against DoS attacks that
> > > > would
> > > >
> > > > With respect to "new" 'cuid' values, is the server required to
> > > > remember which ones it has seen in perpetuity, or can it time them
> > > > out eventually?
> > >
> > > [Med] The attack vector is a DOTS client which changes frequently its cuid.
> > > The DOTS server can set an interval in which the same client cannot
> > > present a new cuid.
> > >
> > > >
> > > > Section 10
> > > >
> > > > The security considerations seem to be taking a narrow focus on
> > > > the requirements for and consequences of specific bits on the wire
> > > > in the signal channel protocol.  I think it's appropriate to also
> > > > include some high-level thoughts about the functional behavior of
> > > > the protocol, allowing to signal that an attack is underway and
> > > > trigger mitigation, increasing the availability of services, etc.,
> > > > and the risks that are posed by the protocol failing to work
> > > > properly, whether that means letting attack traffic through or
> > > > improperly blocking legitimate traffic.
> > >
> > > [Med] Would a pointer to the architecture/requirements I-Ds be
> > > sufficient
> > to
> > > cover to high-level aspects?
> > >
> > > >
> > > > Section 13.1
> > > >
> > > > I think the IANA registries should be listed as Informational and
> > > > not Normative references.
> > > >
> > >
> > > [Med] Done.
> > >
> > > > Section 13.2
> > > >
> > > > Pending resolution of the question about using
> > > > draft-ietf-core-yang-cbor rules or RFC7951+RFC7049, the
> > > > draft-ietf-core-yang-cbor reference may need to be Normative.
> > >
> > > [Med] Please refer to my answer to that question.
> > > draft-ietf-core-yang-cbor
> > is
> > > informative.
> > >
> > > >
> > > > Given that "URI" is a well-known abbreviation, we may be able to
> > > > get away with not citing RFC 3986.  On the other hand, it's not
> > > > causing any harm to leave it in...
> > >
> > > [Med] Will leave it.
> > >
> > > >
> > > > RFC 4632 needs to be Normative, since we need to know CIDR to
> > > > encode/decode target-prefixes.
> > >
> > > [Med] Works for me.
> > >
> > > >
> > > > Similarly, I think that RFCs 6234
> > >
> > > [Med] This one is not listed as normative because other hash algos
> > > may be used.
> > >
> > > , 7413
> > > [Med] The support if TFO is not mandatory.
> > >
> > > , 7589
> > > [Med] This is a MAY in the spec. It is just fine to leave it as
> > informative..
> > >
> > > , 7918
> > > [Med] Idem as TFO.
> > >
> > > , 7924
> > > [Med] Idem as TFO.
> > >
> > > , and 7951
> > > [Med] this one was not listed as normative because the document
> > > lists two ways to do the mapping.
> > >
> > > > should also be Normative.
> > > >
> > > >
> > > > -Ben
> > >
> > > _______________________________________________
> > > Dots mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dots