Subject: [xmpp] WGLC of draft-ietf-xmpp-posh-02

From: Ben Campbell <[email-masked]>
Date: Mon, 13 Oct 2014 18:17:23 -0500

(Oops, messed up the authors' address the first time. Apologies for the duplicate.)

This is a Working Group Last Call of draft-ietf-xmpp-posh-02. The draft is available at the following URL:

http://tools.ietf.org/html/draft-ietf-xmpp-posh-02

The WGLC will conclude on 27 October, 2014. Please send your comments to the authors and the XMPP mailing list.

Thanks!

Ben.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 14 Oct 2014 09:42:48 +0100

> available at the following URL:

0) Abstract:

The last sentence is problematic, because it's not clear that the XMPP WG
can make such a pronouncement.

Also, it fails to explain why hosted HTTPS isn't a problem, but I suspect
I'll never understand that one. :-)

I note that this Abstract is huge, and contains almost the same information
as the Introduction.

1) Introduction:

I was under the impression that when this issue was first raised, the
problem was one of management of certificates rather than anything else -
that is, if you host 1,000 domains, you needed to have a certificate for
each of them in practise, and this meant handling 1,000 certificates, each
with different expiry dates etc.

Suggestion: After the existing three bullet points:

o Even if your legal department is happy, this still means managing one
certificate for each customer across the infrastructure, contributing to a
large administrative load.

Though the same organization that raised this point seems perfectly happy
to do so for HTTP; as noted before, this is because of Strange Things
Beyond My Understanding.

Finally, this section does not constitute a thought experiment, but an
illustrative story.

3) Obtaining Verification Materials

It would make things clearer if the term of art "source domain" were
briefly introduced, at least hinting at its meaning. While it's mentioned
in Terminology, because there is no typographic convention to alert the
reader that it is a term of art, it's difficult to spot it immediately. As
an alternative to calling it out, perhaps capitalizing it (although it's
not capitalized in RFC 6125)?

I note that "end-entity certificate" is not called out explicitly, but this
is probably OK - though using it in the initial point 1's parenthesis may
help. "(in PKIX, this takes the form of a PKIX end-entity certificate
[RFC5280])."

In the second numbered list, there seems to be a dearth of metasyntactic
variables. The Foo client connecting to the foo domain to verify the Foo
service by looking for the foo token is almost awesomely unclear. Since at
this stage we have already established that the Source Domain contains
"foo", perhaps we could make this the "Bar" service, with posh.bar.json -
this also has the advantage that the Bar Service is very familiar to a
large proportion of the XMPP community.

Within this point 1, "foo.example.com" is referred to as the "domain" - it
is, I think, the Source Domain, and would be clearer noted as such.

Finally, I think it's worthwhile stressing that although the ultimate goal
is to verify the certificate foo presents for the Bar service of the Source
Domain, the certificate presented by HTTPS is still validated in isolation
by traditional methods - that is, the HTTPS cert has to be valid for the
Source Domain.

3.1) Source Domain Possesses PKIX Certificate Information

I'll freely admit I'm not terribly keen on this being in JSON. It means
including a JSON library within XMPP; we've not needed one before.

3.3) Performing Verification

a) This reads "You take a bunch of hashes and see if any match". Given the
example contains more than one hash function, which should be used? Both?
Whatever the client supports?

b) I've a nagging feeling that we should include Issuer and Serial matches
as well, in order to mitigate against hashes becoming weaker. I suspect
that hashing only the keying material (or using the SKI) might be even
better. Has this been run past someone who actually knows some crypto (ie,
someone other than me)?

4) Secure Delegation

This text reads that we should match the "POSH certificate". This is
presumably a term of art, but used only in this section. Similarly "TLS
server" is used only once, here. There are two TLS servers at play here,
and it's unclear what a POSH certificate might be; given that the only
certificates discussed are not the JSON objects.

7) Alternates and Roll-over

It appears that it is impossible to state something like a switch of
hosting using this mechanism; also I'd note that this same mechanism might
also be used if a hosting provider has multiple certificates.

8) Security Considerations

Not really sure that the second paragraph belongs here. (Nor, actually, am
I sure it belongs anywhere in the document).

Summary:

Some more work required.

I still would rather the earth swallowed this whole, really, and we did
these things properly. I would be happier to go along with this if there
were any sign that large hosting providers in the XMPP world were at all
likely to deploy any kind of security at all, but this seems unlikely
because of the combination of this not being trivial, and there being
implementations which follow the strict rules of RFC 6120 and drop the
session if TLS is encountered with a non-matching certificate - yet
cheerfully connect if there's no TLS at all.

Still, rant over - if we're to do this, there's a few rough edges in the
specification, and I'd appreciate knowing if the certificate identity
mechanism has been properly reviewed.

Dave.

---

From: Philipp Hancke <[email-masked]>
Date: Sat, 25 Oct 2014 10:16:08 +0200

minor editorial stuff:
 > While this approach was developed for use in the Extensible
 > Messaging and Presence Protocol (XMPP) as a Domain Name
 > Association prooftype, it can be applied to any non-HTTP

"Domain Name Association (DNA) prooftype" (as done at the end of the 
introduction)?

section 1:
 > The product managers in your company are pushing you

bugging you? :-)

section 3.2:
 > The client performs an HTTPS GET for the URL

HTTPS GET _request_ for the URL?

---

From: Philipp Hancke <[email-masked]>
Date: Sat, 25 Oct 2014 10:41:14 +0200

> The WGLC will conclude on 27 October, 2014. Please send your comments to the authors and the XMPP mailing list.

In several places, "Server identity" and "TLS client" are used, e.g.
 > Server identity checking (see [RFC6125]) involves three different
 > aspects:
[...]
 > a TLS client SHOULD consider the delegation invalid.

I think this is not the "TLS client" but the "POSH client" and the "Peer 
Identity". The main use case is when an xmpp s2s-server uses POSH to 
verify an incoming connection.

section 5:
	The TLS client SHOULD perform all POSH retrievals
	before opening any socket connections to the application
	protocol server.
(ed: extra whitespace before that sentence)

SHOULD is too strong here. I see it as a fallback rather and would only 
do POSH when not finding a proper identity. This would mean that 
sometimes, POSH is used without need.
I suspect this makes it easier to use POSH as part of the TLS handshake 
rather than as an application layer check.

This is also not possible for the s2s scenario where POSH may be 
triggered by an incoming
<db:result>somekeywhichwouldnotbeused</db:result>
which would happen after <starttls/> and after the TLS handshake itself 
is done.

Should be easy to fix though.