Re: [Taps] Secdir telechat review of draft-ietf-taps-transport-security-11

Tommy Pauly <tpauly@apple.com> Wed, 22 April 2020 17:40 UTC

Return-Path: <tpauly@apple.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 B60523A107A; Wed, 22 Apr 2020 10:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.92
X-Spam-Level:
X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 oIsNYnnfg3Oy; Wed, 22 Apr 2020 10:40:29 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A989A3A1085; Wed, 22 Apr 2020 10:40:28 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03MHKubf009136; Wed, 22 Apr 2020 10:40:27 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=vJ2b6JqtxWjFG+u9sMDweo9mmEjM58RJYgtSwdMi6j8=; b=MCIsuQViGhsylvm/vHzVxPxJ+kgibuO6VrAYCmxRziXxJqR4np+lqnaqsLBM4hjFKhos ATIWDajEl9HESPGpWLY7f/LqBhrfwzKJnAbtkiTV8tYaC53vNH+iPK5nCoB9nCRVNDqT q8aI2oqCu1D4nmLiCGCTLm8R1oBaFdHP2spTXnAtMS/EW9TYCPbZdtthubciKOCSrhec uiaEy3dwPbB0acrLijVhFtuIPychPwpT/ll3fhy1z2bwXwzig50bd4DVTPZsAqZo4iqj 3vPkzh/4nXDmWbwPbUDZ82H5rNbOLjzjXpOVe5DxizKIYXzr8+Twk26gQWu26QLc1RAA Og==
Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 30hfm8qg38-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Apr 2020 10:40:27 -0700
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q97007EYAFE4O40@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:40:26 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q97008009LCHV00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:40:26 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 87664f9d82f37ffc26ec7a9e377fbbd0
X-Va-E-CD: 7d5012b5022cd168c2069f5acb778cdc
X-Va-R-CD: 7dceb8163aa915c9fea3d2dc5ac00017
X-Va-CD: 0
X-Va-ID: bdeca734-cb6c-49b6-bdc4-53d326a446d7
X-V-A:
X-V-T-CD: 87664f9d82f37ffc26ec7a9e377fbbd0
X-V-E-CD: 7d5012b5022cd168c2069f5acb778cdc
X-V-R-CD: 7dceb8163aa915c9fea3d2dc5ac00017
X-V-CD: 0
X-V-ID: 7691e565-f993-4609-a630-8f1b3c4d2fa9
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0
Received: from [17.232.192.67] (unknown [17.232.192.67]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9700F9FAFBRC00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:40:25 -0700 (PDT)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <27E233E4-CD15-477C-9FE2-A6191ADB6E0F@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_04244C08-F17C-418C-A70D-EF7B04826354"
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\))
Date: Wed, 22 Apr 2020 10:40:23 -0700
In-reply-to: <158696570597.6243.17363184130849112053@ietfa.amsl.com>
Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org
To: Paul Wouters <paul@nohats.ca>
References: <158696570597.6243.17363184130849112053@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3608.80.7.2.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/0ysf2BaYc05gql99LH2S6gLOb30>
Subject: Re: [Taps] Secdir telechat review of draft-ietf-taps-transport-security-11
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: Wed, 22 Apr 2020 17:40:32 -0000

Hi Paul,

Thanks for the review! You can find an updated version of the document here:

https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html <https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html>

Responses inline.


> On Apr 15, 2020, at 8:48 AM, Paul Wouters via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Paul Wouters
> Review result: Has Nits
> 
> 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 Nits
> 
> Compared to my last review (-09) a lot of text has been removed, reducing the
> technical details and giving a briefer (but arguably cleaner) overview.
> 
> I do still have a personal preference of dropping CurveCP and MinimalT as I
> don't really think these are anything but abandoned research items. I have
> never seen or heard of these being deployed. I would be more tempted to list
> openconnect (draft-mavrogiannopoulos-openconnect) which actually does see quite
> some deployment. If the intent is really to show different kind of API's, than
> there are other esoteric examples that could be included, such as
> Off-The-Record(OTR) or Signal, which are mostly encrypted chat programs, but
> with the ability to generate session keys for encrypted bulk transport (eg for
> video/audio or file transfer)

We discussed for Signal and OTR. Our sense was that these protocols are more asynchronous application-layer protocols that are akin to MLS, that can be more independent from a transport layer.
> 
> Section 5.1
> 
> "Session Cache Management (CM):" which does not include IKEv2/IPsec, even
> though it does have session resumption (RFC 5723). I guess this is because the
> section limits itself to "the application" that can restart the session. But
> for IKEv2/IPsec the same could be said. An application that after a long idle
> period sends a packet, triggers a kernel ACQUIRE, which triggers an IKEv2
> session resumption. WireGuard does not have this capability as there are no
> API/hooks for packet trigger tunnel events (AFAIK)

Indeed, this refers to an explicit interface for cache management.

> 
> "Pre-Shared Key Import (PSKI):" lists WireGuard, but AFAIK it does not support
> PSK based authentication - only public key based authentication.

We discussed that WireGuard uses the IKpsk2 Noise pattern (see https://www.wireguard.com/protocol/, and https://noiseexplorer.com/patterns/IKpsk2/), in which a responder uses its PSK to additionally authenticate a connection.

> While I
> understand the IKEv2 entry (PSKs are used for authentication of peers), I am
> not sure the ESP entry should be here. ESP does not "authenticate peers",
> unless you call "being able to decrypt and authenticate packets" as an instance
> of "authenticating peer"

We’ve changed the reference to be IPsec as a unit for IKEv2 + ESP in these lists.

> 
> Section 5.2
> 
> This states "This can call into the application to offload validation.".  This
> "can" is only not supported by WireGuard, as all of this is happening inside
> the kernel. Maybe a note could be useful here?

Switched to "This can offload validation or occur transparently to the application."
> 
> "Source Address Validation" - It is a little unclear why TCP based protocols
> are not listed here. They (implicitly) do source address validation. Perhaps
> the introduction in this paragraph can state this more explicitly. Eg "for
> those protocols that do not use TCP and therefor do not have builtin source
> address validation ......."

We clarify here that:

"Of the protocols listed above that depend on the transport for message framing, some do have well-defined mappings for sending their messages over byte-stream transports like TCP.”

Thanks,
Tommy
> 
> 
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps