Re: [Taps] Secdir early review of draft-ietf-taps-transport-security-04

"Christopher Wood" <christopherwood07@gmail.com> Mon, 03 December 2018 15:56 UTC

Return-Path: <christopherwood07@gmail.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896C112D7EA; Mon, 3 Dec 2018 07:56:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 nGCgktNJ1Na0; Mon, 3 Dec 2018 07:56:51 -0800 (PST)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 4FC9C12872C; Mon, 3 Dec 2018 07:56:48 -0800 (PST)
Received: by mail-pf1-x42f.google.com with SMTP id i12so6566476pfo.7; Mon, 03 Dec 2018 07:56:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=1lMlPtAp+8IdY/z8sJ1+V6xXO5Tzdo7NMqHAIojWqO4=; b=dqMtXowbN/JYhfPCQIBKyG1xDw43cIBR3VgrukhMUQkA667e4NM0hp3zZWIchoKn71 mGa/kcGmwuUc1vab3zBhpoTbI0ADs10juYWxGlWQY3B5rgZPgdhizV6kSFIi1nzuDbrg hfoRcJH7UQ5Oerh8kWMeOPDdviHuJs3qf5wzV9corMEs2s8Pff67PQm2+y/UCjgNhxgj fhO+f5Hxn5AJxDIU0VnCRKubhCUdI/w5sNaknzlKLLXWT3//KRxuShWQ6FmHWDIJ6eqd IwhEw179k0mdWtdtqbqJDowiY22pDe6heWQNKv8LnurQuR7eZdumasP6UwHKwoC880// Sk/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1lMlPtAp+8IdY/z8sJ1+V6xXO5Tzdo7NMqHAIojWqO4=; b=HHcDJ7JNBXIj/olzXb9EoNha6DaZueoYJbFp5PIdl9wo8exDYKzhgF44WMGPR63zE1 DqpJcqwDkkfOi3sOpuAKW14yguZZWJ9aAOt1/8zlG/zb6+3siWZFDrWMqbtSVabLDl3R At/2C6vXORF1nshJ/1b28KtxmtI3TvUNYBiNxZ0fLuf6GR9312SrvOsfRCSEkx3nli44 J7fnlqfJEVFFaWJq7O3nS07V9lRxSdkbPYPufyyHp1vpirsl43tZhTHigUkiGB0tt8YB f+8bDmkEAOMinl1NeA2Map3w4qDJvmJWkIQcNNIriv9WK+W3LFcF62Uf1OfeiQn3F3Sd 86pA==
X-Gm-Message-State: AA+aEWZVQSs/DNUQMxm0LGCoGHLGsS0FtkW8NfYsVet/hNOu64aOwZE+ OSmZyrCcY8p+SNjgOCkq5Ef0BYCj
X-Google-Smtp-Source: AFSGD/WKas2m+mZxRaaVrclNwj9qvCBc3w71hP+rodNXZbpeXyRczcw5XKuuGM9ZNGw6wOl2Ai7kBg==
X-Received: by 2002:a62:e0d8:: with SMTP id d85mr16087369pfm.214.1543852607469; Mon, 03 Dec 2018 07:56:47 -0800 (PST)
Received: from [172.16.33.70] ([144.178.28.6]) by smtp.gmail.com with ESMTPSA id c23sm20137870pfi.83.2018.12.03.07.56.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Dec 2018 07:56:46 -0800 (PST)
From: Christopher Wood <christopherwood07@gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: secdir@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org
Date: Mon, 03 Dec 2018 07:56:45 -0800
X-Mailer: MailMate (1.12.2r5568)
Message-ID: <03808BD3-11AA-4010-9B8D-7E33EC1FE39B@gmail.com>
In-Reply-To: <154321083813.24275.4373340388504093292@ietfa.amsl.com>
References: <154321083813.24275.4373340388504093292@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/osfFEcKQn2ySbz_yh91Qt8hkIhQ>
Subject: Re: [Taps] Secdir early review of draft-ietf-taps-transport-security-04
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Dec 2018 15:56:54 -0000

(ietf to bcc to minimize spam)

Hi Paul,

Thanks for the feedback! Please see inline below.

On 25 Nov 2018, at 21:40, Paul Wouters wrote:

> Reviewer: Paul Wouters
> Review result: Has Issues
>
> Review of draft-ietf-taps-transport-security-04
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> The summary of the review is HAS ISSUES.
>
> SecDir tools note: The secdir review link refers to an abstract 
> containing the
> text:
>
>         This draft summarizes a number of IETF transport security 
> protocols a
>
> Note the word "IETF ... protocols". I don't actually see that in any 
> of the
> revisions 00 to 04? Where did this comment/text come from?

As Spencer noted, it likely originated from the early review request.

>
> Reading the introduction, this draft's goal is:
>
>    This document provides a survey of commonly used or notable network
>    security protocols, with a focus on how they interact and integrate
>    with applications and transport protocols.  Its goal is to 
> supplement
>    efforts to define and catalog transport services [RFC8095] by
>    describing the interfaces required to add security protocols.
>
> My first comment is regarding "commonly used or notable". Especially
> the latter one is odd. Why should the IETF reader be aware of
> "notable" but "not commonly used" protocols? And the reason I
> say this is because it lists CurveCP and MinimalT, which as far
> as I know are not deployed at all. While openvpn, which has a
> serious userbase, is not mentioned at all. And openconnect, an open
> specification compatible with Cisco Anyconnect, which even has a 
> draft,
> draft-mavrogiannopoulos-openconnect-02, is not mentioned at all. In my
> opinion, the document would be improved by adding Openvpn and 
> Openconnect,
> and removing CurveCP and MinimalT.
>
> My second comment is regarding IETF vs non-IETF protocols. Or even
> "specified in a draft or RFC" versus "there is an academic paper and 
> some
> implementation and it's not clear what's what". The reason I am saying
> this is that for instance the protocol "specification" of WireGuard 
> keeps
> changing. Their website lists a "whitepaper" that is changing over 
> time
> with no changelog, and wild claims that I've spend time in the last 
> few
> years to counter, upon which it gets rewritten with new misleading or
> wrong claims.
>
> It is kind of hard to do an IETF style summary of protocols when the
> "specification" includes phrases like:
>
>         the tunnel simply works. Key exchanges, connections, 
> disconnections,
>         reconnections, discovery, and so forth happen behind the 
> scenes
>         transparently and reliably, and the administrator does not 
> need to
>         worry about these details. In other words, from the 
> perspective of
>         administration, the WireGuard interface appears to be 
> stateless.
>
> This is not a white paper but a Public Relations document.
>
> None of the other discussed protocols in this document require
> administrators to "worry" about those "details" either.
>
> At the IETF, we recommend IETF protocols. If someone comes up with an
> alternative protocol that accomplishes the same as an existing one, we
> tend to tell people to use the existing IETF protocol instead. Or, we
> think their new protocol merits further standarization, and we ask 
> them
> to produce either a ISE or IETF stream document that people can 
> reference,
> comment, improve and discuss openly on its technical merits.
>
> It is also clear the white paper is not a good complete formal
> specification like we do at IETF. For example, if there is packetloss,
> the "specification" does not at all specify which of the parties (or
> both?) are responsible for retransmission. Can one spoofed packet lead
> a WireGuard endpoint to retransmit its response repeatedly?
>
> This further weakens their "stateless" claim. (and if it sounds like I
> am being harsh, I know I am. It is because previously, I had to 
> counter
> false claims about IPsec speed, and IKE "being noisy" where as having
> looked again at "the whitepaper" (which keeps changing every time I 
> look
> at it) it seems to now have a new hobby horse in the word "stateless". 
> the
> openvpn tun0: is also "stateless", so is the VTI IPsec based interface 
> vti0:
>
> Because of these reasons, I am a bit worried that an IETF document is
> making any claims about WireGuard features, as there is no way to know
> what the protocol will be like by the time this document is published,
> and this document cannot even point to a stable reference of te 
> specification
> at the time of review.
>
> If this document wants to mention WireGuard as a protocol to take note 
> of,
> I would like to see at least some text there urging WireGuard to write 
> up
> (and version) their protocol in an IETF draft/RFC or other 
> proper/formal
> specification.
>
> Now, having said all of this about WireGuard, I do agree with 
> mentioning
> WireGuard in this document as it does have an actual userbase. Let's
> just urge and help them with their specification.  (and If the 
> author(s)
> of WireGuard are reading this, I am more than happy to help you with 
> this)
>
> As for CurveCP and MinimalT, as far as I can see, these  are just 
> academic
> exercises with no serious deployment. While the IRTF might be 
> discussing
> the these, I don't think an IETF document should reference these two
> proof of concept ideas until they have matured more.

Protocol selection criteria was admittedly sort of ad-hoc in the 
beginning. For starters, we included CurveCP and MinimalT because they 
are unique in one way or another in contrast to the other protocols 
considered. We then included WireGuard specifically because of its 
(growing) popularity. And while it continues to grow, we are careful to 
ensure the core feature set described remains stable. The informal 
criteria we’ve established now is that any new protocol must bring 
something new to the table. For example, we added protocols such as SRTP 
because they had features not yet covered by other protocols.

That said, we can certainly add OpenVPN and OpenConnect to round things 
out. Though I see no issue with including CurveCP and MinimalT. As 
stated in the introduction, this document is not restricted to IETF 
protocols. Rather, it aims to survey any protocol that might influence 
the API surface exposed. It is our opinion that the set of protocols 
included meets this goal. If necessary, we can move the more esoteric 
protocols to the appendix, though we should certainly not remove them 
for lack of a specification.

>
> Introduction / Abstract:
>
> Expand/explain TAPS on first use?
>
> Section 4.4.1.1:
>
>         IKEv2 is a control protocol that runs on UDP port 500
>
> Change to:
>
> IKEv2 is a control protocol that runs on UDP or TCP port 4500 and UDP 
> port 500.
>
> Note you don't mention the one big drawback, that it cannot be run on 
> any UDP
> port (although at least now we can run on any TCP port) which is an 
> important
> problem when networks block IKE/IPsec on purpose compared to non-IETF 
> VPN
> protocols.
>
>         It then
>         goes through a phase of authentication in which both peers 
> present
>         blobs signed by a shared secret or private key, after which 
> another
>         set of keys is derived, referred to as the "Child SA".  These 
> Child
>         SA keys are used by ESP.
>
> This text makes it appear only the blob's are authenticated, but the 
> entire
> IKE exchange is authenticated. Also sessions keys are not all that is 
> a
> Child SA. So perhaps:
>
> IKE then
> performs a phase of authentication in which both peers present
> blobs signed by a shared secret or private key that authenticates
> the entire IKE exchange and the IKE identities. IKE then derives
> further sets of keys on demand, which together with traffic policies
> are referred to as the "Child SA". These Child SA keys are used by 
> ESP.
>
>         Each proposal may contain an encryption algorithm, an 
> authentication
>         algorithm
>
> This is a bit misleading with both the "may" and the lack of AEAD 
> discussion?
> Perhaps:
>
> Each proposal contains an encryption with authentication algorithm or 
> an AEAD
> algorithm,
>
>         Any SA used by IKEv2 can be rekeyed upon expiration,
>
> Rekeying happens before expiration, not upon (which would imply 
> trafficflow
> interuption) Similarly to how it is described for tcpcrypt in the 
> document. So
> perhaps just change "upon" to "before" ? Or go in a little more detail 
> with:
>
> Any SA used by IKE/IPsec can be rekeyed before expiration. It does so 
> by
> negotiating a second SA, and once confirmed up and running, the old SA 
> is
> deleted. This guarantees there is no slowdown or halt of traffic flow 
> during
> rekeying.
>
>         that allows a set of Security Associations to migrate over 
> different
>         addresses and interfaces
>
> I would say "different outer IP addresses and interfaces"
>
>         Each SA is
>         identified by a Security Parameter Index (SPI), which is 
> marked on
>         each encrypted ESP packet.
>
> I would avoid the word "mark" here, since to me that more presents 
> internal
> state inside a kernel (eg iptables MARK) and not something that goes 
> over the
> wire. So perhaps:
>
> The SA of an encrypted packet is identified by its Security Parameter 
> Index
> (SPI) [which is send as part of the ESP header)

These are all great suggestions! We will include them.

>
>         an anti-replay service (a form of partial sequence integrity)
>
> What is partial about this? Perhaps you meant to say ESP, like UDP, 
> does not
> provide guaranteed delivery? Anyway, a "partial" security function 
> reads odd :)

This is quoted text from RFC4303.

>
>         and limited traffic flow confidentiality.
>
> What is "limited" about it? You can generate bogus traffic and pad 
> traffic to
> any size (most common max mtu). What would you want in additional to 
> make it
> not "limited" ?

This text is also quoted from RFC4303, so we left it as is. Though I 
think your suggestions point to what the authors are leading towards: 
traffic analysis.

>
> One thing I would add to the ESP section is mentioning it acts like 
> UDP. It
> cannot be reset by a single TCP RST packet, and you don't have two 
> layers of
> netflows doing retransmission. This feature of ESP (and some UDP based
> protocols in this document) is fairly important.
>
> Section 4.4.2.1:
>
>         Mutual Authentication
>
> It is possible to do server-only or opportunistic/anonymous IKE as 
> well. Maybe
> add "Usually" ?

ACK — will do.

>
> 4.6.1:
>
>         Tcpcrypt exposes a universally-unique connection-specific 
> session ID
>         to the application, suitable for application-level endpoint
>         authentication either in-band or out-of-band.
>
> This kind of conflicts with the introduction that claims this is only 
> an
> opportunistic encryption protocol? Maybe merge this part into the 
> description
> text?

Good observation. Yes, that is misleading. We’ll try to fix it.

>
> 4.6.2:
>
> I might say here something about only passive attacker protection? 
> That seems
> like an important difference compared to the other protocols. Or 
> perhaps make
> this clear in the introduction text when mentioning opportunistic 
> encryption.

Yes, good point. We’ll fix that.

>
> 4.7:
>
>         WireGuard is a layer 3 protocol designed to complement or 
> replace
>         IPsec [WireGuard] for certain use cases.
>
> I am confused about how it "complements" IPsec? Perhaps you mean it is 
> an
> "alternative" (and perhaps a non-IETF alternative) ?
>
> I think "replace" is very misleading, as IPsec has a vast number of 
> different
> use cases compared to WireGuard's "static VPN configuration".

Yes, we should drop “to complement or replace” and say that it’s 
an alternative.

>
>         WireGuard is designed to be entirely stateless, modulo the 
> CryptoKey
>         routing table,
>
> Wouldn't you be able to say the same about the ESP SPD/SAD table? I'm 
> not sure
> how different the ESP/wireguard statelessness is on a scale or truly 
> stateless
> to NFS
>
> You don't mention anything about port preconfiguartion and the "port 
> knocking"
> thing?
>
>            o  Record replay prevention (Stateful, timestamp-based).
>
> I thought it was stateless module CryptoKey routing? :)
>
> You do not mention mobility or session resumption for WireGuard. Since 
> it is
> all about static inner IP addresses over arbitrary outer addresses, it 
> has
> mobility. And I guess the 1RTT means it has session resumption?
>
> Can you add a description of rekeying for WireGuard similar to 
> IKEv2/ESP? I
> thought there was an issue there that during rekey, there is no 
> continued data
> flow possible, so connections briefly slow down or halt when the 
> channel is
> being rekeyed.

I’m on the fence about this suggestion (and about keeping the 
IKEv2/ESP rekeying text). Some of the feedback we’ve received thus far 
is that the internal protocol details are irrelevant to the overall 
story. Rekeying might fall in that category. We’ll play with it and 
see if we can find a happy medium.

>
> Does WireGuard not offer padding or any other kind of Traffic 
> Confidentiality
> options ?

As far as I know, it does not.

>
> 4.8:
>
> The MinimalT section seems to lack some information bullet points 
> compared to
> the other sections? eg shouldn't it have things like:  o Datagram 
> Transport ?

Indeed! This section needs some improvement.

>
> Misc:
>
> Should tor be added to the list of protocols?

We hadn’t considered it, though it might be worth including. If we can 
find a new feature not yet exposed by the others, then yes, by our 
criteria outlined above.

>
> Why are MinimalT and CurveCP part of this list? Is there any actual 
> deployment
> out there? I thought this document described actual transport security
> protocols people can pick. I don't see CurveCP as a real candidate for 
> this. I
> don't know about MinimalT.

As stated above, ease of use or popularity in practice is not the only 
filter we used. I’m therefore inclined to keep these.

>
> 5:
>
> I'm a little confused by the term Application in this section. Is this 
> the
> enduser application or the userland part of the security protocol (eg 
> IKE). I
> think you mean the application of the enduser?

Yes, the application of the enduser.


>
> 5.1:
>
> Listed as mandatory feature is:
>
>    o  Public-key certificate based authentication.
>
> Yet you have mentioned that neither WireGuard or CurveCP can do 
> authentication
> based on certificates?

Indeed. This should read, “Public-key (raw or certificate) based 
authentication.”

>
> 5.2:
>
>         o  Length-hiding padding (LHP):
>
>             *  Application dependency: Knowledge of desired padding 
> policies.
>
> This is not (always?) true? For example ESP can do padding after IKE 
> negotiated
> it, and do it based on MTU ? The (end user) application does not have 
> to be
> aware of anything?

That’s a fair point, though (in my view) padding without application 
input seems incomplete. Perhaps we can rephrase this to:

   “(Optional) Application dependency: Knowledge of desired padding 
policies. Some protocols, such as IKE, can negotiate 
application-agnostic padding policies.”

>
> 5.3:
>
> The definition of "Mandatory" within this section is confusing. Maybe 
> use
> another word like "Core" to indicate it is part of the core of the 
> protocol and
> cannot be disabled?

We used mandatory to be consistent with the section above.

>
> NITS:
>
> spelling error: defailt

Oops. Will fix!

Thanks again for your careful review and feedback. We greatly appreciate 
it.

Best,
Chris et al.