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

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 09 September 2019 16:37 UTC

Return-Path: <mcr@sandelman.ca>
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 5C71E120816; Mon, 9 Sep 2019 09:37:52 -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, 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 VzcXLc9a4aZI; Mon, 9 Sep 2019 09:37:49 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7747512080E; Mon, 9 Sep 2019 09:37:49 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [148.69.85.38]) by relay.sandelman.ca (Postfix) with ESMTPS id D1F801F459; Mon, 9 Sep 2019 16:37:46 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id C8A7427CF; Mon, 9 Sep 2019 17:38:23 +0100 (WEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Benjamin Kaduk <kaduk@mit.edu>
cc: draft-ietf-ace-coap-est.all@ietf.org, ace@ietf.org
In-reply-to: <20190909144232.GH18198@kduck.mit.edu>
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>
Comments: In-reply-to Benjamin Kaduk <kaduk@mit.edu> message dated "Mon, 09 Sep 2019 09:42:33 -0500."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Mon, 09 Sep 2019 17:38:23 +0100
Message-ID: <7801.1568047103@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/ithK8-r5WxxyQ8iK9FqsrwOuXD4>
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 16:37:56 -0000

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.

    >> 2) You are saying that we should replace tls-unique (RFC5929) with a
    >> TLS Exporter. But RFC7030 didn't reference RFC5705.  You are
    >> suggesting that we update ourselves to use RFC5705.  That would seem
    >> to require that we change some PKIX things in CSR.

    > From a crypto perspective, we should do that.  From a
    > protocol-specification perspective, we should retain parity with
    > classic EST and only update when it does.  So we should probably mostly
    > ignore this other than trying to kick off work on classic EST, and
    > mandating extended-master-secret.

okay, good.

    >> 3) I'm wondering if we need to have a clear response/error code for
    >> the case where the tls-unique does not match.  At least, from the
    >> HTTPS-EST server to the COAPS-EST "proxy" that might be valuable, even
    >> if the code it not sent back to the client.

    > [I didn't think much about whether this would give an attacker leverage
    > from which to execute new attacks]

An HTTPS-EST server that responses to the COAPS-EST with such an error is
probably mis-configured for that end point.  It probably does not believe
that the CoAPS-EST proxy is authorized to speak for the end point.
Both are already trusted.

The end point is probably already also trusted btw.  The major use case that
we had for server-generating keys is for updating keys for existing
installations.  Such as moving from 10yr old 1024RSA keys that were manually
deployed (at the factory) to 256bit ECDSA keys, etc.

    >> +------------------------------+-------+----------------------------+
    >> | HTTP Media-Type | ID | Reference |
    >> +------------------------------+-------+----------------------------+
    >> | application/pkcs7-mime; | 280 | [THISDOCUMENT] | |
    >> smime-type=server-generated- | | | | key | | | |
    >> application/pkcs7-mime; | 281 | [THISDOCUMENT] | |
    >> smime-type=certs-only | | | | application/pkcs8 | 284 | [THISDOCUMENT]
    >> - |
    >> |                              |       |                            |
    >> | application/csrattrs | 285 | [THISDOCUMENT] | | application/pkcs10 |
    >> 286 | [THISDOCUMENT] |
    >> |                              |       |                            |
    >> | application/pkix-cert | TBD28 | [THISDOCUMENT] | | | 7 | |
    >> +------------------------------+-------+----------------------------+

    > No, I was thinking we should add "[THISDOCUMENT]" to the existing
    > entries, not replace them.

got it.

    >> I think that 3SHAKE requires session resumption to be supported.  I'm
    >> not sure that using session resumption is the best thing in a
    >> constrained client system.  I think that whenever we get to doing a
    >> new operation, that we actually need a new session setup at that point
    >> anyway.

    > Hmm, but we perhaps cannot guarantee that this will hold universally
    > for all devices implementing coap-est.  I do think that we can mandate
    > other aspects that make 3SHAKE impossible (like
    > extended-master-secret), though.

okay.

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