Re: [TLS] new version of draft-dthakore-tls-authz

[Nikos Mavrogiannopoulos <[e-mail]>]

On 01/24/2013 06:56 PM, Darshak Thakore wrote:

> Hello all,
> 
> I have uploaded a new version of the draft that specifies a new SupplementalData authorization extension to exchange DTCP Certificates.
> This version addresses a number of comments that were received during the IETF-85 meeting and subsequently on the mailing list.
> 
> The following points are addressed in the new draft
> 
>   1.  Added details about the format of DTCP Certificates and provided section references to the DTCP Specs. This should help readers navigate to the relevant parts of the DTCP Spec more easily since most of the information in the DTCP Specs is irrelevant to this I-D (besides the actual DTCP certificate details)
>   2.  Added a section to explain the use cases for this TLS extension and how it allows devices with existing DTCP Certificates to leverage it for different uses (besides its use and independent of its use for content protection)
>   3.  Provided clarification that this extension is only meant to exchange DTCP certificates as additional authorization information during a TLS exchange. It is *not* meant to tunnel any secondary protocol within TLS, nor does it replace the role of X.509 certificates in the TLS protocol
>   4.  Provided clarification in Section 3.2 about the dtcp_authz_data stuct
> 
> I would greatly appreciate any comments/feedback on it.


Some comments:
1. What is the [[]] notation?

You use it in:
         struct {
             opaque DTCPCert<1..2^24-1>;
             [[opaque ASN.1Cert<1..2^24-1>]];
             opaque signature<1..2^16-1>;
         } DigitallySigned;
and later you mention that the certificate is optional. If you want to
make the certificate optional you do:
         struct {
             opaque DTCPCert<1..2^24-1>;
             opaque ASN.1Cert<0..2^24-1>;
             opaque signature<1..2^16-1>;
         } DigitallySigned;

Otherwise your structure cannot be parsed (TLS structures are different
from ASN.1).

2. How does the random nonce protect from replay attacks? My I
understanding is that it isn't used at all. What kind of replay attacks
are you considering at? Why use a new nonce and not the TLS nonces?

3. One cannot get an overview of your additions. I'd suggest another
figure, similar to figure 1, that will focus on the exchange that is
relevant only for your extension (that way it would be apparent what you
are protecting with the nonce).

e.g.
        ClientHello (with client_authz) -------->

                                       ServerHello(with server_authz)
                                             SupplementalData (with ???)

4. You say "cryptographically tie its dtcp_authz_data with the TLS
session being established."

How do you mean by cryptographically tie? (usually such a phrase implies
a commitment - e.g., a signature))

regards,
Nikos