Subject: Re: [TLS] SAS extension?

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Aug 2008 08:44:10 -0700

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
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 05 Aug 2008 10:57:10 -0600

> discussions on SIP about this for over a year, but no forward 

Oh gosh, I don't know that I want to venture down the SIP Identity rat 
hole. :) 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.

> with sensitive information or the company's intellectual 

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.

> http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01 

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. 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. Join 
the [email-masked] list if you're interested in discussing the topic:

http://mail.jabber.org/mailman/listinfo/security

Peter

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Aug 2008 10:07:29 -0700

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

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

> 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 
> 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 

Thanks,
-d

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 05 Aug 2008 11:36:38 -0600

>>> Peter Saint-Andre wrote:

<snip/>

> all prefer auditable systems -- not systems that rely on humans

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

> (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

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 06 Aug 2008 10:07:48 +0300

Hi Peter,

if you have a long-lived association with someone, you can certainly 
obtain much stronger credentials for him/her (e.g. a self-signed cert 
for which you know the fingerprint, cf. BTNS). You don't need to resort 
to the weaker SAS? Or am I missing something?

Thanks,

    Yaron

>
> 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
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 Aug 2008 08:40:40 -0600

> to the weaker SAS? Or am I missing something?

Quite possibly, yes.

We even have an Intermediate CA (see <https://www.xmpp.net>) and I'm 
investigating the possibility of using it to issue client certificates 
so that end users can easily obtain Class 1 certs from a CA that is 
recognized on the Jabber network (currently we use it only to issue 
server certs). But even so we might want to use SAS as a shorthand way 
of verifying certs, since fingerprints are perceived as too long to 
communicate. Or so I'm told -- I'm one of those strange people who 
verifies fingerprints for ssh so I don't feel the need for SAS myself...

Peter

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 07 Aug 2008 18:28:53 +0300

Hi Peter,

sorry, I wasn't clear. I didn't mean manual comparison of the 
fingerprint. I meant if you've been communicating with this person 
multiple times, you can store their fingerprint once and compare it 
*automatically* in the future. I think SAS should only be needed for the 
first communication, and something stronger should be used afterwards.

Thanks,

    Yaron

Peter Saint-Andre wrote:

>>> 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.
>>>
>>
>> for which you know the fingerprint, cf. BTNS). You don't need to 
>> resort to the weaker SAS? Or am I missing something?
>
> Quite possibly, yes.
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 Aug 2008 15:21:35 -0600

> first communication, and something stronger should be used afterwards.

Oh yes, for sure -- those principles are part of the core cert checking 
rules for XMPP in the client-to-server and server-to-server cases, but 
we'll need to define something similar in the end-to-end case as well.

More here:

http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-06.html#security-certificates

Peter