Re: [TLS] [rfc9147] Clarification on DTLS 1.3 CID Retirement and Usage

[Tschofenig, Hannes]

Hi Kristijan,

searching through the mailing list I found this mail. So, sorry for the late 
response.

The CID design in DTLS 1.3 has not been focused on multi-homing use cases. It 
was not a design goal; you have to design on an extension in the style of what 
is currently happening with QUIC or what was previously done with MOBIKE.

Ciao
Hannes

From: TLS  On Behalf Of Kristijan Sedlak
Sent: Sunday, December 10, 2023 11:50 AM
To:  
Subject: [TLS] [rfc9147] Clarification on DTLS 1.3 CID Retirement and Usage

Dear IETF TLS Working Group,

I am reaching out to seek clarification on specific aspects of Connection ID 
(CID) management in DTLS 1.3, as detailed in RFC 9147.

The current specification delineates the process for issuing new CIDs via a 
NewConnectionId message. However, the methodology for retiring old CIDs seems 
subject to various interpretations.

Is it correct to assume that an endpoint dictates the number of active CIDs it 
manages and that CIDs should be utilized in the sequence they are provided? For 
example, if the initial negotiated CID is 0 and an endpoint subsequently issues 
NewConnectionId with CIDs 1, 2, and 3, my interpretation is that upon receiving 
the first datagram from a new path (which is also applicable for an existing 
path), the records should ideally be tagged with the next CID (1, 2, or 3) 
rather than CID 0. This approach suggests that upon the reception of a higher 
CID, lower CIDs should be considered retired and later removed.

This understanding implies that CIDs in DTLS 1.3 are not designed for multipath 
operations, and it is anticipated that only one path (one CID) would be active 
at a given time. Could you please confirm if this interpretation is in 
alignment with the intended specifications, or offer additional insights into 
the appropriate management of CIDs in DTLS 1.3? Including such clarification in 
the RFC would be invaluable in mitigating potential confusion.

Thank you.
Kristijan

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DTLS 1.3 sequence number lengths and lack of ACKs

[Tschofenig, Hannes]

Fair enough. I don’t have a strong preference as long as we document it 
somewhere.

Ciao
Hannes

From: David Benjamin 
Sent: Tuesday, April 16, 2024 3:18 PM
To: Tschofenig, Hannes (T CST SEA-DE) 
Cc:  ; Nick Harper 
Subject: Re: [TLS] DTLS 1.3 sequence number lengths and lack of ACKs

Regarding UTA or elsewhere, let's see how the buffered KeyUpdates issue pans 
out. If I haven't missed something, that one seems severe enough to warrants an 
rfc9147bis, or at least a slew of significant errata, in which case we may as 
well put the fixups into the main document where they'll be easier for an 
implementator to find.

Certainly, as someone reading the document now to plan an implementation, I 
would have found it much, much less helpful to put crucial information like 
this in a separate UTA document instead of the main one, as these details 
influence how and whether to expose the 8- vs 16-bit choice to Applications 
Using TLS at all.

David



On Tue, Apr 16, 2024, 05:17 Tschofenig, Hannes 
mailto:hannes.tschofe...@siemens.com>> wrote:
Hi David,

thanks again for these comments.

Speaking for myself, this exchange was not designed based on QUIC. I believe it 
pre-dated the corresponding work in QUIC.

Anyway, there are different usage environments and, as you said, there is a 
difference in the amount of messages that may be lost. For some environments 
the loss 255 messages amounts to losing the message exchanges of several days, 
potentially weeks. As such, for those use cases the shorter sequence number 
space is perfectly fine. For other environments this is obviously an issue and 
you have to select the bigger sequence number space.

More explanation about this aspect never hurts. Of course, nobody raised the 
need for such text so far and hence we didn’t add anything. As a way forward, 
we could add text to the UTA document. In the UTA document(s) we already talk 
about other configurable parameters, such as the timeout.

Ciao
Hannes

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
David Benjamin
Sent: Friday, April 12, 2024 11:36 PM
To: mailto:tls@ietf.org>> mailto:tls@ietf.org>>
Cc: Nick Harper mailto:nhar...@chromium.org>>
Subject: [TLS] DTLS 1.3 sequence number lengths and lack of ACKs

Hi all,

Here's another issue we noticed with RFC 9147: (There's going to be a few of 
these emails. :-) )

DTLS 1.3 allows senders to pick an 8-bit or 16-bit sequence number. But, unless 
I missed it, there isn't any discussion or guidance on which to use. The draft 
simply says:

> Implementations MAY mix sequence numbers of different lengths on the same 
> connection

I assume this was patterned after QUIC, but looking at QUIC suggests an issue 
with the DTLS 1.3 formulation. QUIC uses ACKs to pick the minimum number of 
bytes needed for the peer to recover the sequence number:
https://www.rfc-editor.org/rfc/rfc9000.html#packet-encoding

But the bulk of DTLS records, app data, are unreliable and not ACKed. DTLS 
leaves all that to application. This means a DTLS implementation does not have 
enough information to make this decision. It would need to be integrated into 
the application-protocol-specific reliability story, if the application 
protocol even maintains that information.

Without ACK feedback, it is hard to size the sequence number safely. Suppose a 
DTLS 1.3 stack unconditionally picked the 1-byte sequence number because it's 
smaller, and the draft didn't say not to do it. That means after getting out of 
sync by 256 records, either via reordering or loss, the connection breaks. For 
example, if there was a blip in connectivity and you happened to lose 256 
records, your connection is stuck and cannot recover. All future records will 
be at higher and higher sequence numbers. A burst of 256 lost packets seems 
within the range of situations one would expect an application to handle.

(The 2-byte sequence number fails at 65K losses, which is hopefully high enough 
to be fine?  Though it's far far less than what QUIC's 1-4-byte sequence number 
can accommodate. It was also odd to see no discussion of this anywhere.)

David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

[Tschofenig, Hannes]

Hi John,

I missed this email exchange and I largely agree with what has been said by 
others before.

I disagree with your conclusion since the “identity” in the raw public key case 
is the public key.
With the self-signed certificate there would the danger that the self-asserted 
identity in the certificate is actually used for anything.

Ciao
Hannes


From: TLS  On Behalf Of John Mattsson
Sent: Thursday, March 28, 2024 4:22 PM
To: TLS@ietf.org
Subject: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

Hi,

I looked into what RFC 8446(bis) says about Raw Public Keys. As correctly 
stated in RFC 8446, TLS 1.3 with signatures and certificates is an 
implementation of SIGMA-I:

SIGMA does however require that the identities of the endpoints (called A and B 
in [SIGMA]) are included in the messages. This is not true for TLS 1.3 with 
RPKs and TLS 1.3 with RPKs is therefore not SIGMA. TLS 1.3 with RPKs is 
vulnerable to what Krawczyk’s SIGMA paper calls misbinding attacks:

“This attack, to which we refer as an “identity misbinding attack”, applies to 
many seemingly natural and intuitive protocols. Avoiding this form of attack 
and guaranteeing a consistent binding between a session key and the peers to 
the session is a central element in the design of SIGMA.”

“Even more significantly we show here that the misbinding attack applies to 
this protocol in any scenario where parties can register public keys without 
proving knowledge of the corresponding signature key.”

As stated in Appendix E.1, at the completion of the handshake, each side 
outputs its view of the identities of the communicating parties. On of the TLS 
1.3 security properties are “Peer Authentication”, which says that the client’s 
and server’s view of the identities match. TLS 1.3 with PRKs does not fulfill 
this unless the out-of-band mechanism to register public keys proved knowledge 
of the private key. RFC 7250 does not say anything about this either.

I think this needs to be clarified in RFC8446bis. The only reason to ever use 
an RPK is in constrained IoT environments. Otherwise a self-signed certificate 
is a much better choice. TLS 1.3 with self-signed certificates is SIGMA-I.

It is worrying to find comments like this:

“I'd like to be able to use wireguard/ssh-style authentication for my app. This 
is possible currently with self-signed certificates, but the proper solution is 
RFC 7250, which is also part of TLS 1.3.”
https://github.com/openssl/openssl/issues/6929

RPKs are not the proper solution.

(Talking about misbinding, does RFC 8446 say anything about how to avoid selfie 
attacks where an entity using PSK authentication ends up talking to itself?)

Cheers,
John Preuß Mattsson

[SIGMA] https://link.springer.com/chapter/10.1007/978-3-540-45146-4_24

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Issues with buffered, ACKed KeyUpdates in DTLS 1.3

[Tschofenig, Hannes]

Hi David,

this is great feedback. Give me a few days to respond to this issue with my 
suggestion for moving forward.

Ciao
Hannes

From: TLS  On Behalf Of David Benjamin
Sent: Saturday, April 13, 2024 7:59 PM
To:  
Cc: Nick Harper 
Subject: Re: [TLS] Issues with buffered, ACKed KeyUpdates in DTLS 1.3

Another issues with DTLS 1.3's state machine duplication scheme:

Section 8 says implementation must not send new KeyUpdate until the KeyUpdate 
is ACKed, but it says nothing about other post-handshake messages. Suppose 
KeyUpdate(5) in flight and the implementation decides to send NewSessionTicket. 
(E.g. the application called some "send NewSessionTicket" API.) The new epoch 
doesn't exist yet, so naively one would start sending NewSessionTicket(6) in 
the current epoch. Now the peer ACKs KeyUpdate(5), so we transition to the new 
epoch. But retransmissions must retain their original epoch:

> Implementations MUST send retransmissions of lost messages using the same 
> epoch and keying material as the original transmission.
https://www.rfc-editor.org/rfc/rfc9147.html#section-4.2.1-3

This means we must keep sending the NST at the old epoch. But the peer may have 
no idea there's a message at that epoch due to packet loss! Section 8 does ask 
the peer to keep the old epoch around for a spell, but eventually the peer will 
discard the old epoch. If NST(6) didn't get through before then, the entire 
post-handshake stream is now wedged!

I think this means we need to amend Section 8 to forbid sending *any* 
post-handshake message after KeyUpdate. That is, rather than saying you cannot 
send a new KeyUpdate, a KeyUpdate terminates the post-handshake stream at that 
epoch and all new post-handshake messages, be they KeyUpdate or anything else, 
must be enqueued for the new epoch. This is a little unfortunate because a TLS 
library which transparently KeyUpdates will then inadvertently introduce 
hiccups where post-handshake messages triggered by the application, like 
post-handshake auth, are blocked.

That then suggests some more options for fixing the original problem.

7. Fix the sender's KeyUpdate criteria

We tell the sender to wait for all previous messages to be ACKed too. Fix the 
first paragraph of section 8 to say:

> As with other handshake messages with no built-in response, KeyUpdates MUST 
> be acknowledged. Acknowledgements are used to both control retransmission and 
> transition to the next epoch. Implementations MUST NOT send records with the 
> new keys until the KeyUpdate and all preceding messages have been 
> acknowledged. This facilitates epoch reconstruction (Section 4.2.2) and 
> avoids too many epochs in active use, by ensuring the peer has processed the 
> KeyUpdate and started receiving at the new epoch.
>
> A KeyUpdate message terminates the post-handshake stream in an epoch. After 
> sending KeyUpdate in an epoch, implementations MUST NOT send any new 
> post-handshake messages in that epoch. Note that, if the implementation has 
> sent KeyUpdate but is waiting for an ACK, the next epoch is not yet active. 
> In this case, subsequent post-handshake messages may not be sent until 
> receiving the ACK.

And then on the receiver side, we leave things as-is. If the sender implemented 
the old semantics AND had multiple post-handshake transactions in parallel, it 
might update keys too early and then we get into the situation described in 
(1). We then declare that, if this happens, and the sender gets confused as a 
result, that's the sender's fault. Hopefully this is not rare enough (did 
anyone even implement 5.8.4, or does everyone just serialize their 
post-handshake transitions?) to not be a serious protocol break? That risk 
aside, this option seems the most in spirit with the current design to me.

8. Decouple post-handshake retransmissions from epochs

If we instead say that the same epoch rule only applies for the handshake, and 
not post-handshake messages, I think option 5 (process KeyUpdate out of order) 
might become viable? I'm not sure. Either way, this seems like a significant 
protocol break, so I don't think this is an option until some hypothetical DTLS 
1.4.


On Fri, Apr 12, 2024 at 6:59 PM David Benjamin 
mailto:david...@chromium.org>> wrote:
Hi all,

This is going to be a bit long. In short, DTLS 1.3 KeyUpdates seem to conflate 
the peer receiving the KeyUpdate with the peer processing the KeyUpdate, in 
ways that appear to break some assumptions made by the protocol design.

When to switch keys in KeyUpdate

So, first, DTLS 1.3, unlike TLS 1.3, applies the KeyUpdate on the ACK, not when 
the KeyUpdate is sent. This makes sense because KeyUpdate records are not 
intrinsically ordered with app data records sent after them:

> As with other handshake messages with no built-in response, KeyUpdates MUST 
> be acknowledged. In order to facilitate epoch reconstruction (Section 4.2.2), 
> implementations MUST NOT send records with the new keys or send a new 
> 

Re: [TLS] DTLS 1.3 sequence number lengths and lack of ACKs

[Tschofenig, Hannes]

Hi David,

thanks again for these comments.

Speaking for myself, this exchange was not designed based on QUIC. I believe it 
pre-dated the corresponding work in QUIC.

Anyway, there are different usage environments and, as you said, there is a 
difference in the amount of messages that may be lost. For some environments 
the loss 255 messages amounts to losing the message exchanges of several days, 
potentially weeks. As such, for those use cases the shorter sequence number 
space is perfectly fine. For other environments this is obviously an issue and 
you have to select the bigger sequence number space.

More explanation about this aspect never hurts. Of course, nobody raised the 
need for such text so far and hence we didn’t add anything. As a way forward, 
we could add text to the UTA document. In the UTA document(s) we already talk 
about other configurable parameters, such as the timeout.

Ciao
Hannes

From: TLS  On Behalf Of David Benjamin
Sent: Friday, April 12, 2024 11:36 PM
To:  
Cc: Nick Harper 
Subject: [TLS] DTLS 1.3 sequence number lengths and lack of ACKs

Hi all,

Here's another issue we noticed with RFC 9147: (There's going to be a few of 
these emails. :-) )

DTLS 1.3 allows senders to pick an 8-bit or 16-bit sequence number. But, unless 
I missed it, there isn't any discussion or guidance on which to use. The draft 
simply says:

> Implementations MAY mix sequence numbers of different lengths on the same 
> connection

I assume this was patterned after QUIC, but looking at QUIC suggests an issue 
with the DTLS 1.3 formulation. QUIC uses ACKs to pick the minimum number of 
bytes needed for the peer to recover the sequence number:
https://www.rfc-editor.org/rfc/rfc9000.html#packet-encoding

But the bulk of DTLS records, app data, are unreliable and not ACKed. DTLS 
leaves all that to application. This means a DTLS implementation does not have 
enough information to make this decision. It would need to be integrated into 
the application-protocol-specific reliability story, if the application 
protocol even maintains that information.

Without ACK feedback, it is hard to size the sequence number safely. Suppose a 
DTLS 1.3 stack unconditionally picked the 1-byte sequence number because it's 
smaller, and the draft didn't say not to do it. That means after getting out of 
sync by 256 records, either via reordering or loss, the connection breaks. For 
example, if there was a blip in connectivity and you happened to lose 256 
records, your connection is stuck and cannot recover. All future records will 
be at higher and higher sequence numbers. A burst of 256 lost packets seems 
within the range of situations one would expect an application to handle.

(The 2-byte sequence number fails at 65K losses, which is hopefully high enough 
to be fine?  Though it's far far less than what QUIC's 1-4-byte sequence number 
can accommodate. It was also odd to see no discussion of this anywhere.)

David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DTLS 1.3 epochs vs message_seq overflow

[Tschofenig, Hannes]

Hi David,

thanks for your reviews and the details comments.

Let me search for the exchanges that lead to the increase in the epoch space. I 
recall that this was very late in the process based on feedback from John, who 
noticed that the smaller epoch space helps IoT communication but not the DTLS 
use in SCTP.

Regarding your statement: “65K epochs should be enough for anybody, perhaps 
DTLS 1.4 should update the RecordNumber structure accordingly and save a few 
bytes in the ACKs“. Possibly correct. I am going to ask the SCTP community for 
feedback to find out whether that is also true for them.

Ciao
Hannes

From: TLS  On Behalf Of David Benjamin
Sent: Friday, April 12, 2024 1:16 AM
To:  
Cc: Nick Harper 
Subject: Re: [TLS] DTLS 1.3 epochs vs message_seq overflow

On Thu, Apr 11, 2024 at 7:12 PM David Benjamin 
mailto:david...@chromium.org>> wrote:
Hi all,

In reviewing RFC 9147, I noticed something a bit funny. DTLS 1.3 changed the 
epoch number from 16 bits to 64 bits, though with a requirement that you not 
exceed 2^48-1. I assume this was so that you're able to rekey more than 65K 
times if you really wanted to.

I'm not sure we actually achieved this. In order to change epochs, you need to 
do a KeyUpdate, which involves sending a handshake message. That means burning 
a handshake message sequence number. However, section 5.2 says:

> Note: In DTLS 1.2, the message_seq was reset to zero in case of a rehandshake 
> (i.e., renegotiation). On the surface, a rehandshake in DTLS 1.2 shares 
> similarities with a post-handshake message exchange in DTLS 1.3. However, in 
> DTLS 1.3 the message_seq is not reset, to allow distinguishing a 
> retransmission from a previously sent post-handshake message from a newly 
> sent post-handshake message.

This means that the message_seq space is never reset for the lifetime of the 
connection. But message_seq is a 16-bit field! So I think you would overflow 
message_seq before you manage to overflow a 16-bit epoch.

Now, I think the change here was correct because DTLS 1.2's resetting on 
rehandshake was a mistake. In DTLS 1.2, the end of the previous handshake and 
the start of the next handshake happen in the same epoch, which meant that 
things were ambiguous and you needed knowledge of the handshake state machine 
to resolve things. However, given the wider epoch, perhaps we should have said 
that message_seq resets on each epoch or something. (Too late now, of course... 
DTLS 1.4 I suppose?)

Alternatively, if we think 65K epochs should be enough for anybody, perhaps 
DTLS 1.4 should update the RecordNumber structure accordingly and save a few 
bytes in the ACKs. :-)

Does all that check out, or did I miss something?

David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Key Update for TLS/DTLS 1.3

[Tschofenig, Hannes]

Hi all,

we have just submitted a draft that extends the key update functionality of 
TLS/DTLS 1.3.
We call it the "extended key update" because it performs an ephemeral 
Diffie-Hellman as part of the key update.

The need for this functionality surfaced in discussions in a design team of the 
TSVWG. The need for it has, however, already been discussed years ago on the 
TLS mailing list in the context of long-lived TLS connections in industrial IoT 
environments.
Unlike the TLS 1.3 Key Update message, which is a one-shot message, the 
extended Key Update message requires a full roundtrip.

Here is the link to the draft:
https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/

I am curious what you think.

Ciao
Hannes

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Design Rational for Key Exporter

[Tschofenig, Hannes]

Hi all,

I was wondering why the design of the key exporter is such that it is based on 
the early_exporter_master_secret or the exporter_master_secret and no new key 
export is triggered at a later point in time, for example when a key update is 
performed. RFC 5705, which is used as a basis for the key exporter design in 
TLS 1.3, just states that there are protocols that want to obtain keying 
material from the TLS exchange. RFC 5705 nor the TLS 1.3 spec indicate the 
design rational of why no later events (e.g. post-handshake authentication or 
key updates) trigger a new key export. Was this done on purpose or was there 
just no use case for it at that time?

Ciao
Hannes

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

[Tschofenig, Hannes]

Hi Martin,

I believe the best approach is to address this issue is to use replay 
protection for post-handshake authentication messages. I believe there is value 
in enhancing the functionality of the post handshake authentication, 
particularly the key update message, and we could do it in this context.

FWIW I have prepared a draft that adds new functionality to the key update 
message:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-key-update/draft-tschofenig-tls-extended-key-update.txt

Ciao
Hannes

-Ursprüngliche Nachricht-
Von: TLS  Im Auftrag von Martin Thomson
Gesendet: Dienstag, 28. November 2023 23:11
An: tls@ietf.org
Betreff: Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

On Tue, Nov 28, 2023, at 19:29, John Mattsson wrote:
> I would strongly recommend all DTLS 1.3 libraries to completely remove
> the option to disable replay protection.

I believe that the reason this exists is that some higher-layer protocols have 
their own replay protection, such that as long as the datagram is authentic, it 
is safe.  However, I agree that if we are sending handshake messages that 
affect DTLS state, it is probably not good to have the DTLS layer fail to 
provide that protection.  I believe that you can operate DTLS 1.3 without 
post-handshake handshake/control messages, in which case you might manage to 
avoid exposure.

NSS has no means to disable replay protection and I see no reason to add that 
means.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

[Tschofenig, Hannes]

Hi John,

the reason for not having replay protection for the application data is not 
because there is no replay protection at all but rather that there are 
applications that provide replay protection instead of using the lower layer.
Hence, the scenario you present below is likely not going to be applicable 
because the replay detection will happen at the higher layer.

Ciao
Hannes

Von: TLS  Im Auftrag von John Mattsson
Gesendet: Mittwoch, 29. November 2023 00:00
An: TLS@ietf.org
Betreff: Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

Hi,

Lack of replay also enables tracking of client and server. If the client or 
server is a device moving together with a person this enables tracking of the 
person.

An attacker can store a message from one location and then replay it to the 
client or server in another location. If the client or server accept the 
replayed message, the attacker knows that the device in the two locations are 
one and the same. It is best practice to assume that an attacker can always 
detect if a message was accepted. If the client or server send a response to 
the replayed message (like a replayed client authentication request) this is 
trivial.

This is different from the attack described in Section C.4 "Client and Server 
Tracking Prevention" of RFC8446bis, which describes the client reusing a 
ticket. A network attacker mounting a replay attack are described in Section 8 
of RFC8446bis. I think a sentence or two should be added to Section C.4 to 
describe that a network attacker mounting a replay attack can be used for 
server tracking and that the mitigations in Section 8 help.
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/

Cheers,
John Preuß Mattsson

From: TLS mailto:tls-boun...@ietf.org>> on behalf of John 
Mattsson 
mailto:john.mattsson=40ericsson@dmarc.ietf.org>>
Date: Tuesday, 28 November 2023 at 09:30
To: TLS@ietf.org mailto:tls@ietf.org>>
Subject: Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?
Hi,

Reading RFC 9147 (DTLS 1.3) I cannot find any other interpretation than that 
replay protection may be disabled for all records. This is not a problem for 
the initial lock-step handshake, alerts, KeyUpdate, and ACKs. It seems to be a 
major problem for NewSessionTicket, NewConnectionId, RequestConnectionId, and 
Post-handshake client authentication as the lack of replay protection might 
significantly affect availability. It seems to me that DTLS 1.3 forgot to 
update replay protection based on the new post-handshake messages. Let me know 
if I miss something.

It is a bit surprising that DTLS 1.3 published in 2022 allows the application 
to turn off replay protection at all. This very far from current best practice 
for security protocols. There are very good reasons why Datagram QUIC mandates 
replay protection and why TLS 1.3 has several pages discussing security 
considerations for 0-RTT data, which lacks replay protection. In general, 
turning off replay protection (even just for application data) might lead to 
loss of confidentiality, integrity, and availability, i.e., the whole CIA triad.

Applications cannot be expected to understand the severe consequences of not 
having replay protection or understand how to fix it on the application layer. 
I also don't see any need for turning off replay protection except RFC 6083 
which is a bit of a special case, and which turned out to have replay issues.
https://datatracker.ietf.org/meeting/115/materials/slides-115-tsvwg-sctp-auth-security-issues-00

I would strongly recommend all DTLS 1.3 libraries to completely remove the 
option to disable replay protection.

An easy fix for the post-handshake messages is to "clarify" that replay 
protection must not be turned off for anything else than application data. I 
you agree I can submit an "erratum" for RFC 9147. But this does not solve the 
general issue that turning off replay protection would be a major security 
problem in almost all applications.

Cheers,
John Preuß Mattsson

From: TLS mailto:tls-boun...@ietf.org>> on behalf of John 
Mattsson 
mailto:john.mattsson=40ericsson@dmarc.ietf.org>>
Date: Friday, 24 November 2023 at 14:50
To: TLS@ietf.org mailto:tls@ietf.org>>
Subject: [TLS] DTLS 1.3 replay protection of post-handshake messages?
Hi,

How does replay protection of Post-handshake messages work in DTLS 1.3 if the 
per-record replay-protection mechanism is turned off?

1. Is the post-handshake messages replay protected in some other way, which I 
miss?

2. Should RFC 9147 state that the per-record replay-protection mechanism can 
only be turned off for application data? (I could not find anything in RFC 9147 
stating something like this).

(things like post-handshake authentication need replay protection in some way)

Cheers,
John Preuß Mattsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

[Tschofenig, Hannes]

John,

when you say that DTLS over SCTP is not a good design (and reference the work 
in the design team) you should also note that you have file IPRs on an 
alternative designed. Hence, I think you are a little bit biased.

Ciao
Hannes

Von: TLS  Im Auftrag von John Mattsson
Gesendet: Dienstag, 28. November 2023 23:58
An: Martin Thomson ; tls@ietf.org
Betreff: Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

>I believe that the reason this exists is that some higher-layer protocols have 
>their own replay protection, such that as long as the datagram is authentic, 
>it is safe.
I agree that you theoretically do that. But I don't see the problem in these 
cases. Replay protection is almost free. I do understand the use case in RFC 
6083 where DTLS is sent on top of SCTP and having DTLS replay protection turned 
on cause problems. But I also think that DTLS over SCTP is not a good design.

>NSS has no means to disable replay protection and I see no reason to add that 
>means.
That seems like the right approach to me.

Cheers,
John

From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
Martin Thomson mailto:m...@lowentropy.net>>
Date: Tuesday, 28 November 2023 at 23:11
To: tls@ietf.org mailto:tls@ietf.org>>
Subject: Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?
On Tue, Nov 28, 2023, at 19:29, John Mattsson wrote:
> I would strongly recommend all DTLS 1.3 libraries to completely remove
> the option to disable replay protection.

I believe that the reason this exists is that some higher-layer protocols have 
their own replay protection, such that as long as the datagram is authentic, it 
is safe.  However, I agree that if we are sending handshake messages that 
affect DTLS state, it is probably not good to have the DTLS layer fail to 
provide that protection.  I believe that you can operate DTLS 1.3 without 
post-handshake handshake/control messages, in which case you might manage to 
avoid exposure.

NSS has no means to disable replay protection and I see no reason to add that 
means.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls