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

[Benjamin Kaduk <[e-mail]>]

Thanks!  This is similar text to what's been floating around for a while in
a handful of documents; subsequent real-world experience with the procedure
has revealed that it's helpful to be very clear in the document about what
the entrypoint is for someone requesting a new registration.  For many of
the existing registries, the expected procedure is "person making
registration request sends email to the named list" (as opposed to filling
out IANA's webform and having IANA send mail to the list), so we could
consider adding some text like "New registration requests should be sent
in the form of email to the review mailing list.  IANA will only accept new
registrations from the Designated Experts, and will check that review was
requested on the mailing list in accordance with these procedures."

-Ben

On Wed, Jan 23, 2019 at 12:15:27PM +0000, [e-mail] wrote:
> 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