Subject: [xmpp] About POSH

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 21 Jun 2013 01:46:54 +0000

Earlier this month, Peter Saint-Andre and I submitted [POSH] as a more generic solution to the secure delegation problem.  We believe that it is applicable to other non-HTTP services, and have gotten some informal feedback to that end.

We would greatly appreciate any feedback this group can provide on the new version, especially if you have opinions about its use for other non-HTTP services.  The discussion forum is < [email-masked] >.

Thanks!

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

[POSH] :: PKIX over Secure HTTP < http://tools.ietf.org/html/draft-miller-posh-00 >

---

From: Simon Tennant <[email-masked]>
Date: Fri, 21 Jun 2013 13:34:59 +0200

What's unclear to me is the lookup order and which certification to trust?
- should I trust DNSsec before POSH?

Is there any versioning of the results. I presume this is v1.0. How will
clients handle newer versions of the protocol?

Can any of this lookup reuse the the DNS-SD discovery protocol (the TXT
record format and IANA registry)?
https://tools.ietf.org/html/rfc6763#page-19

Of course my fear with anything webfinger-y, is that it supposes the type
of people who look after the infrastructure can work with the people that
look after content that goes onto the naked domain (which is usually
outsourced or run by an web agency). IMHO, a far more reliable approach
would be to have a dedicated URL away from the root domain for this content
(https://posh.example.com, for example).

S.

On 21 June 2013 03:46, Matt Miller (mamille2) <[email-masked]> wrote:

> Earlier this month, Peter Saint-Andre and I submitted [POSH] as a more
> generic solution to the secure delegation problem.  We believe that it is
> applicable to other non-HTTP services, and have gotten some informal
> feedback to that end.
>
> We would greatly appreciate any feedback this group can provide on the new
> version, especially if you have opinions about its use for other non-HTTP
> services.  The discussion forum is < [email-masked] >.
>
>
> Thanks!
>
> - m&m
>
> [POSH] :: PKIX over Secure HTTP <
> http://tools.ietf.org/html/draft-miller-posh-00 >
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>
>

-- 
Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
goo.gl/tQgxP

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 26 Jun 2013 05:24:37 +0000

[including [email-masked]; will remove [email-masked] in subsequent replies to this thread]

> - should I trust DNSsec before POSH?

I believe much of that is still in [XMPP-DNA], but we are recommending that applications try to locate both as simultaneously as possible (a la Happy Eyeballs).

Otherwise, I think it comes down to what the application implementers (and application deployers) believe will most quickly result in success.

> clients handle newer versions of the protocol?

The content is JSON, and conforming to a [JWK] Set.  I think it could be extended to add a "version" or "poshVer" property if needed.

Do you see any specific changes you think are likely and would require versioning for interoperability?

> https://tools.ietf.org/html/rfc6763#page-19

I don't think that DNS-SD itself provides any real benefit here.  This is effectively reusing portions of the SRV query (including the registry of service and protocol names), while reusing a highly popular data encapsulation format for which parsers and generators are readily available for just about every conceivable platform.

> (https://posh.example.com, for example).

I fail to see how shifting the burden from one content distributor to another is far more reliable.  Presumably, if the source-domain owner already contracted with one agency to host their HTTPS service and another (or some collection of anothers) for their non-HTTPS services, it stands to reason they would then most likely contract with said HTTPS hosting agency for the "posh." + source-domain.

In my opinion, requiring "posh." + source-domain actually makes this less reliable because it requires implicit trust in DNS hierarchies always reflecting the domain ownership a specific way, but without actually easing the deployment burden.

- m&m

[XMPP-DNA] Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP) < http://tools.ietf.org/html/draft-ietf-xmpp-dna >
[JWK] JSON Web Key (JWK) < http://tools.ietf.org/html/draft-ietf-jose-json-web-key >