Re: WGLC of draft-ietf-xmpp-posh-02

On 14 October 2014 00:17, Ben Campbell <[email protected]> wrote:

> This is a Working Group Last Call of draft-ietf-xmpp-posh-02. The draft is
> 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.

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