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

[Christopher Wood <[e-mail]>]

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
<[e-mail]> 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.