Subject: [core] WGLC comments on draft-ietf-ace-dtls-authorize

From: Jim Schaad <[email-masked]>
Date: Mon, 22 Oct 2018 12:09:19 -0700

Section 3 - Am I just missing where you talk about introspection or is it
missing from the text?

Section 3.2 - looks like you missed a "cnf" in the first paragraph - should
be req_cnf

Section 3.3 - Figure 4 - Where is the 'alg' parameter defined at that level?

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?

Section 3.3 - Figure 5 - Is this defining a new set of entries for cnf or is
there a missing layer someplace?

Section 3.3 - Should some type of key identifier also be defined so that the
entire token is not always sent on every DTLS setup?  Also so that the key
can be referenced on a second request to the AS.

Section 3.4 - Is it worth while to make it explicit when the DTLS session is
required to be shutdown and that a simple authorization error is not one of
them?   Looks like it should be - these errors SHOULD NOT cause the DTLS
connection to be closed.

Section 4 - The requirement that the "kid" be in a previously issued token
would have problems with this if you were to use the "kid" of an RPK which
can be constant rather than being changed on each newly created token.

Section 4 - The term "must associate" is slightly ambiguous - does this mean
add to (augment) or replace the previous token.

Section 4 - Should a secondary access token have a later expiration date
that the one that contains the actual key value?

Section 5 - this seems to be a very strange place to define the new
parameter.

Section 8 - you need to put your kid in the IANA considerations as well

Section 9.1 - Having tilicoa-tls-dos-handshake as a normative reference may
cause problems unless this is on a publication track.

Section 9.3 - Can we get these URLs converted over to normal references?  

Jim