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

[Peter Saint-Andre - &yet <[e-mail]>]

Hi Dave, our apologies for the delayed reply.

On 10/14/14, 2:42 AM, Dave Cridland wrote:
> On 14 October 2014 00:17, Ben Campbell <[e-mail]
> <mailto:[e-mail]>> 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.

Perhaps "it can probably be applied". We're not saying that it SHOULD be 
so applied.

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

It is a problem, and folks in that space would love to have a solution, 
but an HTTPS-based solution would work because it would be turtles all 
the way down.

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

Noted. The abstract could definitely be more concise!

> 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.

That is a problem, too. But I think the truly insuperable challenge is 
not being able to obtain such certificates in the first place.

> 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.

Yep.

> 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.

I prefer the term 'fable'.

> 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])."

Noted in both cases.

> 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.

Heh, yes, that's bad.

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

Yes.

> 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.

Indeed. This is assumed but not called out. It's really how all of this 
POSH stuff is bootstrapped in the first place.

> 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.

IMHO it was the least-worst solution, but I'll let my co-author speak to 
that more directly.

> 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?

I would say: 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)?

Given the ease of swapping out POSH files, it seems to me that the best 
defense here is to change your POSH file if you've been using a weak 
hash. It's not as if these are CA-issued certificates valid for years on 
end.

> 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.

Perhaps this would be better:

The delegation from the source domain to the delegated domain can be 
considered secure if the credentials offered by the POSH server match 
the verification materials possessed by the client, regardless of how 
those materials are obtained.

> 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.

A hosting switch would presumably be handled by updating one's SRV 
records, not primarily by updating one's POSH data.

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

This topic was raised during the POSH BoF a few IETF meetings ago, and 
we added the text to address the concern that we weren't using EST 
(Enrollment over Secure Transport = RFC 7030) or that we were offering a 
competing technology to EST.

> Summary:
>
> Some more work required.

Always.

> I still would rather the earth swallowed this whole, really, and we did
> these things properly.

Matt and I both think that the long-term solution is DANE. However, we 
also realize that it will take a long time for DANE to be widely 
deployed, and in the meantime we're not checking server identities in a 
strong fashion. POSH is just a stopgap and hopefully will last only 
about as long as the career of the Spice Girls. :-)

> 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.

Well, you have a point there. Unfortunately I can't claim that POSH will 
suddenly make people care about security if they don't care right now.

> Still, rant over - if we're to do this, there's a few rough edges in the
> specification,

Yes, we'll clean those up.

> and I'd appreciate knowing if the certificate identity
> mechanism has been properly reviewed.

IMHO the WG chairs might consider asking for an early or dedicated 
security review on that point.

Peter

-- 
Peter Saint-Andre
https://andyet.com/