Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-protocol-security-requirements-14: (with DISCUSS and COMMENT)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 29 September 2016 12:10 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD2112B0A8; Thu, 29 Sep 2016 05:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.617
X-Spam-Level:
X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 6a_E6fXsWf_Y; Thu, 29 Sep 2016 05:10:19 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91E912B50C; Thu, 29 Sep 2016 05:09:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E53D6BE38; Thu, 29 Sep 2016 13:09:20 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2MLFz9GfOx9; Thu, 29 Sep 2016 13:09:20 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3F8D3BE2E; Thu, 29 Sep 2016 13:09:20 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1475150960; bh=GVNauLTMtOGkLqH7+8fR1nL5ekWlGgE/Ns9v91JnA0w=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=vBOU8ITKWV/wW7y8CRIVXfQs7KgoWLnO7fsP+80J5AITkxamzZd+fI634gmhGiJKF 8Pb2aT7UJVhPdgeqfSd45xeuorelunPhlGL1uUp4RKv2VL0S1ZNjiOZzJ3QVFMsacs xRBJYGoPWL26F9oZ+1a1XTYddyLD13qhWqhxtys8=
To: Susan Hares <shares@ndzh.com>, 'The IESG' <iesg@ietf.org>
References: <147509830903.16624.17764292480373284772.idtracker@ietfa.amsl.com> <000301d21a49$d5d72ff0$81858fd0$@ndzh.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <fbf0f00d-bd37-c508-8b2b-6367c5565f8c@cs.tcd.ie>
Date: Thu, 29 Sep 2016 13:09:20 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <000301d21a49$d5d72ff0$81858fd0$@ndzh.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070106090705060803030205"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/ovsesbylklGGznD33nhq-t1Cq4g>
Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org
Subject: Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-protocol-security-requirements-14: (with DISCUSS and COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Sep 2016 12:10:39 -0000

Thanks Sue,

That wording is fine and I've cleared.

Cheers,
S.

On 29/09/16 13:05, Susan Hares wrote:
> Stephen: 
> 
> Version 15 has the following added: 
> 
> SEC-REQ-16:  The I2RS protocol makes use of both 
> secure and insecure transports, but this use MUST NOT be 
> done in any way that weakens the secure transport protocol
> used in the I2RS protocol or other contexts that 
> do not have this requirement for mixing secure
> and insecure modes of operation.  
> 
> I tweaked the English in your text.  Does this satisfy your discuss?  If so, will you remove your DISCUSS.   I am working on version -16 to resolve your comments. 
> 
> 
> Sue Hares 
> 
> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] 
> Sent: Wednesday, September 28, 2016 5:32 PM
> To: The IESG
> Cc: draft-ietf-i2rs-protocol-security-requirements@ietf.org; Jeffrey Haas; i2rs-chairs@ietf.org; jhaas@pfrc.org; i2rs@ietf.org
> Subject: Stephen Farrell's Discuss on draft-ietf-i2rs-protocol-security-requirements-14: (with DISCUSS and COMMENT)
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-i2rs-protocol-security-requirements-14: Discuss
> 
> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> Thanks for the major revision, this is a lot better.  I have one discuss point and a bunch of comments.
> 
> The discuss is: I think it's an error to mix the secure and insecure transports in one set of protocol requirements. And I would definitely put a DISCUSS on any protocol solution that aims to weaken the security of e.g. port 443 or equivalent. In other words, I think you need to rule out any protocol solutions that weaken the secure transports that you are re-using. I therefore suggest adding a new requirement along these lines:
> 
> "SEC-REQ-NN: While I2RS might need to make use of both secure and insecure transports, this MUST NOT be done in any way that weakens the secure transport protocol, either as used in I2RS, or especially not as used in other contexts that do not have this requirement for mixing secure and insecure modes of operation and that depend on security being as good as we can provide."
> 
> So I'd like to discuss adding the above or similar.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> 
> - The topic of marking things as allowing insecure read access has been discussed a lot so I won't get into it again.
> 
> - section 4: "Data passed over the insecure transport channel MUST NOT contain any data which identifies a person or any "write" transactions." I don't get what identifying a write transaction might mean?
> 
> - 4.1: "AAA protocols MAY be used to distribute these identifiers, but other mechanism can be used." If I'm doing TLS with mutual-auth, then I need a private key and certificate. I don't think AAA protocols can transport those (and they probably ought not) so I'm not sure what's meant here.
> 
> - 4.2: What do "valid identity" and "valid identifier" mean?
> If the same then use the same terms. But I think you need to define "validity" or else say that work needs to be done later. 
> 
> - 4.3: I think you're saying here that the i2rs client is trusted to simply assert the secondary identifier. If so, then saying that would be good. If not, then I don't know what you mean.
> 
> - 4.4: I still don't see why it'd not be better to use a different protocol for the non-secure stuff and avoid all the potential discussion and pitfalls of trying to do all this in one protocol.
> 
> - 4.4: "It is mandatory to use (MTU) on any I2RS client's Write transaction or the configuration of an Event Scope transaction." Which "it" do you mean?
> 
> - 4.4: The BCP107 stuff is still not useful.
> 
> - 4.5: "detect when the data integrity is questionable" - I've no idea what that means. Nor what it could mean.  Can you explain?
> 
> 
>