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

[<[e-mail]>]

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; [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.
> >       The DOTS signal channel messages sent as early data by the DOTS
> >       client are idempotent requests.  Owing to the protections afforded
> >       by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC 8446
> >       anti-replay mechanisms, all DOTS signal channel messages are safe
> >       to transmit in TLS 1.3 0-RTT data.
> 
> That text would meet the "application profile" requirements.  Hopefully
> it's a true statement so we can actually use it :)
> 

[Med] That is at least the authors' conclusion :) 
We will wait for your ACK before implementing changes and posting the updated version of the draft.