<div dir="ltr">Hi!<br><div class="gmail_extra"><br><div class="gmail_quote">2014-05-07 18:38 GMT+02:00 Andreas Schultz <span dir="ltr"><<a href="mailto:aschultz@tpip.net" target="_blank">aschultz@tpip.net</a>></span>:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>[...]<br>
><br>
> DTLS is not yet runnable, as there is not yet a red thread through the code.<br>
> dtls_connection.erl is the most incomplete module. It is the module that<br>
> implements<br>
> the finite state machine of the DTLS handshake, it correspondes to<br>
> tls_connection.erl. In general tls_* implements TLS specific parts and<br>
> dtls_* DTLS specific parts and ssl_* common parts.<br>
<br>
</div>Looking at dtls_connection.erl, it seems to me that it replicates to much functionality<br>
from tls_connection.erl.<br>
<br></blockquote><div><br></div><div>Did not say anything of it being finished. You should see it more as sketch. I have been refactoring in a lot in small steps, making sure that TLS is not is broken. And I do expect that there will be more refactoring.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At the pure TLS FSM level, DTLS and TLS are almost identical. The only real difference<br>
here is the HELLO VERIFY request.<br></blockquote><div><br></div><div>Well tls_connection and ssl_connection does not  implement a pure handshake-FSMs, it also handles the user data, record- and alert protocols.</div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To me it looks like the current dtls_* modules duplicate lots of the SSL record level<br>
FSM functions, when they IMHO should only abstract the differences in the transport<br>
level mapping.<br>
<div><br></div></blockquote><div><br></div><div>I am sure there is still room for improvement,  for our design two things are important. The connection process for TLS and DTLS shall be separate behaviour implementations so that a bug in one will not affect the other. We want to leave room for API functions that may be DTLS and/or TLS specific, and also we want to reuse as much as possible of the original SSL/TLS code. I have also tried to use a much as possible  of your contributed code.  And yes there are some design decisions left to make and some code that is there now that may be disregarded.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>

> You could always do a test suite for DTLS that corresponds to<br>
> ssl_to_openssl_SUITE.erl in the test directory. Once you have a test suite<br>
> it is easier to try to fill in the gaps in dtls_* .<br>
<br>
</div>The pure connection oriented test can be converted with very little effort. </blockquote><div><br></div><div>Yes sure they can, but it is still work that needs to be done and does not take zero time. It is just a start, but you need to start somewhere and once dtls_connection is  more close to connection process implementation you can start a test driven approach of making it work.</div>

<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The test<br>
that manually open a TCP connection are a bit harder. The real challenge will be to<br>
come up with exhaustive testes for packet loss, reordering and duplication.<br></blockquote><div><br></div><div>Good testing is always a challenge ;)</div><div><br></div><div><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB</div>
<div><br></div></div></div></div>