Re: [tsvwg] DTLS 1.3 over SCTP

[Magnus Westerlund <[e-mail]>]

Hi,

Please see inline.

From: Michael Tuexen <[e-mail]>
Date: Sunday, 16 July 2023 at 19:52
To: Magnus Westerlund <[e-mail]>
Cc: tsvwg IETF list <[e-mail]>
Subject: Re: [tsvwg] DTLS 1.3 over SCTP
> On 14. Jul 2023, at 14:12, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:
>
> Hi Michael,
>  A question I don’t understand on what basis you managed to extend the TLS record size from from 2^14 to 2^16 bytes?
>  When I read RFC 8449 it does not change the TLS underlying protocol limit which is 2^14 and depending on version what you need to account for in that limit.
>  What I can see the following text from RFC 8449 applies:
>     An endpoint that supports all record sizes can include any limit up
>    to the protocol-defined limit for maximum record size.  For TLS 1.2
>    and earlier, that limit is 2^14 octets.  TLS 1.3 uses a limit of
>    2^14+1 octets.  Higher values are currently reserved for future
>    versions of the protocol that may allow larger records; an endpoint
>    MUST NOT send a value higher than the protocol-defined maximum record
>    size unless explicitly allowed by such a future version or extension.
Hi Magnus,

the idea is to make use of "unless explicitly allowed by such a future version or extension".
The extension would be a flags extension that indicates that the value is raised.
See https://www.ietf.org/archive/id/draft-ietf-tls-tlsflags-11.html
Yes, I understand that the signaling is straight forward, and that TLS flag draft appears to be just an efficient way of not having to use full parameters when establishing the DTLS connection.

>  Are you attempting to define a (D)TLS extension here in TSVWG that changes the TLS record size to 2^16? I would think that would require some security analysis to determine that the usage of larger record doesn’t weaken the security due to the larger record sizes. I would think such changes should go through TLS WG and then be used by TSVWG.
I'm open to that. We can do it from within the 6083-bis document in TSVWG or
in the TLS WG in a separate document. I contacted Eric Rescorla, Martin Thomson,
Hannes Tschofenig and a couple of other people. They agreed that bumping that
limit should be possible. Actually, I could not figure out, why the limit of
2^14 exists at all.
MW: It might be possible to raise without issues, however it would need analysis. What I think might be the large work here is to determine what ciphers can be used without security failures or to reduced security. Someone will have to do analysis to raise this limit. My opinion is that this work really needs to happen in TLS.

>  Otherwise, I think it is good that RFC 6083 are being fixed for its security issues unless completely replaces by a more capable solution. However, this draft it does not address all the requirements to our understanding that 3GPP has on a DTLS based security solution. The short-commings are the following:
>
>     • Do not support sufficiently large protected message sizes. As discussed in this thread the theoretical maximum message sizes for some of 3GPP application protocols are above 144 kb and even as large as 500 kb.
>     • Periodic re-authentication of the peer
>     • Forward secrecy rekeying, like re-running differ-hellman exchange, which is not done by the DTLS 1.3 keyupdate mechanism.

Any idea how that last two goals are achieved by using TLS 1.3 or DTLS 1.3? Or were these
features just dropped when getting rid of re-negotiation?
MW: TLS 1.3 dropped these capabilities when re-negotiation was removed. I think the main reason is that no one was there and pushing for long lived use cases. In the web world there are rarely any real issue with dropping the connection and forcing the client to reconnect if one runs into these needs. SCTP application clearly has other expectations, especially the applications 3GPP have for it.
So those two later issues and the lack for any solution in DTLS 1.3 is why we defined the parallel DTLS Connection procedure.

>  Thus, I don’t see this draft as any replacement for the DTLS over SCTP work that 3GPP has requested. But it can ensure that we don’t have in non-deprecated that have known security issues.  Cheers
I have a hard time to parse the last sentence.

MW: Sorry, the point being that doing a RFC6083bis without large message support is replacing the clearly broken RFC 6083 which would be good from an general perspective that we should not leave clearly broken things as standard tracks document.
Cheers
Magnus