On 01.03.2016 20:52, Dave Cridland wrote: > FWIW, ISR is 1-RTT, unless you pipeline through, which doesn't really > count. Calling it 0-RTT is marketing.
Independent on which label you put on that claim, it doesn't change that the it is true. > So the main reason I'm thinking of wrapping ISR around SASL is because > ISR replaces SASL to some degree, which is where Thijs and Tobias's > concerns come from. The way I see it, is that it does not replace SASL, not even to some degree, as SASL is (still) used to authenticate entities. ISR does authenticate a stream resumption in an efficient manner. > If you wrap ISR around SASL - and we can discuss removing the stream > restart post-SASL in this case, too - then the security properties of > the authentication portion of ISR become a matter of choosing the SASL > mechanism, which is both vastly simpler to define and also allows us to > easy handle things like hash agility. I deliberately choose to not build ISR on top of SASL. First, I believe it's not possible to achieve a zero round trip resumption doing so. And secondly, it just feels wrong to have the stream in a different state after <success/> depending on whether or not ISR is used. > To put it another way, ISR effectively combine the authentication and > 198 into one step. Your proposal builds ISR by taking '198, and adding a > brand new authentication mechanism. I'm suggesting that it seems > worthwhile to explore building it the other way around, so we take SASL > and add the '198 bits we need onto that. I'm looking forward seeing something like that put in a more formal specification. But I fear that it won't be able to achieve the same properties as ISR, will be a more elegant and/or straightforward solution. > The net result will be identical, except that the bits most likely to > require changing have already-existing discovery and selection. > > For example, assuming we remove post-SASL stream restarts if ISR is in > play, using SASL PLAIN gives the same number of RTTs, and the same > security properties, as the original ISR proposal. Using YAP would be > 1-RTT with channel binding. Using SCRAM would be 2-RTT, with SASL-level > mutual authentication. That *is not* an identical result. ISR using HMAC and tls-server-end-point provides mutual authentication and channel binding with a zero round trip resumption [1]. > I think your proposal is trying to be a one-size-fits all approach, and > I don't think such an approach is either viable or desirable. I think most mobile developers using XMPP would disagree. The "Token-based reconnection" ProtoXEP was created because of this requirement. And I also pointed out [1, p19] that the round trip intense session establishment process is an issue for mobile XMPP. We have SM, CSI, MAM, and soon hopefully MIX. And another important building block for mobile friendliness is a zero round trip stream resumption mechanism providing good security properties. - Florian 1: Note that this is not the ISR version submitted as ProtoXEP, but the one based on the input from Thijs, which happened after the submission. 2: https://archive.fosdem.org/2015/schedule/event/xmpp_and_android/attachments/slides/749/export/events/attachments/xmpp_and_android/slides/749/xmpp_and_android.pdf
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
