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

[<[e-mail]>]

Re-,

Works for me. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[e-mail]]
> Envoyé : mercredi 27 février 2019 17:02
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Konda, Tirumaleswar Reddy; [e-mail];
> [e-mail]
> Objet : Re: Designed Expert Guidelines (RE: [Dots] AD review of draft-ietf-
> dots-signal-channel-25 (5th Part))
> 
> 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; 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 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