-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for STARTTLS #35
Comments
I only know about RFC 3788, which requires setting up the SCTP association appropriately, then exchanges the START-TLS and START-TLS-ACK message in the clear and then do TLS. RFC 6083 did not exist at that time. The reason RFC 3788 was written is that there were some SIGTRAN specifications already published and they only specified the unsecured protocol. We requested separate port numbers for the protocols over TLS, but IANA declined that. So we had to do the START-TLS dance. To be honest, in my limited testing I have done for a German mobile operator, I have never seen SIGTRAN over TLS... So I don't have a problem with not supporting START-TLS, we just need to be clear about it. |
I think the way forward here is to explicitly note that STARTTLS will not work with this specification. |
The note that STARTTLS will not work with this specification has been added. |
The way forward and the added note looks good. |
The note has been reformulated in the PR due to that it was contextual problematic. We may want to further improve the style of it in the future. |
So part of the discussion in #27 brought up the case of STARTTLS. I think that needs more consideration as due to even RFC 6083 requirement to have SCTP-AUTH, one can't move from a plain SCTP association to one with DTLS. Instead one actually need to create an association with the intent to use DTLS. So are there any point in attempting to support STARTTLS like for services that use TLS/TCP where it works.
The text was updated successfully, but these errors were encountered: