On Wed, Dec 16, 2015 at 1:14 PM, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> wrote: > On 12/16/15, 12:16 , "Watson Ladd" <watsonbl...@gmail.com> wrote: > >>On Wed, Dec 16, 2015 at 12:09 PM, Blumenthal, Uri - 0553 - MITLL >><u...@ll.mit.edu> wrote: >>> On 12/16/15, 10:50, "Watson Ladd" <watsonbl...@gmail.com> wrote: >>>>>If there are practical consequences, like loss of confidentiality – I’m >>>>> dying to hear the outline of a practical attack. >>>> >>>>The problem is that people design systems assuming something like >>>>indistinguishability. And so when you violate that assumption, all >>>>bets are off. >>> >>> I don’t buy this. AFAIK, TLS has not been designed based on that >>> assumption. And I’m not making any bets. :) >> >>What security properties does TLS provide? > > When the vast majority of TLS users employ it (TLS), they expect (a) that > TLS would ensure the authenticity of their remote peer, (b) that TLS would > protect their data exchange from being eavesdropped on and/or modified, > and (c) that these hold even when the “enemy” (whoever he might be) > controls the entire communications path between them and their peers. > > You can translate the above into more formal definition. :-) > >>In the past TLS users have made assumptions that TLS provides security >>properties it does not. > > Very true. > >>The solution to this problem is to provide the security properties >>that people expect, and they expect IND. > > Not necessarily so. > > As far as I’m concerned, IND-* is a good property to have, but not a > “sacred cow”.
Do you have an alternative definition you can put in and crank and get the limit out? That's the level of definition at which this sort of analysis has to be done, not blathering about "confidentiality" and specific attacks. The reason I used IND-* is that's what the analyses that have been performed used, because it is defined well enough to do this. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
