Re: [Ace] FW: WGLC comments on draft-ietf-ace-dtls-authorize

[Benjamin Kaduk <[e-mail]>]

On Fri, Mar 08, 2019 at 04:01:26PM +0000, Göran Selander wrote:
> 
> On 2019-03-03, 02:44, "Jim Schaad" <[e-mail]> wrote:
> 
>     I am responding to the review below in regards to the most recent version -06.
>     
>     > -----Original Message-----
>     >     > Section 3.3 - Figure 4 - Where is the 'alg' parameter defined at that level?
>     > 
>     >     See next comment.
>     > 
>     > [GS]  alg parameter included
>     > 
>     >     > Section 3.3 - I am always bothered by the fact that PSK should really be
>     > PSS
>     >     > at this point.  The secret value is no longer a key and thus does not
>     >     > necessarily have a length.  There is also a problem of trying to decide
>     > what
>     >     > the length of this value would be based on the algorithm.  If the client
>     >     > offers TLS_PSK_WITH_AES_128_CCM_8 and
>     > TLS_PSK_WITH_AES_256_CCM_8  (I may
>     >     > have gotten these wrong but the intent should be understandable) then
>     > what
>     >     > length is the PSK supposed to be?
>     > 
>     >     I think what you are saying is that for the shared secret (k) in the
>     >     COSE_Key structure in Fig. 4, the AS needs to tell C what to do with
>     >     that shared secret? This was the intention of the alg parameter (which
>     >     has a not-so-useful value in this example).
>     
>     Some of what is done here makes sense and some of it makes no sense at all.
>     
>     Happy with the removal of the "alg" parameter in the root map.  
>     
>     Happy with the addition of the kid parameter in the COSE_Key object since this is required for doing DTLS w/o sending the token as the identifier.
>     
>     I have no idea what the algorithm is doing here?  This is not currently a COSE algorithm, it is a TLS algorithm and thus would not make a great deal of sense.  
> 
> GS: I admit this does not make sense, neither here nor in Fig. 6.
> 
> The terms of what the PSK length should be would be better covered by a statement along the lines of "When offering and/or accepting a TLS cryptographic suite, the length of the PSK should be at least as long as the symmetric encryption algorithms that are offered." This may already be pointed to in the TLS documents and thus can be referenced to rather than stated explicitly.

What would you do with a PSK that is longer than the input needed by the
symmetric algorithm in use?

-Ben

> GS: 
> 1. If the PSK is not uniformly random, the security level is not given by the length. I note in the ACE framework: "The AS generates a random symmetric PoP key." Perhaps we should add 'uniform' to this text?
> 
> 2. About the proposed text, how about making it into a consideration: "Note that the security level depends both of the length of PSK and the security of the TLS cipher suite and key exchange algorithm." I didn't find any text in TLS that I could reference.