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

["Eric Vyncke (evyncke)" <[e-mail]>]

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 <[e-mail]>
Date: Monday, 19 April 2021 at 11:16
To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Joseph Salowey <[e-mail]>, Thomas Fossati <[e-mail]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

    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:

    > -- 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 ?

    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" <[e-mail]> wrote:
    >
    > É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.
    >

    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.