13 Jan
2025
13 Jan
'25
6:50 a.m.
This message constitutes notice of a Last Call for comments on
XEP-0484.
Title: Fast Authentication Streamlining Tokens
Abstract:
This specification defines a token-based method to streamline
authentication in XMPP, allowing fully authenticated stream
establishment within a single round-trip.
URL: https://xmpp.org/extensions/xep-0484.html
This Last Call begins today and shall end at the close of business on
2025-01-27.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
13 Jan
13 Jan
9:35 a.m.
On Mon, Jan 13, 2025 at 12:50 PM Daniel Gultsch <daniel(a)gultsch.de> wrote:
This message constitutes notice of a Last Call for comments on
XEP-0484.
Title: Fast Authentication Streamlining Tokens
Abstract:
This specification defines a token-based method to streamline
authentication in XMPP, allowing fully authenticated stream
establishment within a single round-trip.
URL: https://xmpp.org/extensions/xep-0484.html
This Last Call begins today and shall end at the close of business on
2025-01-27.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
Yes. Making login/resumption faster is important and FAST is the last
building block in the new SASL2/Bind 2 stack that isn’t stable yet.
2. Does the specification solve the problem stated in
the introduction
and requirements?
yes
3. Do you plan to implement this specification in your
code? If not,
why not?
Yes it’s implemented in Conversations
4. Do you have any security concerns related to this
specification?
Yes. I think the section 3.2 as well as the security considerations
are missing text that instruct developers not to downgrade their
channel binding method compared to their normal login method. Meaning
when logged in with SCRAM-SHA1-PLUS/exporter only tokens that use an
equivalent or better channel binding mechanism should be requested
and/or excepted.
The channel bindings for normal login are protected via XEP-0474: SASL
SCRAM Downgrade Protection while the fast mechanisms are not covered
by this. That’s fine if and only if we add language to 484 saying that
clients should not request anything weaker than used during login.
5. Is the specification accurate and clearly written?
Yes
4 Feb
4 Feb
10:02 a.m.
1. Is this specification needed to fill gaps in the
XMPP protocol
stack or to clarify an existing protocol?
Yes.
2. Does the specification solve the problem stated in
the introduction
and requirements?
Yes.
3. Do you plan to implement this specification in your
code? If not,
why not?
Yes.
4. Do you have any security concerns related to this
specification?
I don't love that the suggested SASL mechanisms have no protection against
tokens being stolen and re-used via MITM, but this could be solved by using
SCRAM in implementations which is not forbidden.
5. Is the specification accurate and clearly written?
I do not particularly like at all having the SASL mechanisms for FAST
specified completely seperately. I do sort of understand the reason it was
does, but it's not generic at all. For example if I want do (and I do want
to) support "app passwords" I need to solve the same problems (select which
credential is being used, specify which SASL mechanisms can be used for
which credential) but I wouldn't be able to re-use the solution FAST uses
and would need yet another third solution.
11:57 a.m.
On Tue, Feb 4, 2025 at 4:02 PM Stephen Paul Weber
<singpolyma(a)singpolyma.net> wrote:
I guess that depends a lot on what exactly your vision for "app
passwords" is but if they don’t renew themselves and aren’t
necessarily requested via XMPP you can just use SASL2 with PLAIN for
example and already get the 0rtt parts.
(I actually have a deployment where we use PLAIN anyway and thus never
felt the need to use FAST after we got SASL2+Bind2)
I mean FAST is really just a thin wrapper around a family of SASL
mechanisms so I don’t get the point that it is too narrowly defined
around those mechanisms.
But I guess if you feel strongly spec out what you need for "app
passwords" and we can look at the concrete overlap.
cheers
Daniel
4. Do you have
any security concerns related to this specification?
I don't love that the suggested SASL mechanisms have no protection against
tokens being stolen and re-used via MITM, but this could be solved by using
SCRAM in implementations which is not forbidden.
5. Is the specification accurate and clearly
written?
I do not particularly like at all having the SASL mechanisms for FAST
specified completely seperately. I do sort of understand the reason it was
does, but it's not generic at all. For example if I want do (and I do want
to) support "app passwords" I need to solve the same problems (select which
credential is being used, specify which SASL mechanisms can be used for
which credential) but I wouldn't be able to re-use the solution FAST uses
and would need yet another third solution.
3:37 p.m.
I guess that depends a lot on what exactly your vision
for "app
passwords" is but if they don’t renew themselves and aren’t
necessarily requested via XMPP you can just use SASL2 with PLAIN for
example and already get the 0rtt parts.
Yes, with PLAIN is what I do now, but no way to use SCRAM for example which
is the whole issue.
(I actually have a deployment where we use PLAIN anyway
and thus never
felt the need to use FAST after we got SASL2+Bind2)
Generally for me the purpose of FAST is to stop storing passwords on client
devices, but I understand everyone has their own use case.
I mean FAST is really just a thin wrapper around a
family of SASL
mechanisms so I don’t get the point that it is too narrowly defined
around those mechanisms.
I don't think FAST is tied to any particular SASL mechanisms? That's why we
duplicate mechanism discovery as part of FAST, which is the main thing I'm
talking about here.
5 Feb
5 Feb
10:35 a.m.
I don't think FAST is tied to any particular SASL
mechanisms? That's why we
duplicate mechanism discovery as part of FAST, which is the main thing I'm
talking about here.
Ok, so, a concrete proposal for an alternative to the current design which I
think would work for FAST and also for other things such as app passwords:
When requesting a FAST token, return the token and also a SASL authcid value
to go along with it. Then when doing authentication in the future, this
authcid will select which credential to check against (the FAST token)
instead of using a custom mechanism (the <fast/> tag).
This solves one of the two warts in a way that works with SASL instead of
reinventing it.
Now, as for the duplicate mechanisms thing, I don't personally see why this
is needed at all at this point. A token is a password and thus should work
with any password-supporting SASL mechanism (HT-*, SCRAM, PLAIN, etc).
However, in case we want to still allow servers to not implement FAST for
every relevant SASL mechanism they support, I would suggest this change.
Instead of:
<request-token xmlns='urn:xmpp:fast:0'
mechanism='HT-SHA-256-ENDP'/>
We do (insersection of server and client supported mechanisms):
<request-token xmlns='urn:xmpp:fast:0'>
<mechanism>SCRAM-SHA-1</mechanism>
<mechanism>HT-SHA-256-ENDP</mechanism>
</request-token>
And the server will select a supported one to bind to the token:
<token xmlns='urn:xmpp:fast:0'
mechanism='HT-SHA-256-ENDP'
expiry='2020-03-12T14:36:15Z'
token='WXZzciBwYmFmdmZnZiBqdmd1IGp2eXFhcmZm' />
10 Feb
10 Feb
11:53 a.m.
On Wed, 5 Feb 2025 at 15:35, Stephen Paul Weber
<singpolyma(a)singpolyma.net> wrote:
The authcid is how we convey the authenticating username.
I don't think FAST is tied to any particular
SASL mechanisms? That's why we
duplicate mechanism discovery as part of FAST, which is the main thing I'm
talking about here.
Ok, so, a concrete proposal for an alternative to the current design which I
think would work for FAST and also for other things such as app passwords:
When requesting a FAST token, return the token and also a SASL authcid value
to go along with it. Then when doing authentication in the future, this
authcid will select which credential to check against (the FAST token)
instead of using a custom mechanism (the <fast/> tag). This solves one of the two warts in a way that works
with SASL instead of
reinventing it.
Now, as for the duplicate mechanisms thing, I don't personally see why this
is needed at all at this point. A token is a password and thus should work
with any password-supporting SASL mechanism (HT-*, SCRAM, PLAIN, etc).
However, in case we want to still allow servers to not implement FAST for
every relevant SASL mechanism they support, I would suggest this change.
Instead of:
The problem is that for some mechanisms and authentication backends,
the server needs to know what kind of credentials are being used
up-front. In an ideal world, I think we would have SASL able to encode
this information.
Specifically, there are two things the server needs to know:
1) The type of credential being used (password, FAST token, bearer token, etc.)
2) In some cases, some identifier of the credential being used (when
the same user has multiple credentials of the same type, common with
tokens)
In many cases (1) can be hackily inferred from the mechanism - e.g.
just assume that SCRAM is always a password, and that HT is always a
FAST token. However I don't think this is a future-proof design, and
there are cases where a mechanism may be useful for multiple
credential types.
For (2) we currently use the SASL2 client id (a single user may have
multiple FAST tokens, because they have multiple devices). Again, it
would be great if SASL had this concept built-in, but it does not
right now.
The FAST protocol was designed the way it was in order to work around
these constraints. I agree that the protocol could be more elegant if
we were to change the SASL layer to accommodate some of its
requirements. But I also think that what we have is fine and
future-proof.
Regards,
Matthew
12:39 p.m.
I don't think FAST is tied to any particular SASL
mechanisms? That's why
we
duplicate mechanism discovery as part of FAST, which is the main thing I'm
talking about here.
Ok, so, a concrete proposal for an alternative to the current design which I
think would work for FAST and also for other things such as app passwords:
When requesting a FAST token, return the token and also a SASL authcid value
to go along with it. Then when doing authentication in the future, this
authcid will select which credential to check against (the FAST token)
instead of using a custom mechanism (the <fast/> tag). This solves
one of the two warts in a way that works with SASL instead of
reinventing it.
Now, as for the duplicate mechanisms thing, I don't personally see why this
is needed at all at this point. A token is a password and thus should work
with any password-supporting SASL mechanism (HT-*, SCRAM, PLAIN, etc).
However, in case we want to still allow servers to not implement FAST for
every relevant SASL mechanism they support, I would suggest this change.
Instead of:
The problem is that for some mechanisms and authentication backends,
the server needs to know what kind of credentials are being used
up-front. In an ideal world, I think we would have SASL able to encode
this information.
Specifically, there are two things the server needs to know:
1) The type of credential being used (password, FAST token, bearer token, etc.)
2) In some cases, some identifier of the credential being used (when
the same user has multiple credentials of the same type, common with
tokens)
2:32 p.m.
On Mon, 10 Feb 2025 at 17:39, Stephen Paul Weber
<singpolyma(a)singpolyma.net> wrote:
The server would need to know that FAST is being used in order to know
it's not a username, but my understanding is that a reason for
proposing this is to remove the explicit indication to the server that
this is a FAST authentication. Right?
Well, passwords don't have such identifiers, only the username. It
feels somewhat hacky to override the meaning of authcid in this way.
I'd perhaps be okay with defining the authcid as a credential id,
except that it currently is not, and I definitely don't like the idea
of it sometimes containing a username and sometimes something else.
That's just asking for mix-ups, with potentially bad consequences.
Regards,
Matthew
The authcid is
how we convey the authenticating username.
Yes I understand that's what currently is placed there. I'm proposing that
for FAST we put a token id there, which will of course convey the account in
question to the server as well (since a token is only valid for a single
account). 1) The type of
credential being used (password, FAST token, bearer token, etc.)
2) In some cases, some identifier of the credential being used (when
the same user has multiple credentials of the same type, common with
tokens)
I think these are basically the same thing. We need to know what credential
is being used. If we have an identifier then we will also know the type of
that credential based on the id.
2:58 p.m.
Somebody claiming to be Matthew Wild wrote:
On Mon, 10 Feb 2025 at 17:39, Stephen Paul Weber
<singpolyma(a)singpolyma.net> wrote:
The server would need to know that FAST is being used in order to know
it's not a username, but my understanding is that a reason for
proposing this is to remove the explicit indication to the server that
this is a FAST authentication. Right?
Your concern is namepace collision between username and a fast token id if
the ids are also valid usernames?
I think since the IDs are fully under the control of the server this isn't a
problem is practise is it? The server would not assign any credential
(including FAST tokens) an id that is an existing username, and would not
allow creation of an account with username that matches any existing
credential id. Username is the credential ID for the "primary account
password" as used today.
The
authcid is how we convey the authenticating username.
Yes I understand that's what currently is placed there. I'm proposing that
for FAST we put a token id there, which will of course convey the account in
question to the server as well (since a token is only valid for a single
account). 
5 Feb
5 Feb
9:28 a.m.
On Mon, 13 Jan 2025 at 11:52, Daniel Gultsch <daniel(a)gultsch.de> wrote:
This message constitutes notice of a Last Call for
comments on
XEP-0484.
1. Is this specification needed to fill gaps in the
XMPP protocol
stack or to clarify an existing protocol?
Yes
2. Does the specification solve the problem stated in
the introduction
and requirements?
Yes
3. Do you plan to implement this specification in your
code? If not,
why not?
N/A (currently, at least).
4. Do you have any security concerns related to this
specification?
No
5. Is the specification accurate and clearly written?
Yes
BUT... I think we may have a problem with the replay protection included in
this layer.
Many many apologies for not having reviewed this until now. Or, you know,
if I knew about this before, I'd forgotten it, which I'm also sorry for if
this is the case.
When I designed CLIENTKEY - draft-cridland-kitten-clientkey-00 - Client Key
SASL mechanism
<https://datatracker.ietf.org/doc/draft-cridland-kitten-clientkey/> - it
was designed such that it, too, had replay protection built-in to the SASL
mechanism. When discussing this with various people at the IETF, it was
suggested that having a write for each authentication would be extremely
expensive in some environments, preventing the usage (LDAP was given as an
example here). Similarly, for clustered implementations this required a
coordinated write (and possibly a lock); otherwise it might be possible to
replay a session almost-concurrently and quickly enough to hit another
cluster node successfully. Anyway, a lot of push-back, which is why I
decided not to actively progress CLIENTKEY.
There's an additional concern at the back of my mind, which is that this
all represents a bit of a layer violation, which might be important or
might not be.
So...
One option here is to (as I did with CLIENTKEY) move the replay concern
into the SASL mechanism. I don't think this is a bad option; clients should
be expected to know the security properties of the SASL mechanisms they
use, and to know whether it's safe to use within TLS early data. But it
does mean servers cannot enforce (or at least, servers cannot easily
enforce) that an unsuitable mechanism hasn't been used in early data and
thus at risk of replay.
Another is to require it anyway at the FAST layer rather than the SASL
mechanism layer. This has advantages, but does mean that if the IETF ever
did take up CLIENTKEY or similar mechanisms with built-in replay protection
- I mean, other than DIGEST-MD5 - we're doing everything twice. And it also
means that the IETF might end up standardizing the other model.
Anyway, this is all very late - but I think we need consensus on an
approach prior to moving this along the track.
Dave.
11:23 a.m.
On 13/01/2025 12.50, Daniel Gultsch wrote:
This message constitutes notice of a Last Call for
comments on
XEP-0484.
Title: Fast Authentication Streamlining Tokens
Abstract:
This specification defines a token-based method to streamline
authentication in XMPP, allowing fully authenticated stream
establishment within a single round-trip.
URL: https://xmpp.org/extensions/xep-0484.html
This Last Call begins today and shall end at the close of business on
2025-01-27.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
Yep.
2. Does the specification solve the problem stated in
the introduction
and requirements?
Si!
3. Do you plan to implement this specification in your
code? If not,
why not?
Unfortunately, the time I can dedicate to voluntary XMPP development has
become scarce. I hope the situation will change again.
4. Do you have any security concerns related to this
specification?
The XEP states that the 'count' attribute protects against replay
attacks if TLS' 0-RTT data is used. I am not sure if this is true. An
attacker could take the original 0-RTT package from the wire and replay
it against the server. How does 'count' help here?
What is essential is that 0-RTT data only contains the authentication
data, but nothing more [1]. If it would contain, for example, also a
correctly pipelined <message/>, then an attacker could potentially
replay the 0-RTT data and cause the server to send the message.
Further remarks:
Shouldn't token invalidation be possible without having to go through a
SASL authentication? I am at a kiosk browser and hit the 'logout'
button. Now the browser first has to disconnect and reconnect to
invalidate the token?
Same for token rotation: what if a client has a long-lasting connection.
Wouldn't it be good to be able to rotate the token without having to
re-connect? Why not have the server simply push a new token to the
client if the current one approaches its expiry date?
- Flow
1: See also the relevant paragraph about 0-RTT in
https://datatracker.ietf.org/doc/html/draft-schmaus-kitten-sasl-ht-10#name-…
10 Feb
10 Feb
12:07 p.m.
On Wed, 5 Feb 2025 at 16:24, Florian Schmaus <flo(a)geekplace.eu> wrote:
Per the XEP, the server rejects subsequent packets with a 'count' less
than or equal to what it has already seen.
4. Do you have
any security concerns related to this specification?
The XEP states that the 'count' attribute protects against replay
attacks if TLS' 0-RTT data is used. I am not sure if this is true. An
attacker could take the original 0-RTT package from the wire and replay
it against the server. How does 'count' help here? What is essential is that 0-RTT data only contains the
authentication
data, but nothing more [1]. If it would contain, for example, also a
correctly pipelined <message/>, then an attacker could potentially
replay the 0-RTT data and cause the server to send the message.
I don't think this matters, if the server correctly rejects the
authentication. Servers already need to ensure they don't process
pipelined data on failed authentications (with or without 0-RTT).
Further remarks:
Shouldn't token invalidation be possible without having to go through a
SASL authentication? I am at a kiosk browser and hit the 'logout'
button. Now the browser first has to disconnect and reconnect to
invalidate the token?
Yes, I agree this is a bit awkward. We should spec a way to do this
after authentication, e.g. with a simple iq.
Same for token rotation: what if a client has a
long-lasting connection.
Wouldn't it be good to be able to rotate the token without having to
re-connect? Why not have the server simply push a new token to the
client if the current one approaches its expiry date?
Similarly, I think this could be added.
1: See also the relevant paragraph about 0-RTT in
https://datatracker.ietf.org/doc/html/draft-schmaus-kitten-sasl-ht-10#name-…
I think this text is overly restrictive, as explained above.
Regards,
Matthew
13 Feb
13 Feb
5:41 a.m.
On 10/02/2025 18.07, Matthew Wild wrote:
+1
I am sorry, but I don't think it was explained above. But I now
understand that your mental model regarding 0-RTT data differs from mine.
I am surprised that the FAST XEP mentions the issue with side effects
causing data in the 0-RTT payload, explaining that the counter would fix
that completely. That is not the case if the attacker removes the
original 0-RTT packet from the wire. It seems to be consensus by the TLS
designers that 0-RTT payload should only cause an idempotent operation.
But if we need replay protection, then the operation we protect is not
idempotent, as otherwise, we wouldn't need replay protection.
I believe you want to reduce XMPPs initial connection and authentication
delay as much as I do. But the 0-RTT data should only contain what is
necessary for (fast re-)authentication. Everything else should be done
in a subsequent [1], i.e., in the 1.5 round trip, which is a small price
to pay for the security you gain. As bonus, replay protection becomes a
non-issue for FAST.
If you really want to go down that route, then at least consider adding
a timestamp. This would reduce the time window for an attacker to replay
the packet. The timestamp could replace the counter, be in addition to
it, or even be optional.
Hopefully this does not come over as overly negative. I really
appreciate your work on FAST. I only disagree on technical grounds on
how 0-RTT is used in FAST.
- Flow
1: This probably needs support from Bind 2
On Wed, 5 Feb 2025 at 16:24, Florian Schmaus
<flo(a)geekplace.eu> wrote:
Per the XEP, the server rejects subsequent packets with a 'count' less
than or equal to what it has already seen.
But in the scenario I depicted, the authentication would succeed.
4. Do you
have any security concerns related to this specification?
The XEP states that the 'count' attribute protects against replay
attacks if TLS' 0-RTT data is used. I am not sure if this is true. An
attacker could take the original 0-RTT package from the wire and replay
it against the server. How does 'count' help here?
What is essential is that 0-RTT data only
contains the authentication
data, but nothing more [1]. If it would contain, for example, also a
correctly pipelined <message/>, then an attacker could potentially
replay the 0-RTT data and cause the server to send the message.
I don't think this matters, if the server correctly rejects the
authentication. Servers already need to ensure they don't process
pipelined data on failed authentications (with or without 0-RTT).
Further
remarks:
Shouldn't token invalidation be possible without having to go through a
SASL authentication? I am at a kiosk browser and hit the 'logout'
button. Now the browser first has to disconnect and reconnect to
invalidate the token?
Yes, I agree this is a bit awkward. We should spec a way to do this
after authentication, e.g. with a simple iq.
1: See also
the relevant paragraph about 0-RTT in
https://datatracker.ietf.org/doc/html/draft-schmaus-kitten-sasl-ht-10#name-…
I think this text is overly restrictive, as explained above.
6 a.m.
On Thu, 13 Feb 2025 at 10:42, Florian Schmaus <flo(a)geekplace.eu> wrote:
I am sorry, but I don't think it was explained above. But I now
understand that your mental model regarding 0-RTT data differs from mine.
I am surprised that the FAST XEP mentions the issue with side effects
causing data in the 0-RTT payload, explaining that the counter would fix
that completely. That is not the case if the attacker removes the
original 0-RTT packet from the wire. It seems to be consensus by the TLS
designers that 0-RTT payload should only cause an idempotent operation.
But if we need replay protection, then the operation we protect is not
idempotent, as otherwise, we wouldn't need replay protection.
Sorry, I think I understand now. The missing part is the assumption
that the attacker will block the original handshake and that client
will retry on failure. So the repeated transmission is actually coming
from the client itself generating a new packet, not from the attacker
duplicating things.
If the client does not increase the count unless the server responds
with <success/>, doesn't that fix this issue? But my confidence is
certainly decreasing at this point.
I generally dislike the use of timestamps for things like this. Either
something is safe, or it's not. Reducing the unsafe part to a small
time window is almost certainly going to remain unacceptably unsafe in
some circumstances.
1: See also the relevant paragraph about 0-RTT in
https://datatracker.ietf.org/doc/html/draft-schmaus-kitten-sasl-ht-10#name-…
I think this text is overly restrictive, as explained above. I believe you want to reduce XMPPs initial connection
and authentication
delay as much as I do. But the 0-RTT data should only contain what is
necessary for (fast re-)authentication. Everything else should be done
in a subsequent [1], i.e., in the 1.5 round trip, which is a small price
to pay for the security you gain. As bonus, replay protection becomes a
non-issue for FAST.
FWIW I do care about round trips, but I'm not trying to be fanatical
about it :) I don't think anyone implements 0-RTT at this point, and I
don't know how much anyone actually cares right now, considering the
other savings we've already achieved.
Regards,
Matthew
24 Feb
24 Feb
6:41 a.m.
On 13/02/2025 12.00, Matthew Wild wrote:
On Thu, 13 Feb 2025 at 10:42, Florian Schmaus
<flo(a)geekplace.eu> wrote:
I am sorry, but I don't think it was explained above. But I now
understand that your mental model regarding 0-RTT data differs from mine.
I am surprised that the FAST XEP mentions the issue with side effects
causing data in the 0-RTT payload, explaining that the counter would fix
that completely. That is not the case if the attacker removes the
original 0-RTT packet from the wire. It seems to be consensus by the TLS
designers that 0-RTT payload should only cause an idempotent operation.
But if we need replay protection, then the operation we protect is not
idempotent, as otherwise, we wouldn't need replay protection.
Sorry, I think I understand now. The missing part is the assumption
that the attacker will block the original handshake and that client
will retry on failure. So the repeated transmission is actually coming
from the client itself generating a new packet, not from the attacker
duplicating things.
Not only that.
The attacker could "hold" the original packet and the client will run
into a timeout, potentially assuming that the packet did not reach the
server and that the "commands" in the packet where not executed.
Afterwards, the attacker could replay the packet, causing the packet's
"commands" to be executed. This could leave the client in a state where
its assumption about what happened to be different from what actually
happened.
For example, the client may appear online to others, while it considers
itself being offline.
This can just be fixed by only including the data required for
authentication in the 0-RTT packet and performing everything else, in
particular resource binding, in a subsequent step.
1: See also the relevant paragraph about 0-RTT in
https://datatracker.ietf.org/doc/html/draft-schmaus-kitten-sasl-ht-10#name-…
I think this text is overly restrictive, as explained above.
If the client does not increase the count unless the
server responds
with <success/>, doesn't that fix this issue? But my confidence is
certainly decreasing at this point.
The only fix is for the 0-RTT data to exclusively contain material used
for authentication. Then an attack replaying the packet could "just"
authenticate the connection, but this connection would be unusable for
the attacker as they don't actually possess the TLS key material.
I generally dislike the use of timestamps for things
like this. Either
something is safe, or it's not. Reducing the unsafe part to a small
time window is almost certainly going to remain unacceptably unsafe in
some circumstances.
Right, but there is no need to close the door on 0-RTT yet. We need some
more implementation experience before we decide that. But as of now, we
certainly should not force 0-RTT implementers to shove more than the
data required for authentication into the 0-RTT packet.
- Flow
I believe you want to reduce XMPPs initial
connection and authentication
delay as much as I do. But the 0-RTT data should only contain what is
necessary for (fast re-)authentication. Everything else should be done
in a subsequent [1], i.e., in the 1.5 round trip, which is a small price
to pay for the security you gain. As bonus, replay protection becomes a
non-issue for FAST.
FWIW I do care about round trips, but I'm not trying to be fanatical
about it :) I don't think anyone implements 0-RTT at this point, and I
don't know how much anyone actually cares right now, considering the
other savings we've already achieved.
38
days inactive
80
days old
15 comments
5 participants
participants (5)
-
Daniel Gultsch -
Dave Cridland -
Florian Schmaus -
Matthew Wild -
Stephen Paul Weber