[erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support.
Albin Stigö
albin.stigo@REDACTED
Fri Mar 15 17:25:42 CET 2019
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...
What's the name in the #state that holds the pid of the controlling process
(the process that receives {ssl.. data)?
--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/20190315/bc00253e/attachment.htm>
More information about the erlang-questions
mailing list