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

[Benjamin Kaduk <[e-mail]>]

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.

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