[tsvwg] Secdir last call review of draft-ietf-tsvwg-datagram-plpmtud-15

[Stephen Farrell via Datatracker <[e-mail]>]

Reviewer: Stephen Farrell
Review result: Has Issues


Hi, 

As Hilary Orman always nicely says: do not be alarmed, 
this is just a secdir review:-)

I classed this as "has issues," but the issues below should be
fairly easy to fix.  Maybe all but 2 are real issues that say are
worth fixing, if I'm right about 'em (but I'm also often wrong 
too:-)

Cheers,
S.

- Abstract: This draft aims for proposed standard but is
updating a BCP (RFC8085/BCP145).  I'm happy to leave the
process-lawyering for that to others.

- 4.1: I'm not sure if this is recommending that PLs allow for
padding outside of cryptographic protection. If so, that
seems like an anti-pattern when considering the overall set of
requirements one might envisage for a PL. If not, that's fine,
but would it be worth stating that?

- 4.4: Would you count the AEAD tag length in the MPS of an
AEAD-encrypting PL or not? I assume not, and the tag length
is counted as PL overhead even if sent as a sort-of trailer
within the ciphertext?

- 4.4: What'd be the MPS etc for an MP-TCP-like PL? Is that
well-defined? 

- 4.5: (a nit) "The validation SHOULD utilize information that
  it is not simple for an off-path attacker to determine
[RFC8085]." A SHOULD that's that vague seems likely prone to
issues. Might be best to just s/SHOULD/ought/ or something
like that. 

- 6.2.3: what if TLS record layer padding is being done as
well?  Probably just needs a mention, so people don't get
their sums/APIs wrong. 

- 6.3: I am surprised that the QUIC description here is ready
to be an RFC before QUIC itself. I do see there are
normative references, but the potential for a breaking change
still exists, and seems a bit unwise. (I'd suggest, holding
this in the WG 'till the referenced QUIC drafts are in the RFC
editor queue, or else taking that bit out and putting it into
a new I-D.)

- section 9: Ok this is a stretch so maybe not worth bothering
  with but... A PL doing all this may be emitting oddly sized
padding octets from time to time that piggy-back on
application data. That (number of padding octets and the
pattern with which those are emitted) seems like a medium-nice
covert channel e.g. for exfiltrating data, not necessarily to
the packet destination but to anyone on-path who can observe
the signal.