[erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support.

Ingela Andin ingela.andin@REDACTED
Thu Mar 14 18:22:31 CET 2019


Hi!

Andreas, see comment below.

Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz <
andreas.schultz@REDACTED>:

> Hi
>
> Ingela Andin <ingela.andin@REDACTED> schrieb am Do., 14. März 2019 um
> 17:34 Uhr:
>
>> Hi Albin!
>>
>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stigö <albin.stigo@REDACTED>:
>>
>>> Hi Ingela,
>>>
>>> Thanks for the quick reply!
>>>
>>> While cb_info certainly is one way of doing it, it feels a bit
>>> complicated... specifically if switching between active and passive
>>> mode. Not sure if ssl ever use passive mode internally? Demuxing is a
>>> different use case, I think..
>>>
>>>
>> The cb_info is intended so that you may replace the transport layer, with
>> most likely, an SCTP transport (can be done for  both TLS and DTLS
>> although there are some extensions needed for the DLTS version to work
>> properly). I think some people also use it to implement WebSockets.
>>
>> ssl internally uses active n for TLS (since latest release) and active
>> once for DTLS (we might change it) but an OTP supervised process will not
>> use passive recv as we do not want it to block.
>>
>>
>>
>>> Something that IMHO would be fantastic and simple (?) would be a
>>> dtls_filter_fun option. If true packet is passed up the ssl stack,
>>> otherwise passed on like a normal udp packet!
>>>
>>>
>> Sounds reasonable. Otherwise sent to some other Erlang process than the
>> "DTLS-connection" process that is.
>>
>
> No, that's not enough. Some protocols put additional headers in front of
> the DTLS packets. So there needs to be a way to strip headers on Rx and add
> it on Tx (with session information if needed).
>
>
Maybe the demultiplexor process can have a "packet mode" that is set to "no
packet"  default and needs a callback handler for anything else?


Regards Ingela Erlang/OTP team - Ericsson AB


> Andreas
>
>
>>
>>
>>> There's an RFC regarding the demultiplexing of SRTP/DTLS, it basically
>>> boils down to looking at the first byte of the packet, if it's
>>> [20..63] it should be treated as DTLS otherwise something else. So
>>> this would be absolutely trivial to implement if there was a
>>> dtls_filter_fun...
>>>
>>> https://tools.ietf.org/html/rfc7983
>>>
>>> Then of course there also has to be a way to bypass DTLS when sending
>>> data... maybe send/3 (Socket, Data, Options)...
>>>
>>>
>> Maybe transport_send as compared to the existing  transport_accept. Would
>> only work for DTLS.
>>
>> Regards Ingela Erlang/OTP team  - Ericsson AB
>>
>>
>>> What do you think?
>>>
>>>
>>> --Albin
>>>
>>> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin <ingela.andin@REDACTED>
>>> wrote:
>>> >
>>> > Hi!
>>> >
>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stigö <
>>> albin.stigo@REDACTED>:
>>> >>
>>> >> Hi,
>>> >>
>>> >> I'm working on an Erlang WebRTC peer client (to send audio/video to
>>> >> the browser).
>>> >>
>>> >> WebRTC requires dtls-srtp and that in turn requires:
>>> >>
>>> >> 1. The use_srtp extension for key exchange.
>>> >
>>> >
>>> > We will be implementing this as part of TLS-1.3 that we are currently
>>> working on, and we will have something runnable for OTP-22.0, although we
>>> are not promising that it will complete or that use_srtp will be part of
>>> OTP-22.0
>>> >
>>> >
>>> >>
>>> >> 2. Multiplexing of stun/turn/srtp packets on the socket.
>>> >>
>>> >> I know there's been work towards use_srtp and it's even in the source,
>>> >> but commented out. Ingela has been working on it for OTP 2, I believe,
>>> >> is there an ETA on this feature?
>>> >
>>> >
>>> >>
>>> >>
>>> >>
>>> >> Is multiplexing on the DTLS socket already possible using the cb_info?
>>> >> Has anyone tried that?
>>> >>
>>> >> http://erlang.org/pipermail/erlang-questions/2018-October/096457.html
>>> >>
>>> >
>>> > The code has been written to make such extensions possible. There
>>> might be a need for more callbacks. I have not really had time to work on
>>> that as
>>> > TLS-1.3, optimizations and erlang distribution over TLS has been
>>> prioritized higher.  Suggestions are welcome.
>>> >
>>> > Regards Ingela Erlang/OTP team - Ericsson AB
>>> >
>>> >
>>> >
>>> >
>>> >>
>>> >>
>>> >> --Albin
>>> >> _______________________________________________
>>> >> erlang-questions mailing list
>>> >> erlang-questions@REDACTED
>>> >> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
> --
> --
> Dipl.-Inform. Andreas Schultz
>
> ----------------------- enabling your networks ----------------------
> Travelping GmbH                     Phone:  +49-391-81 90 99 0
> Roentgenstr. 13                     Fax:    +49-391-81 90 99 299
> 39108 Magdeburg                     Email:  info@REDACTED
> GERMANY                             Web:    http://www.travelping.com
>
> Company Registration: Amtsgericht Stendal        Reg No.:   HRB 10578
> Geschaeftsfuehrer: Holger Winkelmann          VAT ID No.: DE236673780
> ---------------------------------------------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190314/ce96df2e/attachment.htm>


More information about the erlang-questions mailing list