I've been trying to figure out exactly what you mean before replying and
have been struggling to do so, so I apologize if I'm misunderstanding
your emails, but I believe this isn't a problem unless you use the
channel binding itself as keying material for something. The I-D
specifically has a
Hi Jonathan,
Am Mittwoch, dem 27.10.2021 um 18:02 +0100 schrieb Jonathan Hoyland:
> Hi Ruslan,
>
> Without digging into the guts of GSS-API and SCRAM I can't give you a
> concrete attack, the issue is that all our assumptions about protocol
> security assume that different protocols use totally
Hi Ruslan,
Without digging into the guts of GSS-API and SCRAM I can't give you a
concrete attack, the issue is that all our assumptions about protocol
security assume that different protocols use totally separate key material.
For example if I have one protocol that signs arbitrary blobs and
Hoping now that the submissions deadline has passed that some volunteers to
review the PR:
https://github.com/tlswg/tls-exported-authenticator/pull/76
Cheers,
spt
> On Oct 21, 2021, at 21:44, Sean Turner wrote:
>
> -IESG
>
> Jonathan -> thanks for the review.
>
> WG -> This has been sitting
Hi David,
my question considers 2. ,
if one peer uses RFC 7627 and the other not (legacy).
Case 1:
- client using RFC 7627, server not (legacy)
-- client fallsback to full-handshakes
Case 2:
- server using RFC 7627, client not (legacy)
-- if the client tries a resumption, the current
