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

[Benjamin Kaduk <[e-mail]>]

On Sun, Mar 10, 2019 at 10:17:35AM -0700, Jim Schaad wrote:
> 
> 
> > -----Original Message-----
> > From: Benjamin Kaduk <[e-mail]>
> > Sent: Sunday, March 10, 2019 10:10 AM
> > To: Göran Selander <[e-mail]>
> > Cc: Jim Schaad <[e-mail]>om>; draft-ietf-ace-dtls-
> > [e-mail]; [e-mail]
> > Subject: Re: [Ace] FW: WGLC comments on draft-ietf-ace-dtls-authorize
> > 
> > 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, we are talking about TLS and this is the pre-shared secret.  It is an input to the KDF function and is not a symmetric algorithm key.
> 

Ah, I must have been looking at the wrong part of the doc.

Sorry for the noise.

-Ben