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

[<[e-mail]>]

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