Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Peter Saint-Andre]

On 3/21/17 2:06 AM, Florian Schmaus wrote:
> On 20.03.2017 22:32, Dave Cridland wrote:
>> Loosely, this is OK, but, in order:
>>
>> 1) Section 6 must go. … This issue is a blocker for me.
> 
> I don't have much hope, but have to ask anyway: Would you consider a
> dual approach where we keep section 6, get the XEP into experimental
> while simultaneously work on creating a suitable SASL mech at the IETF?

Realistically, the work at the IETF will take quite awhile. A good first
step would be reaching out to Matt Miller, who is one of the co-chairs
and might in fact still be on this list.

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Evgeny Khramtsov]

Tue, 21 Mar 2017 08:24:24 +
Dave Cridland  wrote:

> I think if you do this (or rely on it), then we'll also hit different
> interop issues - a large number of XML serializers cannot preselect
> namespace prefixes.

Ah, then we should avoid using them indeed.
But now I'm wondering how those serializers deal with 'stream:' or
'db:' namespaces. But this is offtopic of course :)
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Dave Cridland]

On 21 March 2017 at 08:06, Florian Schmaus  wrote:
> On 20.03.2017 22:32, Dave Cridland wrote:
>> Loosely, this is OK, but, in order:
>>
>> 1) Section 6 must go. … This issue is a blocker for me.
>
> I don't have much hope, but have to ask anyway: Would you consider a
> dual approach where we keep section 6, get the XEP into experimental
> while simultaneously work on creating a suitable SASL mech at the IETF?
>
> Alternatively, if we remove section 6, would you accept ISR as is?

I'd be more comfortable with removing it for now.

I'd also like to see the namespaced attributes go, but otherwise it's
a good start point.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Dave Cridland]

On 21 March 2017 at 07:40, Florian Schmaus  wrote:
> On 20.03.2017 23:31, Dave Cridland wrote:
>> Ah, but Kev noted to me that this is using namespaced attributes.
>>
>> We have, traditionally, avoided these, on the basis that nobody (well,
>> almost nobody) understands them.
>>
>> I don't think these are actually required here; a child element will
>> work just as well. Can we do that instead?
>
> While I am aware of the "problem" of prefixes, it was a deliberate
> decision to use them in ISR-SASL2.
>
> First, I don't think they introduce any interoperability issues here,
> since their usage is negotiated by obtaining the ISR key, and they are
> only used between the two immediate endpoints of the XMPP stream.
> Secondly, I think it is more elegant to use the them in this particular
> case. I also was unsure if *not* using them, i.e., putting a child
> element within XEP-0198's , would violate XEP-0198's schema
> (although I think it does not).
>

I don't think you need to conform to the schema of a base
specification if both sides have agreed to deviate by negotiation,
although we almost always use a distinct namespace, and tacitly assume
our schemas implicitly say any extension elements in another namespace
are permitted anywhere.

> I'd like to continue using them for ISR-SASL2 because I don't think they
> cause any issues.

I think Evgeny's message, and my response, suggests otherwise.

I agree they're a sensible option here from a design perspective, but
I don't think we lose anything with a child element.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Dave Cridland]

On 21 March 2017 at 07:44, Evgeny Khramtsov  wrote:
> Tue, 21 Mar 2017 08:40:26 +0100
> Florian Schmaus  wrote:
>
>> I'd like to continue using them for ISR-SASL2 because I don't think
>> they cause any issues.
>
> I'm ok with that, but only if there is a standard prefix name, like
> "isr" in your case and using of other prefixes is forbidden for this
> namespace. Otherwise, interoperability problems will come.

I think if you do this (or rely on it), then we'll also hit different
interop issues - a large number of XML serializers cannot preselect
namespace prefixes.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Florian Schmaus]

On 21.03.2017 01:21, Peter Saint-Andre wrote:
> On 3/20/17 4:23 PM, Dave Cridland wrote:
>> On 20 March 2017 at 22:04, Florian Schmaus  wrote:
>>> On 20.03.2017 22:32, Dave Cridland wrote:
>> Incidentally, I think a token-based SASL mechanism might be generally
>> useful; 
> 
> We already have a token-based authentication mechanism for OAuth 2
>  but perhaps that's not what
> you had in mind...

I've also looked into that RFC, but as far as I can tell:
- No channel binding
- No mutual authentication
- Does not signal the hash-algo as part of its SASL name

→ not suitable for ISR.

- Florian




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Florian Schmaus]

On 20.03.2017 22:32, Dave Cridland wrote:
> Loosely, this is OK, but, in order:
> 
> 1) Section 6 must go. … This issue is a blocker for me.

I don't have much hope, but have to ask anyway: Would you consider a
dual approach where we keep section 6, get the XEP into experimental
while simultaneously work on creating a suitable SASL mech at the IETF?

Alternatively, if we remove section 6, would you accept ISR as is?

- Florian






signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Florian Schmaus]

On 20.03.2017 23:23, Dave Cridland wrote:
> On 20 March 2017 at 22:04, Florian Schmaus  wrote:
>> On 20.03.2017 22:32, Dave Cridland wrote:
>>> Loosely, this is OK, but, in order:
>>>
>>> 1) Section 6 must go. I don't believe that the XSF has the required
>>> expertise to adequately review a SASL mechanism. I'm saying this
>>> without commenting on the mechanism described in Section 6. This needs
>>> to go through the IETF (this document can reference any particular
>>> SASL mechanism for MTI it likes, including this one). The right
>>> working group is - probably - Kitten, though traditionally XMPP itself
>>> works through the ART area, and we might want to give an ART AD or two
>>> a heads-up. This issue is a blocker for me.
>>
>> Section 6. was written in mind being probably factored out. So I'm happy
>> to bring this to the IETF. Anyone who wants to shepherd me?
> 
> I'm confident we can find a shepherd, but I can do that if we need
> one. (Assuming you actually do mean a Document Shepherd).

Shepherding in no particular sense, so not strictly limited to a
document shepherd (but that would be also very appreciated).

> Incidentally, I think a token-based SASL mechanism might be generally
> useful; Surevine could use one if it existed, certainly. It's useful
> to have a device-specific token which can then be managed and/or
> revoked, independent of ISR - this implies a multiple-use token rather
> than a single-use one, however. I have a vague feeling that something
> based around a fusion of HOTP and YAP might yield something that
> satisfies this. If you're open to the idea, I'll outline a quick
> design.

Well, I do think that X-HT-* does already everything required for ISR
and for a generic token-based SASl mechanism. The only thing missing for
an official IETF SASL mech is probably support for auth(c|z)id, which is
trivial to add.

I looked into Kurt's YAP as SASL mech for ISR, as you know. And compared
to X-HT-*, it is missing the mutual authentication part, which I
consider very important for the X-HT-*'s use case. And somehow X-HT-* is
a fusion of HOTP and YAP. But I'm not sure what exactly you mean with
"multiple-use token" and how it fits into the picture. That said, I
think it would be really great if you could do a strawman, elaborate a
bit what you are trying to solve and if prepare yourself for some stupid
follow up questions from my side. :)

>>> 2) I don't think §5.2.3 is right - I don't think ISR should be placing
>>> any requirements on the upper layer. You might think - correctly -
>>> that a server requiring 2FA on a resume is not behaving very sensibly,
>>> but I don't think it's behaving in a way that would cause
>>> interoperability problems.
>>
>> I'm sorry, but I'm confused (maybe it is already to late for me :)). You
>> mean ISR should not allow 2FA on resume? Why not? Care to elaborate what
>> you mean with "placing any requirements on the upper layer"? If ISR is
>> based on SASL2, why shouldn't it also support  XEP-0388 § 2.6.3?
> 
> No, I mean the reverse. §5.2.3 says:
> 
> Performing instant stream resumption using multiple SASL mechanisms
> MUST only be done if the 'without-isr-token' attribute is set to
> 'true'.
> 
> I took that to mean, "Servers MUST NOT use  if the
> without-isr-token attribute is set to true".

Noted. It appears the negation of without-isr-token was not a good idea.
I'll try to improve the wording and how it turns out without the negation.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Evgeny Khramtsov]

Tue, 21 Mar 2017 08:40:26 +0100
Florian Schmaus  wrote:

> I'd like to continue using them for ISR-SASL2 because I don't think
> they cause any issues.

I'm ok with that, but only if there is a standard prefix name, like
"isr" in your case and using of other prefixes is forbidden for this
namespace. Otherwise, interoperability problems will come.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Florian Schmaus]

On 20.03.2017 23:31, Dave Cridland wrote:
> Ah, but Kev noted to me that this is using namespaced attributes.
> 
> We have, traditionally, avoided these, on the basis that nobody (well,
> almost nobody) understands them.
> 
> I don't think these are actually required here; a child element will
> work just as well. Can we do that instead?

While I am aware of the "problem" of prefixes, it was a deliberate
decision to use them in ISR-SASL2.

First, I don't think they introduce any interoperability issues here,
since their usage is negotiated by obtaining the ISR key, and they are
only used between the two immediate endpoints of the XMPP stream.
Secondly, I think it is more elegant to use the them in this particular
case. I also was unsure if *not* using them, i.e., putting a child
element within XEP-0198's , would violate XEP-0198's schema
(although I think it does not).

I'd like to continue using them for ISR-SASL2 because I don't think they
cause any issues.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Peter Saint-Andre]

On 3/20/17 4:23 PM, Dave Cridland wrote:
> On 20 March 2017 at 22:04, Florian Schmaus  wrote:
>> On 20.03.2017 22:32, Dave Cridland wrote:
>>> Loosely, this is OK, but, in order:
>>>
>>> 1) Section 6 must go. I don't believe that the XSF has the required
>>> expertise to adequately review a SASL mechanism. I'm saying this
>>> without commenting on the mechanism described in Section 6. This needs
>>> to go through the IETF (this document can reference any particular
>>> SASL mechanism for MTI it likes, including this one). The right
>>> working group is - probably - Kitten, though traditionally XMPP itself
>>> works through the ART area, and we might want to give an ART AD or two
>>> a heads-up. This issue is a blocker for me.
>>
>> Section 6. was written in mind being probably factored out. So I'm happy
>> to bring this to the IETF. Anyone who wants to shepherd me?
>>
> 
> I'm confident we can find a shepherd, but I can do that if we need
> one. (Assuming you actually do mean a Document Shepherd).

I doubt that Florian knows all about the special lingo of the IETF. ;-)

But yes, it's important to have someone who can guide you through the
labyrinth.

> Incidentally, I think a token-based SASL mechanism might be generally
> useful; 

We already have a token-based authentication mechanism for OAuth 2
 but perhaps that's not what
you had in mind...

> Surevine could use one if it existed, certainly. It's useful
> to have a device-specific token which can then be managed and/or
> revoked, independent of ISR - this implies a multiple-use token rather
> than a single-use one, however. I have a vague feeling that something
> based around a fusion of HOTP and YAP might yield something that
> satisfies this. If you're open to the idea, I'll outline a quick
> design.

Do tell. :-)

Peter

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Sam Whited]

On Mon, Mar 20, 2017 at 12:50 PM, XMPP Extensions Editor
 wrote:
> URL: https://xmpp.org/extensions/inbox/isr-sasl2.html

> Example 2. An  xmlns:isr='urn:xmpp:isr:0' \ isr:mechanism='X-HT-SHA-256-ENDP'/>

I don't think that namespaced attributes are necessary; they add
complication, don't work with a number of XML libraries that I've
tried, and aren't widely understood. Since they appear to be required
in this case (there's no way to rewrite this example not to use them),
I would consider using my veto because of this.

I'd also like to add my voice to the general agreement and say that we
should not be defining our own SASL mechanisms (but a general token
based mechanism would be a nice thing to have).

RE: Nonza's: I also don't like the term, but like it even less that we
made up a term and are now going to have to include "(see XEP-0360)"
in every document that uses them. If we have to include a
parenthetical letting people know where they can look up the term, we
might as well have just used a more general term and added a bit of
explanation where necessary to narrow it down. This may be a topic for
discussion elsewhere though.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Dave Cridland]

Ah, but Kev noted to me that this is using namespaced attributes.

We have, traditionally, avoided these, on the basis that nobody (well,
almost nobody) understands them.

I don't think these are actually required here; a child element will
work just as well. Can we do that instead?

On 20 March 2017 at 17:50, XMPP Extensions Editor  wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Instant Stream Resumption
>
> Abstract: This specification introduces a mechanism for instant
>   stream resumption, based on Stream Management (XEP-0198), allowing
>   XMPP entities to instantaneously resume an XMPP stream.
>
> URL: https://xmpp.org/extensions/inbox/isr-sasl2.html
>
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Dave Cridland]

On 20 March 2017 at 22:04, Florian Schmaus  wrote:
> On 20.03.2017 22:32, Dave Cridland wrote:
>> Loosely, this is OK, but, in order:
>>
>> 1) Section 6 must go. I don't believe that the XSF has the required
>> expertise to adequately review a SASL mechanism. I'm saying this
>> without commenting on the mechanism described in Section 6. This needs
>> to go through the IETF (this document can reference any particular
>> SASL mechanism for MTI it likes, including this one). The right
>> working group is - probably - Kitten, though traditionally XMPP itself
>> works through the ART area, and we might want to give an ART AD or two
>> a heads-up. This issue is a blocker for me.
>
> Section 6. was written in mind being probably factored out. So I'm happy
> to bring this to the IETF. Anyone who wants to shepherd me?
>

I'm confident we can find a shepherd, but I can do that if we need
one. (Assuming you actually do mean a Document Shepherd).

Incidentally, I think a token-based SASL mechanism might be generally
useful; Surevine could use one if it existed, certainly. It's useful
to have a device-specific token which can then be managed and/or
revoked, independent of ISR - this implies a multiple-use token rather
than a single-use one, however. I have a vague feeling that something
based around a fusion of HOTP and YAP might yield something that
satisfies this. If you're open to the idea, I'll outline a quick
design.

> What is MTI?
>

"Mandatory To Implement". (But not to deploy).

>> 2) I don't think §5.2.3 is right - I don't think ISR should be placing
>> any requirements on the upper layer. You might think - correctly -
>> that a server requiring 2FA on a resume is not behaving very sensibly,
>> but I don't think it's behaving in a way that would cause
>> interoperability problems.
>
> I'm sorry, but I'm confused (maybe it is already to late for me :)). You
> mean ISR should not allow 2FA on resume? Why not? Care to elaborate what
> you mean with "placing any requirements on the upper layer"? If ISR is
> based on SASL2, why shouldn't it also support  XEP-0388 § 2.6.3?
>

No, I mean the reverse. §5.2.3 says:

Performing instant stream resumption using multiple SASL mechanisms
MUST only be done if the 'without-isr-token' attribute is set to
'true'.

I took that to mean, "Servers MUST NOT use  if the
without-isr-token attribute is set to true".

>> 3) My usual distaste for the made-up term "Nonza" remains. Given you
>> clearly understood XEP-0388, which does not use the term, I remain
>> mystified as to its purpose.
>
> I tired to motivate a clear definition for Nonzas in XEP-0360 § 1. and
> like to point out that I receive many positive feedback for doing so. I
> also note that I asked for suggestions for the exact term back then.

I don't think it needs (and has ever needed) a single word term. Most
of the time, "element" suffices.

> Anyway, I assume that 3) is no blocker for you?

Neither (3) nor (2) are blockers - that is I won't use my veto, though
I'll continue to argue against both.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Florian Schmaus]

On 20.03.2017 22:32, Dave Cridland wrote:
> Loosely, this is OK, but, in order:
> 
> 1) Section 6 must go. I don't believe that the XSF has the required
> expertise to adequately review a SASL mechanism. I'm saying this
> without commenting on the mechanism described in Section 6. This needs
> to go through the IETF (this document can reference any particular
> SASL mechanism for MTI it likes, including this one). The right
> working group is - probably - Kitten, though traditionally XMPP itself
> works through the ART area, and we might want to give an ART AD or two
> a heads-up. This issue is a blocker for me.

Section 6. was written in mind being probably factored out. So I'm happy
to bring this to the IETF. Anyone who wants to shepherd me?

What is MTI?

> 2) I don't think §5.2.3 is right - I don't think ISR should be placing
> any requirements on the upper layer. You might think - correctly -
> that a server requiring 2FA on a resume is not behaving very sensibly,
> but I don't think it's behaving in a way that would cause
> interoperability problems.

I'm sorry, but I'm confused (maybe it is already to late for me :)). You
mean ISR should not allow 2FA on resume? Why not? Care to elaborate what
you mean with "placing any requirements on the upper layer"? If ISR is
based on SASL2, why shouldn't it also support  XEP-0388 § 2.6.3?

> 3) My usual distaste for the made-up term "Nonza" remains. Given you
> clearly understood XEP-0388, which does not use the term, I remain
> mystified as to its purpose.

I tired to motivate a clear definition for Nonzas in XEP-0360 § 1. and
like to point out that I receive many positive feedback for doing so. I
also note that I asked for suggestions for the exact term back then.
Anyway, I assume that 3) is no blocker for you?

- Florian




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Peter Saint-Andre]

On 3/20/17 3:32 PM, Dave Cridland wrote:
> Loosely, this is OK, but, in order:
> 
> 1) Section 6 must go. I don't believe that the XSF has the required
> expertise to adequately review a SASL mechanism. I'm saying this
> without commenting on the mechanism described in Section 6. This needs
> to go through the IETF (this document can reference any particular
> SASL mechanism for MTI it likes, including this one). The right
> working group is - probably - Kitten, though traditionally XMPP itself
> works through the ART area, and we might want to give an ART AD or two
> a heads-up. This issue is a blocker for me.

Agreed.

Also, what is the "X-" in "X-HT-*"? I hope it's not short for
"experimental" because https://www.rfc-editor.org/rfc/rfc6648.txt
discourages such things...

Peter

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Florian Schmaus]

On 20.03.2017 18:50, XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Instant Stream Resumption
> 
> Abstract: This specification introduces a mechanism for instant
>   stream resumption, based on Stream Management (XEP-0198), allowing
>   XMPP entities to instantaneously resume an XMPP stream.
> 
> URL: https://xmpp.org/extensions/inbox/isr-sasl2.html
> 
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.

This is
https://mail.jabber.org/pipermail/standards/2016-February/030927.html
based on XEP-0388 aka. SASL2 (and somehow an improved version of
https://mail.jabber.org/pipermail/standards/2016-February/030898.html).

Back then, Dave had some concerns (can't find the mailing list post
ATM). I think the new version, ISR-SASL2, addressed those. But I'm sure
Dave will tell us what needs to be changed in order to get this ProtoXEP
a number. Of course, your feedback is also appreciated. :)

- Florian






signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Proposed XMPP Extension: Instant Stream Resumption

[XMPP Extensions Editor]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Instant Stream Resumption

Abstract: This specification introduces a mechanism for instant
  stream resumption, based on Stream Management (XEP-0198), allowing
  XMPP entities to instantaneously resume an XMPP stream.

URL: https://xmpp.org/extensions/inbox/isr-sasl2.html

The XMPP Council will decide in the next two weeks whether to accept this 
proposal as an official XEP.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Dave Cridland]

On 1 Mar 2016 10:17 pm, "Florian Schmaus"  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  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
> ___
>
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Florian Schmaus]

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  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: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Dave Cridland]

On 1 March 2016 at 17:13, Florian Schmaus  wrote:

> On 01.03.2016 09:26, Dave Cridland wrote:
> > I wonder - and I've not thought through the implications of this -
> > whether instead of trying to build a SASL-equivalent authentication into
> > '198, with all that entails, is it worth approaching this from the other
> > direction?
> >
> > I mean instead of something like this:
> >
> >
> > > S:  > > xmlns='urn:xmpp:sm:3'
> > > xmlns:isr='urn:xmpp:isr:0'
> > > isr:id='6956e8e5-b123-4a1a-9d23-939199568c4f'
> > > isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'/>
> > >
> >
> >
> >
> > Something more like:
> >
> >  > isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'>...
>
> There is a reason ISR is built on top of SM, and thus the token/key is
> found only after successful SM activation, i.e. in . As far as
> I understand it, your suggestion doesn't provide the same key feature as
> the current ISR approach does: 0-Round Trip session resumption
> (neglecting the TLS handshake, which is not in the scope of ISR).
>
>
FWIW, ISR is 1-RTT, unless you pipeline through, which doesn't really
count. Calling it 0-RTT is marketing.

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.

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.

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.

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.


> > I would think this design would address Tobias's current veto:
> >
> > [16:11:09] Tobias: but yeah..i'm -1, will post on list, and as it aims
> > to replace the whole SASL step for a reconnection it's currently pretty
> > light on the discussion on how it obtains the same level of security
>
> I'm still waiting for Tobias's mail. :)
>
> There are different views that will come to different answers to this
> concern. For example one could say that ISR doesn't need to provide the
> same level of security that SASL does, since ISR is only possible after
> at least one successful SASL authentication. The lifetime of an ISR key
> is limited, and I assume, since I didn't hear anyone complaining yet,
> that the latest HMAC based scheme proposed for ISR provides sufficient
> security for the use case.
>
> Or, one could say that, if you neglect 2FA and such, a securely
> generated key with 128 or more bits is good enough. I believe the real
> answer lies in between. For what ISR tries to achieve, it's pretty
> solid, sound and more then sufficiently secure. If I wrong, then I'm
> more than happy be corrected and (if possible) fix the issues in the ISR
> approach.
>

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.


>
> - Florian
>
>
>
> ___
> 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
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Tobias Markmann]

Hi Florian,

On Tue, Mar 1, 2016 at 6:13 PM, Florian Schmaus  wrote:

>
> There is a reason ISR is built on top of SM, and thus the token/key is
> found only after successful SM activation, i.e. in . As far as
> I understand it, your suggestion doesn't provide the same key feature as
> the current ISR approach does: 0-Round Trip session resumption
> (neglecting the TLS handshake, which is not in the scope of ISR).


Right, we should aim for a minimum number of round trips for ISR, else you
could just do normal SASL for authentication.



> > I would think this design would address Tobias's current veto:
> >
> > [16:11:09] Tobias: but yeah..i'm -1, will post on list, and as it aims
> > to replace the whole SASL step for a reconnection it's currently pretty
> > light on the discussion on how it obtains the same level of security
>
> I'm still waiting for Tobias's mail. :)
>

Yes, sorry for the delay.

>
> There are different views that will come to different answers to this
> concern. For example one could say that ISR doesn't need to provide the
> same level of security that SASL does, since ISR is only possible after
> at least one successful SASL authentication. The lifetime of an ISR key
> is limited, and I assume, since I didn't hear anyone complaining yet,
> that the latest HMAC based scheme proposed for ISR provides sufficient
> security for the use case.


> Or, one could say that, if you neglect 2FA and such, a securely
> generated key with 128 or more bits is good enough. I believe the real
> answer lies in between. For what ISR tries to achieve, it's pretty
> solid, sound and more then sufficiently secure. If I wrong, then I'm
> more than happy be corrected and (if possible) fix the issues in the ISR
> approach.


Right. My major concern was that the way it was described in the proposed
XEP, the resumption provided less secure authentication compared to SASL
with SCRAM-* or SCRAM-*-PLUS, and did very little on describing what level
of authentication it provides compared t the SASL layer it proposed to
replace.

With standard TLS and SCRAM at the first authentication the client is
authenticated only by proving knowledge of the password and the server by
TLS certificate authentication and also proving knowledge of the password
to the client, both without leaking the clear password.

Something like Thijs proposal or your adaptation sounds like a sensible way
to go, considering a more depth security analysis when it's accepted.

Cheers,
Tobi
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Florian Schmaus]

On 01.03.2016 09:26, Dave Cridland wrote:
> I wonder - and I've not thought through the implications of this -
> whether instead of trying to build a SASL-equivalent authentication into
> '198, with all that entails, is it worth approaching this from the other
> direction?
> 
> I mean instead of something like this:
>  
> 
> > S:  > xmlns='urn:xmpp:sm:3'
> > xmlns:isr='urn:xmpp:isr:0'
> > isr:id='6956e8e5-b123-4a1a-9d23-939199568c4f'
> > isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'/>
> >
> 
> 
> 
> Something more like:
> 
>  isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'>...

There is a reason ISR is built on top of SM, and thus the token/key is
found only after successful SM activation, i.e. in . As far as
I understand it, your suggestion doesn't provide the same key feature as
the current ISR approach does: 0-Round Trip session resumption
(neglecting the TLS handshake, which is not in the scope of ISR).

> I would think this design would address Tobias's current veto:
> 
> [16:11:09] Tobias: but yeah..i'm -1, will post on list, and as it aims
> to replace the whole SASL step for a reconnection it's currently pretty
> light on the discussion on how it obtains the same level of security

I'm still waiting for Tobias's mail. :)

There are different views that will come to different answers to this
concern. For example one could say that ISR doesn't need to provide the
same level of security that SASL does, since ISR is only possible after
at least one successful SASL authentication. The lifetime of an ISR key
is limited, and I assume, since I didn't hear anyone complaining yet,
that the latest HMAC based scheme proposed for ISR provides sufficient
security for the use case.

Or, one could say that, if you neglect 2FA and such, a securely
generated key with 128 or more bits is good enough. I believe the real
answer lies in between. For what ISR tries to achieve, it's pretty
solid, sound and more then sufficiently secure. If I wrong, then I'm
more than happy be corrected and (if possible) fix the issues in the ISR
approach.

- Florian




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Dave Cridland]

On 19 February 2016 at 20:12, Florian Schmaus  wrote:

> On 18.02.2016 09:45, Thijs Alkemade wrote:
> > Of course, there are situations where a certificate legitimately
> changes, but
> > quick resumption failing once every 3 months and having to fall back to a
> > normal XEP-0198 resume sounds fine to me. I'd assume the possibility of
> > specifying the IP address + port on which to resume makes it easy to
> always
> > redirect the client to the same server in the cluster.
>
> Exactly my thought: It's not really an issue if once every few months
> ISR would fail because of a changed cert.
>
> > The YAP draft Dave linked looks interesting, though it only offers
> channel
> > binding and not mutual authentication, but I think that can be easily
> fixed by
> > something like:
> >
>

I wonder - and I've not thought through the implications of this - whether
instead of trying to build a SASL-equivalent authentication into '198, with
all that entails, is it worth approaching this from the other direction?

I mean instead of something like this:


> > S:  > xmlns='urn:xmpp:sm:3'
> > xmlns:isr='urn:xmpp:isr:0'
> > isr:id='6956e8e5-b123-4a1a-9d23-939199568c4f'
> > isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'/>
> >
>


Something more like:

...

I would think this design would address Tobias's current veto:

[16:11:09] Tobias: but yeah..i'm -1, will post on list, and as it aims to
replace the whole SASL step for a reconnection it's currently pretty light
on the discussion on how it obtains the same level of security



> > Resumption uses SASL with:
> >
> > C: id || HMAC(key, "Client" || ChannelBinding)
> > S: HMAC(key, "Server" || ChannelBinding)
> >
> > Where the id is only necessary so the server can find the key
> efficiently (it
> > could be made stateless by making the id an encrypted token containing
> key, or
> > by deriving key from id using HMAC).
>
> I'd like to take on this approach and modify it a bit:
>
> - Instead of xsr:id we simply use the stream ID that's in  if
> resume=true. I'd assume that ISR supporting servers will always also
> support (ver likely) xep198 stream resumption.
> - I'd like to fix ChannelBinding to tls-server-end-point. Mostly because
> the situation hasn't much improved since Tobias asked in 2011 [1]: You
> can't implement tls-unique in Java SE or Android without resorting to a
> custom TLS stack.
> - Don't use SASL for ISR. The XMPP session state after SASL 
> is a fundamentally different one then after .
>
> So basically we have now:
>
> * Client receives  with ISR key
>
>xmlns='urn:xmpp:sm:3'
>   xmlns:isr='urn:xmpp:isr:0'
>   id='some-long-sm-id'
>   resume='true'
>   isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52' />
>
>
> * Client performs ISR with HMAC(isr:key, "Initiator" || cb)
>
>   from='jul...@im.example.com'
>  to='im.example.com'
>  version='1.0'
>  xml:lang='en'
>  xmlns='jabber:client'
>  xmlns:stream='http://etherx.jabber.org/streams'>
>xmlns='urn:xmpp:isr:0'
>   previd='some-long-sm-id'
>   h='42'>
>   
> initiator-hmac
>   
> 
>
>
> * Server acknowledges ISR with HMAC(isr:key, "Responder" || cb)
>
>from='im.example.com'
>   id='t7AMCin9zjMNwQKDnplntZPIDEI='
>   to='jul...@im.example.com'
>   version='1.0'
>   xml:lang='en'
>   xmlns='jabber:client'
>   xmlns:stream='http://etherx.jabber.org/streams'>
> 
>  
> 
>xmlns='urn:xmpp:isr:0'
>   key='006b1a29-c549-41c7-a12c-2a931822f8c0'
>   h='21'>
>   
> responder-hmac
>   
> 
>
> where
>   initiator-hmac = Base64(HMAC(key, "Initiator" ||
> cb-tls-server-end-point))
>   responder-hmac = Base64(HMAC(key, "Responder" ||
> cb-tls-server-end-point))
>
>
> I'm not even sure if we need verify the server cert with the one at the
> time of . I don't see a point, since the server is
> authenticated by responder-hmac.
>
> Or am I missing something? If not, then I'm going to change the ISR
> ProtoXEP to this.
>
> - Florian
>
> 1: https://www.ietf.org/mail-archive/web/kitten/current/msg02767.html
>
>
> ___
> 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
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Florian Schmaus]

On 18.02.2016 09:45, Thijs Alkemade wrote:
> Of course, there are situations where a certificate legitimately changes, but
> quick resumption failing once every 3 months and having to fall back to a
> normal XEP-0198 resume sounds fine to me. I'd assume the possibility of
> specifying the IP address + port on which to resume makes it easy to always
> redirect the client to the same server in the cluster.

Exactly my thought: It's not really an issue if once every few months
ISR would fail because of a changed cert.

> The YAP draft Dave linked looks interesting, though it only offers channel
> binding and not mutual authentication, but I think that can be easily fixed by
> something like:
> 
> S:  xmlns='urn:xmpp:sm:3'
> xmlns:isr='urn:xmpp:isr:0'
> isr:id='6956e8e5-b123-4a1a-9d23-939199568c4f'
> isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'/>
> 
> Resumption uses SASL with:
> 
> C: id || HMAC(key, "Client" || ChannelBinding)
> S: HMAC(key, "Server" || ChannelBinding)
> 
> Where the id is only necessary so the server can find the key efficiently (it
> could be made stateless by making the id an encrypted token containing key, or
> by deriving key from id using HMAC).

I'd like to take on this approach and modify it a bit:

- Instead of xsr:id we simply use the stream ID that's in  if
resume=true. I'd assume that ISR supporting servers will always also
support (ver likely) xep198 stream resumption.
- I'd like to fix ChannelBinding to tls-server-end-point. Mostly because
the situation hasn't much improved since Tobias asked in 2011 [1]: You
can't implement tls-unique in Java SE or Android without resorting to a
custom TLS stack.
- Don't use SASL for ISR. The XMPP session state after SASL 
is a fundamentally different one then after .

So basically we have now:

* Client receives  with ISR key




* Client performs ISR with HMAC(isr:key, "Initiator" || cb)



  
initiator-hmac
  



* Server acknowledges ISR with HMAC(isr:key, "Responder" || cb)



 


  
responder-hmac
  
. I don't see a point, since the server is
authenticated by responder-hmac.

Or am I missing something? If not, then I'm going to change the ISR
ProtoXEP to this.

- Florian

1: https://www.ietf.org/mail-archive/web/kitten/current/msg02767.html



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Florian Schmaus]

On 17.02.2016 17:29, Daniel Gultsch wrote:
> The remote-tok thing doesn't work because at this point it is already
> too late as the server (read a potential MiM attacker) already receiced
> the token. I think the server needs to be authenticated before the
> clients sends the tok. Or am I misunderstanding the problem? Maybe the
> client could at the very least verify that the certificate hasn't changed?

You are right, exposing the 'tok' in  without having the
server verified seems like a bad idea.

How about

- hashing 'tok' in  then (and maybe even hashing
'prev-remotetok' in ), so that they are not exposed
- requiring the initiator to save the server cert and verify that it
hasn't changed (which matches ISR's design principle to expose the 'tok'
only over TLS secured connection, thus requiring TLS for ISR)
- doing both of the above

I always liked the mutual authenticated of modern SASL mechanisms. I
didn't thought about having that property in ISR, because unlike SASL
passwords, the ISR token is ephemeral as it is limited to the maximum SM
resumption period, which should be usually something like a few minutes.

But if the above mentioned approaches add mutual authentication, without
having to introduce another step or round-trip, then I'm happy to add it
to the XEP.

Your comments please. :)

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Florian Schmaus]

On 17.02.2016 17:29, Daniel Gultsch wrote:
> The remote-tok thing doesn't work because at this point it is already
> too late as the server (read a potential MiM attacker) already receiced
> the token. I think the server needs to be authenticated before the
> clients sends the tok. Or am I misunderstanding the problem? Maybe the
> client could at the very least verify that the certificate hasn't changed?

You are right, exposing the 'tok' in  without having the
server verified seems like a bad idea.

How about

- hashing 'tok' in  then (and maybe even hashing
'prev-remotetok' in ), so that they are not exposed
- requiring the initiator to save the server cert and verify that it
hasn't changed (which matches ISR's design principle to expose the 'tok'
only over TLS secured connection, thus requiring TLS for ISR)
- doing both of the above

I always liked the mutual authenticated of modern SASL mechanisms. I
didn't thought about haveing that property in ISR, because unlike SASL
passwords, the ISR token is ephemeral as it is limited to the maximum SM
resumption period, which should be usually something like a few minutes.

But if the above mentioned approaches add mutual authentication, without
having to introduce another step or round-trip, then I'm happy to add it
to the XEP.

Your comments please. :)

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Daniel Gultsch]

The remote-tok thing doesn't work because at this point it is already too
late as the server (read a potential MiM attacker) already receiced the
token. I think the server needs to be authenticated before the clients
sends the tok. Or am I misunderstanding the problem? Maybe the client could
at the very least verify that the certificate hasn't changed?
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Dave Cridland]

On 16 February 2016 at 19:01, Thijs Alkemade  wrote:

>
> > On 16 feb. 2016, at 17:18, XMPP Extensions Editor 
> wrote:
> >
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> >
> > Title: Instant Stream Resumption
> >
> > Abstract: This specification introduces an mechanism for instant
> >  stream resumption, based on Stream Management (XEP-0198), allowing
> >  XMPP entities to instantaneously resume an XMPP stream.
> >
> > URL: http://xmpp.org/extensions/inbox/isr.html
> >
> > The XMPP Council will decide in the next two weeks whether to accept
> this proposal as an official XEP.
>
>
> I'll just repeat my point that all quick connection attempts so far seem to
> throw out mutual authentication without hesitation. That may be an
> acceptable
> trade-off in certain scenarios, but it should be emphasized that it
> decreases
> security.
>
>
I was thinking much the same with respect to channel binding. I'd be
curious as to whether something based around Kurt's YAP design might work?

https://tools.ietf.org/html/draft-zeilenga-sasl-yap-06

Dave.
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Florian Schmaus]

On 16.02.2016 20:01, Thijs Alkemade wrote:
> 
>> On 16 feb. 2016, at 17:18, XMPP Extensions Editor  wrote:
>>
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: Instant Stream Resumption
>>
>> Abstract: This specification introduces an mechanism for instant
>>  stream resumption, based on Stream Management (XEP-0198), allowing
>>  XMPP entities to instantaneously resume an XMPP stream.
>>
>> URL: http://xmpp.org/extensions/inbox/isr.html
>>
>> The XMPP Council will decide in the next two weeks whether to accept this 
>> proposal as an official XEP.
> 
> 
> I'll just repeat my point that all quick connection attempts so far seem to
> throw out mutual authentication without hesitation. That may be an acceptable
> trade-off in certain scenarios, but it should be emphasized that it decreases
> security.

Thanks for your feedback Thijs. As always, much appreciated. I'd like to
say that it's in fact the first time that someone directs me into the
mutual authentication problematic.


Would adding a 'remotetok' be sufficient. E.g.



And then on instant resumption the initiator sends



and the remote part responds with



Could it really be so easy to add mutual authentication to ISR, or am I
missing something?

- Florian




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Florian Schmaus]

On 16.02.2016 20:01, Thijs Alkemade wrote:
> 
>> On 16 feb. 2016, at 17:18, XMPP Extensions Editor  wrote:
>>
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: Instant Stream Resumption
>>
>> Abstract: This specification introduces an mechanism for instant
>>  stream resumption, based on Stream Management (XEP-0198), allowing
>>  XMPP entities to instantaneously resume an XMPP stream.
>>
>> URL: http://xmpp.org/extensions/inbox/isr.html
>>
>> The XMPP Council will decide in the next two weeks whether to accept this 
>> proposal as an official XEP.
> 
> 
> I'll just repeat my point that all quick connection attempts so far seem to
> throw out mutual authentication without hesitation. That may be an acceptable
> trade-off in certain scenarios, but it should be emphasized that it decreases
> security.

Thanks for your feedback Thijs. As always, much appreciated. I'd like to
say that it's in fact the first time that someone directs me into the
mutual authentication problematic.


Would adding a 'remotetok' be sufficient. E.g.



And then on instant resumption the initiator sends



and the remote part responds with



Could it really be so easy to add mutual authentication to ISR, or am I
missing something?

- Florian




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

[Thijs Alkemade]

> On 16 feb. 2016, at 17:18, XMPP Extensions Editor  wrote:
> 
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Instant Stream Resumption
> 
> Abstract: This specification introduces an mechanism for instant
>  stream resumption, based on Stream Management (XEP-0198), allowing
>  XMPP entities to instantaneously resume an XMPP stream.
> 
> URL: http://xmpp.org/extensions/inbox/isr.html
> 
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.


I'll just repeat my point that all quick connection attempts so far seem to
throw out mutual authentication without hesitation. That may be an acceptable
trade-off in certain scenarios, but it should be emphasized that it decreases
security.

Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Proposed XMPP Extension: Instant Stream Resumption

[XMPP Extensions Editor]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Instant Stream Resumption

Abstract: This specification introduces an mechanism for instant
  stream resumption, based on Stream Management (XEP-0198), allowing
  XMPP entities to instantaneously resume an XMPP stream.

URL: http://xmpp.org/extensions/inbox/isr.html

The XMPP Council will decide in the next two weeks whether to accept this 
proposal as an official XEP.

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___