[TLS] Genart last call review of draft-ietf-tls-keylogfile-01

[Russ Housley via Datatracker]

Reviewer: Russ Housley
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
.

Document: draft-ietf-tls-keylogfile-01
Reviewer: Russ Housley
Review Date: 2024-04-12
IETF LC End Date: 2024-04-18
IESG Telechat date: unknown

Summary: Ready


Major Concerns:

None


Minor Concerns:

Section 3: The text says: "Access to the content of a file in
SSLKEYLOGFILE format allows an attacker to break the
confidentiality protection on any TLS connections that are
included in the file."  This is clearly true.  However, the
attacker this access to the keys can also break the integrity
protections.

Section 4: The registration of the new application/sslkeylogfile
media-type for all IETF registrations in the standards tree
requires a posting to the media-ty...@iana.org mail list.  A search
of the mail archive id not uncover "sslkeylogfile".  To avoid delay,
that mail list discussion should probably get started now.


Nits:

Section 1: s/file format that logging/file format for logging/



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

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

[David Benjamin]

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

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

[David Benjamin]

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 KeyUpdate until the previous KeyUpdate has been acknowledged (this
avoids having too many epochs in active use).
https://www.rfc-editor.org/rfc/rfc9147.html#section-8-1

Now, the parenthetical says this is to avoid having too many epochs in
active use, but it appears that there are stronger assumptions on this:

> After the handshake is complete, if the epoch bits do not match those
from the current epoch, implementations SHOULD use the most recent **past**
epoch which has matching bits, and then reconstruct the sequence number for
that epoch as described above.
https://www.rfc-editor.org/rfc/rfc9147.html#section-4.2.2-3
(emphasis mine)

> After the handshake, implementations MUST use the highest available
sending epoch [to send ACKs]
https://www.rfc-editor.org/rfc/rfc9147.html#section-7-7

These two snippets imply the protocol wants the peer to definitely have
installed the new keys before you start using them. This makes sense
because sending stuff the peer can't decrypt is pretty silly. As an aside,
DTLS 1.3 retains this text from DTLS 1.2:

> Conversely, it is possible for records that are protected with the new
epoch to be received prior to the completion of a handshake. For instance,
the server may send its Finished message and then start transmitting data.
Implementations MAY either buffer or discard such records, though when DTLS
is used over reliable transports (e.g., SCTP [RFC4960]), they SHOULD be
buffered and processed once the handshake completes.
https://www.rfc-editor.org/rfc/rfc9147.html#section-4.2.1-2

The text from DTLS 1.2 talks about *a* handshake, which presumably refers
to rekeying via renegotiation. But in DTLS 1.3, the epoch reconstruction
rule and the KeyUpdate rule mean this is only possible during the
handshake, when you see epoch 4 and expect epoch 0-3. The steady state
rekeying mechanism never hits this case. (This is a reasonable change
because there's no sense in unnecessarily introducing blips where the
connection is less tolerant of reordering.)

*Buffered handshake messages*

Okay, so KeyUpdates want to wait for the recipient to install keys, except
we don't seem to actually achieve this! Section 5.2 says:

> DTLS implementations maintain (at least notionally) a next_receive_seq
counter. This counter is initially set to zero. When a handshake message is
received, if its message_seq value matches next_receive_seq,
next_receive_seq is incremented and the message is processed. If the
sequence number is less than next_receive_seq, the message MUST be
discarded. If the sequence number is greater than next_receive_seq, the
implementation SHOULD queue the message but MAY discard it. (This is a
simple space/bandwidth trade-off).
https://www.rfc-editor.org/rfc/rfc9147.html#section-5.2-7

I assume this is intended to apply to post-handshake messages too. (See
below for a discussion of the alternative.) But that means that, when you
receive a KeyUpdate, you might not immediately process it. Suppose
next_receive_seq is 5, and the peer sends NewSessionTicket(5),
NewSessionTicket(6), and KeyUpdate(7). 5 is lost, but 6 and 7 come in,
perhaps even in the same record which means that you're forced to ACK both
or neither. But suppose the implementation is willing to buffer 3 messages
ahead, so it ACKs the 6+7 record, by the rules in section 7, which permits
ACKing fragments that were buffered and not yet processed.

That means the peer will switch keys and now all subsequent records from
them will come from epoch N+1. But the sender is not ready for N+1 yet, so
we contradict everything above. We also contradict this parenthetical in
section 8:

> Due to loss and/or reordering, DTLS 1.3 implementations may receive a
record with an older epoch than the current one (the requirements above
preclude receiving a newer record).
https://www.rfc-editor.org/rfc/rfc9147.html#section-8-2

I assume then that this was not actually what was intended.

*Options (and non-options)*

Assuming I'm reading this right, we seem to have made a mess of things. The
sender could avoid this by only allowing one active post-handshake
transaction at a time and serializing them, at the cost of taking a
round-trip for each. But the receiver needs to account for all possible
senders, so that doesn't help. Some option