POSH originated in XMPP WG --  having bof to see if others are also interested and if there's wider applicability

Matt Miller described Certificate Checking in XMPP
Key issue is deployed services do not really check for real certificates.  People are starting to care about who is listening to and recording their conversations.
Option 1: DNSSEC+DANE, but requires infrastructure changes
Option 2: POSH: Secure delegation (HTTPS redirects) and trustworthy delegation (HTTPS content)


John Levine described Certificate Checking in SMTP
Even though we have TLS in SMTP for decades, no one uses them.  Even if two servers connect and happen to start TLS, they do not check the certificates. Clients (SUBMIT, IMAP, POP) do SSL, but lots of kluge code to make particular popular services work. Exceptions: US military, where CA’s are fixed and community is closed.
Also there are some smtp implementations that use DANE.


Olle Johansson described Certificate Checking in SIP
Thing 1: MITM attack is built in (proxies and B2BUA's)
Thing 2: Lots of different specifications for what name goes into the certificate
S/MIME: specified, but no one does it
Answer? SIP Identity (RFC 4474)? Use HTTPS to fetch certificate for SIP domain
RFC 6072 SIP certificate distribution mechanism


Is there a problem that needs to be solved: A fair number (~20)
Is the problem well defined and understood: No; a small handful that says Yes (~5)

Cullen: what is the problem to be solve?
Joe Hildebrand: (1) how to have hosting companies host without having private keys
Paul Hoffman: not clear because people confuse authentication and authorization
Steve Kent: did not feel there is a solution described
Chairs: there *is* a draft that describes what gets shipped around
Jonathan Lennox: Hosting provider needs some kind of private key. CA's do not want to issue cross-domain certificates. Worse, the certificate is for the name, so if you get a certificate for XMPP, it is good for SMTP, etc.
Ian Smith: all protocols described are message-based protocols. The solution should be end-to-end (e.g., S/MIME), not TLS.
Matt: you still need to know WHAT server you are talking to
Joe: for example, you want to protect from traffic analysis from only metadata
Dave Crocker: only solves first hop (end to TLS)
Dave Crocker: after a day of study thinks he kind of gets it, but he is not sure there is enough of the problem space described.
Mark Nottingham: [is a hosting provider] has the problem of customers wanting him to serve TLS, but do not want to give him their certificates. He is talking HTTPS, not just XMPP et al.
Mike Richardson: there is a problem, it is well understood, and he does not get it. Also, lots of unwarranted FUD around DANE+DNSSEC
???: Why is EST not a solution (enrollment over secure transport)
Matt: first look up first hop - already not helpful (Dan would disagree)
Derek Atkins: Read the draft, thinks he understands, and still does not get the problem. He hears lots of people say they do not want to give out keys to hosting provider. "You want to get to a domain. You do not want host to have real keys. You need multiple hosts per domain. You have to trust your HTTPS hosting provider to make it work. So, why do you trust your HTTPS provider but not XMPP provider?"
Roberto: Assume you are a CDN that wants customers and customers want a CDN but the customer does not trust the CDN. So, you want to find a way to transitively trust.

Do people understand the problem: 2-3 now say No, about 20 said Yes

Are people willing to do the work? 5 people willing to write drafts, 6 people willing to write code, ~15 willing to review drafts, a few might actually use the work

Charter Discussion:
About 10 people looked at the charter.
Moving discussion to the mail list.
Paul Hoffman points out the charter talks only about XMPP, but we talked about SIP and SMTP too.
Alexey: protocol document does talk about it
Remember to discuss in posh@ietf.org