Re: [secdir] [Taps] Secdir early review of draft-ietf-taps-transport-security-04
Christopher Wood <christopherwood07@gmail.com> Wed, 27 February 2019 05:33 UTC
Return-Path: <christopherwood07@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E633C130E2E; Tue, 26 Feb 2019 21:33:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 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, URIBL_BLOCKED=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 Fvz7owjMh_xy; Tue, 26 Feb 2019 21:33:43 -0800 (PST)
Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 22B8812D4EC; Tue, 26 Feb 2019 21:33:40 -0800 (PST)
Received: by mail-yw1-xc29.google.com with SMTP id k14so7169880ywe.4; Tue, 26 Feb 2019 21:33:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=d1PRIgTVME4dLtjoPufWhRCZNNYWoTIfO7kQHxKjirQ=; b=AMi6JvyiVG8gn5bBriwD3I+4nOns8gLrXMGCWGQpjJxkufFtVg1vpQUr2jq9ub3Su3 QUefIHohbYBOjFYcJF3vYEJaS3xr7AofbyMPl6r4hijaCCtDGoh/ResoePoAMjmfdkIP ACXMnWXUVsgpcUYoG2j3B3czJo3dLmw2b9BtLdoI6Tl8QUSiO1rI/C3BMqDFEyZqQ504 8HntodNJCgBrwJ7Sr5C56ds1Oz8nukVMfNxVU/dn6VYJYWphRZm9HSXh9MZYoQn3Me5E T8r3ZoDZhbtZOB7y+85EFYvQMmlGdO1AM6WDjhC3dw0NVdRCqoWivoA0YlmeuwM36RHM p/jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=d1PRIgTVME4dLtjoPufWhRCZNNYWoTIfO7kQHxKjirQ=; b=saUpNvJ+f1wtFV6UKGQGFoypx3Tp9cAigm0JOPl9HdFVj2oQB7tjnNCF38oHux7YMq 1LRonByAOr4JcTAvNU76klWWzhDPa/sVD8jqD8ZUk8j0/L1B99ukOdWDSyGzq/saCpkL fF87I16qOsRIXZKj/wEA03ngEEfyluSqxdGkvwCSsxNeARYmpwNK9miLJy6o6dCFvOsc YPKKrYC4uCF2Ni8k7qeWjg557wHGkJqCydtoQ1WzCbE5YCSnbd7icmshSDcLUKkbTWPq H4Y68p3fXAnW0pyRSLXr3HKg20PJ/GblsGXzawDCjDiNFNy/03+V5acjSLa331EiqQeo 2S6Q==
X-Gm-Message-State: AHQUAuadSN8NDAXL/mmwpnddIqwyFK0a+GYn0lCA4BEBxiA+fGaUMYMb Gsnbk3QrB1QtVNW0Q4aoSaSC2rTQeEI1zfE7Cic7Is/w
X-Google-Smtp-Source: AHgI3IaT6N1Hi07uqA+URfVilYQsqxskDxGqLALTLD1js/YsLsWTDH4IbHZOkveaEhB5LHOH03yXb33kG44aaR29Myo=
X-Received: by 2002:a81:83c1:: with SMTP id t184mr21543529ywf.350.1551245619057; Tue, 26 Feb 2019 21:33:39 -0800 (PST)
MIME-Version: 1.0
References: <154321083813.24275.4373340388504093292@ietfa.amsl.com> <03808BD3-11AA-4010-9B8D-7E33EC1FE39B@gmail.com>
In-Reply-To: <03808BD3-11AA-4010-9B8D-7E33EC1FE39B@gmail.com>
From: Christopher Wood <christopherwood07@gmail.com>
Date: Tue, 26 Feb 2019 21:33:27 -0800
Message-ID: <CAO8oSX=36n3v0vnUxki8bVHs5_NE3K55Wn=UCUeiEqpvChASWA@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: secdir@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps WG <taps@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/UsHwhrc-SdEuCIFkk_yWz7sko70>
Subject: Re: [secdir] [Taps] Secdir early review of draft-ietf-taps-transport-security-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2019 05:33:47 -0000
Hi Paul, We just posted a revision to this document incorporating updates based on your comments [1]. (Thanks again for your careful review!) If you have time to check the diffs, we would greatly appreciate any more feedback you may have. Best, Chris [1] https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ On Mon, Dec 3, 2018 at 7:56 AM Christopher Wood <christopherwood07@gmail.com> wrote: > > (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.
- [secdir] Secdir early review of draft-ietf-taps-t… Paul Wouters
- [secdir] Secdir early review of draft-ietf-taps-t… Tero Kivinen
- Re: [secdir] [Taps] Secdir early review of draft-… Christopher Wood
- Re: [secdir] [Taps] Secdir early review of draft-… Christopher Wood
- Re: [secdir] [Taps] Secdir early review of draft-… Paul Wouters
- Re: [secdir] [Taps] Secdir early review of draft-… Christopher Wood