Re: [TLS] Banning implicit CIDs in DTLS
Thanks, all! It looks like we have consensus on #148, so I merged it. Let's spin a new version with these changes and move forward. Best, Chris On Fri, May 29, 2020, at 8:29 AM, Hannes Tschofenig wrote: > > I also agree. Even without implicit CIDs we can still put multiple > handshake messages into a single record. Hence, there is no performance > problem. > > > *From:* TLS *On Behalf Of * Richard Barnes > *Sent:* Thursday, May 28, 2020 3:37 PM > *To:* Christopher Wood > *Cc:* TLS@ietf.org > *Subject:* Re: [TLS] Banning implicit CIDs in DTLS > > > I agree with EKR that this seems like the most expedient solution to the > issue. > > > --Richard > > > On Thu, May 21, 2020 at 12:00 PM Christopher Wood > wrote: > > > PR #148 in the DTLS 1.3 draft > > (https://github.com/tlswg/dtls13-spec/pull/148) proposes banning implicit > > CIDs. This comes at an obvious cost in terms of bytes on the wire. However, > > in discussions on a parallel thread [1 and related], it's noted that this > > removes header malleability. > > > > Given that we don't have backing analysis suggesting that malleability > > (with the other AAD properties) is safe*, the chairs propose merging this > > PR as-is. To that end, please respond to the list by May 28, 2020, > > indicating whether or not you support this PR. > > > > Thanks, > > Chris, on behalf of the chairs > > > > *One proposal to address this is by extending the AAD to include the > > pseudo-header. However, the chairs feel this is an unnecessary divergence > > from QUIC. > > > > [1] https://mailarchive.ietf.org/arch/msg/tls/kFnlBW-TmlArcU0lD9UQdf_1t_o/ > > > > ___ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Banning implicit CIDs in DTLS
I also agree. Even without implicit CIDs we can still put multiple handshake messages into a single record. Hence, there is no performance problem. From: TLS On Behalf Of Richard Barnes Sent: Thursday, May 28, 2020 3:37 PM To: Christopher Wood Cc: TLS@ietf.org Subject: Re: [TLS] Banning implicit CIDs in DTLS I agree with EKR that this seems like the most expedient solution to the issue. --Richard On Thu, May 21, 2020 at 12:00 PM Christopher Wood mailto:c...@heapingbits.net>> wrote: PR #148 in the DTLS 1.3 draft (https://github.com/tlswg/dtls13-spec/pull/148) proposes banning implicit CIDs. This comes at an obvious cost in terms of bytes on the wire. However, in discussions on a parallel thread [1 and related], it's noted that this removes header malleability. Given that we don't have backing analysis suggesting that malleability (with the other AAD properties) is safe*, the chairs propose merging this PR as-is. To that end, please respond to the list by May 28, 2020, indicating whether or not you support this PR. Thanks, Chris, on behalf of the chairs *One proposal to address this is by extending the AAD to include the pseudo-header. However, the chairs feel this is an unnecessary divergence from QUIC. [1] https://mailarchive.ietf.org/arch/msg/tls/kFnlBW-TmlArcU0lD9UQdf_1t_o/ ___ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Banning implicit CIDs in DTLS
Hi, I changed my mind and support PR #148 on removing implicit CIDs. Reason, FWIW: The main use of implicit CIDs is reduced transmission bandwidth in case of multiple records within a single datagram, which I still consider valid. However, firstly there doesn't appear to be consensus on the relevance of this case, and secondly, if so, there's more to optimize than just the CID: Concretely, going down the route of adding a new content type as suggested by Achim, or alternatively adding a framing in the already existing intermediate layer given by the DTLSInnerPlaintext, seems preferable, since it saves the header plus the record protection overhead, instead of just parts of the header. Such a change could moreover be added as an extension to DTLS 1.3 at a later point, if desired. My support for the use of a pseudo header for the AAD isn't impacted by this, but that's not the point of this thread. Cheers, Hanno From: TLS on behalf of Hanno Becker Sent: Thursday, May 28, 2020 9:17 AM To: Achim Kraus ; TLS@ietf.org Subject: Re: [TLS] Banning implicit CIDs in DTLS Hi Achim and all, > > Now, it turns out in the specific situation (and whenever the data > > framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one > > might as well buffer and coalesce all the application stuff into one > > single record, making the need for CID compression moot. > I'm not sure, how CoAP (RFC 7252) offers framing. AFAIK it uses the size > of the UDP message (or that of the DTLS "application_data" part).. Only > for TCP the size is explicitly encoded in the CoAP messages (but that's > not RFC7252). If I miss something about that, it would be great, if you > share some details to help me out. > In my opinion, introducing a new TLS Content Type > "multi_application_data" would help in a more general way. Even without > the "implicit CIDs" discussion it may help in some cases, where a couple > of "very small" "application_data"-messages are sent at once. As mentioned before, I second that wish for more efficient stacking of multiple records within a single datagram. Note that this goal could also be achieved without an additional content type if we'd go for the pseudo-header AAD. Namely, in this case, one could generalize the implicit CID to allow dropping further header fields and defining their implicit value for non-initial records, as Thomas mentioned before: (a) For CID, the value is the same as for the previous record in the datagram (perhaps transitively continued). (b) For record sequence numbers, an omitted sequence number means that it's the successor of the one used in the previous record. (c) For epochs, the value is the same as for the previous record in the same datagram. If you follow this through, you end up with the extreme possibility of having multiple DTLS records within a single datagram, where the explicit headers of the non-initial records consist solely of their length. This would still be longer than what you'd get with a multi_application_data content type, or application layer framing, because the authentication tag overhead occurs multiple times, but it comes at the benefit of not changing the protection of the records, since the input to the AEAD algorithm is unchanged.. It's only the record header _format_ that can be chosen freely and optimized dynamically. Regards, Hanno From: TLS on behalf of Achim Kraus Sent: Thursday, May 28, 2020 9:02 AM To: tls@ietf.org Subject: Re: [TLS] Banning implicit CIDs in DTLS Hi Thomas, > Now, it turns out in the specific situation (and whenever the data > framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one > might as well buffer and coalesce all the application stuff into one > single record, making the need for CID compression moot. I'm not sure, how CoAP (RFC 7252) offers framing. AFAIK it uses the size of the UDP message (or that of the DTLS "application_data" part). Only for TCP the size is explicitly encoded in the CoAP messages (but that's not RFC7252). If I miss something about that, it would be great, if you share some details to help me out. In my opinion, introducing a new TLS Content Type "multi_application_data" would help in a more general way. Even without the "implicit CIDs" discussion it may help in some cases, where a couple of "very small" "application_data"-messages are sent at once. best regards Achim Am 27.05.20 um 12:03 schrieb Thomas Fossati: > On 24/05/2020, 20:45, "Eric Rescorla" wrote: >> In what context do you have a use for implicit CIDs? > > The specific use case I had in mind is that of an endpoint sending small > and frequent application data units to the same peer - e.g., sensor > readings through CoAP ob
Re: [TLS] Banning implicit CIDs in DTLS
I agree with EKR that this seems like the most expedient solution to the issue. --Richard On Thu, May 21, 2020 at 12:00 PM Christopher Wood wrote: > PR #148 in the DTLS 1.3 draft ( > https://github.com/tlswg/dtls13-spec/pull/148) proposes banning implicit > CIDs. This comes at an obvious cost in terms of bytes on the wire. However, > in discussions on a parallel thread [1 and related], it's noted that this > removes header malleability. > > Given that we don't have backing analysis suggesting that malleability > (with the other AAD properties) is safe*, the chairs propose merging this > PR as-is. To that end, please respond to the list by May 28, 2020, > indicating whether or not you support this PR. > > Thanks, > Chris, on behalf of the chairs > > *One proposal to address this is by extending the AAD to include the > pseudo-header. However, the chairs feel this is an unnecessary divergence > from QUIC. > > [1] https://mailarchive.ietf.org/arch/msg/tls/kFnlBW-TmlArcU0lD9UQdf_1t_o/ > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Banning implicit CIDs in DTLS
Hi Achim, > I'm not sure, how CoAP (RFC 7252) offers framing. AFAIK it uses the > size of the UDP message (or that of the DTLS "application_data" part). > Only for TCP the size is explicitly encoded in the CoAP messages (but > that's not RFC7252). If I miss something about that, it would be > great, if you share some details to help me out. No, you're right, I got 8323 and 7252 framing mixed up. Thanks! 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Banning implicit CIDs in DTLS
Hi Achim and all, > > Now, it turns out in the specific situation (and whenever the data > > framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one > > might as well buffer and coalesce all the application stuff into one > > single record, making the need for CID compression moot. > I'm not sure, how CoAP (RFC 7252) offers framing. AFAIK it uses the size > of the UDP message (or that of the DTLS "application_data" part). Only > for TCP the size is explicitly encoded in the CoAP messages (but that's > not RFC7252). If I miss something about that, it would be great, if you > share some details to help me out. > In my opinion, introducing a new TLS Content Type > "multi_application_data" would help in a more general way. Even without > the "implicit CIDs" discussion it may help in some cases, where a couple > of "very small" "application_data"-messages are sent at once. As mentioned before, I second that wish for more efficient stacking of multiple records within a single datagram. Note that this goal could also be achieved without an additional content type if we'd go for the pseudo-header AAD. Namely, in this case, one could generalize the implicit CID to allow dropping further header fields and defining their implicit value for non-initial records, as Thomas mentioned before: (a) For CID, the value is the same as for the previous record in the datagram (perhaps transitively continued). (b) For record sequence numbers, an omitted sequence number means that it's the successor of the one used in the previous record. (c) For epochs, the value is the same as for the previous record in the same datagram. If you follow this through, you end up with the extreme possibility of having multiple DTLS records within a single datagram, where the explicit headers of the non-initial records consist solely of their length. This would still be longer than what you'd get with a multi_application_data content type, or application layer framing, because the authentication tag overhead occurs multiple times, but it comes at the benefit of not changing the protection of the records, since the input to the AEAD algorithm is unchanged. It's only the record header _format_ that can be chosen freely and optimized dynamically. Regards, Hanno From: TLS on behalf of Achim Kraus Sent: Thursday, May 28, 2020 9:02 AM To: tls@ietf.org Subject: Re: [TLS] Banning implicit CIDs in DTLS Hi Thomas, > Now, it turns out in the specific situation (and whenever the data > framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one > might as well buffer and coalesce all the application stuff into one > single record, making the need for CID compression moot. I'm not sure, how CoAP (RFC 7252) offers framing. AFAIK it uses the size of the UDP message (or that of the DTLS "application_data" part). Only for TCP the size is explicitly encoded in the CoAP messages (but that's not RFC7252). If I miss something about that, it would be great, if you share some details to help me out. In my opinion, introducing a new TLS Content Type "multi_application_data" would help in a more general way. Even without the "implicit CIDs" discussion it may help in some cases, where a couple of "very small" "application_data"-messages are sent at once. best regards Achim Am 27.05.20 um 12:03 schrieb Thomas Fossati: > On 24/05/2020, 20:45, "Eric Rescorla" wrote: >> In what context do you have a use for implicit CIDs? > > The specific use case I had in mind is that of an endpoint sending small > and frequent application data units to the same peer - e.g., sensor > readings through CoAP observe. In this (and similar) situation(s) where > the payload / header ratio is low one wants to have as little transport > overhead as possible. > > Now, it turns out in the specific situation (and whenever the data > framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one > might as well buffer and coalesce all the application stuff into one > single record, making the need for CID compression moot. > > So, I am now convinced I don't have a compelling case to bring to the > table and might as well move into Martin's "vanishingly small use cases" > camp, therefore subscribing the gist of PR#148. > > > PS A note about the more general argument of a pure pseudo-header > approach: it'd enable compression boxes at ingress into a constrained > network, which would be really useful. Without a thorough analysis wrt > header malleability this is unfortunately out of reach. > > -- > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > r
Re: [TLS] Banning implicit CIDs in DTLS
Hi Thomas, > Now, it turns out in the specific situation (and whenever the data > framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one > might as well buffer and coalesce all the application stuff into one > single record, making the need for CID compression moot. I'm not sure, how CoAP (RFC 7252) offers framing. AFAIK it uses the size of the UDP message (or that of the DTLS "application_data" part). Only for TCP the size is explicitly encoded in the CoAP messages (but that's not RFC7252). If I miss something about that, it would be great, if you share some details to help me out. In my opinion, introducing a new TLS Content Type "multi_application_data" would help in a more general way. Even without the "implicit CIDs" discussion it may help in some cases, where a couple of "very small" "application_data"-messages are sent at once. best regards Achim Am 27.05.20 um 12:03 schrieb Thomas Fossati: On 24/05/2020, 20:45, "Eric Rescorla" wrote: In what context do you have a use for implicit CIDs? The specific use case I had in mind is that of an endpoint sending small and frequent application data units to the same peer - e.g., sensor readings through CoAP observe. In this (and similar) situation(s) where the payload / header ratio is low one wants to have as little transport overhead as possible. Now, it turns out in the specific situation (and whenever the data framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one might as well buffer and coalesce all the application stuff into one single record, making the need for CID compression moot. So, I am now convinced I don't have a compelling case to bring to the table and might as well move into Martin's "vanishingly small use cases" camp, therefore subscribing the gist of PR#148. PS A note about the more general argument of a pure pseudo-header approach: it'd enable compression boxes at ingress into a constrained network, which would be really useful. Without a thorough analysis wrt header malleability this is unfortunately out of reach. -- 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Banning implicit CIDs in DTLS
On 24/05/2020, 20:45, "Eric Rescorla" wrote: > In what context do you have a use for implicit CIDs? The specific use case I had in mind is that of an endpoint sending small and frequent application data units to the same peer - e.g., sensor readings through CoAP observe. In this (and similar) situation(s) where the payload / header ratio is low one wants to have as little transport overhead as possible. Now, it turns out in the specific situation (and whenever the data framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one might as well buffer and coalesce all the application stuff into one single record, making the need for CID compression moot. So, I am now convinced I don't have a compelling case to bring to the table and might as well move into Martin's "vanishingly small use cases" camp, therefore subscribing the gist of PR#148. PS A note about the more general argument of a pure pseudo-header approach: it'd enable compression boxes at ingress into a constrained network, which would be really useful. Without a thorough analysis wrt header malleability this is unfortunately out of reach. -- 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Banning implicit CIDs in DTLS
On Sun, May 24, 2020 at 11:01 AM Thomas Fossati wrote: > On 22/05/2020, 01:09, "Christopher Wood" wrote: > > On Thu, May 21, 2020, at 9:22 AM, Thomas Fossati wrote: > > > Hi Chris, > > > > > > On 21/05/2020, 17:00, "Christopher Wood" > > > wrote: > > > > *One proposal to address this is by extending the AAD to include > > > > the pseudo-header. However, the chairs feel this is an unnecessary > > > > divergence from QUIC. > > > > > > I don't understand the "unnecessary" in the above para, i.e., why > > > are we so tied to QUIC in this case? I'm asking because it looks > > > like this was a core criterion in the Chairs' proposal. > > > Sorry for the confusion! The point here was that QUIC authenticates > > what's on the wire, which we felt was important. I should have spelled > > that out. There are of course other things to consider, as Martin > > points out. > > OK, thanks for clarifying. > > I want to be able to use implicit CIDs so I don't support PR#148 as-is. > In what context do you have a use for implicit CIDs? -Ekr > As much as I'd like to go for a pure pseudo-header approach, I don't > think I have enough data at this point in time that I'd feel safe going > that way. > > Since adding implicit CID to the AD doesn't look like a big deal in > terms of performance overhead, that would be my preference. > > cheers, t > > 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. > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Banning implicit CIDs in DTLS
On 22/05/2020, 01:09, "Christopher Wood" wrote: > On Thu, May 21, 2020, at 9:22 AM, Thomas Fossati wrote: > > Hi Chris, > > > > On 21/05/2020, 17:00, "Christopher Wood" > > wrote: > > > *One proposal to address this is by extending the AAD to include > > > the pseudo-header. However, the chairs feel this is an unnecessary > > > divergence from QUIC. > > > > I don't understand the "unnecessary" in the above para, i.e., why > > are we so tied to QUIC in this case? I'm asking because it looks > > like this was a core criterion in the Chairs' proposal. > Sorry for the confusion! The point here was that QUIC authenticates > what's on the wire, which we felt was important. I should have spelled > that out. There are of course other things to consider, as Martin > points out. OK, thanks for clarifying. I want to be able to use implicit CIDs so I don't support PR#148 as-is. As much as I'd like to go for a pure pseudo-header approach, I don't think I have enough data at this point in time that I'd feel safe going that way. Since adding implicit CID to the AD doesn't look like a big deal in terms of performance overhead, that would be my preference. cheers, t 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Banning implicit CIDs in DTLS
I don't support this PR. Compactness of wire presentation is important (and acknowledged - why would there be a compressed header otherwise) and implicit CIDs should hence allowed and authenticated via AEAD additional data, preferably by generally adopting the pseudo header AAD approach. Disappointingly, despite its length the discussion so far has failed to point out concrete problems with the resulting header format malleability. From: TLS on behalf of Christopher Wood Sent: Friday, May 22, 2020 1:09 AM To: Thomas Fossati ; TLS@ietf.org Subject: Re: [TLS] Banning implicit CIDs in DTLS On Thu, May 21, 2020, at 9:22 AM, Thomas Fossati wrote: > Hi Chris, > > On 21/05/2020, 17:00, "Christopher Wood" wrote: > > *One proposal to address this is by extending the AAD to include the > > pseudo-header. However, the chairs feel this is an unnecessary > > divergence from QUIC. > > I don't understand the "unnecessary" in the above para, i.e., why are we > so tied to QUIC in this case? I'm asking because it looks like this was > a core criterion in the Chairs' proposal. Sorry for the confusion! The point here was that QUIC authenticates what's on the wire, which we felt was important. I should have spelled that out. There are of course other things to consider, as Martin points out. Best, Chris ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Banning implicit CIDs in DTLS
On Thu, May 21, 2020, at 9:22 AM, Thomas Fossati wrote: > Hi Chris, > > On 21/05/2020, 17:00, "Christopher Wood" wrote: > > *One proposal to address this is by extending the AAD to include the > > pseudo-header. However, the chairs feel this is an unnecessary > > divergence from QUIC. > > I don't understand the "unnecessary" in the above para, i.e., why are we > so tied to QUIC in this case? I'm asking because it looks like this was > a core criterion in the Chairs' proposal. Sorry for the confusion! The point here was that QUIC authenticates what's on the wire, which we felt was important. I should have spelled that out. There are of course other things to consider, as Martin points out. Best, Chris ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Banning implicit CIDs in DTLS
On Fri, May 22, 2020, at 01:58, Christopher Wood wrote: > PR #148 I think that this is the right solution to this problem. > *One proposal to address this is by extending the AAD to include the > pseudo-header. However, the chairs feel this is an unnecessary > divergence from QUIC. I'm not sure that we need to concern ourselves with avoiding divergence. I would instead point to the advantages of only authenticating what is on the wire: with multiple records in a datagram, having to prepend to the AAD means a performance hit of some kind. Either because you need to pass AAD in two chunks (one for the extra bit, one for the on-the-wire header), which is not commonly supported in APIs, or you need to move or copy stuff around to create a single contiguous AAD. The result is a small amount of complexity. I can probably make a case for not including connection ID in the AAD entirely on the basis of it being analogous to IP or port, but unless that was formally verified, I wouldn't want to rely on that. So #148 WFM. The number of cases where a connection ID can be omitted are vanishingly small anyway. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Banning implicit CIDs in DTLS
Hi Chris, On 21/05/2020, 17:00, "Christopher Wood" wrote: > *One proposal to address this is by extending the AAD to include the > pseudo-header. However, the chairs feel this is an unnecessary > divergence from QUIC. I don't understand the "unnecessary" in the above para, i.e., why are we so tied to QUIC in this case? I'm asking because it looks like this was a core criterion in the Chairs' proposal. Cheers, t 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Banning implicit CIDs in DTLS
This would be my preferred resolution On Thu, May 21, 2020 at 8:59 AM Christopher Wood wrote: > PR #148 in the DTLS 1.3 draft ( > https://github.com/tlswg/dtls13-spec/pull/148) proposes banning implicit > CIDs. This comes at an obvious cost in terms of bytes on the wire. However, > in discussions on a parallel thread [1 and related], it's noted that this > removes header malleability. > > Given that we don't have backing analysis suggesting that malleability > (with the other AAD properties) is safe*, the chairs propose merging this > PR as-is. To that end, please respond to the list by May 28, 2020, > indicating whether or not you support this PR. > > Thanks, > Chris, on behalf of the chairs > > *One proposal to address this is by extending the AAD to include the > pseudo-header. However, the chairs feel this is an unnecessary divergence > from QUIC. > > [1] https://mailarchive.ietf.org/arch/msg/tls/kFnlBW-TmlArcU0lD9UQdf_1t_o/ > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
