[Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel)

[<[e-mail]>]

Hi Ben, all, 

We edited a short draft (https://tools.ietf.org/html/draft-boucadair-dots-earlydata-00) to motivate the following text included in the signal channel 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.
      The DOTS signal channel messages sent as early data by the DOTS
      client are idempotent requests.  As a reminder, Message ID
      (Section 3 of [RFC7252]) is changed each time a new CoAP request
      is sent, and the Token (Section 5.3.1 of [RFC7252]) is randomized
      in each CoAP request.  The DOTS server(s) can use Message ID and
      Token in the DOTS signal channel message to detect replay of early
      data, and accept 0-RTT data at most once.  Furthermore, 'mid'
      value is monotonically increased by the DOTS client for each
      mitigation request, attackers replaying mitigation requests with
      lower numeric 'mid' values and overlapping scopes with mitigation
      requests having higher numeric 'mid' values will be rejected
      systematically by the DOTS server.

      Owing to the aforementioned protections, especially those afforded
      by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC 8446
      anti-replay mechanisms, all DOTS signal channel requests are safe
      to transmit in TLS 1.3 as early data.  Refer to
      [I-D.boucadair-dots-earlydata] for more details.

This text and also the Designated Expert guidelines are implemented in -28. These are the two pending issues from your AD review. 

Other edits were also made to record what was agreed on the list.

We hope this version is now ready to move forward. 

Cheers,
Med

> > > > > 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