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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 05 March 2020 12:47 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E3C3A1410; Thu, 5 Mar 2020 04:47:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjYHh1X6R0mY; Thu, 5 Mar 2020 04:47:07 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A4A3A140F; Thu, 5 Mar 2020 04:47:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DF420BE8A; Thu, 5 Mar 2020 12:47:01 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obLYNGWXirTg; Thu, 5 Mar 2020 12:47:01 +0000 (GMT)
Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 948F0BE79; Thu, 5 Mar 2020 12:47:01 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1583412421; bh=lsSIHxf9DTfJcqxuHi4hZ2wxt14y2JsXZOZwp7YmYvY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kyU2EBGbBWBPiV0Wi2kcHGdzsQC2OmlwGJQ19WKEwla3d/r9sAlln5VpWUQnbIul0 i2B8kQWMi0STzmLijaHhFWMeI1mDem6MVD8CLU8o7MiGc6KmpIlvDDZOX9SNiZfkJ5 220FKOiJD89jay9ksbuUAYI8b1CzlfDZeSZ2gVHM=
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, secdir@ietf.org
Cc: draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org, last-call@ietf.org, tsvwg@ietf.org
References: <158328103137.7648.9240148667630328703@ietfa.amsl.com> <b721e053-e8f7-07d0-42c5-11fd25d5d6ea@erg.abdn.ac.uk>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <5c00c98f-0e8b-a164-6c4e-7d4457249e81@cs.tcd.ie>
Date: Thu, 5 Mar 2020 12:47:00 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <b721e053-e8f7-07d0-42c5-11fd25d5d6ea@erg.abdn.ac.uk>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ZA9oDIhSBPTmjRlDBXZFC7WFVJgMxmeEP"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/mh6lXMF0fNexHgoKQehoY81E9oQ>
Subject: Re: [tsvwg] Secdir last call review of draft-ietf-tsvwg-datagram-plpmtud-15
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Thu, 05 Mar 2020 12:47:10 -0000

Hi Gorry,

On 04/03/2020 15:55, Gorry Fairhurst wrote:
> Thanks for this review Stephen.
> 
> On 04/03/2020 00:17, Stephen Farrell via Datatracker wrote:
>> 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.
> We spoke with our TSV ADs and they  don't see any issue with this.
> BCP and Standards track are equivalent.

I'll leave you all to enjoy discussion of that in peace so;-)

>> - 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?
> We suggest adding to the security considerations, see later.

Ack.

>> - 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?
> 
> Yes, all PL-overhead is included, but I think worth noting explicitly
> in Section 4.1 to avoid doubt. I suggest we add:
> 
> OLD: Protocols that permit exchange of control messages (without an
> application data block) can generate a probe packet by extending a
> control message with padding data. 
> NEW: Protocols that permit
> exchange of control messages (without an application data block) can
> generate a probe packet by extending a control message with padding
> data. The total size of a probe packet includes all headers and
> padding added to the payload data being sent (e.g., including
> protocol option fields, security-related fields such as an AEAD tag
> and TLS record layer padding).

I like the NEW text. But I'm still not clear if a 16 octet
AEAD tag is to be subtracted from the MPS or not;-) I guess
that'd depend on e.g. the specific ciphersuite in use and
so could vary? That might be just me though - I've always
found discussion about packet size limits ambiguous as some
people do and some do not account for overhead when they
talk about sizes. Maybe if you gave an example that'd make
it crystal clear even for the likes of me?

> 
>> - 4.4: What'd be the MPS etc for an MP-TCP-like PL? Is that 
>> well-defined?
> 
> For MP-TCP this isn't an issue, but each PL could have it's own
> issues and needs to work out what MPS means.

Ok.

> 
>> - 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.
> 
> RFC8085 does provide some examples, and this is a common-enough 
> transport requirement to protect from DDOS. Could the SHOULD be
> retained and this be fixed by a more specific reference perhaps?
> 
> (see Section 5.1 of [RFC8085]).

Yeah, that seems right.

> 
>> - 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.
> Agree. Please see proposeed text above and the proposed adds to the 
> security considerations below.

Ack.

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

I'll leave that one so:-) It's not a security issue, so
for the purposes of a secdir review, it oughtn't be a
blocker of any sort.

>> 
>> - 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.
> 
> I think this is useful. Security thoughts are always welcome. How
> about adding two extra paras to the Security Considerations, are
> these near?:
> 
> "DPLPMTUD methods can introduce padding data to inflate the length
> of the datagram to the total size required for a probe packet. The
> total size of a probe packet includes all headers and padding added
> to the payload data being sent (e.g., including security-related
> fields such as an AEAD tag and TLS record layer padding). The value
> of the padding data does not influence the DPLPMTUD search algorithm,
> and therefore needs to be set consistent with the policy of the PL.
> A secure PL MUST provide cryptographic protection for the padding if
> this is needed to satisfy the security requirements of that PL.

That seems almost ok:-) I'd maybe switch the last sentence
around to say something like: "If a PL can make use of
cryptographic confidentiality or data-integrity mechanisms,
then adding anything (incl. padding) for DPLPMTUD that is
not protected by those cryptographic mechanisms is an anti-
pattern to be avoided, even if technically possible."

> A PL that implements this spec would send probe packets, whose size
> and frequency can be observed by the network. Designers of search
> algorithms need to consider whether the size of probe packets and the
> pattern of probing could result in a potential covert channel (e.g.,
> for exfiltrating data to an on-path device or the endpoint of the 
> connection). "

WFM,
Thanks,
S.


> 
> Gorry
> 
>>