LloydThis just came up, thought it might be of interest https://secure-resumption.com/
xnyhpsLloyd: That was also mentioned here yesterday. My expectation is that nothing on XMPP is vulnerable as nothing uses TLS resumption.
Lloydxnyhps, ahh missed that apologies. Good to hear about the lack of vulnerability though
xnyhps(Though I don't have much concrete evidence for that…)
stpeterhas joined
Ashhas left
emchohas left
emchohas joined
Kevhas joined
KevAs far as I can tell from the description, this doesn't require the client to not check server certs.
Kevdwd: Are you sure this is the case?
KevOr, at least, it doesn't require as sever as 'verify nothing', I think.
Zashhas joined
xnyhpsKev: The image shows the Attacker replaces the cert with its own cert.
KevI 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.
jabberjockehas joined
KevI need to work out how I'm going to grab lunch, if I'm going to be travelling across London at lunchtime.
KevNeed to leave the hotel at 11 to get to the Hilton for 12:30, if TFL is to be believed.
Ashhas joined
xnyhpsI stand corrected, jabber.org lets you do TLS resumption.Hm.
KevAlthough not client strong-auth.
dwdKev, I think that the Attacker would have to pretend to be some site for which the credentials matched, at least.
xnyhpsAttacker has attacker.com, user visits that and it obtains the client-cert from the user and presents it to goodserver.com?
KevMaybe I should understand the attack, instead of just reading the decription.
Kev+s
KevI read it as the attacker presenting their own identity.
KevAnd then swapping out to a MITMd session to the victim.
xnyhpsYeah, I think you're right.
xnyhpsBut of course, when you try to attack the channel-binding part of SCRAM-SHA-1-PLUS, you do need valid credentials of the server.
xnyhpsOr the client must have used an identical nodepart and password on your server as on the malicious server.
xnyhpsBut if you have that, there's nothing you can win by an attack, you have the password. :)
ralphmhah
KevI guess I need to start thinking about heading into town.
KevRight. See folks at precis, I guess.
Kevhas left
jabberjockehas left
Zashhas joined
dwdAh, Kitten have just started discussing the TLS MITM stuff.
ZashKitten is now?
dwdLooks like the consensus might be that resumption is a no-no.
dwdThis is on the list.
Zashah
dwdKitten is Thursday, 1520-1650.
Zashhas left
xnyhpshas left
stpeterhas left
Lancehas joined
Santiago26has joined
Lloydhas left
Ashhas left
Ashhas joined
emchohas left
emchohas joined
emchohas left
Santiago26has left
Santiago26has joined
intosihas left
emchohas joined
emchohas left
emchohas joined
Kevhas joined
KevAnd that's my first hallway bump-into-someone.
KevWho else is here? :)
emchohas left
Santiago26has left
Santiago26has joined
dwdI'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.
stpeterhas joined
KevIt's entirely possible I won't be here by 6pm, but we'll see. I'm intending crowd-following once precis/xmpp are done.
KevI have my pretty noob-ribbon on :)
dwdIf I'd gone properly, I would have qualified for a noob ribbon, plus a WG Chair dot, which I'd have found amusing.
Santiago26has left
stpeterdwd: I don't think you would have been the first
stpeteralthough it is rare
stpeterfor what WG are you a chair?
dwdqresync, now in shutdown-wait.
KevI guess I should try to find precis.
KevFollow the yelllow arrows?
stpeterI need to find that, too, but I'm still in another meeting
stpeterah, it's downstairs
stpeter3 floors down in the east wing, right off the lobby
stpeterthis hotel has a strange layout
KevIt's a labyrinth.
KevGoing hunting, BRB.
Kevhas left
dwdhas left
stpeterhas left
Santiago26has joined
Zashhas joined
stpeterhas joined
Kevhas joined
Santiago26has left
Alexhas left
Alexhas joined
Lancehas joined
emchohas joined
emchohas left
emchohas joined
Ashhas left
Lancehas joined
ZashKev: Did you see the video?
Santiago26has left
KevI haven't watched it yet.
KevI saw that there was one.
xnyhpshas left
Kevhas left
Zashhas left
Ashhas joined
Kevhas joined
Santiago26has left
Santiago26has joined
Zashhas joined
SMhas joined
emchohas left
xnyhpshas left
Santiago26has left
Santiago26has joined
emchohas joined
emchohas left
emchohas joined
emchohas left
emchohas joined
Lancehas joined
emchohas left
Lancehas joined
emchohas joined
emchohas left
emchohas joined
Santiago26has left
Zashhas joined
xnyhpshas left
fippohah, another two tls vulnerabilities. I think the tlswg will have fun
fippoeven though those were library issues
ralphmZash: was my suggestion clear?
Zashhas left
Zashhas joined
KevSo, 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.
ZashHmm
xnyhpsI thought 7?
ralphmKev: ubber can't do time travel. Disappointing
KevUpon arrival Surevine will have pizza and beer waiting (around 6:30pm). The latest schedule is posted up on http://lanyrd.com/2014/xmppuk/.
xnyhpsOh, meetup had 7.
Tobiashas joined
stpeterdo we need to sign up for Uber in order to catch a ride
xnyhpsI think you need to give them your credit card number.
KevI would be inclined to just grab the tube, personally, but I have an Oyster card.
ZashI wanna see the series of tubes :)
stpeterhttp://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."
stpeterI'd be happy with the tube
Zashralphm: Your suggestion was?
xnyhpsI was planning to take the tube, too.
KevIt's 20mins by tube, along Bakerloo, I believe.
Kevhttps://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.
ralphmZash: webrtc data channels
Zashralphm: Because that's likely to be implemented by clients anyways?
stpeterralphm: XTLS (Dirk Meyer's work) could offer a webrtc data channel as one of the transport options
ralphmZash: yes, that's my thinking
Zashstpeter: Which is why it sounded like XTLS to me
stpeternods to Zash
ralphmstpeter: yes, but I want to do away with IBB entirely
Zashralphm: Does XTLS say you have to use IBB?
stpeterralphm: so XTLS but MUST NOT offer IBB?
ZashI don't see the need, really. Jingle lets you negotiate transport.
ZashBut what are the security bits you want to solve?
ralphmZash: well, sure, but my personal opinion is that IBB is horrible and don't want to have people need to implement it
stpeterwebrtc data channels seem convenient, for sure
ralphmZash: I think having out-of-band XML Streams for e2e are easier to implement
Ge0rGI like IBB because it allows to leverage a trusted server for end-to-end file exchange
ralphmGe0rG: I don't see how that is better than negotiating an out-of-band connection with the server, over Jingle.
Ge0rGbesides, aren't XTLS and WebRTC data channels solving the same problem?
stpeterGe0rG: no
stpeterGe0rG: XTLS is end-to-end encryption - data channels would be one end-to-end transport over which we could negotiate end-to-end TLS
Zashralphm: 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
ZashUnless there are better tls libs that I've not seen
Ashhas left
Ge0rGstpeter: but webrtc has dtls for end-to-end encryption, righT?
ralphmstpeter: 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
fippostpeter: we do negotiate end-to-end (d)tls with webrtc data channels. but the exchange of fingerprints is not protected.
xnyhpsZash: Wat? Aren't most TLS libraries separated from network libraries?
Zashxnyhps: Not really looked further than LuaSec
stpeterralphm: ah, thanks for the clarification
ralphmXTLS says:
ralphm 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.
ralphmSo I'm saying we go the next step and actually prototype that thing mentioned, with the same tech as used for webrtc data channels.
ralphmI think this makes people's live slightly better and allows us to piggyback on that work.
Ge0rGhow is dtls security handled in webrtc?
ZashGe0rG: AFAIK, you send a fingerprint through the SDP blob via your whatever server.