Last Call Review of draft-ietf-tsvwg-datagram-plpmtud-15
review-ietf-tsvwg-datagram-plpmtud-15-secdir-lc-farrell-2020-03-03-00
Request | Review of | draft-ietf-tsvwg-datagram-plpmtud |
---|---|---|
Requested revision | No specific revision (document currently at 22) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2020-03-10 | |
Requested | 2020-02-25 | |
Authors | Gorry Fairhurst , Tom Jones , Michael Tüxen , Irene Ruengeler , Timo Völker | |
I-D last updated | 2020-03-03 | |
Completed reviews |
Secdir Last Call review of -15
by Stephen Farrell
(diff)
Genart Last Call review of -15 by Francis Dupont (diff) Opsdir Last Call review of -17 by Tim Chown (diff) Secdir Telechat review of -19 by Stephen Farrell (diff) |
|
Assignment | Reviewer | Stephen Farrell |
State | Completed | |
Request | Last Call review on draft-ietf-tsvwg-datagram-plpmtud by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/yyP-LnKKj0DbW6d5W9jgK9ETJVw | |
Reviewed revision | 15 (document currently at 22) | |
Result | Has issues | |
Completed | 2020-03-03 |
review-ietf-tsvwg-datagram-plpmtud-15-secdir-lc-farrell-2020-03-03-00
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.