Subject: [Ace] Review Comments on -03

From: Jim Schaad <[email-masked]>
Date: Sun, 15 Jul 2018 20:48:14 -0400

Note - the OSCORE profile people should scan these comments for relevancy as
well.

Meta Question - Is there a check list that I can run through which says that
these are the things that a profile needs to cover.  Part of this question
about how the document is structured.  I was of the opinion that a profile
was going to need to cover one or both of the following issues:  How does
this profile deal with communications between the C and the RS?  How does
this profile deal with communications between the C and the AS?  How does
this profile deal with communications between the RS and the AS?

*  If the document discusses how to do communications between the client and
the AS, I do not believe that you can rule how mutual authentication between
those two entities as being out of scope.  You don't need to specific how
the initial configuration is done, but the fact that you are using DTLS with
pre-configured credentials needs to be in scope.

* It is too bad that we don't have the generic coap schemas defined yet so
that we can use that as part of the URL returned with an access denied
response.

* Point to Authz document for the details of getting the AS URL back in
section 2 p 3

* Update section 2 to talk about the use of the rs_cnf parameter.  For RPK
no cnf parameter would be expected to be returned.

*  Deal with RPK and PSK in separate paragraphs.  Yes you may have some
duplication of text but the details are sufficiently different that it would
read better.  Section 2

* Section 2.1 - PSK is not a session key.  The session key is inside of TLS.
This means that the session  key is not the identity.

* Section 2.2 - Is there an intent in this paragraph that if the kid does
not match the current DTLS session that the CWT would be rejected?  That
appears to me to be what the text says but I am not sure.  Next paragraph
appears to say any active DTLS session rather than just the current one.

* Section 2.3 p 3 - How is a check done for the PSK being the same if one
has deleted all of the CWTs and then get an update over the secure channel.
Just having the kid be the same should not be sufficient.

* Section 2.3 - Is the kid parameter still needing to be defined given the
CWT POP key id option?  (Assuming that it does not disappear.)

* Section 3 - YEAH you are doing POP on the RPK as part of the request.  I
like this!!!!!!!

*  Section 3 - The last 2 sentences in this section are giving me problems.
I don't understand when  and where you are putting kids and why.

* Section 4 - if the token is already secure then no secure channel would be
needed.  Hard to have a secure channel if you have not setup anything yet.

* Section  4 - Are we really using MAX-AGE and not expires in for duration.

* Section 4 - Update the pointer to a PoP token description

* Section 4.1 - I think that this is not what the COSE_Encrypt structure is
defined in the POP structure for.  Revisit this.

* Section 4.2 - Remove everything to do with renegotiation of TLS - It is no
longer present in 1.3

s/Is also adds/It also adds/

jim

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Jul 2018 07:14:26 -0400

Hi Jim,

> On Jul 15, 2018, at 20:48, Jim Schaad <[email-masked]> wrote:
> 

Can you expand on that?  What should we have defined?

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Mon, 16 Jul 2018 08:26:04 -0400

In the event of an unauthorized, the RS has the ability to return a URL to the AS it knows about.  If it returns coaps://AS/token, then this might be thought of implying that one needs to use dtls to talk to the AS rather than using OSCORE.  The same might be true if you just returned coap://AS/token.  Once upon a time, I thought there was some work being done in the core group that would help clean this up.  It has not finished, nor have I seen much about it recently.

Jim

> -----Original Message-----
> From: Carsten Bormann <[email-masked]>
> Sent: Monday, July 16, 2018 7:14 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; ace <[email-masked]>
> Subject: Re: Review Comments on -03
> 
> Hi Jim,
> 
> > * It is too bad that we don't have the generic coap schemas defined
> > yet so that we can use that as part of the URL returned with an access
> > denied response.
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Jul 2018 08:31:30 -0400

> In the event of an unauthorized, the RS has the ability to return a URL to the AS it knows about.  If it returns coaps://AS/token, then this might be thought of implying that one needs to use dtls…

Right.  We have no way to indicate with a coaps:// URI which kind of security parameters are expected (with https://, there is a default, but that is not always right either; I am not aware of any activity to solve that problem there).  We could define a format for URI + security parameters.  The question here was always what would be good, actionable hints that don’t also provide too much information disclosure.  This is maybe a question that ACE and CoRE have in common.

Grüße, Carsten

---

From: Olaf Bergmann <[email-masked]>
Date: Tue, 31 Jul 2018 14:01:28 +0200

Hi Jim,

Thank you for your detailed review and good comments. I will come up
with proposed changes within the next days.

One thing is not clear to me, see below:

> * Section 4.2 - Remove everything to do with renegotiation of TLS - It is no

I understand that you want a protocol that works immediately with TLS 1.3,
and everybody would like every version prior 1.3 to vanish immediately.
But does this mean that we do not address TLS1.2 in this protocol
at all?

Grüße
Olaf

---

From: Jim Schaad <[email-masked]>
Date: Tue, 31 Jul 2018 07:38:34 -0700

No, I do not believe that you should disallow TLS 1.2 as it is going to be here for quite a while still.  I don't believe that we should be documenting how to use TLS 1.2 features that are not being carried forward.

Jim

> From: Olaf Bergmann <[email-masked]>
> Sent: Tuesday, July 31, 2018 5:01 AM
> Cc: [email-masked]; 'ace' <[email-masked]>
> Subject: Re: [Ace] Review Comments on -03
> 
> Hi Jim,
> 
> Thank you for your detailed review and good comments. I will come up with
> proposed changes within the next days.
> 
> > * Section 4.2 - Remove everything to do with renegotiation of TLS - It
> > is no longer present in 1.3
> 
> I understand that you want a protocol that works immediately with TLS 1.3, and
> everybody would like every version prior 1.3 to vanish immediately.
> But does this mean that we do not address TLS1.2 in this protocol at all?
> 
> Grüße
> Olaf