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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Friday, February 15, 2019 8:35 PM
> To: [e-mail]
> Cc: Konda, Tirumaleswar Reddy <[e-mail]>;
> [e-mail]; [e-mail]
> Subject: Re: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-dots-
> signal-channel)
> 
> 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 Med,
> 
> Short form: I need to think about it harder.  There's some indication that the
> CoAp Message ID is at the wrong level to protect the 0-RTT data, but I'm not
> sure yet.

I don't think Message ID and Token are at a wrong level to protect 0-RTT data, https://tools.ietf.org/html/draft-tschofenig-uta-tls13-profile-01 discusses introducing a new CoAP option "timestamp", which allows the client to attach a timestamp to each CoAP message for the purpose 
of replay detection. 

Cheers,
-Tiru

> 
> Sorry for the delays; this has been a frenetic couple weeks :(
> 
> -Ben
> 
> On Fri, Feb 15, 2019 at 03:01:29PM +0000, [e-mail]
> wrote:
> > Hi Ben,
> >
> > What is the status for this one? Are we OK to move forward?
> >
> > Thank you.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : [e-mail]
> > > [mailto:[e-mail]]
> > > Envoyé : mardi 29 janvier 2019 14:32 À : Benjamin Kaduk Cc : Konda,
> > > Tirumaleswar Reddy; [e-mail];
> > > [e-mail]
> > > Objet : Using Early Data in DOTS (RE: [Dots] AD review of
> > > draft-ietf-dots-
> > > signal-channel)
> > >
> > > 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