Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

[Jim Schaad <[e-mail]>]

I have deleted things I am not replying to.

-----Original Message-----
From: Benjamin Kaduk <[e-mail]> 
Sent: Tuesday, July 30, 2019 3:03 PM
To: Jim Schaad <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: AD review of draft-ietf-ace-cwt-proof-of-possession-06

Noting that there are several points that Jim left to the authors to reply
to, also inline...

On Tue, Jul 30, 2019 at 10:10:12AM -0700, Jim Schaad wrote:
> Comments inline.
> 
> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Tuesday, July 30, 2019 8:56 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: AD review of draft-ietf-ace-cwt-proof-of-possession-06
> 
> Section 3.3
> 
> Is the /HMAC256/ the conventional diagnostic notation for alg value 5 
> (noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")?
> 
> [JLS] HMAC 256/256 is the algorithm name while HMAC w/ SHA-256 is 
> descriptive.  I believe that this is completely consistent in RFC 8152.

Er, I'm not sure what you're saying is best to use in the diagnostic
notation.

[JLS] I would use the algorithm name if it was up to me.  That is what I did
in the COSE documents.

> Section 3.4
> 
>      {
>       /iss/ 1 : "coaps://server.example.com",
>       /aud/ 3 : "coaps://client.example.org",
> 
> Is it in any way confusing to use client.example.org as opposed to, 
> say, resource.example.org as the audience?
> 
>       /exp/ 4 : 1361398824,
>       /cnf/ 8 : {
>         /kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad'
> 
> /kid/ in the 'cnf' map has key 3, not 2.
> 
>    Note that the use of a Key ID to identify a proof-of-possesion key
>    needs to be carefully circumscribed, as described below and in
>    Section 6.  Where the Key ID is not a cryptographic value derived
>    from the key or where all of the parties involved are not validating
>    the cryptographic derivation, it is possible to get into situations
>    where the same Key ID is being used for multiple keys.  The
> 
> I don't think this quite covers the needed properties, since we also 
> need some assurance that all parties are interpreting the kid value in 
> the same way. It may be possible to construct such a scenario via an 
> attacker replaying a stolen token or even just inadvertent confusion 
> by some party (quite plausible when we consider scenarios that involve 
> the same key being described by different 'kid' values in messages with
different recipients).
> In particular, if the situation arises where an attacker is able to 
> choose the 'kid' value that will be used, they could deliberately 
> cause a collision with a legitimate value used by some other party.
> 
> [JLS] I don't agree with that.   It should be assumed by all
implementations
> that there will be collisions between kid values.  Except in very 
> specific cases such as all of the kids being assigned by a group 
> keying server, there is no way for the assumption of a single kid 
> value being assigned once on a recipient basis will ever be a true
statement.

Thanks; that's a good point, and this jogs loose some of the previous
discussions we had on the list about key IDs.  (Looking back at the quoted
text from the document, I wonder if all readers will understand that
"cryptographic value derived from the key" needs to include enough bits of
cryptographic output to make the chance of brute-force/random collision
acceptably small.) It does still seem potentially useful to have agreement
among parties as to whether key IDs are arbitrary identifiers or
cryptographically derived, though my above discussion about scenarios and
consequences is flawed as you note.

[JLS] Yes I agree that it could do better about talking about lengths for
the purpose of non-collision.  I don't think that I care much about the
issue of brute-forcing as even if there is a faked kid, the shared secret
would still need to be determined which is more difficult.  And as below, I
don't think this is ever going to be a very big issue for the IoT world as
long enough kid values collides with as small as possible messages.

>    In the world of constrained Internet of Things (IoT) devices, there
>    is frequently a restriction on the size of Key IDs, either because of
>    table constraints or a desire to keep message sizes small.  These
>    restrictions are going to protocol dependent.  For example, DTLS 
> can
> 
> Section 5
> 
> This sort of correlation can occur even for subsequent connections 
> between the same two parties if observed by a passive observer (e.g., 
> in the case of a mobile client that changes location).  I forget if we 
> have strong enough guarantees on the use of transport-level encryption 
> that would prevent such CWTs from being observed in this fashion.
> 
> [JLS] No we don't.  Most of the time we are sending CWTs in the clear 
> and not over a transport-level encrypted channel.

I don't propose that we add or suggest remediation measures, but do think we
should note the risk.

[JLS] reasonable (I guess)

> Section 6
> 
> Section 7.2.1
> 
>    Change Controller:
>       For Standards Track RFCs, list the "IESG".  For others, give the
>       name of the responsible party.  Other details (e.g., postal
>       address, email address, home page URI) may also be included.
> 
> In light of the GDPR and similar regulations (and, as is done in RFC 
> 8602), we may not want to keep all of these, especially postal 
> address, given the lack of a clear need.
> 
>    Specification Document(s):
>       Reference to the document or documents that specify the parameter,
>       preferably including URIs that can be used to retrieve copies of
> 
> Is the reference required to be publicly accessible?  If not, is it 
> required that a copy be made available to the experts and IANA?
> 
> [JLS] It is not clear to me that this is an Designated Expert 
> registry.  It is only referred to once in the JWT Confirmation Method 
> Name and that could refer to the JWT registry and not this one.

Section 7 (toplevel) says that all new registries established by this
document use Specification Required [RFC8126], which includes review by an
expert or experts.

[JLS] All one of them.  I think this can be pulled down close to the actual
registry declaration.

> Section 7.2.2
> 
>    o  Confirmation Method Name: "Encrypted_COSE_Key"
>    o  Confirmation Method Description: Encrypted COSE_Key
>    o  JWT Confirmation Method Name: "jwe"
>    o  Confirmation Key: 2
>    o  Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0
>       structure (with an optional corresponding COSE_Encrypt or
>       COSE_Encrypt0 tag)
> 
> Do we want to say something about how, in the case when the tag is 
> omitted, the application protocol specification needs to indicate how 
> to determine which one is in use?
> 
> [JLS] This is easy as the number of elements in the array is different 
> between the two.

Okay, so you think it's obvious to anyone who goes off and tries to
implement it, so we don't need to say anything?

[JLS] Yes I think so

> Section 8.2
> 
> I think [JWT] needs to be normative, as we have a SHOULD-level 
> requirement for the audience restriction procedures it specifies.
> 
> [JLS] Should this be indirect through the CWT spec rather than via the 
> JWT spec?

Perhaps.  (The text in question in this doc is in Section 4, "Applications
utilizing proof of possession SHOULD also utilize audience restriction, as
described in Section 4.1.3 of [JWT], as it provides additional
protections.")  I guess JWT itself doesn't even use the phrase "audience
restrictions", so perhaps just changing to the CWT ref is enough, here.

[JLS] Yeah, I looked at both and it seemed to me that the text was
essentially the same in both documents.

Jim

***

-Ben