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

Ingela Andin ingela.andin@REDACTED
Fri Mar 29 17:22:13 CET 2019 

Hi!

Den ons 20 mars 2019 kl 09:33 skrev Albin Stigö <albin.stigo@REDACTED>:

> 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..
>
>
The "active once" emulation between the DTLS statemachine and the
demultiplexer process would be like pull.  But we do not do push as that
would be a bottleneck.

Regards Ingela Erlang/OTP team - Ericsson AB



>
> --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/20190329/fc243473/attachment.htm>

More information about the erlang-questions mailing list