Re: [multipathtcp] HMAC output size in draft-ietf-mptcp-rfc6824bis-15 (plus other comments) (with COMMENT)

Alan Ford <alan.ford@gmail.com> Sat, 08 June 2019 10:21 UTC

Return-Path: <alan.ford@gmail.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1BF12006E; Sat, 8 Jun 2019 03:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 4qOALtuJcSng; Sat, 8 Jun 2019 03:21:51 -0700 (PDT)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB40D12004E; Sat, 8 Jun 2019 03:21:50 -0700 (PDT)
Received: by mail-wr1-x435.google.com with SMTP id n4so4457492wrw.13; Sat, 08 Jun 2019 03:21:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=og7MOGYSP4s0HIVsueuG176HF3u+mkMmpoG1KYEJjBg=; b=igrZ3gjQhBlHTc4pdn4Rz+QFxwr+sip6zUADdkNMLlm5YHLETRtMbR5ivSR6GeWI5C MGBjQuHMkayUoZMOAJ7OhRLzmkSx0H/fVg8RahFMenucyOUp4nQ875rejyuGEBkDhRBP NR1nPDoOPMDj+71D/FlX1rxKCgP3JMOEfSn3LQPifwpF/E0NiKt0fYUDHj05/Z0oQMpT 2kGOKiUFjBD8iODkcMEkO6i9LfMfzBiXejQkBGLirA3ur57e/GkQNd5ZFWtH21Uo9acp i7R219XYMP3bBAyuKACrRp8h7fAhDRFW3JfGuBNRHCO8E4rzh9NQF0Zm/4HJdbYG5zqO XHkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=og7MOGYSP4s0HIVsueuG176HF3u+mkMmpoG1KYEJjBg=; b=stqKKc26OkL2uEo3BRvyP9QqHr6vQUVtLs4Sh6AC/ZcBevejjhj2F6obvN4Ucr7t2H CEhrzKZVwUj6ZTTiJSDvLumJER2AzY6beUdm1LbP+dvavfIC9u8ps2AEEYdsQGAvgQrV P3SiqCjFO+egCJZcnQ4bYJl52/D7p1NonnNUjQmKjTTA9yxKNO0FlQRvkY0CY5+ZjkY4 6LK4Uawz0N2gWc/0dDoyPW2LvXoCk4bcH7CZ4f5KkpBS74eoKJZAQYVwF2cPXVzW3Jsg y1cB7PIo3xM4L4hG6XX2Q9AUhV43HewBjSK1mgZH386FALjOQg1tRWTRVKdjM7ovQYeC cmjg==
X-Gm-Message-State: APjAAAX87HO5rx9VaJ/aFA+OxV3bIWxdgXRcWEdT/XxnzwsA8xa47DOk pcueBD4Y6Z97iemV7L6fmRM=
X-Google-Smtp-Source: APXvYqz/aIUsG/y3MO4j4RZ+41LHOHyaE0rbeccOOvGuTO6lvKxSDs+2vJbYVcOYYvJN+Rc8Ns3IIw==
X-Received: by 2002:adf:dc81:: with SMTP id r1mr13774534wrj.298.1559989309160; Sat, 08 Jun 2019 03:21:49 -0700 (PDT)
Received: from [192.168.1.66] (19.35.115.87.dyn.plus.net. [87.115.35.19]) by smtp.gmail.com with ESMTPSA id c129sm5117107wma.27.2019.06.08.03.21.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jun 2019 03:21:48 -0700 (PDT)
From: Alan Ford <alan.ford@gmail.com>
Message-Id: <732F1407-C353-4029-9FB9-5164F0F039FA@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FEECCD2F-69BB-40EE-B1BE-6CD4022FA43A"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Sat, 8 Jun 2019 11:21:46 +0100
In-Reply-To: <20190606163222.GB23396@kduck.mit.edu>
Cc: draft-ietf-mptcp-rfc6824bis@ietf.org, The IESG <iesg@ietf.org>, multipathtcp@ietf.org, philip.eardley@bt.com, mptcp-chairs@ietf.org
To: Benjamin Kaduk <kaduk@mit.edu>
References: <20190606163222.GB23396@kduck.mit.edu>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/BA8ggBgo78_tUDdm1UUHV15ILX0>
Subject: Re: [multipathtcp] HMAC output size in draft-ietf-mptcp-rfc6824bis-15 (plus other comments) (with COMMENT)
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Jun 2019 10:21:54 -0000

Hi Ben,

Thank you very much for your detailed comments. My responses are inline, and a -18 rev is about to appear with the changes included.

> It seems that this may just be a relic of the switch from SHA-1 to SHA-256,
> since the SHA-1 output is 160 bits and SHA-256's is, well, 256 bits.
> However, I'm concerned that the document is ambiguous about constructing
> the HMAC field in MP_JOIN.  It may just be an editorial matter and easily
> resolved, but I cannot state so with confidence without further input.
> 
> In particular, Figure 7 refers to a 160-bit field for the HMAC (which
> would match with the usage of HMAC-SHA-1 in RFC 6824), but there is
> no mention of truncating the SHA-256 HMAC in the body text (we do have
> such discussion for the generation of tokens and IDSNs).  Are
> implementations truncating from 256 to 160 bits for this message or
> sending the full 256?  It also seems important to know whether there's
> enough room in the TCP options space for it all to fit, but I didn't get
> a chance to try to chase that down.  There's also a note in the body text
> in Section 3.2 that still talks about "generating a 160-bit / 20-octet
> HMAC" from SHA-256, which should get updated.

Great catches, than you. This will remain 160 bits due to option space limitations, but shall be truncated as per RFC2104 (i.e. leftmost bits). I will clarify in the text.

> I also made some other notes while reading through for the crypto
> perspective, which would have gone in the Comment section if I had balloted
> in time:
> 
> I appreciate the discussion of what happens when Address ID 0 is
> removed; that saves me from having to ask about it.
> 
> Section 3.1
> 
>   prefer not to attempt a v0 connection.  An initiator MAY cache
>   information for a peer about what version of MPTCP it supports if
>   any, and use this information for future connection attempts.
> 
> I'm a bit surprised to not see guidance here for how long to cache
> (specifically here and not most other places in the document), since
> this might affect "baseline load" in some environments.

That’s kinda the reason why we don’t go into detail! This statement is a MAY, as a suggestion that an implementation may wish to do this. There may be different reasons for an implementation choosing to do this, and certain environmental limitations that mean that it is not appropriate.

> Section 3.2
> 
>   packets) that is used as the "message".  This specification defines
>   that HMAC as defined in [RFC2104] is used, along with the SHA-256
>   hash algorithm [RFC6234], thus generating a 160-bit / 20-octet HMAC.
>   Due to option space limitations, the HMAC included in the SYN/ACK is
> 
> [As noted in the Discuss section, SHA-256 HMACs will be 256 bits/32 octets.]
> 
>   Although calculating an HMAC requires cryptographic operations, it is
>   believed that the 32-bit token in the MP_JOIN SYN gives sufficient
>   protection against blind state exhaustion attacks; therefore, there
>   is no need to provide mechanisms to allow a responder to operate
>   statelessly at the MP_JOIN stage.
> 
> I would have liked to see some discussion in the security considerations
> about what probability of success an attacker has at brute-forcing this
> (as compared to port/sequence-number guessing attacks on plain TCP).

Whilst I’m not sure it’s directly comparable, we can add something like “This is in comparison to state exhaustion on a TCP port, where the port is typically already known, and SYN cookies can be deployed to aid in stateless operation.” although I am not sure this would add anything. I think saying anything like “this is 65536 times more secure“ would be disingenuous given MPTCP tokens are random but TCP ports are typically well-known.

>   Due to option space limitations, the HMAC included in the SYN/ACK is
>   truncated to the leftmost 64 bits, but this is acceptable since
>   random numbers are used; thus, an attacker only has one chance to
>   guess the HMAC correctly (if the HMAC is incorrect, the TCP
>   connection is closed, so a new MP_JOIN negotiation with a new random
>   number is required).
> 
> nit: I think this might be more clear if we clarified that this is "only
> one chance to guess the HMAC that matches the nonce previously sent by
> the peer" -- each party commits to a nonce before the HMAC is generated,
> and requires the received HMAC to match that nonce.

Thank you!

>   The key for the HMAC algorithm, in the case of the message
>   transmitted by Host A, will be Key-A followed by Key-B, and in the
>   case of Host B, Key-B followed by Key-A.  These are the keys that
>   were exchanged in the original MP_CAPABLE handshake.  The "message"
> 
> This is a little dicey in theory in terms of putting underlying
> structure in the HMAC key and the risk of related key attacks, but for
> SHA-256 I don't know of any specific hazards.  Key
> combination/derivation methods such as HKDF would alleviate this (mostly
> theoretical) risk, but given that the goal is "not worse than TCP" I
> don't see a need to insist upon them here.

Thanks for the pointer here. I think this would be inappropriate to introduce at this stage given lack of real-world experience and especially since the impact on “friendly” middleboxes may cause issues, and as you say is not required to meet our security goals. But it’s a great pointer for future evolutions of this spec.

>   If the HMACs are verified as correct, then both hosts have
>   authenticated each other as being the same peers as existed at the
>   start of the connection, and they have agreed of which connection
>   this subflow will become a part.
> 
> nit: there's not much notion of "identity" here, so I'd suggest using a
> verb like "verified" or "assured" rather than
> "authenticated", e.g., "both hosts have provided assurance to each other
> that they are the same peers as existed at the start of the connection”.

Thank you.

> Section 3.3
> 
>   The 'F' flag indicates "Data FIN".  If present, this means that this
>   mapping covers the final data from the sender.  This is the
>   connection-level equivalent to the FIN flag in single-path TCP.  A
>   connection is not closed unless there has been a Data FIN exchange,
>   or an implementation-specific, connection-level timeout.  [...]
> 
> Is this really appropriate to lave implementation-specific, since it
> could result in peers disagreeing about whether a connection is closed?

These kinds of issues happen all the time in TCP today as different implementations or network conditions may lead to ends timing out at different points. This will be discovered by the peer through a TCP RST. The text existed primarily to cover MPTCP scenarios equivalent to those found in TCP today. However, this text pre-dates the MP_FASTCLOSE method, which would be preferred in this environment, and so I’ve clarified this is a send timeout and also pointed to MP_FASTCLOSE as another option.

>                       The presence of the checksum can be inferred from
>   the length of the option.  If a checksum is present, but its use had
>   not been negotiated in the MP_CAPABLE handshake, the checksum field
>   MUST be ignored.  [...]
> 
> Why is ignoring better than RST-ing?  We abort on other cases of
> tampering, IIUC.

Hmm, I guess you could call this tampering (adding an unexpected field)! I think the rationale here was if an implementation for some reason misunderstood the negotiation, or was lazy and just checksummed everything, then a receiver should just not care. But for consistency it seems right to close the connection, so we can change that.

> Section 3.3.1
> 
>   The data sequence mapping specifies a mapping from subflow sequence
>   space to data sequence space.  This is expressed in terms of starting
>   sequence numbers for the subflow and the data level, and a length of
>   bytes for which this mapping is valid.  This explicit mapping for a
>   range of data was chosen rather than per-packet signaling to assist
>   with compatibility with situations where TCP/IP segmentation or
>   coalescing is undertaken separately from the stack that is generating
>   the data flow (e.g., through the use of TCP segmentation offloading
>   on network interface cards, or by middleboxes such as performance
>   enhancing proxies).  [...]
> 
> What happens if the resegmentation/coalescing causes the end of the data
> mapping to fall in the middle of a segment but checksums are not enabled?
> There's some discussion of this scenario in Section 3.7 and a note that
> the checksums would detect this but without checksums only a signal at a
> different layer would detect tampering.  It might be worth discussing
> the consequences (corruption in the application stream?) if no such
> signal is available.

Thanks for the thought. This kind of thing is implied in various places but it is probably worth spelling out. So I have added the following two sentences to this paragraph: "Without checksumming enabled, corrupt data may be delivered to the application if a middlebox alters segment boundaries, alters content, or does not deliver all segments covered by a data sequence mapping. It is therefore RECOMMENDED to use checksumming unless it is known the network path contains no such devices.<"

> Section 3.4.1
> 
>   Due to the proliferation of NATs, it is reasonably likely that one
>   host may attempt to advertise private addresses [RFC1918].  It is not
>   desirable to prohibit this, since there may be cases where both hosts
>   have additional interfaces on the same private network, and a host
>   MAY want to advertise such addresses.  The MP_JOIN handshake to
>   create a new subflow (Section 3.2) provides mechanisms to minimize
>   security risks.  The MP_JOIN message contains a 32-bit token that
>   uniquely identifies the connection to the receiving host.  If the
>   token is unknown, the host will return with a RST.  In the unlikely
>   event that the token is valid at the receiving host, subflow setup
>   will continue, but the HMAC exchange must occur for authentication.
> 
> nit: I don't think we actually specified that this is for the case of
> hosts on different private networks using the same private address
> range, so "unlikely event" comes as a surprise.

I don’t quite understand this comment. This text refers to a clash of 32-bit tokens (which are hashes and should be fairly random). If for the purposes of this exercise they are truly random, the probability of such a clash would be 1 in 2147483648 - that seems reasonably unlikely to me!

> Section 5
> 
>   original connection setup.  It also provides verification that the
>   peer can receive traffic at this new address.  Replay attacks would
>   still be possible when only keys are used; therefore, the handshakes
>   use single-use random numbers (nonces) at both ends -- this ensures
>   the HMAC will never be the same on two handshakes.  Guidance on
> 
> I think it's worth saying a bit more about the "single-use" property
> and that the party generating the nonce can discard it in bounded time,
> since the message reacting to the nonce will have aged out.
> On the other hand, generally when we use this sort of time-bounded
> mechanism with nonces we do still need to take steps to ensure
> consistent behavior within the replay window, e.g., cache the packet
> to ensure that any duplicates received are true retransmits and not
> an attacker having won a race with the real recipient.

Added a comment about nonce lifetime being in the lifetime of the TCP handshake.

>   The use of crypto capability bits in the initial connection handshake
>   to negotiate use of a particular algorithm allows the deployment of
>   additional crypto mechanisms in the future.  Note that this
>   negotiation would be susceptible to a bid-down attack by an on-path
>   active attacker who could modify the crypto capability bits response
>   from the receiver to use a less secure crypto mechanism.  The
>   security mechanism presented in this document should therefore
>   protect against all forms of flooding and hijacking attacks discussed
>   in [RFC6181].
> 
> Nit: the language used here is weird, since we "note that" there's an
> additional attack, but then conclude ("should therefore") that all
> attacks are covered.  So perhaps "nonetheless" is a better conjunction,
> to show that the remaining attack is not one discussed in 6181?

Thank you.

>   The version negotiation specified in Section 3.1, if differing MPTCP
>   versions shared a common negotiation format, would allow an on-path
>   attacker to apply a theoretical bid-down attack.  Since the v1 and v0
>   protocols have a different handshake, such an attack would require
>   the client to re-establish the connection using v0, and this being
>   supported by the server.  Note that an on-path attacker would have
>   access to the raw data, negating any other TCP-level security
>   mechanisms.  [...]
> 
> It is perhaps worth distinguishing between an on-path attacker that can
> freely modify/add/discard all traffic from one that can freely inject
> but not block traffic.

Most attacks against the MPTCP signalling would have to be on-path. Injection attacks would require being in-window with TCP sequence numbers so would need some on-path knowledge, or a very lucky guess. The additional security mechanisms on MPTCP signalling are designed to mitigate against these risks.

>   Whilst this specification defines a "medium" security solution,
>   meeting the criteria specified at the start of this section and the
>   threat analysis ([RFC6181]), since attacks only ever get worse, it is
>   likely that a future Standards Track version of MPTCP would need to
>   be able to support stronger security.  [...]
> 
> nit: this *is* a standards-track version; just "future version" will
> be fine.

Thank you.

> Appendix B.3
> 
>   Once this is done, the received cookie can be used for TFO, as shown
>   in Figure Figure 19.  [...]
> 
> nit: "Figure Figure" is redundantly redundant.  (Also in later
> references.)

Thank you.

> Appendix C.1.1
> 
>   Local.Token (32 bits):  This is the token chosen by the local host on
>      this MPTCP connection.  The token must be unique among all
>      established MPTCP connections, generated from the local key.
> 
> nit: I think this is "and is generated from the local key" -- the
> uniqueness is about all MPTCP connections on the host, not just
> those using a given key.  (This follows naturally from the deterministic
> procedure used to generate the token from the key, but we should still
> be precise with our language.)

And thanks again - much appreciated!

Best regards,
Alan