W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2015

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

From: Richard Barnes <rbarnes@mozilla.com>
Date: Wed, 2 Dec 2015 10:02:18 -0500
Message-ID: <CAOAcki_ms6Y3Z-T9Y+BEwSHaWC-tWte4uCKq3wvcHjg_-o-VvQ@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:53 UTC