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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
