Subject: [xmpp] dialback in 3920bis?

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Jun 2010 10:10:18 -0600

We had an inconclusive discussion about this topic in the past few
weeks, so I'd like to re-start it: do we want to include server dialback
in 3920bis?

Pro: everything is in one place, and server developers can reference one
document to implement the core of an XMPP server.

Con: security folks always object that "dialback doesn't provide any
real security, you should use SASL instead for strong authentication".

What are the other positives and negatives?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jehan Pagès <[email-masked]>
Date: Wed, 23 Jun 2010 01:58:55 +0900

Hi,

> What are the other positives and negatives?

the problem of keeping dialback in the main specification is also that
it still gives it a lot of legitimization (even though we would
explicitely write preference of TLS + SASL over dialback). This would
be ok if we just changed the s2s mutual authentication system, for
retro-interoperability. But since when have we shifted from dialback
to TLS+SASL in s2s as the "right way to do it"? Years now! It is time
to move on and write it away from the core specification. Then step by
step, some day in a later version of the core specification, we will
be finally able to forget completely about dialback, becoming nothing
more than a historical note.

If we don't do it, dialback will remain the most widely used s2s
authentication system for years and years, which is currently like a
enormous security breach in the federated network (that's nice and all
to have very nice secure servers but if we still acknowledge too much
insecure s2s connections, this is like a broken link on an otherwise
very strong chain: useless).

So this is my opinion: let's move dialback away from 3920bis so that
implementers stop consider it mainstream.

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Jun 2010 11:09:18 -0600

> very strong chain: useless).

If DNSSEC were widely deployed, would TLS+dialback mostly serve the
needs of service providers? Yes, I think TLS+SASL with CA-issued certs
isn't *that* hard and is really the right way to go, but I'd also like
to hear from people who think that TLS+dialback has value.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Cridland <[email-masked]>
Date: Tue, 22 Jun 2010 21:55:32 +0100

> document to implement the core of an XMPP server.

Excellent. Let's also fold in SASL, TLS, SCRAM, PLAIN, and all other  
dependencies.

</snark>

Seriously, it's fine where it is. I think we could be more honest  
about explaining that XEP-0220 based authentication is the norm,  
rather than the exception, and is effectively mandatory for federated  
implementations on the Internet of today.

I think we're gaining more understanding of excactly how secure  
dialback is in various cases, and the volatile nature of such  
understanding probably fits the XEP model better than the RFC model.

FWIW, Philipp Hancke's suggestion of using db:result handling in lieu  
of SASL EXTERNAL makes a large degree of sense, and I think in  
general there's plenty of mileage to be had out of the syntax we have.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Philipp Hancke <[email-masked]>
Date: Tue, 22 Jun 2010 23:24:10 +0200

> weeks, so I'd like to re-start it: do we want to include server dialback

No. Some parts of dialback (in particular the rules for target 
piggybacking I introduced) have afaik not yet been implemented by anyone 
so they're not backed up by implementation experience.

The question is actually if we want to keep TLS+SASL EXTERNAL in 
3920bis. Imo, XEP 0178 already provides the canonical documentation of 
that and I was quite unhappy with some of the changes when reviewing 
-08. XEP 0178 is, however, designed to use dialback as a fallback if 
TLS+EXTERNAL does not work.

---

From: Justin Karneges <[email-masked]>
Date: Tue, 22 Jun 2010 14:56:03 -0700

On Tuesday 22 June 2010 13:55:32 Dave Cridland wrote:
> I think we could be more honest about explaining that XEP-0220 based
> authentication is the norm, rather than the exception, and is effectively
> mandatory for federated implementations on the Internet of today.

I think it's ridiculous to defer to a XEP what is arguably the reason we are 
even still talking about XMPP.

But I agree with you in that if dialback must live in a separate specification 
then it should be presented in such a way that it is considered an essential 
part of the collection.

-Justin

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 27 Jun 2010 21:15:33 -0600

> then it should be presented in such a way that it is considered an essential 

I've added a clearer note about that to my working copy.

There's some history to this issue. When we formalized XMPP the first
time around, we got beat up about dialback by the security folks active
in the IETF at that time (mostly 2002), with the feedback that it's not
an authentication mechanism and we should strongly prefer TLS+SASL.
There was talk even at that time about pulling dialback out of the core
spec but we left it in for the sake of documenting what was used on the
network. Now, eight years later, dialback is still what's used on the
network. As editor, I'd be willing to put dialback into the core spec
(3920bis) again, but we'd need to:

1. Have clear list consensus that such is the right approach

2. Come to agreement regarding specificiation of the server dialback
protocol (presumably taking the latest text from XEP-0220)

3. Probably define the somewhat nebulous concept of TLS+dialback

4. Hold a second WGLC regarding 3920bis

All of that would slow us down and mean that we wouldn't meet our August
2010 milestone, but if we think it's worth the time and effort so that
everything core server developers need is in one place, I'd be willing
to make this happen.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jehan Pagès <[email-masked]>
Date: Mon, 28 Jun 2010 14:48:28 +0900

Hi,

> 1. Have clear list consensus that such is the right approach

I think we don't really have it.

> protocol (presumably taking the latest text from XEP-0220)

In my opinion, the real issue with dialback is not just that it is
insecure but that the end users are unaware of using an insecure
stream. Worse they may think they are using a very secure connection
if their c2s connection is secure (TLS with good cert and SASL). Here
we are in a case where a man-in-the-middle simply has to offer only
insecure stream features and the originating server will silently
downgrade its security without asking much question or telling any of
the users using such stream.
You even have a note about this:

«
This reality introduces the
   possibility of a downgrade attack from TLS + SASL EXTERNAL to
   dialback if an attacker can gain control of the channel and therefore
   convince the initiating server that the receiving server does not
   support TLS or does not have an appropriate certificate.
»

And I don't like this reality because it simply means that the best
security in the world means nothing, considering that you can silently
come down to an insecure method. This would be as though you were
asking you bank website in https and it would be able to downgrade to
http without the user knowing it nor receiving any warning (maybe you
would even see the lock logo in your browser as though you were
secure). Hence in a way we are, on this particular link in our
security chain (s2s), even less secure than http, which is a real
shame (as http is so insecure).

Security is not about having one possible very secure method and some
other insecure ones, but it is about knowing when you are using either
of them, so when you can trust your connection (or rather how far you
can trust it: for instance on a really insecure one, I don't care for
my chit-chat with friends; on a fully TLS-SASL-secured one between
every node, I could speak business secrets as I trust any connection
relay as well; and I would give my credit card information only on an
end to end encrypted connection). Here as a end user, I cannot
differentiate the first 2 security levels (I know I am c2s-secured or
not, not I don't know anything about the s2s link used and the c2s
link of my correspondent). So this is useless security right now. We
are honestly only offering imaginary good s2s security.
Bye.

Jehan

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 28 Jun 2010 11:17:57 +0200

> an authentication mechanism and we should strongly prefer TLS+SASL.

What exactly have you been telling them? If you told them about Merlin 
casting his spell... :-)

Historical note: the function used by jabberd1 for key generation and 
validation was called 'dialback_merlin' and was printing a
"merlin casts his spell(%s+%s+%s) %s",secret,to,challenge,res)
to the log files.

The dial-back part of the protocol (steps 2+3) is still something I am 
not happy with. As an implementor, I will gradually replace it by some 
kind of reverse dns lookup along the lines of what Kurt Zeilenga 
described when we discussed mutual auth for s2s.

> protocol (presumably taking the latest text from XEP-0220)

Without the rules for multiplexing target domains (unless someone 
volunteers to implement and validate those). Those could be defined in 
an extension.

We might need an additional stream error for closing down a domain pair 
if that is still a major use-case for connection reuse.

> 3. Probably define the somewhat nebulous concept of TLS+dialback

s/TLS+dialback/DWD/ ?

> everything core server developers need is in one place, I'd be willing

Well, did we meet our March 2010 milestone on s2s connection reuse? But 
that depends on dialback (piggybacking), too.

philipp

---

From: Ben Campbell <[email-masked]>
Date: Tue, 29 Jun 2010 17:45:07 -0500

[as co-chair]

> I think we don't really have it.

I'm not seeing seeing such a consensus from list discussion so far. Does anyone think we _do_?

---

From: Matthew Wild <[email-masked]>
Date: Wed, 30 Jun 2010 00:24:58 +0100

> I'm not seeing seeing such a consensus from list discussion so far. Does anyone think we _do_?

I'm not in favour of moving dialback into the core spec. We know we
need to move away from it (in its current form at least), it's still
undergoing changes (we can update it more easily as a XEP) and finally
I don't subscribe to the "all in one place" view - implementors (like
me) may be stupid, but I'm honestly capable of clicking links in
documents :)

Matthew

> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: Curtis King <[email-masked]>
Date: Wed, 30 Jun 2010 09:34:52 -0700

On 2010-06-29, at 4:24 PM, Matthew Wild wrote:

> I'm not in favour of moving dialback into the core spec.

+1

> We know we

+1

I found it much easier to implement rfc3920 without dailback in it and dailback itself as standalone spec.

ck