Re: [tsvwg] DTLS 1.3 over SCTP

[Michael Tuexen <[e-mail]>]

> 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
>  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.
>  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?
>  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.

However, the goal of draft-tuexen-tsvwg-rfc6083-bis is to replace RFC 6083. It might not
cover all requirements from 3GPP, but should describe how to use DTLS 1.3 over SCTP, since
RFC 6083 only cover DTLS 1.2 and lower.

Best regards
Michael
>  Magnus
>    From: tsvwg <[e-mail]> on behalf of Michael Tuexen <[e-mail]>
> Date: Thursday, 13 July 2023 at 16:36
> To: tsvwg IETF list <[e-mail]>
> Subject: [tsvwg] DTLS 1.3 over SCTP
> Dear all,
> 
> Hannes Tschofenig and myself have submitted an ID for using DTLS 1.3 over SCTP:
> https://www.ietf.org/archive/id/draft-tuexen-tsvwg-rfc6083-bis-02.html
> 
> This is an alternative to
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-dtls-over-sctp-bis-06.html
> 
> Our document is based on RFC 6083. The major differences are:
> * Use DTLS 1.3 instead of DTLS 1.0
> * Use key updates instead of renegotiation. This limits the number of
>   rekeyings to 2^64, but that should not limit in real world scenarios.
> * Bump the maximum user message size to 64KB by using RFC 8449.
> 
> Any comments welcome.
> 
> Best regards
> Michael