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

Stephen Farrell via Datatracker <noreply@ietf.org> Wed, 04 March 2020 00:17 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBAD3A08FA; Tue, 3 Mar 2020 16:17:11 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Cc: draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org, last-call@ietf.org, tsvwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.119.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158328103137.7648.9240148667630328703@ietfa.amsl.com>
Reply-To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Tue, 03 Mar 2020 16:17:11 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/mllzyERRvpemottA0JGnrzYoh1M>
Subject: [tsvwg] Secdir last call review of draft-ietf-tsvwg-datagram-plpmtud-15
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2020 00:17:13 -0000

Reviewer: Stephen Farrell
Review result: Has Issues


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 


- 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

- 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.