On 18/05/2020, 01:47, "Martin Thomson" wrote:
> The question is whether it is clear that these limits apply to the use
> of AEADs in TLS more generally. I think that is clear enough, but I
> doubt that people will pay any mind unless they are implementing TLS
> 1.3.
Yes, that's exactly my origin
On Fri, May 15, 2020, at 20:29, Thomas Fossati wrote:
> While the specific behaviours might more or less differ, the same
> considerations apply to 1.2. How do we make sure that the message
> doesn't get ignored? Would it be worth drafting this separately to
> cover both versions (+ an explicit "
On 15/05/2020, 01:51, "Martin Thomson" wrote:
> Continuing the trend where I am the only one to post to this thread...
>
> I just posted a proposal:
>
> https://github.com/tlswg/dtls13-spec/pull/147
Looks good, thanks!
While the specific behaviours might more or less differ, the same
considerati
Continuing the trend where I am the only one to post to this thread...
I just posted a proposal:
https://github.com/tlswg/dtls13-spec/pull/147
This is essentially a transcription of the work done for QUIC to DTLS. There
is one major change, in the addition of TLS_AES_128_CCM_8_SHA256. QUIC
p
On Fri, May 1, 2020, at 14:51, Martin Thomson wrote:
> Thanks to some good work from Felix Günther, Marc Fischlin, Christian
> Janson, and Kenny Paterson we now have a new result to share about the
> integrity limits in QUIC.
>
> There is a long write-up in
> https://github.com/quicwg/base-draf
Thanks to some good work from Felix Günther, Marc Fischlin, Christian Janson,
and Kenny Paterson we now have a new result to share about the integrity limits
in QUIC.
There is a long write-up in https://github.com/quicwg/base-drafts/issues/3619,
the conclusion of which is that endpoints need to
