Hi Jonathan, Am Dienstag, dem 09.11.2021 um 16:01 +0000 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 gives > you some level assurance that the client and server agree on what was > intended. The binding is just that, a binding. Insecure protocols will remain insecure but that still does not compromise secure protocols because they can still bind securely app session to tls session. And again, revealing binding data is not a leak/security breach.
> This eliminates classes of attack such as message confusion. > Adding this protection costs virtually nothing, given that you are > _already_ commiting to updating this section of code (no code > currently makes this specific call to the TLS-Exporter interface). Actually it is already implemented in GnuTLS and GIO-TLS. Introducing context specific label will require changing API to accept input context (do something) while now it is simle property retrieval (get something). Moreover it will stay aside from existing binding interface which is still "get property". > Leaving it out means that people like me who do formal analysis can't > reasonably analyse these designs. > I build models of protocols and prove they meet certain properties. > The only way to keep that analysis viable (we're already talking > hundreds of hours of work) is to eliminate classes of attack > wholesale. There's still no demonstration or even hint of the attack as of now, therefore I still do not see a justification to change API except "it is a right thing to do". But I repeat again - it can be done, if there is a reason for that. Regards, RUslan
signature.asc
Description: This is a digitally signed message part
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
