Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07

Jim Schaad <ietf@augustcellars.com> Tue, 29 January 2019 05:57 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 79157130EF3 for <ace@ietfa.amsl.com>; Mon, 28 Jan 2019 21:57:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 rGYj8ILHvyk4 for <ace@ietfa.amsl.com>; Mon, 28 Jan 2019 21:57:48 -0800 (PST)
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 4AABD130EA4 for <ace@ietf.org>; Mon, 28 Jan 2019 21:57:48 -0800 (PST)
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, 28 Jan 2019 21:57:41 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: "'Panos Kampanakis (pkampana)'" <pkampana@cisco.com>, <ace@ietf.org>
References: <011501d4ac3d$ab2b9650$0182c2f0$@augustcellars.com> <82341b1eb21f4eccb00741d78964f853@XCH-ALN-010.cisco.com> <015e01d4b751$9b0d2170$d1276450$@augustcellars.com> <ea319c559b1849bf943822527ec06f9a@XCH-ALN-010.cisco.com>
In-Reply-To: <ea319c559b1849bf943822527ec06f9a@XCH-ALN-010.cisco.com>
Date: Mon, 28 Jan 2019 21:57:39 -0800
Message-ID: <018101d4b797$8c6e71a0$a54b54e0$@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: AQF61PvzwzMWmD5ENcCTB9smhJ8GWwKQrXUGAsr28UIBp2jRMqZBbJPQ
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/F6nnv4A_OmrCUB8SxsuRK5x6jao>
Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
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: Tue, 29 Jan 2019 05:57:50 -0000

Yes that is the essence of what I am looking for in terms of dealing with a
new trust point.

Jim


> -----Original Message-----
> From: Panos Kampanakis (pkampana) <pkampana@cisco.com>
> Sent: Monday, January 28, 2019 9:42 PM
> To: Jim Schaad <ietf@augustcellars.com>om>; ace@ietf.org
> Subject: RE: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
> 
> Thanks Jim
> 
> > You say that the client should use the new explicit trust anchors right
after
> the cacerts request, but if you do not tear down the DTLS connection you
are
> not doing that.  You are still using the old implicit trust anchors. The
MAY in
> section 11.1 for me is overridden by the previous SHOULD unless this case
is
> specifically called out in section 7.  I cannot understand the logic that
says
> when you get a certificate a year from now the explicit TAs SHOULD be
used,
> but it does not matter when you get the first certificate.
> 
> In the draft we want to say that when you get the cacerts response start
> using those as your explicit trust anchor. But we also want to say that if
you
> pipeline EST-coaps messages in the same connection then you MAY keep the
> DTLS connection open. That has implications on the trust anchor if one of
the
> EST-coaps requests included a cacerts request. I am thinking that in order
to
> make it clearer we can add text to say that "After a cacerts you are
expected
> to use the new trust anchor. If pipelining is used you MAY keep the
> connection open, but the client SHOULD still authenticate the server
identity
> received during the DTLS handshake against the new trust anchor receive in
> response to a cacerts in the same connection. " What do you think? I open
to
> other text suggestion to convey the point as well.
> 
> About the Examples we will address the Max-Age and Content Format in the
> examples. I created new github issues for those.
> 
> Panos
> 
> 
> 
> -----Original Message-----
> From: Jim Schaad <ietf@augustcellars.com>
> Sent: Monday, January 28, 2019 4:37 PM
> To: Panos Kampanakis (pkampana) <pkampana@cisco.com>om>; ace@ietf.org
> Subject: RE: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
> 
> Clipping out things which are not issues:
> 
> 
> > -----Original Message-----
> > From: Ace <ace-bounces@ietf.org> On Behalf Of Panos Kampanakis
> > (pkampana)
> > Sent: Friday, January 18, 2019 12:59 PM
> > To: Jim Schaad <ietf@augustcellars.com>om>; ace@ietf.org
> > Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
> >
> > Hi Jim,
> >
> > Again, thank you for your thorough reviews. We addressed all of them.
> > The new version of the draft is at
> > https://github.com/SanKumar2015/EST-
> > coaps/blob/master/draft-ietf-ace-coap-est.txt
> >
> > For a more easily consumable content, your latest feedback was tracked
> > and addressed here https://github.com/SanKumar2015/EST-
> > coaps/issues?utf8=%E2%9C%93&q=is%3Aissue+draft-ietf-ace-coap-est-07
> >
> > I also lay out the changes  below:
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > - About the persistent DTLS connections (Sect 7), the last two
> > paragraphs
> of
> > section 7 explain why in some cases DTLS connections need to stay open
> > for a limited amount of time. They also point to the Section 11.1
> > about the caveats of a persistent connection and the implicit DB. I do
> > not think it
> is up to
> > this draft to tell the client that he should use the new cert after an
> > enrollment. The old cert might still be perfectly valid or the new
> > cert
> may be
> > generated for a non DTLS client auth use. So, I don't think we need to
> state in
> > this draft that the new cert needs to be used in new DTLS connections.
> >
> > - About the DTLS connections (Sec 11.1), We have usecases where a
> > client does not want to spend the resources, time, performance
> > implications to do
> > 3-5 DTLS connections back to back in order to update its trustanchor
> > and
> do
> > its enrollments for multiple certs. In this cases, explained in
> > section 7
> last
> > paragraphs will keep a persistent DTLS connection. That is what
> > section
> 11.1 is
> > trying to explain. Please keep in mind that in there we state that it
> > is RECOMMENDED for the client to start using the new explicit DB right
> > after the cacerts request. We just add the MAY keep the authenticated
> > with implicit DB DTLS connection open in some cases, but then he MUST
> > use the new DB starting for the next DTLS connection.
> >
> > So, I think our language in Sections 7 and 11.1 suffices when talking
> about
> > persistent TLS connections.
> 
> Any time that the set of trust anchors is changed, you have also changed
the
> set of things that you are going to trust.  If you remove the trust anchor
for
> the current connection, or restrict it in some manner, you may no longer
> have any trust in that connection.  This is the worry that I have.  I
completely
> agree that doing multiple certificate requests (not sure why) or a query
> about the csr attributes followed by the certificate request is totally
> reasonable.
> 
> You say that the client should use the new explicit trust anchors right
after
> the cacerts request, but if you do not tear down the DTLS connection you
are
> not doing that.  You are still using the old implicit trust anchors.
> The MAY in section 11.1 for me is overridden by the previous SHOULD unless
> this case is specifically called out in section 7.  I cannot understand
the logic
> that says when you get a certificate a year from now the explicit TAs
SHOULD
> be used, but it does not matter when you get the first certificate.
> 
> *  It does not look from the version on github that you made any changes
for
> the examples:
> 
> Examples:
> 
> * Section A.1  I don't know what the meaning of Max-Age would be for a GET
> request.  You may want to remove this just to avoid confusion.
> 
> * Section A.2 - I am unclear about the Content-Format note in this
example.
> If you are asking for a specific content then the correct option would be
> Accept.  If you are indicating the content type of the response then you
> should probably put a header line in to that effect.
> 
> In the virtual CoAP WG meeting last week we went through in some explicit
> detail that both Content-Format and Max-Age have no meaning when
> appearing on a request and therefore should not be there.