Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15

Benjamin Kaduk <kaduk@mit.edu> Thu, 05 December 2019 23:58 UTC

Return-Path: <kaduk@mit.edu>
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 67B4D120046; Thu, 5 Dec 2019 15:58:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 9VhlNaPdx1aw; Thu, 5 Dec 2019 15:58:44 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1744120033; Thu, 5 Dec 2019 15:58:43 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xB5NwbJc025322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Dec 2019 18:58:39 -0500
Date: Thu, 05 Dec 2019 15:58:36 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, "draft-ietf-ace-coap-est.all@ietf.org" <draft-ietf-ace-coap-est.all@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Message-ID: <20191205235836.GM13890@kduck.mit.edu>
References: <157097172245.20767.1326966836276837764@ietfa.amsl.com> <BN7PR11MB2547FDB1F0D64569496CEDAAC9920@BN7PR11MB2547.namprd11.prod.outlook.com> <20191112230600.GJ32847@kduck.mit.edu> <BN7PR11MB2547EF1967DB0D86AD6810BEC94D0@BN7PR11MB2547.namprd11.prod.outlook.com> <BN7PR11MB2547FBBCEBBA7A91CE981C50C9430@BN7PR11MB2547.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BN7PR11MB2547FBBCEBBA7A91CE981C50C9430@BN7PR11MB2547.namprd11.prod.outlook.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/eDXwb09mdlJ_qHm2_rQEWMuSygI>
Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15
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: Thu, 05 Dec 2019 23:58:46 -0000

Hi Panos,

Sorry for the slow reply -- it was a busy telechat week for the IESG.
These changes look good; please go ahead and re-upload.

Thanks,

Ben

On Mon, Dec 02, 2019 at 05:37:07AM +0000, Panos Kampanakis (pkampana) wrote:
> Hi Ben,
> 
> Can you confirm if the diff https://github.com/SanKumar2015/EST-coaps/commit/53933bb9f93657955555f2302baef2e39709ae05 addresses your feedback? I will then re-upload it.  
> 
> Thanks,
> Panos
> 
> -----Original Message-----
> From: Ace <ace-bounces@ietf.org> On Behalf Of Panos Kampanakis (pkampana)
> Sent: Monday, November 18, 2019 2:07 PM
> To: Benjamin Kaduk <kaduk@mit.edu>
> Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; draft-ietf-ace-coap-est.all@ietf.org; ace@ietf.org
> Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15
> 
> Hi Ben,
> 
> All addressed, except for the last one. The diff is here https://github.com/SanKumar2015/EST-coaps/commit/53933bb9f93657955555f2302baef2e39709ae05 
> 
> My responses below in Pk> 
> 
> I will wait for your confirmation before I upload version 17.
> 
> Panos
> 
> 
> -----Original Message-----
> From: Benjamin Kaduk <kaduk@mit.edu>
> Sent: Tuesday, November 12, 2019 6:06 PM
> To: Panos Kampanakis (pkampana) <pkampana@cisco.com>
> Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; draft-ietf-ace-coap-est.all@ietf.org; ace@ietf.org
> Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15
> 
> Hi Panos,
> 
> On Wed, Oct 16, 2019 at 03:06:01PM +0000, Panos Kampanakis (pkampana) wrote:
> > Hi Yaron,
> > 
> > Thank you for the thorough review and feedback. 
> > 
> > To make sure I don't miss any of your comments over an email thread, I track all your feedback in git issue 152 https://github.com/SanKumar2015/EST-coaps/issues/152 There I tried to address all your comments and question and clarify some points. 
> > 
> > I also pushed minor changes to fix a few of the issues you brought up. 
> > The diff of the changes pushed is here 
> > https://github.com/SanKumar2015/EST-coaps/commit/86d785f2122596f28674f
> > e8e403d30467c98abfb
> > 
> > Please review the git issue and let us know if there are pending concerns. Otherwise I am planning to reupload a new iteration next week. 
> 
> Thanks for uploading the -16, and thanks again to Yaron for the very thoughtful review.
> 
> Sadly, I seem to have not looked at the github diff closely enough/in a timely fashion, so I think we'll need to publish a -17 before I can move this into IESG evaluation.  Here's my remaining notes:
> 
> Section 4
> 
>    Private keys can be transported as responses to a server-side key
>    generation request as described in Section 4.4 of [RFC7030] and
>    discussed in Section 5.8 of this document.
> 
> I think that, since Yaron brought it up, we should say "Section 4.4 of [RFC7030] (and subsections)".
> 
> PK> Fixed. 
> 
>    curve.  After the standardization of [RFC7748], support for
>    Curve25519 will likely be required in the future by (D)TLS Profiles
>    for the Internet of Things [RFC7925].
> 
> Sorry I missed this before -- "standardization" is a bit of a bugbear (7748 is Informational, not even Standards-Track, let alone full Internet Standard).
> 
> Pk> Replaced "standardization" with "publication". 
> 
>    In a constrained CoAP environment, endpoints can't always afford to
>    establish a DTLS connection for every EST transaction.
>    Authenticating and negotiating DTLS keys requires resources on low-
>    end endpoints and consumes valuable bandwidth.  To alleviate this
>    situation, an EST-coaps DTLS connection MAY remain open for
>    sequential EST transactions.  For example, an EST csrattrs request
>    that is followed by a simpleenroll request can use the same
>    authenticated DTLS connection.  However, when a cacerts request is
> 
> I think we can also clarify that this "MAY remain open" is changing expectations from RFC 7030, where the expectation was that the TLS connection did not remain open.
> 
> Pk> I added " which was not the case in [RFC7030]"
> 
> Section 10.1
> 
>    the first DTLS exchange.  Alternatively, in a case where a /sen
>    request immediately follows a /crts, a client MAY choose to keep the
>    connection authenticated by the Implicit TA open for efficiency
>    reasons (Section 4).  A client that interleaves EST-coaps /crts
>    request with other requests in the same DTLS connection SHOULD
>    revalidate the server certificate chain against the updated Explicit
>    TA from the /crts response before proceeding with the subsequent
>    requests.  If the server certificate chain does not authenticate
>    against the database, the client SHOULD close the connection without
>    completing the rest of the requests.  The updated Explicit TA MUST
>    continue to be used in new DTLS connections.
> 
> I think Yaron was saying that "even if the optimization of keeping the DTLS connection open is useful in the general case, it is very risky and prone to misimplementation when combined with /crts".  So, if I can rephrase the propsal to be that we say something more like "even though in general the DTLS connection can remain open for efficiency (Section 4), after a /crts response, the client MUST close the DTLS connection and establish a new DTLS connection for subsequent EST exchanges", are there reasons that we shouldn't use that behavior?
> 
> Pk> I am not sure it is worth to add more complexity specific to /crts. 
> Pk> We would be adding more complexity for the client to track if this 
> Pk> TLS connection is a cacerts connection then I need to close it, if 
> Pk> it is any other connection then I can interleave requests. I am not 
> Pk> convinced that the risk is that big either. A malicious user that 
> Pk> was authenticated by the Implicit DB could easily craft a cacerts 
> Pk> response that allows him to be authenticated by the Explict DB. In 
> Pk> other words an active attacker would have no problems of fooling the 
> Pk> Explicit DB if he was allowed in by the Implicit DB. I think the 
> Pk> whole issue here is conceptual. The moment we get a new Trust DB we 
> Pk> need to trust it and not use the old one, but I don't think that 
> Pk> keeping the connection open for one or two more requests is that 
> Pk> risky. Even RFC7030 allows for it in the event that the client does 
> Pk> not have an Implicit DB when it is starting
> " The client MAY
>    provisionally continue the TLS handshake to completion for the
>    purposes of accessing the /cacerts or /fullcmc method. "
> I think the language as it is now is pretty clear on what we are trying to do. And the Security Considerations spells out clearly. Of course, as always, some implementer could make a mistake, but that could happen with RFC7030 and any other RFC as well.  
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace