Subject: [TLS] Éric Vyncke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 19 Apr 2021 00:47:51 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-tls-dtls-connection-id-11: No Objection

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 DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. This specification addresses the
IPv4-mainly issue of NAT binding and is still required. I am also trusted the
security ADs for section 5.

Please find below some non-blocking COMMENT points (but replies would be
appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
As an important part of this document is the padding, should it be mentioned
also in the abstract ?

-- Section 3 --
While I am not a DTLS expert, I find this section quite difficult to understand
the reasoning behind the specification as little explanations are given about,
e.g, what is the motivation of "A zero-length value indicates that the server
will send with the client's CID but does not wish the client to include a CID."

-- Section 6 --
I am puzzled by the text:
     "There is a strategy for ensuring that the new peer address is able
      to receive and process DTLS records.  No such strategy is defined
      in this specification."
Does this mean that there is no way to update the peer IP address ?

== NITS ==

-- Section 1 --
Please expand CID on first use outside of the abstract.

-- Section 4 --
Suggest to add a short paragraph as a preamble to figure 3. Currently, it looks
like figure 3 belongs to the 'zeros' field description.

---

From: Achim Kraus <[email-masked]>
Date: Mon, 19 Apr 2021 11:10:46 +0200

Hello Éric,

 > This specification addresses the IPv4-mainly issue of NAT binding and
is still required.

Yes, that is the main initial trigger.
It helps also for peers, which use only temporary assigned IP-addresses
which may change (e.g during a power-saving-sleep-wake-up cycle in some
CAT-NB solutions). And there are also some advanced use-cases, e.g. CID
based load-balancer.

For your other points, Thomas created an issue on github
(https://github.com/tlswg/dtls-conn-id/issues/103). I left some comments
there.

best regards
Achim Kraus

Am 19.04.21 um 09:47 schrieb Éric Vyncke via Datatracker:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 19 Apr 2021 09:16:25 +0000

Hi Éric,

Thank you very much for your review, there's now a ticket to track it
here:

  https://github.com/tlswg/dtls-conn-id/issues/103

Re:

>      "There is a strategy for ensuring that the new peer address is
>       able to receive and process DTLS records.  No such strategy is
>       defined in this specification."

No, it means that we delegate the application using DTLS to do the
Validation (*).  Specifically, the DTLS API on the receiver must be able
to:
(1) forward the "peer address update" signal to the application so that
    it can carry out validation of the new address using some minimal
    application traffic exchange (e.g., CoAP has the Echo option for
    that purpose);
(2) update the new address if requested by the application - in case
    the action triggered by (1) is successful in confirming that the
    new address is effectively the known peer.

This should be already captured in the penultimate paragraph of Section
6.  If that is not the case, could you suggest text to improve it?

Cheers, thanks!

(*) Note that an in-protocol solution [1] has been proposed but it is
    not (yet) adopted.

[1] https://tools.ietf.org/html/draft-tschofenig-tls-dtls-rrc-01

On 19/04/2021, 08:48, "Éric Vyncke via Datatracker" <[email-masked]> wrote:
> Thank you for the work put into this document. This specification
> addresses the IPv4-mainly issue of NAT binding and is still required.
> I am also trusted the security ADs for section 5.
>
> Please find below some non-blocking COMMENT points (but replies would
> be appreciated), and some nits.
>
> As an important part of this document is the padding, should it be
> mentioned also in the abstract ?
>
> -- Section 3 --
> While I am not a DTLS expert, I find this section quite difficult to
> understand the reasoning behind the specification as little
> explanations are given about, e.g, what is the motivation of "A
> zero-length value indicates that the server will send with the
> client's CID but does not wish the client to include a CID."
>
> -- Section 6 --
>      "There is a strategy for ensuring that the new peer address is
>       able to receive and process DTLS records.  No such strategy is
>       defined in this specification."
> Suggest to add a short paragraph as a preamble to figure 3. Currently,
> it looks like figure 3 belongs to the 'zeros' field description.
>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 19 Apr 2021 13:31:24 +0000

Thank Thomas for your reply.

Re-reading the end of the section 6 gives indeed some insights on the overall process, which I failed to understand at first reading. May I suggest to complement the last bullet as " defined in this specification but relies on the application using DTLS" ?

Hope this helps

-éric

-----Original Message-----
From: Thomas Fossati <[email-masked]>
Date: Monday, 19 April 2021 at 11:16
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Joseph Salowey <[email-masked]>, Thomas Fossati <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

    Hi Éric,

    Cheers, thanks!

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 19 Apr 2021 09:32:46 -0700

Hi Éric,

Trimming heavily, as several other responses have landed already...

We had a lot of discussion in the WG about zero-length CIDs and the various
edge cases that can arise.  (You might imagine, for example, wanting to use
the new record format and get content-type confidentiality even when a CID
is not needed for routing messages.)  We ended up concluding that it's
simpler and safer to do what's described now -- no CID means the RFC 6347
record format.  But the discussion in the document may not have captured
the full extent of the WG discussion, so we can take a look at whether
there is more to be said.

The short answer is that this is a typical mechanism where each part tells
the other how to contact them, but in order to confirm the negotiation to
use the feature, we need a signal for "I don't need a CID but I support
CIDs", and the zero-length field in the handshake packets plays that role
quite naturally.

-Ben