[erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support.
Albin Stigö
albin.stigo@REDACTED
Sat Mar 16 10:21:22 CET 2019
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?
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/20190316/4d430fbc/attachment.htm>
More information about the erlang-questions
mailing list