Subject: Re: [nfsv4] Martin Duke's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 7 Jul 2020 22:27:47 -0700

On Thu, Jun 25, 2020 at 01:56:10PM -0700, Martin Duke via Datatracker wrote:
> Martin Duke has entered the following ballot position for
> draft-ietf-nfsv4-rpc-tls-08: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This presumably a trivial fix but I think it's important enough to be a DISCUSS:
> 
> I think the document needs some discussion of the security properties of TLS1.3
> early data over TCP, if only to refer to Section 8 of RFC 8446 (replay) and
> mention that it is not forward-secure, unlike the rest of the payload.

I actually think that the situation is well-defined without such additional
text -- Appendix E.5 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.

Since this document does not provide such a profile, early data MUST NOT be
used, and there's no need to say more.

-Ben

---

From: Martin Duke <[email-masked]>
Date: Wed, 8 Jul 2020 06:50:46 -0700

Thank you for that reference.

I agree that simply saying that Early Data MUST NOT be used is sufficient.
I am skeptical that implementers of this draft will read E.5 of RFC 8446.

On Tue, Jul 7, 2020 at 10:27 PM Benjamin Kaduk <[email-masked]> wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Chuck Lever <[email-masked]>
Date: Tue, 14 Jul 2020 07:50:50 -0400

To address this issue, I've added the following text (in italics) to the
Security Considerations section.

   One purpose of the mechanism described in the current document is to
   protect RPC-based applications against threats to the confidentiality
   of RPC transactions and RPC user identities.  A taxonomy of these
   threats appears in Section 5 of [RFC6973].  Also, Section 6 of
   [RFC7525] contains a detailed discussion of technologies used in
   conjunction with TLS.  Implementers should familiarize themselves
   with these materials.

   Once a TLS session is established, the RPC payload carried on TLS
   version 1.3 is forward-secure.  However, implementers need to be
   aware that replay attacks can occur during session establishment.
   Remedies for such attacks are discussed in detail in Section 8 of
   [RFC8446].  Further, the current document does not provide a profile
   that defines the use of 0-RTT data (see Appendix E.5 of [RFC8446]).
   Therefore, RPC-over-TLS implementations MUST NOT use 0-RTT data.

> On Jul 8, 2020, at 9:50 AM, Martin Duke <[email-masked]> wrote:
> 
> I agree that simply saying that Early Data MUST NOT be used is sufficient. I am skeptical that implementers of this draft will read E.5 of RFC 8446.
> 

--
Chuck Lever

---

From: Martin Duke <[email-masked]>
Date: Fri, 17 Jul 2020 17:12:49 -0700

That looks good. Ping me when there's a new version.

On Tue, Jul 14, 2020 at 4:52 AM Chuck Lever <[email-masked]> wrote:

>    [RFC8446].
> *Further, the current document does not provide a profile   that defines
> the use of 0-RTT data (see Appendix E.5 of [RFC8446]).   Therefore,
> RPC-over-TLS implementations MUST NOT use 0-RTT data.*
>
>