- From: Richard Barnes <rbarnes@mozilla.com>
- Date: Wed, 2 Dec 2015 10:02:18 -0500
- To: Florian Bösch <pyalot@gmail.com>
- Cc: Aymeric Vitte <vitteaymeric@gmail.com>, Brad Hill <hillbrad@gmail.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAOAcki_ms6Y3Z-T9Y+BEwSHaWC-tWte4uCKq3wvcHjg_-o-VvQ@mail.gmail.com>
On Wed, Dec 2, 2015 at 10:01 AM, Florian Bösch <pyalot@gmail.com> wrote: > In DTLS, each handshake message is assigned a specific sequence >> number within that handshake. When a peer receives a handshake >> message, it can quickly determine whether that message is the next >> message it expects. If it is, then it processes it. If not, it >> queues it for future handling once all previous messages have been >> received. >> >> > The point of receiving UDP packets with fresh unqueued data is > performance. If you queue the packet for future handling, you've thrown > that away, and it begs the question, why don't you just use TCP/IP (which > guarantees ordering)... > Because the queuing is only done for handshake messages, which are a tiny fraction of all the messages sent in a typical DTLS session. Other messages can be reordered, dropped, etc. > > On Wed, Dec 2, 2015 at 3:54 PM, Richard Barnes <rbarnes@mozilla.com> > wrote: > >> >> >> On Wed, Dec 2, 2015 at 9:36 AM, Florian Bösch <pyalot@gmail.com> wrote: >> >>> 1) Encryption between Alice and Bob by means of an asymmetric >>> public/private key exchange protocol cannot be secure if both also exchange >>> the keys and none has a method to verify the keys they got are the correct >>> ones. Chuck who might control the gateway over which either Alice or Bob >>> communicate can simply substitute his own public key for either of the two. >>> The whole point of certificates is that the sought out endpoint can provide >>> a set of credentials that're signed by a certificate authority, which is in >>> a chain of trust up to the root authority which is implicitly trusted. >>> >>> 2) You cannot obtain the benefits of UDP (out of order packages as fast >>> as they come) and yet retain the benefits of asymmetric public/private key >>> encryption schemes which rely on packages arriving in order. Attempting to >>> get both will result in detrimental performance or non existent security. >>> >> >> I think that if you read the DTLS spec, you'll see that it handles >> reordering just fine. >> >> https://tools.ietf.org/html/rfc6347#section-3.2.2 >> >> >> >>> >>> On Wed, Dec 2, 2015 at 2:05 PM, Aymeric Vitte <vitteaymeric@gmail.com> >>> wrote: >>> >>>> >>>> >>>> Le 02/12/2015 13:18, Florian Bösch a écrit : >>>> > On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte < >>>> vitteaymeric@gmail.com >>>> > <mailto:vitteaymeric@gmail.com>> wrote: >>>> > >>>> > Then you should follow your rules and apply this policy to >>>> WebRTC, ie >>>> > allow WebRTC to work only with http. >>>> > >>>> > >>>> > Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP. >>>> > Also WebRTC does P2P, and there's no certificates/authorities there >>>> (you >>>> > could encrypt, but I don't think it does even when using TCP/IP (which >>>> > it doesn't in case of streaming video over UDP). >>>> >>>> See https://github.com/Ayms/node-Tor#security, WebRTC uses DTLS with >>>> self-signed certifcates + a third party mechanism supposed to secure the >>>> connection. >>>> >>>> As a matter of fact this is almost exactly the same mechanism used by >>>> the Tor network, where the CERTS cells use the long term ID key of a Tor >>>> node to make sure that you are discussing with that one. >>>> >>>> This does not prevent of course from discussing with a malicious node >>>> not identified as such with valid long term ID keys, which is not a >>>> problem for Tor (but is a problem for WebRTC), as long as it behaves as >>>> expected, and if it does not, this will be detected. >>>> >>>> The above mechanism is specific to the Tor network, for other uses of >>>> the Tor protocol an alternative is explained here: >>>> https://github.com/Ayms/node-Tor#pieces-and-sliding-window for WebRTC >>>> >>>> And again, adding a TLS layer on top of all this is of complete no use. >>>> >>>> -- >>>> Get the torrent dynamic blocklist: http://peersm.com/getblocklist >>>> Check the 10 M passwords list: http://peersm.com/findmyass >>>> Anti-spies and private torrents, dynamic blocklist: >>>> http://torrent-live.org >>>> Peersm : http://www.peersm.com >>>> torrent-live: https://github.com/Ayms/torrent-live >>>> node-Tor <https://github.com/Ayms/torrent-livenode-Tor> : >>>> https://www.github.com/Ayms/node-Tor >>>> GitHub : https://www.github.com/Ayms >>>> >>> >>> >> >
Received on Wednesday, 2 December 2015 15:02:58 UTC