Re: [TLS] SAS extension?

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.

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.

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

-d

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