Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

>
> 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)...

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
>>>
>>
>>
>