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

Albin Stigö albin.stigo@REDACTED
Wed Mar 20 09:32:49 CET 2019 

I looked at GnuTLS and they have the option to use a pull and a push
callback function when the SSL stack wants data and wants to send data
respectively. I think it's a nice idea because it decouples the SSL stack
completely from the underlying socket. It seems this is sometimes
desirable..


--Albin

On Sat, Mar 16, 2019, 11:53 Albin Stigö <albin.stigo@REDACTED> wrote:

> True... A callback receiving {udp, Socket, IP, InPortNo, Packet} and
> deciding whether to use the the ssl demuxer or pass it on to another
> process might be enough. The STUN packets could come from any IP
> unsolicited when doing ICE nat traversal path discovery (as described by
> WebRTC).
>
>
> --Albin
>
> On Sat, Mar 16, 2019, 11:00 Ingela Andin <ingela.andin@REDACTED> wrote:
>
>>
>> Hi!
>>
>> Den lör 16 mars 2019 kl 10:21 skrev Albin Stigö <albin.stigo@REDACTED>:
>>
>>> Ok sorry about the confusion. What's needed is a second level of
>>> demultiplexing after the first... But I realize now this will be very
>>> difficult to achieve with the current implementation because that relies on
>>> one socket per connection. Otherwise you won't know which process to send
>>> the none DTLS packets to... Or am i missing something?
>>>
>>>
>> You will have to extend the demultiplexor process so that it sends
>> packets to different processes depending on some criteria. It is ok to
>> change the internals of
>> the process if that is necessary. But we like the basic functionality to
>> be the framework of the process and then add extended features mainly
>> through callbacks.
>>
>> Regards Ingela Erlang/OTP Team - Ericsson AB
>>
>>
>>> I might have to attempt a separate DTLS use_srtp app just for this
>>> application...
>>>
>>>
>>> --Albin
>>>
>>> On Sat, Mar 16, 2019, 09:05 Ingela Andin <ingela.andin@REDACTED> wrote:
>>>
>>>> Hi Albin!
>>>>
>>>> Den fre 15 mars 2019 kl 17:25 skrev Albin Stigö <albin.stigo@REDACTED
>>>> >:
>>>>
>>>>> Ok thanks!
>>>>>
>>>>> Maybe demultiplexing should just be default when the use_srtp
>>>>> extension is used, since that's how it's supposed to be used anyway... or a
>>>>> rfc7983_demux option...
>>>>>
>>>>>
>>>> ? A DTLS server will always have a demultiplexing process as UDP does
>>>> not have a connection concept.
>>>>
>>>>
>>>>
>>>>> What's the name in the #state that holds the pid of the controlling
>>>>> process (the process that receives {ssl.. data)?
>>>>>
>>>>>
>>>> It is part of the "user"  in the state of the TLS/DTLS connection
>>>> process. You should not have to care.  You set the controlling process with
>>>> ssl:controlling_process/2.
>>>>
>>>> I guess what you care about is the demultiplexing process and which Pid
>>>> it sends the incoming UDP packets to. All the code is defined in the
>>>> dtls_packet_demux.erl
>>>>
>>>> Regards Ingela Erlang/OTP team - Ericsson AB
>>>>
>>>>
>>>>> --Albin
>>>>>
>>>>> On Fri, Mar 15, 2019, 17:01 Ingela Andin <ingela.andin@REDACTED>
>>>>> wrote:
>>>>>
>>>>>> Hi Albin!
>>>>>>
>>>>>> There is the handshake_compleation option together with the
>>>>>> handshake_continue functions that let you pause the handshake and retrieve
>>>>>> the hello extensions and possibly provide more options before
>>>>>> continuing the handshake.
>>>>>>
>>>>>> Den fre 15 mars 2019 kl 13:20 skrev Albin Stigö <
>>>>>> albin.stigo@REDACTED>:
>>>>>>
>>>>>>> Am I right to assume this is the single point of udp receive for
>>>>>>> dtls?
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/erlang/otp/blob/702ef9b0fa0a9b7345e3b397f23d8a76a2ac4df2/lib/ssl/src/dtls_connection.erl#L906
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> If you want to multiplex UDP packets to other processes than the DTLS
>>>>>> connection process that is not encrypted under DTLS you
>>>>>> should not look at the DTLS connection process but at the
>>>>>>
>>>>>>
>>>>>> https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_packet_demux.erl#L140
>>>>>>
>>>>>> Regards Ingela Erlang/OTP team Ericsson AB
>>>>>>
>>>>>>
>>>>>>> --Albin
>>>>>>>
>>>>>>> On Fri, Mar 15, 2019 at 1:10 PM Albin Stigö <albin.stigo@REDACTED>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > There're all kinds of abuse of DTLS it seems :-)
>>>>>>> >
>>>>>>> > I still think the use cases are orthogonal though... Demuxing as
>>>>>>> > described in https://tools.ietf.org/html/rfc7983 is trivial and
>>>>>>> > requires no state. A demux_fun would solve that problem.
>>>>>>> >
>>>>>>> > DTLS packets wrapped in extra headers with the need of state
>>>>>>> > information is much more complicated... Maybe what is needed are
>>>>>>> two
>>>>>>> > different approaches? Especially since you will need forward and
>>>>>>> > backwards transform..?
>>>>>>> >
>>>>>>> > Ingela, is there already an API for getting the key data from
>>>>>>> use_srtp
>>>>>>> > (when implemented) or will that have to be added also?
>>>>>>> >
>>>>>>> >
>>>>>>> > --Albin
>>>>>>> >
>>>>>>> > On Fri, Mar 15, 2019 at 11:35 AM Andreas Schultz
>>>>>>> > <andreas.schultz@REDACTED> wrote:
>>>>>>> > >
>>>>>>> > > Albin Stigö <albin.stigo@REDACTED> schrieb am Do., 14. März
>>>>>>> 2019 um 18:49 Uhr:
>>>>>>> > >>
>>>>>>> > >> Hi Ingela and Andreas,
>>>>>>> > >>
>>>>>>> > >> > 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).
>>>>>>> > >>
>>>>>>> > >> I have to admit I have not encountered this practice... do you
>>>>>>> have a
>>>>>>> > >> particular protocol in mind or is it a part of dtls-srtp I have
>>>>>>> > >> missed? One could argue that if you add additional headers and
>>>>>>> > >> maintain some kind of state you are actually dealing with a
>>>>>>> different
>>>>>>> > >> transport layer...?
>>>>>>> > >
>>>>>>> > >
>>>>>>> > > CAPWAP is doing that
>>>>>>> https://tools.ietf.org/html/rfc5415#section-4.1
>>>>>>> > >
>>>>>>> > >> I would very much like a way where filtered out packages were
>>>>>>> sent to
>>>>>>> > >> the controlling process as {udp,Socket instead of {ssl,
>>>>>>> Socket... The
>>>>>>> > >> question in the latter case is if Socket should be the ssl
>>>>>>> socket or
>>>>>>> > >> the transport socket. Messing with the transport socket could be
>>>>>>> > >> detrimental to dtls.
>>>>>>> > >>
>>>>>>> > >> One could also extend the filter_fun idea to a transform_fun
>>>>>>> where one
>>>>>>> > >> could transform in packet in addition to demultiplexing, but
>>>>>>> like I
>>>>>>> > >> said, I think additional headers to dtls packets belong to the
>>>>>>> > >> transport layer.
>>>>>>> > >
>>>>>>> > >
>>>>>>> > > Passing a State in and out of such a transform would be good.
>>>>>>> > >
>>>>>>> > > Andreas
>>>>>>> > >
>>>>>>> > >>
>>>>>>> > >>
>>>>>>> > >> I don't have in-depth knowledge of the ssl app but it seems
>>>>>>> adding a
>>>>>>> > >> filter_fun would be almost trivial?
>>>>>>> > >>
>>>>>>> > >> > Maybe transport_send as compared to the existing
>>>>>>> transport_accept. Would only work for DTLS.
>>>>>>> > >>
>>>>>>> > >> Well either that or some way of accessing the transport socket,
>>>>>>> but
>>>>>>> > >> transport_send for sure plays well with existing API!
>>>>>>> > >>
>>>>>>> > >>
>>>>>>> > >> --Albin
>>>>>>> > >>
>>>>>>> > >> On Thu, Mar 14, 2019 at 6:22 PM Ingela Andin <
>>>>>>> ingela.andin@REDACTED> wrote:
>>>>>>> > >> >
>>>>>>> > >> > 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
>>>>>>> > >> >>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> > >
>>>>>>> > > --
>>>>>>> > > --
>>>>>>> > > 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/20190320/30092aaf/attachment.htm>

More information about the erlang-questions mailing list