> On 17 feb. 2016, at 22:46, Matthieu Rakotojaona > <matthieu.rakotoja...@gmail.com> wrote: > > Le mercredi 17 février 2016 19:18:01 CEST, Florian Schmaus a écrit : >> requiring the initiator to save the server cert and verify that it >> hasn't changed > > Be aware that this will probably "soon" be impossible with TLS 1.3 which > allows 0-RTT Handshake (see > https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2): application data will > be sent along with TLS handshake info by the client, which means the server > certificate won't be visible by the client until after the token (or its > transformed version) has already been sent. > > Moreover, there are legitimate cases where the server cert can change yet > security hasn't been compromised: a certificate is renewed, the initiator is > redirected to another server of the cluster through the location attribute.
0RTT (and RFC 5077 resumption too) requires the client to have certain data
cached from the server, for 0RTT including an ephemeral DH key. So in 0RTT the
connection is still authenticated to the original certificate (and I assume
implementations are still required to verify this certificate).
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.
>> You are right, exposing the 'tok' in <inst-resume/> without having the
> server verified seems like a bad idea.
>
> What are the cases where a MiTM server could decipher 'tok', after the
> *mandatory* TLS dance has been done, yet shouldn't have been ? I only see the
> case where the MiTM server has gotten hold of the legit server's private key,
> in which case:
>
> * the legit server is owned
> * the MiTM server doesn't even need to bother with ISR, it can ask everybody
> to re-auth through standards ways. It's going to be even more juicy for him
> because he'll have access to actual passwords (he can send PLAIN as the only
> accepted mechanism, does any client give the possibility to refuse a PLAIN
> auth ?)
> * (possibly more controversial) it's the domain of TLS anyway, it's not
> XMPP's role to add yet another layer of hand-made security
>
>
> Actually it seems to me that TLS remains the part that does server
> "authentication", and the token replaces only the SASL exchange for client
> authentication.
The combination of mutual authentication and channel binding gives
SCRAM-*-PLUS a much stronger authentication than PKI TLS: the password
effectively becomes a shared secret that authenticates the TLS connection.
Sure, the current tls-unique channel binding is pretty broken, but I believe
some work has been done to fix it [1]. An attacker which has compromised a CA
will not be able to MitM connections when the client expects channel binding
to work (there are some clients that "pin" the SASL mechanism they see and
won't accept downgrades).
Just because TLS already includes authentication doesn't mean that any extra
authentication is automatically wrong or useless. All TLS can do is verify
that some CA claims the information on a certificate belongs to the holder of
a private key, while we're in a much better position already because the
client and server share some secret information. SRP or PSK could do this too,
but they seem pretty much dead.
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: <enabled
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).
[1] = https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03
Regards,
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 _______________________________________________
