XSF Discussion - 2014-03-04

Ralph: I'm on that list.

This just came up, thought it might be of interest https://secure-resumption.com/

Lloyd: That was also mentioned here yesterday. My expectation is that nothing on XMPP is vulnerable as nothing uses TLS resumption.

xnyhps, ahh missed that apologies. Good to hear about the lack of vulnerability though

(Though I don't have much concrete evidence for that…)

As far as I can tell from the description, this doesn't require the client to not check server certs.

dwd: Are you sure this is the case?

Or, at least, it doesn't require as sever as 'verify nothing', I think.

Kev: The image shows the Attacker replaces the cert with its own cert.

I could easily have misread this. But it seemed to me to be saying that the attacker's website wasn't claiming to be the victim's website.

I need to work out how I'm going to grab lunch, if I'm going to be travelling across London at lunchtime.

Need to leave the hotel at 11 to get to the Hilton for 12:30, if TFL is to be believed.

I stand corrected, jabber.org lets you do TLS resumption.Hm.

Although not client strong-auth.

Kev, I think that the Attacker would have to pretend to be some site for which the credentials matched, at least.

Attacker has attacker.com, user visits that and it obtains the client-cert from the user and presents it to goodserver.com?

Maybe I should understand the attack, instead of just reading the decription.

+s

I read it as the attacker presenting their own identity.

And then swapping out to a MITMd session to the victim.

Yeah, I think you're right.

But of course, when you try to attack the channel-binding part of SCRAM-SHA-1-PLUS, you do need valid credentials of the server.

Or the client must have used an identical nodepart and password on your server as on the malicious server.

But if you have that, there's nothing you can win by an attack, you have the password. :)

hah

I guess I need to start thinking about heading into town.

Right. See folks at precis, I guess.

Ah, Kitten have just started discussing the TLS MITM stuff.

Kitten is now?

Looks like the consensus might be that resumption is a no-no.

This is on the list.

ah

Kitten is Thursday, 1520-1650.

And that's my first hallway bump-into-someone.

Who else is here? :)

I'm just about to hop into the car. I should make the IETF hallway for about 6pm or so if I'm lucky; if not I'll see you at the meetup.

It's entirely possible I won't be here by 6pm, but we'll see. I'm intending crowd-following once precis/xmpp are done.

I have my pretty noob-ribbon on :)

If I'd gone properly, I would have qualified for a noob ribbon, plus a WG Chair dot, which I'd have found amusing.

dwd: I don't think you would have been the first

although it is rare

for what WG are you a chair?

qresync, now in shutdown-wait.

I guess I should try to find precis.

Follow the yelllow arrows?

I need to find that, too, but I'm still in another meeting

ah, it's downstairs

3 floors down in the east wing, right off the lobby

this hotel has a strange layout

It's a labyrinth.

Going hunting, BRB.

Kev: Did you see the video?

I haven't watched it yet.

I saw that there was one.

hah, another two tls vulnerabilities. I think the tlswg will have fun

even though those were library issues

Zash: was my suggestion clear?

So, I'm currently sat in the TLS WG session, along with assorted other XMPP people, but I note that this goes on until 6:40. ISTR Lloyd suggesting that we should be at Moz at 6:30.

Hmm

I thought 7?

Kev: ubber can't do time travel. Disappointing

Upon arrival Surevine will have pizza and beer waiting (around 6:30pm). The latest schedule is posted up on http://lanyrd.com/2014/xmppuk/.

Oh, meetup had 7.

do we need to sign up for Uber in order to catch a ride

I think you need to give them your credit card number.

I would be inclined to just grab the tube, personally, but I have an Oyster card.

I wanna see the series of tubes :)

http://wiki.xmpp.org/web/IETF_89 says "We're planning on holding the XMPP meetup at MozSpace at 101 St. Martin's Lane, starting at 7pm."

I'd be happy with the tube

ralphm: Your suggestion was?

I was planning to take the tube, too.

It's 20mins by tube, along Bakerloo, I believe.

https://www.google.com/maps/dir/Hilton+London+Metropole,+225+Edgware+Rd,+London+W2+1JU,+UK/51%C2%B030'37.4%22N+0%C2%B007'37.4%22W/@51.5201367,-0.1530664,13z/data=!4m12!4m11!1m5!1m1!1s0x48761ab4122b2d83:0xfdfeed0b864cbfb0!2m2!1d-0.1694932!2d51.5191439!1m3!2m2!1d-0.1270556!2d51.5103889!3e3 What a lovely URI.

Zash: webrtc data channels

ralphm: Because that's likely to be implemented by clients anyways?

ralphm: XTLS (Dirk Meyer's work) could offer a webrtc data channel as one of the transport options

Zash: yes, that's my thinking

stpeter: Which is why it sounded like XTLS to me

stpeter: yes, but I want to do away with IBB entirely

ralphm: Does XTLS say you have to use IBB?

ralphm: so XTLS but MUST NOT offer IBB?

I don't see the need, really. Jingle lets you negotiate transport.

But what are the security bits you want to solve?

Zash: well, sure, but my personal opinion is that IBB is horrible and don't want to have people need to implement it

webrtc data channels seem convenient, for sure

Zash: I think having out-of-band XML Streams for e2e are easier to implement

I like IBB because it allows to leverage a trusted server for end-to-end file exchange

Ge0rG: I don't see how that is better than negotiating an out-of-band connection with the server, over Jingle.

besides, aren't XTLS and WebRTC data channels solving the same problem?

Ge0rG: no

Ge0rG: XTLS is end-to-end encryption - data channels would be one end-to-end transport over which we could negotiate end-to-end TLS

ralphm: Having IBB be MTI for E2E does indeed seem problematic. I think someone mentioned that you'd basically have to open a loopback connection to yourself, tunnel it over IBB and then starttls on that

Unless there are better tls libs that I've not seen

stpeter: but webrtc has dtls for end-to-end encryption, righT?

stpeter: I'm not suggesting using any of webrtc per se, just the same p2p transport for the actual bits, with sctp/rtp/dtls and all that, as you would negotiate webrtc data channels

stpeter: we do negotiate end-to-end (d)tls with webrtc data channels. but the exchange of fingerprints is not protected.

Zash: Wat? Aren't most TLS libraries separated from network libraries?

xnyhps: Not really looked further than LuaSec

ralphm: ah, thanks for the clarification

XTLS says:

More complex scenarios are theoretically supported (e.g., encrypted file transfer using SOCKS5 bytestreams and encrypted voice chat using DTLS-SRTP) but have not yet been fully defined. XTLS theoretically can be used to establish a TLS-encrypted streaming transport or a DTLS-encrypted datagram transport, but integration with DTLS [DTLS] has not yet been prototyped so use with streaming transports is the more stable scenario.

So I'm saying we go the next step and actually prototype that thing mentioned, with the same tech as used for webrtc data channels.

I think this makes people's live slightly better and allows us to piggyback on that work.

how is dtls security handled in webrtc?

Ge0rG: AFAIK, you send a fingerprint through the SDP blob via your whatever server.

ge0rg: http://tools.ietf.org/html/rfc4572#section-6

http://tools.ietf.org/html/rfc5764 has a bunch of text on that, too

so how is that solving a different problem from xtls?

Zash: I don't think it depends on SDP per se, but we might have to do a jingle equivalent.

Ge0rG: it solves the same problems, but without IBB and with a protocol that people will implement in other places (WebRTC)

like, say, browsers

BTW, XTLS = http://tools.ietf.org/id/draft-meyer-xmpp-e2e-encryption-02.txt

in fact, my feeling is that we should just take the IBB guts out of draft-meyer-xmpp-e2e-encryption and replace it with dtls-rtp

stpeter: ah, thanks for that link, of course

ralphm: I've always rather liked the general approach of XTLS

stpeter, +1

it would be fairly straightforward for us to take draft-meyer-xmpp-e2e-encryption-02, change it around, and submit a revised I-D

call it draft-meijer-* instead of draft-meyer-* ;-)

stpeter: no confusion there, I'm sure

heh

But, do we want something that'll work with Carbons?

ralphm: xep 0320 is the jingle equivalent of that. even though it was actually pretty much limited to being an sdp mapping

ralphm: i'd like to see what ekr has in mind wrt webrtc + identity providers before going further in any direction

fippo: right

Zash: I want something that works with carbons and with MAM.

stpeter: I do want to retain the generic nature of that draft, but without any suggestion of doing ibb

So anything that goes out of band has some unfortunate properties there.

+1 to Kev on Carbons and MAM

so many requirements :-)

Kev: and how does draft-miller address this?

That's what I'm trying to work out right now (reading it at the moment), before chatting with Matt tonight.

http://tools.ietf.org/id/draft-ietf-xmpp-e2e-requirements-01.txt needs to be revisited

Kev: my feeling is that it doesn't, but I might be missing something

carbons is supported, but possibly not MAM

Hello, Nelsons Column.

but note that supporting offline makes it hard (maybe impossible) to also support PFS

xnyhps, Kev, when do we need to leave?

immediately after tls-wg ends (-:

Depends if we want to get there for 18:30 or 19:00.

At what time can I invade Moz Space?

the offline case makes life so much more complicated

If we want to get there at 18:30, when I think it 'opens' (@Edwin), we should leave here at 18:00, give or take.

you probably want to leave here @ 18:00 to be there by 18:30

My GMT+1 clock makes this very confusing.

Above times are Zulu.

m&m: indeed. e2e might be conceptually incompatible with mam

Zash: If we want to be there on time, we need to leave 54 minutes from now.

carbons is doable with oob, too

ralphm: I don't believe that to be true. It simply changes the tradeoffs.

Kev: I think we agree

I think the difference is whether carbons is managed by the server, or managed by the client

In the simple case, anything gpg-based can be compatible with carbons and MAM, given ubiquitous private keys.

(Not that I'm pushing we use gpg as our approach)

so much is possible, given ubiquitous private keys :-)

just not PFS d-:

Right.

To FS or not to FS.

there is no P

maybe we don't need the P :)

heh

"perfection is not an option"

Pretty-good Forward Secrecy (PgFS) d-:

Perfection is the opposite of delivered.

m&m, :D

Permissible Forward Secrecy

Pretty Good Forward Secrecy?

Poorly Guarded Privacy.

Hah

heh

m&m: sure with xtls you'd need clients to figure out the multiplex

Yeah

You could also do MAM between your own resources

Over 174"

Because moving all of XMPP to the client is our favourite direction.

Let's build Skype with angle brackets!

We just need a single master authentication server

zash: let's use gmail.com

hotmail.com

facebook.com!

IM is over-rated, we should go back to email!!

and use more ASN.1

m&m, you do use email :-)

far too much

:)

m&m: let's make ma bell proud by putting more intelligence into the network again!

You folks will be getting veggie pizzas if you go on

MattJ will be pleased

XMPP over DTMF

One combination is a nibble, not sure what data rate you can achieve.

Pizza has bread in it, it can't be veggie.

Symbol rate, I mean.

Kev, I thought that you were in for getting everyone to try that.

SM: There is a long-running gag with letting MattJ know that various foods (like bread) are meats.

Oh:)

haha

Those poor Bread animals.

And veggies are meat anyway, the poor greens just don't know it yet.

Carrots are people too!

That's Captain Carrot for you.

So, yes. We should aim to leave in about 15mins if we want to get to Moz for 18:30Z.

Is anyone intending leaving the session 40mins early to get to Moz, or is everyone staying to the bitter end?

unfortunately m&m needs to stick around because he's taking notes

I'd be game to leave, but I don't want to abandon Matt

We do have a backup Matt tho ;)

ouch

heh

I don't really want to abandon anyone, but at the same time I'd like to get over to Moz and start bashing MattJ over the head to update MAM :)

So I'm inclined to leave now and apologise to m&m later :)

I'm hungry.

Zash: So you're leaving?

I'm follwing MattJ

Matt is following you.

You're both useless.

xnyhps: Decide who's leading please.

I'm going to head to Moz now. Others can leave or not.

But then either MattJ or I have to get up...

I hope m&m and I can figure out how to get to MozSpace :-)

Just follow the scent of Pizza.

And remember the address, that usually helps, too ;)

I've got a map cached on my phone (-:

Should do the trick.

Are you using Ubbers?

no, Underground

https://wiki.mozilla.org/London might help

When lost, just go to Trafalgar Square and look at one of the maps there.

The square is big and kinda hard to miss ;)

I have a problem with http://planet.jabber.org/ same for you?