Re: [Ace] Embedded Content Types

"Panos Kampanakis (pkampana)" <pkampana@cisco.com> Fri, 22 February 2019 03:21 UTC

Return-Path: <pkampana@cisco.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B73912F295 for <ace@ietfa.amsl.com>; Thu, 21 Feb 2019 19:21:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 jGwqn5CgapnK for <ace@ietfa.amsl.com>; Thu, 21 Feb 2019 19:21:17 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19646128B33 for <ace@ietf.org>; Thu, 21 Feb 2019 19:21:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4964; q=dns/txt; s=iport; t=1550805677; x=1552015277; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=W6oyGp+MxA2xjvb5HQPPWLZABc3ixEMaoWjTX2/pMDw=; b=N7B83xkcmDzodMuq1lGdi5KEdlPTNONukbfCnhKJLyPTSAjcmeRp9e3q Lrd1wEvwZWRSSqof9yh00Mo9vtutQfbf08TZADm4dGQnEZMijRtjSjXk1 w7EhlvP+6LpH9jWkbd/FHvJRqYa2KtQPNq7VGvQd/rAbPdlv1caKbI4Tv E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAAcam9c/4UNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBgVQvgWonCoN9lX2DRZRZgXsLAQGEbAI?= =?us-ascii?q?Xg2MiNQgNAQMBAQIBAQJtKIVKAQEBAQMjEUUMBAIBBgIOAwQBAQECAiYCAgI?= =?us-ascii?q?wFQgIAgQBDQUIhQuQMZthgS+KMYELiz0XgUA/g241hGuDH4JXAqNTCQKSVCG?= =?us-ascii?q?TC4pJkgcCERSBKCEBNYFWcBWDJ5BdQTGObIEfAQE?=
X-IronPort-AV: E=Sophos;i="5.58,397,1544486400"; d="scan'208";a="240227523"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2019 03:21:16 +0000
Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x1M3LFRY017313 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Feb 2019 03:21:16 GMT
Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Feb 2019 21:21:15 -0600
Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Thu, 21 Feb 2019 21:21:15 -0600
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: Jim Schaad <ietf@augustcellars.com>, "'Carsten Bormann'" <cabo@tzi.org>
CC: "'ace'" <ace@ietf.org>, "'Klaus Hartke'" <hartke@projectcool.de>
Thread-Topic: [Ace] Embedded Content Types
Thread-Index: AdTJQwabXPaUkoDzRkqcz/D5vJfkVwAH1C+AABSNAYAACQoogAAiZMuAAAwKIdD//6n5gIAABfcAgAAL6ICAACd+QA==
Date: Fri, 22 Feb 2019 03:21:15 +0000
Message-ID: <3c160f55d99d43368a319c041d6eadc8@XCH-ALN-010.cisco.com>
References: <02a201d4c945$eb10a510$c131ef30$@augustcellars.com> <17e617f1090e451c8b17f6550c2e213a@XCH-ALN-010.cisco.com> <CCD28BCC-16AA-492B-8E14-DAE9F2CF2E3C@tzi.org> <38fa1ec646974a329c286279b3fa9ff0@XCH-ALN-010.cisco.com> <032f01d4ca2f$ff19c6a0$fd4d53e0$@augustcellars.com> <b4bb6e5f3c7c47ffa040389f000f027f@XCH-ALN-010.cisco.com> <033201d4ca35$23f58f40$6be0adc0$@augustcellars.com> <6F0FAFC5-947C-4B8E-B83F-82D68750A80A@tzi.org> <033301d4ca3e$14130180$3c390480$@augustcellars.com>
In-Reply-To: <033301d4ca3e$14130180$3c390480$@augustcellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.243.182]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/tijGrcYQP00WWCtspYp2w1b2xTo>
Subject: Re: [Ace] Embedded Content Types
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Feb 2019 03:21:19 -0000

That comes with a set of problems. A simplification needs to take place. It is probably better to just mandate one content-type for cert to get away without complicated combined content types. We don't need to support TBD287 and 281 in the embedded responses. It makes more sense to not do so. 

As for why, there are a three reasons I can think of: 
1) Two separate URIs means we are adding state tracking for the CA. The CA now needs to support 
- EST that says "give me the key and a cert all at once and then forget about it".
- EST-coaps that says "give me a key. Remember this key/cert pair and serve the certificate until I decide to come back and get it". Now imagine I have 10000 of endpoints enrolling. The server keeps state for all of them and cannot forget them until he gets the equivalent requests. And then, what happens if a cert is lost on the way back? The CA is supposed to remember the key / cert for some time. There is a DoS vector right there. 

2) One more challenge with two URIs is that the client needs to somehow signal in the 2nd request to the server to tell him what key/cert he is expecting to get, so there is one more new thing the client now needs to do. 

3) Additionally, it sounds like we are doomed with the discovery. The server cannot tell the client what embedded types he supports, thus the client will just try asking different combinations until he gets a response.

That is why I think two URIs are a bad idea. A query type may be OK, but I can see Carsten and Klaus' point. We can just keep one cert content type in the multipart, that simplifies it. 

Rgs,
Panos

-----Original Message-----
From: Jim Schaad <ietf@augustcellars.com>; 
Sent: Thursday, February 21, 2019 6:35 PM
To: 'Carsten Bormann' <cabo@tzi.org>;
Cc: Panos Kampanakis (pkampana) <pkampana@cisco.com>;; 'ace' <ace@ietf.org>;; 'Klaus Hartke' <hartke@projectcool.de>;; draft-ietf-ace-coap-est@ietf.org
Subject: RE: [Ace] Embedded Content Types

It is true that the query parameters are part of the type.  However, the use of two different URIs allows for the discovery to figure out if both versions are supported rather than having either a failure occur because the query parameter is not supported or getting the wrong answer back because it is not looked for.

Jim


> -----Original Message-----
> From: Carsten Bormann <cabo@tzi.org>;
> Sent: Thursday, February 21, 2019 2:52 PM
> To: Jim Schaad <ietf@augustcellars.com>;
> Cc: Panos Kampanakis (pkampana) <pkampana@cisco.com>;; ace 
> <ace@ietf.org>;; Klaus Hartke <hartke@projectcool.de>;; 
> draft-ietf-ace-coap- est@ietf.org
> Subject: Re: [Ace] Embedded Content Types
> 
> On Feb 21, 2019, at 23:31, Jim Schaad <ietf@augustcellars.com>; wrote:
> >
> > I am thinking of two different URLs, that is not do the difference 
> > by a query
> parameter but by changing the URI.
> 
> Note that the query parameters are part of the URI, so fundamentally 
> there is no difference between putting the info there or in the path 
> part of the URI.
> 
> The path part can be slightly more concise.  We are more used to 
> “computing” the query part.  I don’t have a strong preference.
> 
> But in either case it is good if discovery can find the URI being 
> offered (including its query parameters, if those are used).
> 
> (And I agree that the “ct” target attribute really is for the top 
> level media type; of course we could invent a new target attribute 
> “ect” for embedded content formats [and fight against autocorrection 
> for the rest of our lives :-
> )].)
> 
> Grüße, Carsten