On 1 Mar 2016 10:17 pm, "Florian Schmaus" <f...@geekplace.eu> wrote: > > 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. >
If a client sends a stanza prior to receiving the response to an authentication request, it's doing so prior to channel binding having completed. That may fit your security model, I suppose. Certainly the stream hasn't been authenticated or resumed as far as the client knows until one round trip time later. TLSv1.3's 0RTT does, in contrast, show the client to safely send application data prior top the handshake completing. > > 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. > It authenticates the connection, I hope. If it doesn't, we have serious problems. > > 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. Um. Didn't I demonstrate that in my previous mail? Or at least, the same number of round trips. > And > secondly, it just feels wrong to have the stream in a different state > after <success/> depending on whether or not ISR is used. > Okay. But it feels wrong to me to have different authentication mechanisms. We don't design authentication mechanisms here. The times we have, like XEP-0078, haven't ended well. > > 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]. > The mutual auth from TLS? Sure. But a YAP variant can do that; the last draft happens to use a different binding, is all. The main difference with my approach is that if a particular hash algorithm gets weakened, switching is a well defined process. > > 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. > I think most mobile developers would like us to design a method of resuming a stream with the minimal amount of round trips. I also think they'd like us to think carefully about the security. > 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 > > > _______________________________________________ > Standards mailing list > Info: http://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
