Re: [TLS] SAS extension?

> Dan Wing wrote:
> > Peter Saint-Andre wrote:
> > 
> >> In the XMPP community we are defining a way to use TLS for
> >> end-to-end encryption. We'd love to use short authentication
> >> strings (SAS) for identity verification. As far as I can see no one
> >> has worked on a TLS extension for SAS. Is there interest in doing
> >> so? I'd be happy to help write an I-D on this topic, but I'm not a
> >> TLS or security expert so it might not be appropriate for me to
> >> lead the effort.
> > 
> > Yes, I'm interested in this, primarily from the perspective of
> > DTLS-SRTP.  Such a scheme could be helpful as an out-of-band
> > validator of end-to-end identity in the presence of SBCs which 
> > destroy signature scheme (RFC4474).  There have been active
> > discussions on SIP about this for over a year, but no forward 
> > progress.
> 
> Oh gosh, I don't know that I want to venture down the SIP 
> Identity rat hole. :) 

heh.

> But yes I suppose SAS could be helpful there. 
> And if building a SAS extension for TLS will help solve interesting 
> problems for both SIP and XMPP technologies, that's a good thing.

Yep.

> > In another message, Peter Saint-Andre wrote:
> > 
> >> The more I read about SAS, the more I wonder about applicability, 
> >> too.
> >>
> >> In the XMPP community we have worked on a technology for end-to-end
> >> encryption of messaging sessions (a.k.a. encryption sessions, see
> >> [1]), and it has a SAS feature, but it's not clear to me if that
> >> feature is well-specified with regard to the channel in which the
> >> SAS could be communicated (we can't use the XMPP channel, because
> >> we're trying to bootstrap that channel). In any case we have now
> >> begun investigating more seriously the use TLS for end-to-end
> >> encryption of XMPP traffic, both in the link-local case and over
> >> the typical XMPP client-server architecture (see [2], [3], and
> >> [4]). Those developers who have implemented the encrypted sessions
> >> technology think its SAS feature is nifty and would like to have
> >> that feature in the TLS-based technology as well. But as you say,
> >> the SAS would need to be communicated at least via a different
> >> channel and preferably via a trustworthy channel. Developers seem
> >> to think that communicating it via PSTN is sufficient, but doing so
> >> would mean only that an attacker would need to control two
> >> channels, not that the second channel is trustworthy. So we need to
> >> research what might function as a trustworthy channel (e.g.,
> >> encrypted email).
> >>
> >> 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.

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

> Join 
> the security@xmpp.org list if you're interested in discussing 
> the topic:
> 
> http://mail.jabber.org/mailman/listinfo/security

Thanks,
-d

> Peter
> 

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls