Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-dtls-connection-id-10.txt> (Connection Identifiers for DTLS 1.2) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/03/2021 18:32, Thomas Fossati wrote:
Hi Tom, all,

On 12/03/2021, 17:29, "tom petch" <daedulus@xxxxxxxxxxxxx> wrote:
On 12/03/2021 16:18, Achim Kraus wrote:
Hi Tom, Hannes, Thomas,

"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 (or
again, alternately, to use a zero-length CID)."

My feeling is, the text in the paragraphs following that seems to
introduce first the idea of a "zero-length CID", and later use that
only to negate the use of tls_cid record. It may be more straight
forward, if the use of a "zero-length CID" is limited to the
ClientHello and the ServerHello extensions. And later the use of a
tls_cid record is then only for negotiated non-empty CID.

WDYT?

I think that I cannot make sense of that 'alternately'.  The
subsequent paragraphs seem to rule it out as an option.  On a first
read I thought that a zero length CID was a valid option for
Application Data and wanted to know which form of header and MAC was
appropriate but my understanding of the later paragraphs became that a
zero length CID can only appear in Hello; but I do think that this
needs fixing.

Is your suggestion to remove the parenthetical?  I.e.:

OLD
    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 (or again,
    alternately, to use a zero-length CID).

NEW
    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.

Thomas

Yes, that would fix this particular problem I have within this section.

I word it that way since I did raise two other doubts about the wording in this section in my original post, one about successful negotiation, which seems to me an undefined term, and one about sending and receiving, which seems over-restrictive in the context.

Tom Petch

I did track the WG discussion last October and did not see anything
very clear then.

Tom Petch



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.


--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux