Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication?

2017-11-06 Thread Cas Cremers
gt;>> in escalation of privilege or spoofing resulting in a loss of >>> integrity/authenticity in the application. For example, the use bearer >>> tokens such as passwords or session cookies is widespread. It will take >>> much more work to make applications resili

Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication?

2017-11-03 Thread Cas Cremers
ml/draft-ietf-perc-double-07 > > That would be less invasive than mcTLS, while still getting the properties > you describe. > > --Richard > > > On Nov 3, 2017 09:43, "Cas Cremers" <cas.crem...@cs.ox.ac.uk> wrote: > > Dear all, > ​​ > ​​Disclaimer:

[TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication?

2017-11-03 Thread Cas Cremers
Dear all, ​​ ​​Disclaimer: I am not a proponent of the idea behind draft visibility/green/rhrd; I think such a mechanism should not be part of the TLS 1.3 standard. ​​ ​​I have a technical problem with the current design, whose goal is to allow eavesdropping for inspection, i.e., selectively

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

2017-02-15 Thread Cas Cremers
Hi, I think the idea that "this is the best we can do" depends on quite a number of assumptions. In theory, I think it is easy to fix, but of course in the design space we're in, the trade offs are more complex. We also have to consider the non-web use cases where one might expect more symmetric

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

2017-02-13 Thread Cas Cremers
wishes to obtain such a guarantee, it has to be informed by the server’s application. Best, Cas Cremers, Marko Horvat, Jonathan Hoyland, Thyla van der Merwe, and Sam Scott ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

2017-02-10 Thread Cas Cremers
er exchanging further messages. To avoid problems at the application level, we would prefer this agreement to be ensured. Best wishes, Cas Cremers, Marko Horvat, Jonathan Hoyland, Sam Scott, and Thyla van der Merwe. ___ TLS mailing list TLS@i

Re: [TLS] judging consensus on keys used in handshake and data messages

2016-07-08 Thread Cas Cremers
Hi, After several discussions (including the ones Douglas points out) I have also come round to option 1 as the preferred way forward. For our symbolic analysis in Tamarin it should not make a big difference anyway. Best, Cas On Thu, Jul 7, 2016 at 8:47 PM, Douglas Stebila

Re: [TLS] Consensus call for keys used in handshake and data messages

2016-06-14 Thread Cas Cremers
It is not quite as simple as saying "(1) makes proofs more complicated" since it depends on what you are trying to prove. (1) makes some styles of standard AKE property proofs (key secrecy, authentication) harder (2) might make some privacy proofs harder Given that the proof-effort has mostly