Re: [Anima] Magnus Westerlund's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS)

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 15 July 2019 09:41 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100A412006E; Mon, 15 Jul 2019 02:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 9hYInAUPDVjc; Mon, 15 Jul 2019 02:41:53 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150048.outbound.protection.outlook.com [40.107.15.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDAD120048; Mon, 15 Jul 2019 02:41:52 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ivKZacgu8YTWyQZ7eF0rYW2l8TUTYcuMkbO4jdk2X6uIpv/RCObvoX/UdMrt+N3jjWkDmsK6SETpeAuR/eysqaJmlTaM/89DALPJLQyNfV6lr4O1TsHRoKZgWnYKkeIybf/pFtYGJjnk9VYxFiQ3hl8+JrJS0MiIK3JDyqivFBjGxA8hyUOdSavyGmDDESNC66b9/bugSXD8w3oaolfBMHNuVj4GO3Vnq5rz+73D7t3Z6bYIZRJGSJqjqmtt5gTBzSgtjwdMR0HqS1JZkKRaocdt6kd60I1HXfSQJP3rx84juztDb/ZT2PRiRHZeyLRMOCyiHQoehSKlbG/Gjq/bZw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YOequ9GFO4OKKfyQbB6X+3p2IdSgGlIteq5Nb8HC2QI=; b=bMvCz2t4MyjBM89K2Da/kr0YdiGM5QVdwFgvUoYdkCzP5xFNUHHL2FLQwBtXEFalKlSCBg8LRw3W22mYQ4g5VOIQXj0/GE/wIouZPH6vwiVFcuSSP/wcLroleZsHXUC98SGd3d6EUjKiZAOuHElgKDifcaQE/FV/yJNKa+yaETNG898nFG+czq+UJDMsoXnPQjiYla4/fzo9s0GnHA54DJS9inrSGyhyYBSK6XkwTM+/FBU9wSNp0R5CmGhpmoZiM+guhi+d3r07AUOa+aZMzVisOJVoZJWz4StpgqtJa1ZkZdij6muQ1m2OZC/QF2aRufvjURTGAb9+fI6oiJAAgw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YOequ9GFO4OKKfyQbB6X+3p2IdSgGlIteq5Nb8HC2QI=; b=AeOnMv4QmBtE5hKZWdgxDz8qC7OTeJFmB5hS4W41+f4ztN6XtzdCZIEn189nlbZjC0dXEBZpcgVXNQ8UoerKbwScK1JZ+FYz5mGcGkLkwGNpfiLUUOxuaTAb6uW+oJSnEidLxFXGCP5cEE2Cjloc9sz4VXPyuUFc8np0+juCXyg=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2299.eurprd07.prod.outlook.com (10.168.126.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.7; Mon, 15 Jul 2019 09:41:49 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::3418:2814:2ee2:a22b]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::3418:2814:2ee2:a22b%4]) with mapi id 15.20.2094.009; Mon, 15 Jul 2019 09:41:49 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "mcr+ietf@sandelman.ca" <mcr+ietf@sandelman.ca>, "lear@cisco.com" <lear@cisco.com>
CC: "draft-ietf-anima-bootstrapping-keyinfra@ietf.org" <draft-ietf-anima-bootstrapping-keyinfra@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "anima@ietf.org" <anima@ietf.org>, "anima-chairs@ietf.org" <anima-chairs@ietf.org>, "tte+ietf@cs.fau.de" <tte+ietf@cs.fau.de>
Thread-Topic: [Anima] Magnus Westerlund's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS)
Thread-Index: AQHVN+5KUsbp8tUGhUekqxsnMkzX6qbI5VeAgAEK1wCAAYMAAA==
Date: Mon, 15 Jul 2019 09:41:49 +0000
Message-ID: <c18f3126ff68e002e5c09966190c7f541372811b.camel@ericsson.com>
References: <156285243815.32459.10845626927382447919.idtracker@ietfa.amsl.com> <17539.1563043297@dooku.sandelman.ca> <D9A4C31A-1A3D-471A-B92E-7FFAF93AF262@cisco.com>
In-Reply-To: <D9A4C31A-1A3D-471A-B92E-7FFAF93AF262@cisco.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com;
x-originating-ip: [192.176.1.86]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 84f8f666-7a2c-4b85-7ed0-08d70908a92f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:HE1PR0701MB2299;
x-ms-traffictypediagnostic: HE1PR0701MB2299:
x-microsoft-antispam-prvs: <HE1PR0701MB229999A7A63A22A31FD6F26895CF0@HE1PR0701MB2299.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00997889E7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(376002)(39860400002)(346002)(199004)(189003)(8676002)(8936002)(81166006)(81156014)(6436002)(2906002)(118296001)(7736002)(186003)(53936002)(36756003)(6246003)(66946007)(66616009)(66476007)(6306002)(6512007)(66066001)(2501003)(478600001)(86362001)(6486002)(25786009)(229853002)(5660300002)(71200400001)(4326008)(71190400001)(256004)(26005)(14444005)(68736007)(2616005)(76176011)(110136005)(446003)(11346002)(486006)(54906003)(44832011)(3846002)(6116002)(99286004)(476003)(6506007)(102836004)(53546011)(64756008)(66446008)(76116006)(66556008)(14454004)(99936001)(316002)(966005)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2299; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 0bRhFuCLN2hsIclsoPxHS5yFTgKpMMEPlLhkHBgRXZJ/SmzQmQlEE45SHvz7fe56xf9G/Fj5aaEp4lgx4STzZ6l9iNTzIy3rNKeXWz+SF+Uy5rMimV2CWmmg1wVPSb0FzUA0gLfRIshiljbRLunFSz4IX4fkRlWwFDVqGXAjb8r/AgR1akBZe19Z0YFhhiScf7ml87bZUHOJvEIiAdsgcxb4bifkfwI8nRJMPhKhIR5ERhGHijR1lZ4nKjbgTwCETT/G+HnfxLK+xJVEXYdhwWGZjJd7Xe3IYfaURmPVujNQWX0A77v152MtAdp7P4pndQQZR7LNahANxaiG51zVwmiDsXuRauw/0ZpqYUcyY2HUIEI+HSradM6Ge6Dcxnp4lSuIEKkqnkza7TwBSrS9Ry6Uq0UJjL2+b3NvXuQLdCc=
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-v3l51HeEnSBUiCnj654T"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 84f8f666-7a2c-4b85-7ed0-08d70908a92f
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2019 09:41:49.7835 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: magnus.westerlund@ericsson.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2299
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/gvKKFs0KGK6QzxW0u_A49yp8xR4>
Subject: Re: [Anima] Magnus Westerlund's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2019 09:41:56 -0000

Hi,

I will remove my discuss. As long as you have good reasons to have
dependenecies on a particular version of HTTP and TLS and transport
protocol that is fine with me. Just ensure that it is clear for the
different type of interactions what is the actual requirement. And if
there are no reason for having a specific dependency, then ensure that
is clear and that you still put in recommended version for
interoperability. 

Cheers

Magnus


On Sun, 2019-07-14 at 12:36 +0200, Eliot Lear wrote:
> Michael, Magnus,
> 
> I want to reinforce a point I made in that previous discussion about
> pledges using BRSKI with H2 (and by extension QUIC).  In this limited
> case, both present needless overhead both in terms of dev costs and
> COGS.  H2 in particular, and in this particular case, introduces new
> dev complexity because the provisional trust model used in BRSKI
> means that you cannot make use of multiple channels within the
> transport until at least the BRSKI transaction is complete.  And once
> it’s complete, and once EST is complete, the session is expected to
> terminate(*).  When BRSKI is in play, these transactions will happen
> lock step.
> 
> Eliot
> 
> (*) Keep in mind these protocols are used to establish network
> access.  A good analogy is that they are the language used to
> communicate at the gate with the security guard.  Typically one
> prefers that conversation to be short and to the point, so that one
> can get on with the business at hand.
> 
> 
> > On 13 Jul 2019, at 20:41, Michael Richardson <mcr+ietf@sandelman.ca
> > > wrote:
> > 
> > 
> > <#secure method=pgpmime mode=sign>
> > 
> > Magnus Westerlund via Datatracker <noreply@ietf.org> wrote:
> > > A. This is really a discuss discuss. With to little time to dig
> > > into
> > > the details it appears that this protocol is making i hack of its
> > > interface towards the its transport. It appears to attempt to use
> > > an
> > > HTTP rest interface, but then it is also have a lot of talking
> > > about
> > > requirement for the TLS connection underlying the HTTP. So to
> > > illustrate the issue I see here is what happens if one like to
> > > use QUIC
> > > as the underlying transport for the rest interface rather than
> > > TCP/TLS?
> > > So can this document achieve a clearer interface to the lower
> > > layers so
> > > that it will be simpler to move the protocol to another
> > > underlying
> > > version of the HTTP "transport"?
> > 
> > Between the JRC (Registrar) and the MASA, we can support any HTTPS,
> > including
> > HTTP/2 with QUIC (with the 'normal' corporate firewall issue with
> > UDP).
> > 
> > Between the Pledge and the Registrar, we support any HTTPS that
> > works over a
> > single TCP connection.  We can not support QUIC, since the Pledge
> > is behind
> > an intentionally limited proxy.  We had some discussion about this
> > a year or
> > so ago, please see:
> >  
> > https://mailarchive.ietf.org/arch/msg/anima/ml1OSEKhR4-ICS0Bd0zfuzn8uw4
> > 
> > You are certainly right: we have linkage between the TLS layer and
> > the
> > application layer, and we expect TLSClientCertificates and
> > TLSServerCertificates to have meaning at the application layer.
> > 
> > None of the connections could go through TLS "forced proxies" of
> > the kind
> > that are apparently common in Enterprises.
> > 
> > I am open to suggestions on how to make the document clearer about
> > how it
> > interfaces to TLS.  We have a sections:
> >    5.1.  BRSKI-EST TLS establishment details . . . . . . . . . . .
> >  36
> >    5.4.  BRSKI-MASA TLS establishment details  . . . . . . . . . .
> >  38
> > 
> > 
> > 
> > > B. Section 5.6:
> > > The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616]
> > > error
> > > code when a problem occurs.
> > > Referencing RFC 2616 that has been obsolete by RFC 7230 and
> > > companions. I do note that there are no normative reference for
> > > that
> > > part in this document.
> > 
> > Fixed to 7230.
> > Yes, that wasn't even a real reference, just a literal [RFC2616].
> > 
> > --
> > ]               Never tell me the odds!                 | ipv6 mesh
> > networks [
> > ]   Michael Richardson, Sandelman Software Works        | network
> > architect  [
> > ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> > rails    [
> > 
> > 
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software
> > Works
> > -= IPv6 IoT consulting =-
> > 
> > 
> > 
> > _______________________________________________
> > Anima mailing list
> > Anima@ietf.org
> > https://www.ietf.org/mailman/listinfo/anima
> 
> 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------