> 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 D
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 b
#x27;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 t
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 i
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
> grea
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 pro
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,
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) si
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 exte
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 f
t: 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, th
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'
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 su
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 ti
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 discussion
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
16 matches
Mail list logo
