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

From: Francesca Palombini via Datatracker <[email-masked]>
Date: Tue, 20 Apr 2021 09:22:28 -0700

Francesca Palombini 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 on this document. I only have minor comments and nits
below.

Francesca

1. -----

   sending messages to the client.  A zero-length CID value indicates
   that the client is prepared to send with a CID but does not wish the
   server to use one when sending.

...

   to use when sending messages towards it.  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.

FP: clarification question: I am not sure the following formulation is very
clear to me: "to send with a(/the client's) CID". Could "send with" be
rephrased to clarify? The previous paragraph uses "using a CID value", that
would be better IMO.

2. -----

   the record format defined in {{dtls-ciphertext} with the new MAC

FP: nit - missing "}" in markdown.

3. -----

   The following MAC algorithm applies to block ciphers that use the
   with Encrypt-then-MAC processing described in [RFC7366].

FP: remove "with"

4. -----

Section 10.1

FP: I believe you should specify 1. what allowed values are for this column
(i.e. Y or N, and what they mean) and 2. what happens to the existing entries -
namely that they all get "N" value.

5. -----

Section 10.2

FP: Just checking - why is 53 "incompatible with this document"?

6. -----

   Value   Extension Name  TLS 1.3  DTLS Only  Recommended  Reference

FP: nit- s/DTLS Only/DTLS-Only to be consistent with 10.1

---

From: Achim Kraus <[email-masked]>
Date: Tue, 20 Apr 2021 18:46:10 +0200

Hello Francesca,

 > FP: Just checking - why is 53 "incompatible with this document"?

The 53 was is used with the MAC definition of the previous version 06 of
this draft. Though the MAC has been adapted, using a different extension
number makes it easier to migrate existing deployments to that new MAC.
At least for Eclipse/Californium I know, that is used with 53 and the
old MAC.

best regards
Achim Kraus

Am 20.04.21 um 18:22 schrieb Francesca Palombini via Datatracker:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 20 Apr 2021 17:48:53 +0100

Hi Francesca, thank you for your review.

The ticket to track your review is:
https://github.com/tlswg/dtls-conn-id/issues/106

cheers!

-- 
Thomas

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Apr 2021 06:00:02 +0000

Hi Francesca,

~ snip ~

5. -----

Section 10.2

[Hannes] Maybe someone responded already regarding this point. I don't know whether it is good or bad practice to provide all this background in the IANA considerations but the story here is (if I recall it correctly) that we initially assigned the value 53 and implementations used in deployments use 53. Then, late in the process we changed the MAC calculation in Section 5...

Ciao
Hannes

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: Francesca Palombini <[email-masked]>
Date: Wed, 21 Apr 2021 08:29:18 +0000

Hi Hannes, Achim,

Thanks, that's all I was curious about! No need to add that to the IANA considerations, this was more of a question on my side. Then I guess 53 will become unassigned, no need to reserve it, right?

Thomas: thanks for creating the issue - I will track there.

Francesca

On 21/04/2021, 08:00, "Hannes Tschofenig" <[email-masked]> wrote:

    Hi Francesca,

    ~ snip ~

    5. -----

    Section 10.2

    Ciao
    Hannes

---

From: Achim Kraus <[email-masked]>
Date: Wed, 21 Apr 2021 10:36:50 +0200

Hi Francesca,

 > Then I guess 53 will become unassigned, no need to reserve it, right?

After a "reserved period", yes.
If that value is then assigned for TLS or DTLS 1.3 only, then that
period may be very short. If that value is assigned also for DTLS 1.2
(again), I would prefer a longer "reserved period", e.g. 12 months.
(That's just my personal preference.)

Best regards
Achim Kraus