PR for immediate processing: https://github.com/tlswg/dtls13-spec/pull/258
Issue for buffering text: https://github.com/tlswg/dtls13-spec/issues/259
Thanks all
From: TLS on behalf of Hanno Becker
Sent: Monday, November 8, 2021 6:56 PM
To: Ilari Liusvaara ; tls@i
I'm still struggling to figure out what the exact problem is you're
describing or if you have an actual class of attack in mind that might
be possible due to this, but the following in your previous email jumped
out at me:
On Tue, Nov 9, 2021, at 13:03, Jonathan Hoyland wrote:
> If you include cha
Hi Jonathan,
Am Dienstag, dem 09.11.2021 um 16:01 + schrieb Jonathan Hoyland:
> Hi All,
>
> Using a distinct channel binding, even if the upper level protocol is
> not secure, means that if both sides agree on the channel binding
> they agree on the intent of the upper layer protocol, i.e. it
Can be found at: https://notes.ietf.org/notes-ietf-112-tls# Please make
corrections as needed.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hi Dave,
On Tue, 9 Nov 2021 at 16:13, Dave Cridland wrote:
> On Tue, 9 Nov 2021 at 16:01, Jonathan Hoyland
> wrote:
> >
> > Hi All,
> >
> > My specific solution is to simply include a different fixed string for
> each variant of SCRAM and GSS-API, and ideally a nonce.
>
> I think you may mean S
On Tue, 9 Nov 2021 at 16:01, Jonathan Hoyland
wrote:
>
> Hi All,
>
> My specific solution is to simply include a different fixed string for each
> variant of SCRAM and GSS-API, and ideally a nonce.
I think you may mean SASL and GSS-API, but more probably I think you
need to decide what it is you
Hi All,
My specific solution is to simply include a *different* fixed string for
each variant of SCRAM and GSS-API, and ideally a nonce.
Given that applications will have to update their stacks anyway to
accommodate the new fixed string in the current proposal I don't see that
as a hugely difficul
On Tue, 26 Oct 2021 at 17:33, Jonathan Hoyland
wrote:
> There isn't even a one-to-one relationship between GSS-API / SCRAM runs. This
> channel binding design doesn't protect against messages being swapped between
> two GSS-API runs on a single TLS connection.
As I understand your case, you're
