Background
PR #106 narrowed the auto-sense server fallback and added an unconditional structural check (looks_like_client_hello). While reviewing it we noticed the same class of issue — content-dependent early-returns and short-circuiting — exists more broadly throughout the handshake parsing code on both the DTLS 1.2 and 1.3 paths.
This issue is to scope an audit of the full handshake parsing surface (not just auto-sense) for constant-time properties.
Concrete starting points spotted during the PR #106 review
These are the two cases I actually looked at, included as examples of the pattern — not a complete list.
client_hello_wants_psk (src/lib.rs:341-388)
frag_off != 0 — lib.rs:350-352pos + 2 > body.len() — lib.rs:372pos + suites_len > body.len() || suites_len % 2 != 0 — lib.rs:377- The cipher-suite walk returns at the first allowed match —
lib.rs:382-386
DTLS 1.3 server CH extension walk (src/dtls13/server.rs:425-478)
The for ext in &client_hello.extensions { match ext.extension_type { … } } block has per-extension handlers and a _ => {} default. Per-extension parser timings vary; presence/order/contents leak through total time.
What the audit should cover
Not just the two snippets above — the same patterns are likely present in:
- DTLS 1.2 client and server handshake message parsers
- DTLS 1.3 client and server handshake message parsers
- Record-layer parsing (
engine.parse_packet and friends)
- Extension parsers (
SupportedVersionsClientHello::parse, KeyShareClientHello::parse, etc.)
- Anti-replay window updates, sequence number handling
- Cookie/HRR generation and validation
- PSK identity matching
For each: identify content-dependent branches, decide whether they need hardening (replace early returns with | accumulators, always traverse to end, use subtle::Choice-style helpers) or whether the outcome is already observable on the wire and not worth defending.
Out of scope
Constant-time crypto primitives — those should already be handled by the underlying provider (aws-lc-rs etc.). This issue is about the parsing/dispatch paths around the crypto.
Notes
This is defense-in-depth, not a known exploit. Worth bundling with any future audit of handshake correctness more broadly.
Background
PR #106 narrowed the auto-sense server fallback and added an unconditional structural check (
looks_like_client_hello). While reviewing it we noticed the same class of issue — content-dependent early-returns and short-circuiting — exists more broadly throughout the handshake parsing code on both the DTLS 1.2 and 1.3 paths.This issue is to scope an audit of the full handshake parsing surface (not just auto-sense) for constant-time properties.
Concrete starting points spotted during the PR #106 review
These are the two cases I actually looked at, included as examples of the pattern — not a complete list.
client_hello_wants_psk(src/lib.rs:341-388)frag_off != 0—lib.rs:350-352pos + 2 > body.len()—lib.rs:372pos + suites_len > body.len() || suites_len % 2 != 0—lib.rs:377lib.rs:382-386DTLS 1.3 server CH extension walk (
src/dtls13/server.rs:425-478)The
for ext in &client_hello.extensions { match ext.extension_type { … } }block has per-extension handlers and a_ => {}default. Per-extension parser timings vary; presence/order/contents leak through total time.What the audit should cover
Not just the two snippets above — the same patterns are likely present in:
engine.parse_packetand friends)SupportedVersionsClientHello::parse,KeyShareClientHello::parse, etc.)For each: identify content-dependent branches, decide whether they need hardening (replace early returns with
|accumulators, always traverse to end, usesubtle::Choice-style helpers) or whether the outcome is already observable on the wire and not worth defending.Out of scope
Constant-time crypto primitives — those should already be handled by the underlying provider (aws-lc-rs etc.). This issue is about the parsing/dispatch paths around the crypto.
Notes
This is defense-in-depth, not a known exploit. Worth bundling with any future audit of handshake correctness more broadly.