Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Jim Schaad <ietf@augustcellars.com> Mon, 09 September 2019 20:17 UTC

Return-Path: <ietf@augustcellars.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 EA5A1120048; Mon, 9 Sep 2019 13:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 wkwevn1kNuA5; Mon, 9 Sep 2019 13:17:57 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91C4E1200C7; Mon, 9 Sep 2019 13:17:56 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 9 Sep 2019 13:17:29 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Michael Richardson' <mcr+ietf@sandelman.ca>, 'Benjamin Kaduk' <kaduk@mit.edu>
CC: <draft-ietf-ace-coap-est.all@ietf.org>, <ace@ietf.org>
References: <20190828233639.GI84368@kduck.mit.edu> <027701d55ebf$994184b0$cbc48e10$@augustcellars.com> <edcbc2a243cc7118e35aec77b2e1599c@bbhmail.nl> <20190901204340.GG27269@kduck.mit.edu> <6b482aaed0ce510c503984dfbac7286c@bbhmail.nl> <7cd78133c263214be535ec36734f7ec1@bbhmail.nl> <30070.1568030052@dooku.sandelman.ca> <20190909144232.GH18198@kduck.mit.edu> <7801.1568047103@dooku.sandelman.ca>
In-Reply-To: <7801.1568047103@dooku.sandelman.ca>
Date: Mon, 9 Sep 2019 13:17:27 -0700
Message-ID: <007901d5674b$9bc75e00$d3561a00$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIXV+tDlosvqNImECv+N/+Ud7Gh2wKJlQMAAbM3AHgCj7Ug0QK+5t/8AjJ0tzcB31OHDwIOvfELAeARbzumE4bhUA==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/-UwNtJ3YFvK19z9wxijE873zYDo>
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
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: Mon, 09 Sep 2019 20:17:59 -0000


-----Original Message-----
From: Michael Richardson <mcr+ietf@sandelman.ca>; 
Sent: Monday, September 9, 2019 9:38 AM
To: Benjamin Kaduk <kaduk@mit.edu>;
Cc: draft-ietf-ace-coap-est.all@ietf.org; ace@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2


Benjamin Kaduk <kaduk@mit.edu>; wrote:
    >> So, on a constrained device, I'd like to know what to expect (what to
    >> code for).  While I do'nt particularly care for server-generated
keys,
    >> it should probably be specified correctly.  I see that the complexity
    >> of sorting this means that I think that Content-Format 284
    >> (unprotected) will get used most often.

    > Your constrained device is probably only going to implement one cipher
    > [mode], too, right?  If it's an AEAD mode, you use AuthEnvelopedData;
    > otherwise, classic EnvelopedData.

Yes, but each constrained device type might have a different set, and the
EST server for such an installation has to figure out how to send the right
thing.

[JLS] This is the function of section 4.4.1.1 in RFC 7030 which says that
the DecryptKeyIdentifier must be present.  This will provide the EST server
a method to identify the correct key and the correct symmetric encryption
algorithm.

    >> I think that we could go to TLS Exporter right now, but it would take
    >> some work.

    > I'd rather have both classic-EST and coap-EST benefit than just
    > coap-EST.

So you'd agree to deferring this to a document (maybe in LAMPS?) that would
Updates: 7030 and this document.

-- 
]               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
[