Re: [TLS] SAS extension?

Dan Wing wrote:
>> Dan Wing wrote:
>>> Peter Saint-Andre wrote:

<snip/>

>>>> Whether Aunt Tillie would even check the SAS (or any other
>>>> credential) properly is another matter, but that's a separate
>>>> topic...
>>> That inability to audit is a significant hurdle for commercial
>>> deployment, of course.  The problem isn't just Aunt Tillie, it
>>> is the "busy" CxO who can't be bothered to verify they are
>>> really talking to accounting versus talking to a social engineer
>>> that wants to turn a profit prior to the release of a company's 
>>> end-of-quarter financial results.  Similar risks exist with 
>>> drug researchers or any other portion of a company that deals
>>> with sensitive information or the company's intellectual 
>>> property.
>> Well, I tend to think that people who can't be bothered to learn at 
>> least a little bit about security don't deserve to have secured 
>> communications. I realize that's a bit harsh, but so be it.
> 
> Internal auditors, HIPAA, SEC regulations, and Sarbanes-Oxley
> all prefer auditable systems -- not systems that rely on humans
> to remember something.

Aha, sorry, I had missed your text about auditors the first time around.

>>>> [1] http://www.xmpp.org/extensions/xep-0116.html
>>>> [2] http://www.xmpp.org/extensions/xep-0246.html
>>>> [3] http://www.xmpp.org/extensions/xep-0174.html
>>>> [4] http://www.xmpp.org/extensions/xep-0247.html
>>> An approach that some SIP folks considered for end-to-end TLS is
>>> to re-use HTTP's CONNECT (which is how you proxy HTTPS through
>>> an HTTPS proxy).  This might also be helpful for XMPP.  The SIP 
>>> approach is described in 
>>> http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01 
>>> (now expired).
>> Yes, that might work for SIP -- I'm not competent to judge. 
>> For XMPP, we 
>> already use TLS for client-to-server streams, 
>> server-to-server streams, 
>> and direct client-to-client streams in the link-local case. 
> 
> That is very similar to SIP.
> 
>> So re-using TLS for end-to-end connections (via a reliable 
>> transport such as a 
>> direct TCP connection negotiated via ICE-TCP, a mediated 
>> bytestream, or 
>> even XMPP itself) makes a lot of sense for our developer 
>> community.
> 
> Are you trying to secure the data connection between the XMPP
> peers, or trying to secure XMPP signaling between XMPP peers
> that have successfully rendezvoused via XMPP?
> 
> (SIPSEC does the latter.)

Translating SIP-speak into XMPP-speak, I would say the latter. Typically 
this would be used to secure the messages and other signalling traffic 
that you exchange with someone who is known to you, i.e., the person's 
JabberID is already in your XMPP roster (contact list) and you already 
have a long-lived, bi-directional presence subscription with the person.

Peter

Re: [TLS] SAS extension?

Attachment: smime.p7s