We are sponsored by audible! http://www.audibletrial.com/programmingthrowdown
We are on Patreon! https://www.patreon.com/programmingthrowdown
T-Shirts! http://www.cafepress.com/programmingthrowdown/13590693
Join us on Discord! https://discord.gg/r4V2zpC
WebRTC with Sean DuBois
- Making changes to a language itself
- How do people connect using WebRTC?
- What is WebRTC?
- What are options for using WebRTC in your app?
- NAT traversal
- WebRTC security and identification
- The challenges of WebRTC
- Dealing with latency and packet loss
- Sending data reliably
- How did Sean get into WebRTC?
- Tips for getting a job in coding
- How to contribute to Pion
Pion Twitter: https://twitter.com/_pion/
Regarding your wish to tie a Twitter identity to the DTLS authentication step, I think you could in principle do that using TLS-SRP:
ReplyDeletehttps://en.wikipedia.org/wiki/TLS-SRP
SRP is a fascinating protocol for establishing *bidirectionally* that two peers in an exchange know a given secret (like a password) without either side revealing it to the other and without either side having to hold the secret in durable storage. Think zero-knowledge proofs meets hashed-and-salted passwords.
The reason you can use SRP for this is that one of the things that falls out of the math is a random session key. (This means SRP is one of a class of algorithms called a password-authenticated key exchange, PAKE.) TLS-SRP uses that session key as its encryption key.
Getting all of this to work over DTLS instead of TLS/TCP and then getting Twitter to support TLS-SRP over DTLS for proof of identity is an exercise left to the reader. :)
Another difficulty is that there are several flavors of SRP, and each implementation you find online tends to speak only a subset of them, often just one. You end up needing to dig pretty far into the math to figure out which particular flavor a given library on GitHub uses so you can figure out whether it will speak to some other library, as when your client and server are written in different programming languages. (e.g. C++ back-end with JS front-end.) If one library pads the password out with nulls to 256 bits prior to doing a given math step and the other doesn't, for example, you'll never get the two libraries to agree to the knowledge proof.
This site helps with all of that:
http://srp.stanford.edu/index.html
Incidentally, if you've ever wondered why so many web sites these days are asking for the user name / email separately from the password when we were all trained to ask for both at once and then on login failure give a vague error that doesn't reveal which lookup failed, the user name or the password, use of SRP is one possible reason: SRP uses two message exchanges, one carrying the user name, the other carrying the secret knowledge verification, so it *has* to either verify the existence of the user first or at least pretend to do so.
Regarding multicast, there's an important detail that didn't come up in the conversation, which is that consumer-grade network switches don't do anything special with it, so that multicast is basically the same thing as broadcast on most small LANs.
ReplyDeleteThen on professional-grade networking gear, there's a handful of technologies for doing intelligent things with IGMP, the protocol that manages multicast IP groups, but they're usually disabled by default, and when blindly enabled, often don't do everything you want it to do until you configure the services to match your local needs.
The bottom line is that very few networks are properly configured for the most efficient use of IGMP and/or multicast, even at the high end.
The worst of them all is the Internet, which basically drops multicast at the border, which is a shame, because the protocol was created to allow Internet-wide efficient transmission of shared data streams. It could have allowed us to get to a Tivo over the Internet world, where my DVR announces at 7pm on Sundays that it wants to receive 224.1.2.3, which my cable Internet company maps to NBC, so it gets a copy of the live NBC feed at that moment until it stops responding to IGMP query packets which basically ask, "Do you still want to receive this?" An hour later, when the show is done streaming, my DVR could send an IGMP group-leave packet, causing my ISP to stop sending me this traffic.
Instead, multicast is usually blocked at the Internet border gateways, so we're all having to pull redundant copies of each TV show on demand from Netflix, Prime, etc., which is why TV and movies are now the majority of the traffic on the Internet, and these companies are having to do back-room deals with the likes of Comcast to get VoD servers embedded in their regional data centers.
It could have all been multicast, but no....this is why we can't have nice things. :(