This was cc-ed to the wrong list -----Original Message----- From: Jim Schaad <[email protected]> Sent: Monday, October 22, 2018 12:09 PM To: '[email protected]' <[email protected]> Cc: '[email protected]' <[email protected]> Subject: WGLC comments on draft-ietf-ace-dtls-authorize
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 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
