TSVWG Interim

All slides can be found at
https://datatracker.ietf.org/meeting/interim-2023-tsvwg-01/session/tsvwg

Agenda and Note Well

Gorry goes through the agenda. No other business added to the agenda.

Liaison Update from the 3GPP SA3 and RAN3

Liaison presentation is included in the SCTP/DTLS presentation by
Magnus. See below.

SCTP and DTLS

Magnus started his presentation.

Ericsson will make a new IPR declaration to avoid the need for a license
the SCTP crypto solution for the kernel-parts. It will take a while
before it will become available (proposed by the next IETF meeting).

Michael noted that there is a need for a DTLS handshake, which is not in
the kernel. So, I can implement something in the kernel but I am not
able to test it.

Magnus: Yes, but that's the situation.

Michael: I would need an API to the kernel part to test something.

Magnus: The WG would need to look at this when the IPR is understood.

Magnus then continued with the liaison statement read-out. The liaison
slides are in his slide deck.

Michael: Has the 3GPP SA3 looked into the kernel vs. user-land
implementation?

Magnus: I cannot answer this question.

Tiru: Our solutions are currently relying on open source
implementations. We are looking for a solution that is available as an
open source solution.

Charles: We probably have to reach out to the other 3GPP groups
regarding the implementation details.

Gorry: Which group was this?

Charles: It was in the SA3 group, when this was discussed.

Tiru: What I have heard from the delegates was that there was no
detailed discussion on threat model, implementation details, etc. If
there is anything else, please let us know.

Magnus: No, I have no extra details.

John: SA3 does not discuss implementation details. There is often not a
detailed discussion in the 3GPP due to time constraints. Our competitors
had a preference for solution (ii). I am not sure whether we will get
any details on this.

Michael: If the 3GPP does not look into the details, then we should not
look at their evaluation because the complexity varies with the details.

Magnus: I think it is useful for us to make our own evaluation.

Charles: I don't disagree with that. We need to do our evaluation. It is
not a mandate. We asked questions and they provided an answer. We should
also provide a motivation about why we went for a specific solution.

Magnus continues with his proposal comparison.

--- rekeying

Michael asked a question regarding the rekeying worries that Magnus
expressed.

Michael: You need to distinguish the sender and the receiver side of the
encryption. The receiver needs to "drain" the buffer.

Hannes: Rekeying can be annoying, but you need to just define when to do
things. I think real problems do not actually exist, implementations
will help idnetify if there are any problems. "draining" seems rather
dramatic.

Michael: When we switch in the DTLS level to a new epoch we want to get
rid of the SCTP AUTH key. It seems to be OK to keep the keys around at
the SCTP AUTH keys around a bit long to avoid draining.

Michael says that if you get this wrong, then you have to abort the SCTP
association.

Tiru: Are these problems that are to be solved in implementations or
does it need to be dealt with at the protocol level?

Magnus: You have to be very careful about understanding the steps. You
have deisgn options.

Michael: These decisions were made at the time we implement the socket
API interface. There are no special hooks needed. You are programming
against the API and you have to deal with the consequences.

Martin Duke (as inidvidual): Would it be possible to rekey SCTP AUTH in
the context of a connection?

Michael: SCTP AUTH supports 64k in parallel.

Magnus: It is about the integration between the two layers and knowing
about how these layers interact.

Michael: The RFC is implemented in FreeBSD and Linux and it is
available. This is doable.

--- Replay protection

Michael: When designing SCTP we were aware of the need to protect from
replay. If you don't want to rely on this functionality, you can use
AUTH to protect against this attack. Packet duplication can happen all
the time. There is no need for further protection.

Magnus: Yes. ... (comment concerning replay of delayed packets) ...

Michael: Can you provide an example of where such a replay will have an
actual effect?

Magnus: No, I don't think so, it's important to consider thsi in the
threat analysis, but there was no obvious example.

Michael: Can we distinguish between implementations and protocol? We
should focus on protocol deisgn.
I would still like to understand if we can find such a bug. I am not
aware of a bug where this kind of stuff is critical.

Tiru: Did you see this bug in an existing implementation that needs to
be fixed? Or is this a theoretical bug?

Magnus: No, this was analysis. We went through the protocol and this
could be a potential confusion.
We don't have concrete examples from a specific implementation.

--- performance and trust

Michael: I'd like to understand whether the CPU performance is critical?
Do you need additional hardware? I have no feeling whether the CPUs are
saturated likely to be saturated?

Magnus: No, I don't think so, this is control processing and the
processing cost of encryption and the protocol are unlikely tio be
critical.

Hannes: the slide compares two approaches. The Crypto Chunk isn't
actually widely implemented either - so, in both cases there will be a
need for a new extension.

Michael: One of the things we should consider for the solution we choose
is that it should be possible to look at the protocol, implementations,
and we ought to be able to review the implementation.

--- Message size limits

Gorry: For size, it seems that bot aproaches pass this requirements, is
that correct?
Magnus: Yes.

--- Implementation impact

Michael: Why do you need RFC 8449?

Magnus: This is the RSL extension. Implementations do not support
maximum size limits.

Hannes: I worked on a DTLS implementation, this is in some ways just a
parameter for setting the buffer size.

Hannes talked about the time it takes to implement a product-quality
security protocol, and there were merits in separating the security code
(which would also need to be maintained) and the protocol.

---- SCTP Association Restart

Michael: I am not sure the SCTP Association Restart actually works: SCTP
expects the verification tag of zero to be used if there is an INIT
CHUNK in the packet. When you put your crypto into that packet, which
verification tag would you use? Firewalls may drop the packet if the
VTAG is not what is expected so this needs to be considered. (Details
follow)

The attack vector is: the attacker needs to send spoofed packets as a
Man-in-the-middle, MITM.

Magnus: Yes, you need to be a highly competent attacker for this DoS
attack.

Michael: Why can such an attacker just drop packets and result in an
equivalent DoS attach?

Magnus: The attacker needs only to spoof packets.

Michael: We designed SCTP to protect against an off-path attacker -- not
against a MITM. Is this not true anymore?

Magnus: I think there is a significant difference in the attacker
capability needed for the attacks.

Michael: But, then TCP & SCTP are broken? Do we have a threat model that
says what we want to protect against?

Magnus: I think this is something we can discuss later. This is
something we will have to deal with. We might need to have a policy-flag
to enable/disable protection..

Gorry: I am confused about the DoS threat, I'd have thought that
carefuly choosing to drop specific packets by a MITM can result in DoS
that is hard to protect against.

Magnus: For the attack we consider, the attacker does not need drop
capabilities.

Michael: How do you protect against an attacker doing it at the
beginning of the handshake? (without the crypto applied)?

Magnus: Let's take this to future development.

Hannes, Magnus and John discuss about the assessment of the DTLS
implementation status. It was conculded that some development work will
be needed.

Michael: It would be possible to contribute to open source projects.

John: It is difficult for companies to contribute to open source
projects. The OpenSSL project worked on TLS but it was some time before
they started work on DTLS. Also, sometimes the code contributions are
not accepted.

Magnus finishes with a summary and asks the question on which way
forward to choose.

Gorry: I would like to know who has enough information to make a
decision. What else do you need to know?

Sarker: This was a good discussion. There is a lot of implementation
info. It would be good to do some testing and interop and to consider
the implementation efforts. This would be my expectation.

Magnus: In the past, we did an implementation of DTLS over SCTP and in
that case, we failed because our stack didn't have the Connect ID.

Tiru: It was a good discussion today. It seems like some of the issues
Magnus has raised can be addressed. We now need a more detailed
investigation about the implementation details to make a decision.

Michael: Whatever solution we pick, people will need to look at the code
and at the implementation. This has an issue when there is IPR. Maybe
Ericsson can consider to adjust the license they offer to allow the
complete implementation as an open source project - not just parts of
it.

Marcelo (Linux kernel maintainer): What is our goal here? One solution
hides more information from the protocol than the other. Is this a
requirement? Is privacy a concern here (learning about the content of
the exchanged data from the packet header size)?

John: (...not sure I captured the essence) The motivation is 3GPP wants
to have e2e security. DTLS 1.2 provided everything and now we want to
switch to DTLS 1.3.

Martin (individual): I am not an SCTP expert. I feel torn here. I agree
with Michael that if there are IPR concerns for the kernel then it is a
non-starter. FWIW, I think the crypto chunk is probably architecturally
cleaner. The implementation shortfalls can be fixed later. The final
thing I don't object to more data, but I don't want this to become
"bring me a rock". We need to define what information we need. I don't
think it's productive to hope that just working on it a bit longer will
result in an obvious and clear ansewr.

Zahed: This is not the most critical aspect in a mobile network and I
think we are far away from deploying DTLS over SCTP. We do have time. It
would be good to do some more analysis. Waiting for Ericsson licencing
statement would be important before we make a decision.
Do you have thoughts about a design team to move the requirements
forward?

Gorry (as WG Chair): Yes, I think we have made good progress here. My
suggestion is to create a short-lived design team to work on
requirements.

Magnus: I think we have to answer the question soon. I don't want to
spend another 2 years waiting to start.

Tiru: I have seen design teams working fast with regular meetings. I
suggest to also work on the threat model.

Gorry (as WG Chair): Yes, I think we ought to include the security
requirements with a threat model. I will talk to my AD about setting up
design team to understand requirements and threat model, to provide
input before the next TSVWG meeting in November. Interested participants
should contact me.

Gorry did a poll during the discussion: 8 People support progession of
one of these methods.

SCTP and DTLS - updating the current spec

Michael presented his slide deck.

Tiru: Are you saying you want to bring Key Update back?

Michael: Currently, I have no plans. In DTLS 1.2 this was a feature and
then with DTLS 1.3 it has been removed. Right now I have no specific
suggestion.

Tiru: Why is the record size limit a problem?

Michael: We can bump the size to 64 KB, but not larger. If we want to
make it larger, then we need an extension.
We can fragment a user message. That's possible, but it might be IPR
protected. This proposal is about methods that do not have IPR.

Magnus: I think it makes sense to work on a solution on the -bis
document now.

Gorry (ask WG chair): I suggest we talk about this topic at the next
IETF meeting, and consider seeing if people support adoption. Michael,
please ask on the list if people want to progress this topic. Everyone
in the group: please look at this proposal.

UDP Options

Gorry presented the list of current open issues in github. It is planned
to close most of these in rev -24 ,and to then complete the rest so that
we have a version ready for a final confirming WGLC.

Please do use github to discuss these items, or send any comments to the
list.

AOB

There was no AOB, the next meeting will be in Prague in November.