[erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support.
Ingela Andin
ingela.andin@REDACTED
Sat Mar 16 09:05:26 CET 2019
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/9e747dfb/attachment.htm>
More information about the erlang-questions
mailing list