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

[<[e-mail]>]

Re-,

Looking forward to discuss this further. 

I wonder whether you can consider putting the document in the IETF LC for now. If it happen that we need to modify the 0-RTT text, we will handle it as other IETF LC comments.

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[e-mail]]
> Envoyé : vendredi 15 février 2019 16:05
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Konda, Tirumaleswar Reddy; [e-mail];
> [e-mail]
> Objet : Re: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-
> dots-signal-channel)
> 
> 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