Subject: Re: [tsvwg] RFC6083 and interoperability with OpenSSL on top of LKSCTP

From: "Proshin, Maksim" <[email-masked]>
Date: Tue, 4 Dec 2018 10:53:48 +0000

Hi Michael, Robin, Eric,

I forward this message to you as authors of RFC 6083.
Could you please help us with the question about the exporter label from below?

BR, Maxim

From: tsvwg [mailto:[email-masked]] On Behalf Of Proshin, Maksim
Sent: Monday, November 26, 2018 16:30
To: [email-masked]
Subject: [tsvwg] RFC6083 and interoperability with OpenSSL on top of LKSCTP

Hi,

During implementation of DTLS over SCTP specified in RFC6083 and interoperability testing we found a few interoperability issues with the peer where OpenSSL on top of Linux Kernel SCTP is running. We think it might be caused by unclarity in the RFC so we ask the WG to provide some explanations if possible.

One issue is about the exporter label which is defined in Section 5 of RFC6083 as "EXPORTER_DTLS_OVER_SCTP". According to RFC5705 the labels are given with no terminating NULL. Does it mean that the implementation should add or should _not_ add the null-terminating symbol when it calculates an endpoint-pair shared key?

The other issue is about the FORWARD-TSN chunk which must be sent in an authenticated way according to RFC6083 if PR-SCTP mechanism is used. The issue is that regardless of whether the PR-SCTP mechanism is enabled or not, the peer always requires the FORWARD-TSN chunk to be present in the CHUNKS parameter of INIT/INIT ACK. We consider it as an implementation fault but want the WG to confirm it.

BR, Maxim

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 4 Dec 2018 12:31:37 +0100

> On 4. Dec 2018, at 11:53, Proshin, Maksim <[email-masked]> wrote:
> 
> Hi Michael, Robin, Eric,
>  
The label being used in this case is "EXPORTER_DTLS_OVER_SCTP" as specified in
https://tools.ietf.org/html/rfc6083#section-5.

https://tools.ietf.org/html/rfc5705#section-4 states:
Labels here have the same definition as in TLS, i.e., an ASCII string
with no terminating NULL.

So the exported should not use the terminating 0 at the end of the label string.

Is OpenSSL doing this wrong?
> The other issue is about the FORWARD-TSN chunk which must be sent in an authenticated way according to RFC6083 if PR-SCTP mechanism is used. The issue is that regardless of whether the PR-SCTP mech…
Are you saying that an end-point is listing the FORWARD-TSN chunk in the
CHUNKS parameter even though the end-point does not support the FORWARD-TSN
extension. This shouldn't be a problem, but I wouldn't be surprised if
implementations just fill the CHUNKS parameter just based on the requests
by the application.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 4 Dec 2018 12:46:52 +0100

> On 4. Dec 2018, at 12:31, Michael Tuexen <[email-masked]> wrote:
> 
I looked up the code and OpenSSL is using sizeof(labelbuffer) instead of strlen(labelbuffer).

I can file a bug report there. The problem with fixing it is that the fixed version
will not be compatible with the non-fixed version.

Best regards
Michael

---

From: "Proshin, Maksim" <[email-masked]>
Date: Tue, 4 Dec 2018 11:56:23 +0000

Hi Michael,

Thanks for your feedback!

Yes, it seems OpenSSL puts the terminating null. In our tests the handshake with OpenSSL over LKSCTP is only successful when we use the terminating null which we also though is against the standard. We also see it by parsing OpenSSL source code.  

Wrt FORWARD-TSN, regardless of which side originates an association OpenSSL expects that we put the FORWARD-TSN chunk into the CHUNKS parameter even though we don't claim PR-SCTP as supported functionality in any of ends, i.e. even though the endpoint doesn't support the extension, OpenSSL checks that FORWARD-TSN is in the list for authentication.   

BR, Maxim

-----Original Message-----
From: Michael Tuexen [mailto:[email-masked]] 
Sent: Tuesday, December 4, 2018 14:32
To: Proshin, Maksim <[email-masked]>
Cc: Robin Seggelmann <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: RFC6083 and interoperability with OpenSSL on top of LKSCTP

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 4 Dec 2018 13:06:30 +0100

> On 4. Dec 2018, at 12:56, Proshin, Maksim <[email-masked]> wrote:
> 
> Hi Michael,
> 
I'll file a bug report. Do you find the problem only in testing or also in deployment?
> 
> Wrt FORWARD-TSN, regardless of which side originates an association OpenSSL expects that we put the FORWARD-TSN chunk into the CHUNKS parameter even though we don't claim PR-SCTP as supported functionality in any of ends, i.e.. even though the endpoint doesn't support the extension, OpenSSL checks that FORWARD-TSN is in the list for authentication.   
That can be improved... It should be only checked if PR-SCTP is supported.

Best regards
Michael

---

From: "Proshin, Maksim" <[email-masked]>
Date: Tue, 4 Dec 2018 12:22:39 +0000

Hi Michael,

Yes, feel free to submit a bug report. I think it's also worth to submit it for FORWARD-TSN. Thanks in advance!
It's only in testing so far.

BR, Maxim

-----Original Message-----
From: Michael Tuexen [mailto:[email-masked]] 
Sent: Tuesday, December 4, 2018 15:07
To: Proshin, Maksim <[email-masked]>
Cc: Robin Seggelmann <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [tsvwg] RFC6083 and interoperability with OpenSSL on top of LKSCTP

Best regards
Michael