Changed DTLSCiphertext to DTLSCIDCiphertext for easier readability

[hannestschofenig]

Doing so I introduce ciphertext_length, as the length of the AEAD-encrypted form of the serialized DTLSInnerPlaintext structure.

[boaks]

I may be wrong.
For me, the old defines a DTLSCiphertext, which contains a length field, which is referenced by DTLSCiphertext.length. the new one now has still that field, but introduces a "ciphertext_length", which may be considered as "maverick".

[boaks]

Would DTLSCIDCiphertext.length be a replacement for "ciphertext_length"?

[hannestschofenig]

Using DTLSCIDCiphertext.length is IMHO incorrect because the length of the encrypted content is different from the length of the entire DTLSCIDCiphertext structure. Do I see that wrong?

[boaks]

My understanding:
DTLSCIDCiphertext.length is not the length of DTLSCIDCiphertext, it's the value of the field uint16 length of that structure.

e.g.

   uint16 encLength;
   opaque enc_content[DTLSCIDCiphertext.encLength];
} DTLSCIDCiphertext;

RFC5246 contains

 struct {
          ContentType type;       /* same as TLSPlaintext.type */
          ProtocolVersion version;/* same as TLSPlaintext.version */
          uint16 length;
          opaque fragment[TLSCompressed.length];
      } TLSCompressed;

the TLSCompressed.length can't be the length of the whole TLSCompressed structure, but instead the value of the field uint16 length.

[ekr]

Yes, this interpretation is correct.

[jsalowey]

Why is this just for AEAD cipher types?

[boaks]

@jsalowey

FMPOV, there are currently two interpretations of that definition.

Hannes:

Using DTLSCIDCiphertext.length is IMHO incorrect because the length of the encrypted content is different from the length of the entire DTLSCIDCiphertext structure. Do I see that wrong?

So xxx.length is the length of xxx.

My understanding:

DTLSCIDCiphertext.length is not the length of DTLSCIDCiphertext, it's the value of the field uint16 length of that structure.

So xxx.length is the value of the field xxx.length.

I think, my interpretation is right.

If I'm right, then the changes for "easier readability" will change the term (field name) length in more places, not only there.

   ...
    uint16 ciphertext_length;
   opaque enc_content[DTLSCIDCiphertext.ciphertext_length];
} DTLSCIDCiphertext;

with that, also the term lengthin the text, not only in the structure, must be exchanged with ciphertext_length. And, of course, for the other cipher types as well.

With that, I'm not sure, if exchange that term really pays off, this style/expression is used in many other RFCs, and so should be common to the most readers.

(I guess, if @hannestschofenig finds the time to revisit this, he will agree on my interpretation and with that, it may either "change much more", or this PR may get withdrawn.)

[ekr]

It seems to me that there are two changes here:

1. The change to DTLSCIDCiphertext -- innocuous but maybe unnecessary
2. The change to encrypted_record, which is, I believe, wrong. You'll note that RFC8446 uses the style pre-PR.

I suggest we either close this PR or just do 1.

[boaks]

Just for information:

I assume, that the irritation about DTLSCiphertext.length is mainly caused by very common implicit definitions of ???.length in in programing languages, e.g. Java, where

byte[] data = new byte[0124];
...
if (data.length > 0) ...
...

To escape such accidentally misinterpretations using a name different from "length" (and please not "size" nor "sizeof") may help. But I have my doubts, if the effect is worth the work. And potentially, all others, which are common to the notation within the RFC may then get mixed up by such new names.

[hannestschofenig]

I have been trying to address the review from Ben and, reading through your comments, my attempt to improve the readability failed. This means that I will withdraw this PR.