[Dots] Designed Expert Guidelines (RE: AD review of draft-ietf-dots-signal-channel-25 (5th Part))

[<[e-mail]>]

Hi Ben, 

I implemented this change in my local copy: 

OLD: 
   CBOR Key Value:
      Key value for the parameter.  The key value MUST be an integer in
      the 1-65535 range.  The key values of the comprehension-required
      range (0x0001 - 0x3FFF) and of the comprehension-optional range
      (0x8000 - 0xBFFF) are assigned by IETF Review [RFC8126].  The key
      values of the comprehension-optional range (0x4000 - 0x7FFF) are
      assigned by Designated Expert [RFC8126] and of the comprehension-
      optional range (0xC000 - 0xFFFF) are reserved for Private Use
      [RFC8126].

NEW:
   CBOR Key Value:
      Key value for the parameter.  The key value MUST be an integer in
      the 1-65535 range.  The key values of the comprehension-required
      range (0x0001 - 0x3FFF) and of the comprehension-optional range
      (0x8000 - 0xBFFF) are assigned by IETF Review (Section 4.8 of
      [RFC8126]).  The key values of the comprehension-optional range
      (0x4000 - 0x7FFF) are assigned by Specification Required
      (Section 4.6 of [RFC8126]) and of the comprehension-optional range
      (0xC000 - 0xFFFF) are reserved for Private Use (Section 4.1 of
      [RFC8126]).

      Registration requests for the 0x4000 - 0x7FFF range are evaluated
      after a three-week review period on the dots-signal-reg-
      [e-mail] mailing list, on the advice of one or more
      Designated Experts.  However, to allow for the allocation of
      values prior to publication, the Designated Experts may approve
      registration once they are satisfied that such a specification
      will be published.  Registration requests sent to the mailing list
      for review should use an appropriate subject (e.g., "Request to
      register CBOR Key Value: example").

      Within the review period, the Designated Experts will either
      approve or deny the registration request, communicating this
      decision to the review list and IANA.  Denials should include an
      explanation and, if applicable, suggestions as to how to make the
      request successful.  Registration requests that are undetermined
      for a period longer than 21 days can be brought to the IESG's
      attention (using the [e-mail] mailing list) for resolution.

      Criteria that should be applied by the Designated Experts includes
      determining whether the proposed registration duplicates existing
      functionality, whether it is likely to be of general applicability
      or whether it is useful only for a single use case, and whether
      the registration description is clear.  IANA must only accept
      registry updates to the 0x4000 - 0x7FFF range from the Designated
      Experts and should direct all requests for registration to the
      review mailing list.  It is suggested that multiple Designated
      Experts be appointed.  In cases where a registration decision
      could be perceived as creating a conflict of interest for a
      particular Expert, that Expert should defer to the judgment of the
      other Experts.

Cheers,
Med

> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]]
> Envoyé : mardi 22 janvier 2019 08:16
> À : Benjamin Kaduk
> Cc : Konda, Tirumaleswar Reddy; [e-mail];
> [e-mail]
> Objet : RE: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th Part)
> 
> Hi Ben,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Benjamin Kaduk [mailto:[e-mail]]
> > Envoyé : lundi 21 janvier 2019 19:11
> > À : BOUCADAIR Mohamed TGI/OLN
> > Cc : Konda, Tirumaleswar Reddy; [e-mail];
> > [e-mail]
> > Objet : Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th
> Part)
> >
> > On Mon, Jan 21, 2019 at 03:37:38PM +0000, [e-mail]
> wrote:
> > > Re-,
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Benjamin Kaduk [mailto:[e-mail]]
> > > > Envoyé : lundi 21 janvier 2019 16:10
> > > > À : BOUCADAIR Mohamed TGI/OLN
> > > > Cc : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-
> [e-mail];
> > > > [e-mail]
> > > > Objet : Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th
> > Part)
> > > >
> > > > On Mon, Jan 21, 2019 at 07:31:28AM +0000, [e-mail]
> > wrote:
> > > > > Hi Ben, all,
> > > > >
> > > > > Please see inline.
> > > > >
> > > > > Cheers,
> > > > > Med
> > > > >
> > > > > > -----Message d'origine-----
> > > > > > De : Konda, Tirumaleswar Reddy
> > > > [mailto:[e-mail]]
> > > > > > Envoyé : samedi 19 janvier 2019 07:32
> > > > > > À : Benjamin Kaduk; BOUCADAIR Mohamed TGI/OLN
> > > > > > Cc : [e-mail]; [e-mail]
> > > > > > Objet : RE: [Dots] AD review of draft-ietf-dots-signal-channel-25
> > (5th
> > > > Part)
> > > > > >
> > > > > > Hi Ben,
> > > > > >
> > > > > > Please see inline
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Dots <[e-mail]> On Behalf Of Benjamin Kaduk
> > > > > > > Sent: Saturday, January 19, 2019 2:33 AM
> > > > > > > To: [e-mail]
> > > > > > > Cc: [e-mail]; [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 all,
> > > > > > >
> > > > > > > Thanks for all the edits and the published -27.
> > > > > > > Assuming I'm actually caught up on all the review/response
> threads,
> > I
> > > > think
> > > > > > > we're pretty close to being able to go to IETF LC -- here's what
> I
> > see
> > > > as
> > > > > > still left:
> > > > > > >
> > > > > > > - We need to settle the risk of needing normative downrefs called
> > out
> > > > for
> > > > > > >   the last call
> > > > >
> > > > > [Med] I updated the text to:
> > > > > * cite 7618/7624 as normative (+ indicate that a similar mechanism to
> > false
> > > > start may also be defined for DTLS).
> > > > > * tweak the TFO text to maintain it as informative.
> > > >
> > > > Sounds good.
> > > >
> > > > > > > - I just noticed while reviewing the diff that we also need to
> say
> > a
> > > > > > >   little more about (D)TLS 1.3 0-RTT data (more below)
> > > > > > > - It looks like we lost the guidance to the Experts and text
> about
> > the
> > > > > > >   review mailing list from the IANA Considerations, during the
> > > > reshuffling
> > > > > > >   around having IANA manage more things
> > > > > > >
> > > > >
> > > > > [Med] That was on purpose. We would like to rely on RFC8126 rules for
> > > > deigned expert reviews.
> > > >
> > > > I'm not sure I understand this -- 8126 explicitly says that documents
> > > > should provide guidance to the designated expert on what to look for
> and
> > > > what is grounds for rejecting a request.
> > > >
> > >
> > > [Med] What I meant is that the text we used to have in -25 is generic,
> and
> > IMHO does not bring new guidelines to what is discussed in Section 5 of
> 8126.
> >
> > I think there can still be value in repeating the "general applicability,
> > clarity of description, etc. language.  (But it would be even better to
> > come up with some guidance that is tightly tailored to DOTS, if we can.)
> 
> [Med] I tried, actually. It is indeed when I rechecked 8126 that I found that
> text is generic. Seeking for expert reviews will be done via IANA, which is
> familiar with the process of soliciting experts.
> 
> Moreover, I found a bug in the text because it does not apply to the range
> requiring IETF review, but only to a the comprehensive-optional range.
> 
> > And the text about the mailing list and how to format registration requests
> > is definitely not covered in 8126!
> 
> [Med] that mailing list is likely to include the designed experts. This is
> why I thought it is simple to let IANA decide how to reach out designed
> expert(s) once assigned.
> 
> Anyway, I can reinsert the text if you still think it brings value.
> 
> >
> > > > > > > Regarding the (D)TLS 1.3 0-RTT data, RFC 8446 notes that
> > "Application
> > > > > > > protocols MUST NOT use 0-RTT data without a profile that defines
> > its
> > > > use.
> > > > > > > That profile needs to identify which messages or interactions are
> > safe
> > > > to
> > > > > > use
> > > > > > > with 0-RTT and how to handle the situation when the server
> rejects
> > 0-
> > > > RTT
> > > > > > and
> > > > > > > falls back to 1-RTT."  So we either need to say which client
> > requests
> > > > are
> > > > > > 0-RTT
> > > > > > > safe (and why) or defer that profile to another document.  draft-
> > ietf-
> > > > > > dnsop-
> > > > > > > session-signal is perhaps an example of a document that specifies
> > which
> > > > > > > messages are/aren't allowed in early data.
> > > > > > > (draft-ietf-acme-acme is another, but an uninteresting one, since
> > they
> > > > make
> > > > > > > every request include a single-use nonce, and all messages are 0-
> > RTT
> > > > safe.)
> > > > > > > Our use of increasing 'mid' values may help here, in terms of
> > allowing
> > > > > > DELETEs
> > > > > > > to be safe, but I'd have to think a little more to be sure that
> > > > requesting
> > > > > > > mitigation would be safe.  (On first glance the session-
> managemnet
> > bits
> > > > > > would
> > > > > > > not be safe, but I may be missing something.)
> > > > > >
> > > > > > The draft only uses idempotent requests (GET, PUT and DELETE), and
> > CoAP
> > > > is
> > > > > > capable of detecting message duplication (see
> > > > > > https://tools.ietf.org/html/rfc7252#section-4.5) for both
> confirmable
> > and
> > > > > > non-confirmable messages.
> > > > > >  [1] An attacker replaying DELETE will not have any adverse impact,
> > 2.02
> > > > > > (Deleted) Response Code is returned even if the mitigation request
> > does
> > > > not
> > > > > > exist.
> > > > > > [2] The techniques discussed in Section 8 of RFC8446 should suffice
> > to
> > > > handle
> > > > > > anti-replay (e.g. an attacker replaying a 0-RTT data carrying an
> old
> > > > > > mitigation request replaced by a new mitigation scope).
> > > > > >
> > > > >
> > > > > [Med] FWIW, we do already have this text in the draft:
> > > > >
> > > > >       Section 8 of [RFC8446] discusses some mechanisms to implement
> to
> > > > >       limit the impact of replay attacks on 0-RTT data.  If the DOTS
> > > > >       server accepts 0-RTT, it MUST implement one of these
> mechanisms.
> > > > >       A DOTS server can reject 0-RTT by sending a TLS
> > HelloRetryRequest.
> > > >
> > > > (As I noted in my reply to Tiru, we need a more explicit statement.)
> > > >
> > >
> > > [Med] OK. If the assessment is confirmed, we can update the text as
> > follows:
> > >
> > >       Section 8 of [RFC8446] discusses some mechanisms to implement to
> > >       limit the impact of replay attacks on 0-RTT data.  If the DOTS
> > >       server accepts 0-RTT, it MUST implement one of these mechanisms.
> > >       A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest