Subject: [rtcweb] SDES vs DTLS-SRTP revisited

From: Oscar Ohlsson <[email-masked]>
Date: Fri, 16 Mar 2012 16:04:54 +0100

Hi,

There were a couple of things that I didn't explain properly in my SDES vs DTLS-SRTP presentation at the interim meeting. Since time will be short at the next meeting as well, I thought I would try to explain myself in an email.

I noticed that the discussion quickly turned into a direct comparison of the two protocols. When this happens DTLS-SRTP definitely comes out as the winner and trying to defend SDES just seems foolish. But this is not the right focus of the discussion IMO. We should be looking at the system as a whole and determine more exactly the scenarios where SDES poses a security risk.

The first major argument against SDES is that it doesn't offer forward secrecy. Obviously, if the remote endpoint does not support DTLS-SRTP you have to switch to SDES or plain RTP at some point. And from that point and onwards you will never have forward secrecy. The only difference is that the conversion point is moved slightly to the left (one step?) when SDES is supported. However, if web developers starts using SDES without reason (i.e. when the remote endpoint is a browser) then I agree that the lack of forward secrecy is a problem. Do people on this list believe this will be the case? Can it be prevented somehow?

The second major argument is that SDES makes it possible for the service provider to intercept calls undetectable. I've been thinking about this for some time but still haven't understood the problem completely. Say that you're on a call and want to determine if the service provider is listening in:

Case 1: Both endpoints support DTLS-SRTP (can be determined by asking the other party)

If SDES is used you directly conclude that something fishy is going on and hang up. If DTLS-SRTP is used you compare fingerprints and hang up if they don't match. (I've assumed that a user can view detailed security information in the browser).

Case 2: The other endpoint does not support DTLS-SRTP

Regardless of whether SDES is allowed or not you will never be able to tell if the call is being intercepted. The best thing to do in this case is probably to simply hang up.

Does the fingerprint mismatch in case 1 somehow serve as a stronger indication that the call is being intercepted? What action would a suspicious user take besides hanging up? I would be happy if someone could explain this to me.

Regards,

Oscar Ohlsson

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 16 Mar 2012 13:21:09 -0400

Oscar,

I am afraid I missed the point here.

How can one determine that the call is being listened to?   How can the 
browser know whom the RTP stream is passing through?

If you know the SRTP key and filter the flow directed at me, you will be 
on the conversation, right?

Igor

On 3/16/2012 11:04 AM, Oscar Ohlsson wrote:
> ... Say that you're on a call and want to determine if the service provider is listening in:
>
...

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Mar 2012 15:32:05 -0700

> Does the fingerprint mismatch in case 1 somehow serve as a stronger indication that the call is being intercepted? What action would a suspicious user take besides hanging up? I would be happy if s…

Hi Oscar,

Yes, I think the fingerprint mismatch in case 1 serves as a stronger indication
that something was wrong, because there is no technical reason for the
fingerprint not to match if both sides believe they are doing DTLS. I.e.,
it always indicates either a software defect or a man in the middle.
And the suspicious user of course should hang up, but they should also
post pictures to /., which, I would think, serves
as a pretty significant deterrent to providers tampering with people's calls!
By contrast, with SDES, the attack scenario and the legitimate scenario
look the same.

We actually have a worked example of this with Diginotar, where a mechanical
system for detecting MITM attacks lead to a report to Google of such an
attack and, IIRC, Diginotar being removed from the root list.

Best,
-Ekr

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Mar 2012 03:16:48 +0000

> it always indicates either a software defect or a man in the middle.

Absolutely, if DTLS-SRTP is used AND both sides verify the same fingerprints, you know it's either end-to-end or not. (you can't actually jummp to the conclusion of a software defect or MitM, but I'll respond to that in a separate email)  

But that's not really the point.  The point is the browser can't show a lock-icon regardless - it needs the user to do something more, or else it has no more meaning of security than SDES.  The DTLS connection *might* be end-to-end, or it might not, and the only way to know is for the user to actually check.  So the browser cannot show a lock-icon, and will have to say something like this in the info box of advanced details: "The media might be secure end-to-end, but only if the following string matches what the far-end user sees…".

So imagine if we allow SDES, only if the far-end did not offer DTLS-SRTP, and only if the browser's connection to the web-server was HTTPS.  Then if the user goes to check that advanced details box, we can mandate in the RFC that they will be shown that there is no way to verify it is end-to-end: something like "the media cannot be verified to be secure end-to-end".  So why would this be useful?  Because it (1) is actually more accurate and less misleading in cases when talking through gateways to/from the PSTN, since even if the gateway did DTLS-SRTP it would be no more knowably secure than using SDES to begin with, and (2) avoids the problem at hand, which is preventing eavesdropping and injection over WiFi or other insecure access mediums.

Even if we had an Identity Provider model to use so we could avoid users checking fingerprints (which we don't have)... as far as I know it's still relying on a third-party (the identity provider).  And since you mentioned Diginotar, I'd note it's an example that such providers cannot, in fact, be wholly trusted either.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Mar 2012 03:35:17 +0000

> By contrast, with SDES, the attack scenario and the legitimate scenario

I don't think you can jump to the conclusion that there's either a software defect or a MitM.  Imagine if WebRTC user Alice calls Bob through provider-A, using Bob's telephone number.  Provider-A supports DTLS-SRTP on its PSTN gateway, so it handles that and generates a call into the PSTN for Bob, who happens to use Provider-B.  Bob is currently on a WebRTC client connected to Provider-B, and Provider-B happens to also support DTLS-SRTP on its PSTN gateway.  So both Alice and Bob see "DTLS-SRTP", but different fingerprints.  It's not a software defect.  You could argue it's a MitM (the PSTN gateways doing what they do), and certainly there may *be* someone recording the call in the middle for all you know - but you really don't know either way.  Alice dialed Bob, and got the best case scenario given the situation.

The good news is the media is secure from the browsers to the PSTN, which is not an insignificant accomplishment.  If we're worried about WiFi - and I am, for at least marketing/perception reasons if nothing else - then we've alleviated that concern.  

So then there's slashdot.  If Alice or Bob posts to slashdot, it's bad news.  But we can hardly blame Provider-A or Provider-B, since they had no alternative.  Ironically, if WebRTC supported SDES, then Provider-A and B could do that instead, and make it clear/explicit no end-to-end guarantee can be made for the call - while *still* avoiding the main concern, which is the WiFi problem.  In some sense *we*, the IETF/W3C, would be more honest if we allowed SDES (over HTTPS) for gateway cases, since that's actually the level of security being provided.  Mandating DTLS-SRTP provides a false sense of security, and false sense of insecurity if it fails.

-hadriel

---

From: Randell Jesup <[email-masked]>
Date: Sat, 17 Mar 2012 00:59:48 -0400

> The second major argument is that SDES makes it possible for the service provider to intercept calls undetectable. I've been thinking about this for some time but still haven't understood the probl…

It also lets the service provider record the key and provide it later to 
someone who separately had recorded the packets on the media path, 
without requiring a true realtime MITM with packet forwarding and 
realtime decryption.  Note that packet capturing is a technology that's 
in use.

> If SDES is used you directly conclude that something fishy is going on and hang up. If DTLS-SRTP is used you compare fingerprints and hang up if they don't match. (I've assumed that a user can view…

As has been discussed, "comparing fingerprints" is beyond 99.9% of users 
- not from ability, but from understanding what they are and what the 
connotations are.  It's way, way too geeky for even most 
privacy-sensitive people to understand, let along go through to 
considerable hassle to do.  The same argument applied to PGPhone, and a 
bunch of other protocols.  Even SSH's "unknown host" warning is rarely 
ever given a second thought before hitting "ok" - I've seen exactly 1 
user actually check the host key - and that was a security standards 
person.  (Yes, I know there are some people with very specific security 
requirements who I'm sure check, but they're beyond just being the 
exception to the rule.)

> Does the fingerprint mismatch in case 1 somehow serve as a stronger indication that the call is being intercepted? What action would a suspicious user take besides hanging up? I would be happy if s…

You can be MITM'd with DTLS-SRTP without identity validation, though in 
theory reading fingerprints would catch it.

This is part of the point of the Identity mechanisms proposed by EKR 
(using the BrowserId example); to verify the identity of the other party 
in the call in a way that's more usable than reading fingerprints (and 
identifies you as the owner of a particular email address, which is 
useful if you don't personally know the person you're calling.)

Also realize that exposing the key to the JS app also enables it to 
provide that key directly to other parties, and to mirror traffic to a 
3rd-party who would not have to be in the media path.  It could in 
theory decode the data itself and process it or forward it.

None of these are really surprising, and the big issue is "how much 
security do you give up (and to whom)" and "how easy is it to use"?

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Mar 2012 06:17:40 +0000

On Mar 17, 2012, at 12:59 AM, Randell Jesup wrote:

> It also lets the service provider record the key and provide it later to someone who separately had recorded the packets on the media path, without requiring a true realtime MITM with packet forwarding and realtime decryption.  Note that packet capturing is a technology that's in use.

And the exact same thing can be accomplished with DTLS-SRTP.  Imagine if DTLS-SRTP is mandated, and PSTN gateways go do DTLS-SRTP.  Alice makes a call to Bob.  The call goes through the gateway.  At that point the gateway has the actual keys used for encrypting/decrypting the SRTP.  At any future time, if the gateway stored that key anywhere (such as in a log), the key can be retrieved and wireshark'ed captures of the encrypted SRTP can be decrypted.  

So then someone might say "sure but at least the web-server won't be able to decrypt it", so just imagine the web-server routes the call through such a gateway it owns.  Same problem.  If they want to do it, they can do it - i.e., if they're malicious, they'll be malicious.

The only thing that makes DTLS-SRTP any "better", is that you can go and verify the fingerprint with the far-end human (or at least you hope it's the far-end human).  If *and only if* you perform that step, is anything knowingly "better".  Of course as you've pointed out earlier, no one will perform that step, except for folks who probably wouldn't trust this whole thing to begin with.  So unless the identity provider thing happens and is mandated - and I don't hear anyone suggesting that be mandatory to use in order for a call to succeed - then we're arguing about the thickness of the Emperor's clothes, when he's not wearing any.  I'd be happy if we could at least get him a T-shirt.  :)

-hadriel

---

From: Randell Jesup <[email-masked]>
Date: Sat, 17 Mar 2012 02:34:18 -0400

> And the exact same thing can be accomplished with DTLS-SRTP.  Imagine if DTLS-SRTP is mandated, and PSTN gateways go do DTLS-SRTP.  Alice makes a call to Bob.  The call goes through the gateway.  A…

Of course - gateways can tap off anything.  No shock there.

> The only thing that makes DTLS-SRTP any "better", is that you can go and verify the fingerprint with the far-end human (or at least you hope it's the far-end human).  If *and only if* you perform t…

Well imagine if the user's identity provider was Google, and it keys off 
your normal google login.  When when you call anyone, you have a 
verified identity.  Or if you're even a bit privacy-aware, you may want 
to know it's joe and not MITM-man you're talking to, and if the UI is 
arranged well, it's fairly painless.  It doesn't have to be mandatory to 
be useful.

And for some of the distributed-hash uses we've discussed, effectively 
mandating identity would make sense, but that could be at the 
application level.

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Mar 2012 17:29:36 +0000

> Of course - gateways can tap off anything.  No shock there.

Exactly. (and yes I know you knew that already :)
So my point is that DTLS-SRTP doesn't give you much more than SDES over HTTPS, because any number of DTLS-b2bua gateways can be along the path.  Obviously it's *easier* for a malicious or rogue server to read your media when using SDES, because it doesn't have to do be a full media-b2bua to do so, but it's still possible either way.  Until and unless you verify the fingerprint.

> Well imagine if the user's identity provider was Google, and it keys off your normal google login.  When when you call anyone, you have a verified identity.  

Not really, as far as I can tell.  You have an identity Google claims is valid.  If you trust Google not to monitor your conversation, and to have good identity validation, then sure you can trust the identity is what Google claims it to be.  And that would NOT be the case for "when you call anyone" - only when you call other Google users and they are reached by their WebRTC connection to Google.  If, for example, you called another Google user who's only on the PSTN at that time and Google offered call-forwarding, then it would go through their DTLS-gateway and we're back to square one.

Furthermore, if you trusted Google that much already, it's not a huge leap to trust that your SDES over HTTPS to Google is not getting sent in the clear elsewhere by Google, and is not getting recorded by Google.  It is no doubt easier for them to screw that up, but it's also not the scenario we have to worry about - because in the Google case for user-to-user WebRTC-to-WebRTC calls, we'd get DTLS-SRTP *anyway*.  No one's suggesting we don't mandate DTLS-SRTP also be implemented by browsers, and clearly we'd mandate that if the browser receives an offer with DTLS-SRTP, it must use it.  So we'd get DTLS-SRTP within a WebRTC domain.  That's not the problem scenario at hand.

The problem scenario is what to do about the cases when the call goes to/from the PSTN, or to/from an interworking gateway to another protocol/domain that does not have support for end-to-end DTLS-SRTP.  We can either mandate those gateways/IWF implement DTLS-SRTP, or minimally just SDES.  The advantages of DTLS-SRTP over SDES in those scenarios are far less clear, while the advantages of SDES over DTLS in those scenarios are clear.

-hadriel

---

From: Oscar Ohlsson <[email-masked]>
Date: Mon, 19 Mar 2012 08:52:38 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Igor Faynberg
> Sent: den 16 mars 2012 18:21
> To: [email-masked]
> Subject: Re: [rtcweb] SDES vs DTLS-SRTP revisited
> 
> Oscar,
> 
> If you know the SRTP key and filter the flow directed at me, 
> you will be on the conversation, right?
> 
> Igor

Hi Igor,

No you can't know for sure that the call is being listened to, but the behaviour is very suscpicious. If both parties support DTLS-SRTP then why did the web application switch from default DTLS-SRTP to SDES? There are not that many reasonable answers:

- interception/recording
- transcoding
- something else?

That's why I was wondering whether DTLS-SRTP fingerprint mismatch really is a stronger indication of interception. To me it's not an obvious question.

Regards,

Oscar

> > Case 1: Both endpoints support DTLS-SRTP (can be determined 
> by asking 
> > the other party)
> >
> > If SDES is used you directly conclude that something fishy 
> is going on and hang up. If DTLS-SRTP is used you compare 
> fingerprints and hang up if they don't match. (I've assumed 
> that a user can view detailed security information in the browser).
> >
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Oscar Ohlsson <[email-masked]>
Date: Mon, 19 Mar 2012 09:20:53 +0100

> From: Eric Rescorla [mailto:[email-masked]] 
> Sent: den 16 mars 2012 23:32
> To: Oscar Ohlsson
> Cc: [email-masked]
> > There were a couple of things that I didn't explain 
> properly in my SDES vs DTLS-SRTP presentation at the interim 
> meeting. Since time will be short at the next meeting as 
> well, I thought I would try to explain myself in an email.
> >
> > I noticed that the discussion quickly turned into a direct 
> comparison of the two protocols. When this happens DTLS-SRTP 
> definitely comes out as the winner and trying to defend SDES 
> just seems foolish. But this is not the right focus of the 
> discussion IMO. We should be looking at the system as a whole 
> and determine more exactly the scenarios where SDES poses a 
> security risk.
> >
> > The first major argument against SDES is that it doesn't 
> offer forward secrecy. Obviously, if the remote endpoint does 
> not support DTLS-SRTP you have to switch to SDES or plain RTP 
> at some point. And from that point and onwards you will never 
> have forward secrecy. The only difference is that the 
> conversion point is moved slightly to the left (one step?) 
> when SDES is supported. However, if web developers starts 
> using SDES without reason (i.e. when the remote endpoint is a 
> browser) then I agree that the lack of forward secrecy is a 
> problem. Do people on this list believe this will be the 
> case? Can it be prevented somehow?
> >
> > The second major argument is that SDES makes it possible 
> for the service provider to intercept calls undetectable. 
> I've been thinking about this for some time but still haven't 
> understood the problem completely. Say that you're on a call 
> and want to determine if the service provider is listening in:
> >
> > Regardless of whether SDES is allowed or not you will never 
> be able to tell if the call is being intercepted. The best 
> thing to do in this case is probably to simply hang up.
> >
> > Does the fingerprint mismatch in case 1 somehow serve as a 
> stronger indication that the call is being intercepted? What 
> action would a suspicious user take besides hanging up? I 
> would be happy if someone could explain this to me.
> 
> Hi Oscar,
> 
> Yes, I think the fingerprint mismatch in case 1 serves as a 
> stronger indication that something was wrong, because there 
> is no technical reason for the fingerprint not to match if 
> both sides believe they are doing DTLS. I.e., it always 
> indicates either a software defect or a man in the middle.
> And the suspicious user of course should hang up, but they 
> should also post pictures to /., which, I would think, serves 
> By contrast, with SDES, the attack scenario and the 
> legitimate scenario look the same.

Hi Eric,

What is the legitimate scenario you're speaking of above? The only legitimate scenario I can come up with is transcoding and that is applicable to DTLS-SRTP as well.

I'm having hard time seeing why DTLS-SRTP shouldn't be used when both parties support it. That's why I consider SDES downgrading and fingerprint replacement equally suspicious.

Regards,

Oscar

> 
> We actually have a worked example of this with Diginotar, 
> where a mechanical system for detecting MITM attacks lead to 
> a report to Google of such an attack and, IIRC, Diginotar 
> being removed from the root list.
> 
> Best,
> -Ekr
>

---

From: Randell Jesup <[email-masked]>
Date: Mon, 19 Mar 2012 04:40:46 -0400

> So my point is that DTLS-SRTP doesn't give you much more than SDES over HTTPS, because any number of DTLS-b2bua gateways can be along the path.  Obviously it's *easier* for a malicious or rogue ser…

Right, a gateway is nothing more than a MITM from a security perspective.

> Not really, as far as I can tell.  You have an identity Google claims is valid.  If you trust Google not to monitor your conversation, and to have good identity validation, then sure you can trust the identity is what Google claims it to be.  And that would NOT be the case for "when you call anyone" - only when you call other Google users and they are reached by their WebRTC connection to Google.

Actually, identity ala BrowserID would work even if neither of you were 
using Google to make the call - google would only be involved indirectly 
as the identity provider.  Google can (I believe) lie and say you're the 
owner of [email-masked] when you're not - that's the case with any 
PKI-ish system that doesn't have users publishing their own keys (and 
they of course you have to trust the manner in which you got the keys, 
which basically this is).

The advantage of a BrowserID-like system here is that the asserted 
identity level is closely tied to the source of the trust in the 
identity - you're trusting the person you're talking to to be 
[email-masked], and it's gmail.com that you're trusting to verify that.  
The trust in the provider of the identity is closely tied to the 
identity itself, and exposed (in that a BrowserID-like system exposes 
that you're talking to [email-masked], not "Eric Rescorla").

This is not absolute trust nor absolute identification; BrowserID is 
mean to be an alternative (one far less trackable and intrusive) to 
systems like "Facebook Connect"/"Login with Facebook".  However, within 
these limits it *does* provide a way to give users a way to detect MITMs 
and verify who they're talking to (owner of "[email-masked]"), and to do 
so without impossible-in-practice reading of fingerprints, etc.

>    If, for example, you called another Google user who's only on the PSTN at that time and Google offered call-forwarding, then it would go through their DTLS-gateway and we're back to square one.
>
> Furthermore, if you trusted Google that much already, it's not a huge leap to trust that your SDES over HTTPS to Google is not getting sent in the clear elsewhere by Google, and is not getting recorded by Google.

The missing part here is that you need to trust google that the other 
person is [email-masked], but that this trust occurs even if the call 
never traverses google (and even the trust validation may not touch 
google).    If the call does go through google as the service provider 
(or any call where the service provider is also the identity host),  
then it is correct (and has been discussed) that you are trusting google 
not to MITM you.  (BrowserID schemes may be able to provide some 
additional level of assurance in this case, but not as much as the use 
of a third-party IdP (Identity Provider).)

>    It is no doubt easier for them to screw that up, but it's also not the scenario we have to worry about - because in the Google case for user-to-user WebRTC-to-WebRTC calls, we'd get DTLS-SRTP *anyway*.  No one's suggesting we don't mandate DTLS-SRTP also be implemented by browsers, and clearly we'd mandate that if the browser receives an offer with DTLS-SRTP, it must use it.  So we'd get DTLS-SRTP within a WebRTC domain.  That's not the problem scenario at hand.
>

As mentioned elsewhere, for a PSTN gateway I'd use DTLS-SRTP and (as the 
terminating WebRTC context) identify the gateway as the remote party, 
which makes clear the call is secure up to that point only.

-- 
Randell Jesup
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Mar 2012 07:01:45 -0700

I think I may have misunderstood you. I thought the SDES case (#2)
was one where
the other side actually didn't speak DTLS and that's what I was trying
to analyze.

I agree that if the other side supports DTLS and you get SDES, that's bad.

-Ekr

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 19 Mar 2012 12:21:46 -0400

In complete agreement.

Igor

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 20 Mar 2012 11:30:29 +0100

> I don't think you can jump to the conclusion that there's either a software defect or a MitM.  Imagine if WebRTC user Alice calls Bob through provider-A, using Bob's telephone number.  Provider-A s…
I don't get this scenario. If Alice calls Bob using two different 
gateways, won't she go through a credentials and fingerprint exchange 
with the gateways?
In that case, wouldn't the fingerprint belong to the gateway?
> So then there's slashdot.  If Alice or Bob posts to slashdot, it's bad news.  But we can hardly blame Provider-A or Provider-B, since they had no alternative.
It wouldn't be the first time someone posted a story on slashdot that 
got the facts wrong...
>    Ironically, if WebRTC supported SDES, then Provider-A and B could do that instead, and make it clear/explicit no end-to-end guarantee can be made for the call - while *still* avoiding the main concern, which is the WiFi problem.  In some sense *we*, the IETF/W3C, would be more honest if we allowed SDES (over HTTPS) for gateway cases, since that's actually the level of security being provided.  Mandating DTLS-SRTP provides a false sense of security, and false sense of insecurity if it fails.
>
> -hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Mar 2012 15:44:12 +0000

On Mar 20, 2012, at 6:30 AM, Harald Alvestrand wrote:

> I don't get this scenario. If Alice calls Bob using two different gateways, won't she go through a credentials and fingerprint exchange with the gateways?

Yes, but the statement being made was in the context of Alice calling Bob, them seeing their browsers claim DTLS-SRTP "secured" or whatever, and them being super-geeks and checking the detailed info of what the actual DTLS fingerprints were, and finding they don't both see the same fingerprints... and that they would thus believe there was either a software bug or a malicious middleman.

So my point was that's not a good conclusion to jump to, since both caller and called parties can see DTLS-SRTP "secured" mode lock-icon, but with different fingerprints, and yet it being neither a software bug nor a malicious middleman.  I realize no distinction can be made between a PSTN-gateway and a malicious MitM, by design, but that's not a good thing - because it means people will simply learn to ignore the warnings generated by the browser, because from a user perspective they'll all be false positives.

-hadriel

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 20 Mar 2012 17:00:54 +0100

> Yes, but the statement being made was in the context of Alice calling Bob, them seeing their browsers claim DTLS-SRTP "secured" or whatever, and them being super-geeks and checking the detailed inf…
So we've uncovered a requirement here: When a fingerprint is shown, it 
should clearly identify what it is the fingerprint of - in this case, 
the gateway that relays the call to Bob, not Bob.
> So my point was that's not a good conclusion to jump to, since both caller and called parties can see DTLS-SRTP "secured" mode lock-icon, but with different fingerprints, and yet it being neither a…
So in this case, the browser needs to not warn; it needs to say 
"connected to gateway in order to reach Bob".

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Mar 2012 04:45:15 +0000

On Mar 20, 2012, at 12:00 PM, Harald Alvestrand wrote:

> So we've uncovered a requirement here: When a fingerprint is shown, it should clearly identify what it is the fingerprint of - in this case, the gateway that relays the call to Bob, not Bob.

Yup.  So long as no gateways are named "Bob", of course, or no humans are named "Gateway". ;)

-hadriel