Re: [TLS] New Authz extension to use DTCP certificates in TLS SD handshake message

["Mark Brown" <[e-mail]>]

Darshak,

I have feedback and questions for you ranging from details to requirements.
I did a quick scan of the DTCP and DTCP-IP documents, and I may have
misunderstood them at places. I suspect that others on this TLS list might
not want to invest a lot of time doing the same. You might refer to DTCP's
relevant sections more specifically (and at relevant places in your ID) to
ease the recruitment of TLS readers.

 

1. Section (3.2) What *should* be signed and why? Struct "dtcp_authz_data"
does not contain a *signed* nonce, but simply concatenates it with the
signed struct. Did you want to ensure freshness / avoid replay attacks, or
am I misunderstanding your purpose? This purpose should be clarified in your
ID.
 
2. Section (1) Regarding why you are using TLS and AUTHZ, your introduction
raises more questions than it answers for me, even though I suspect that
content protection and authorizations go together at a high level. First,
IMHO, the DTCP and DTCP-IP documents seem to have a lot of overlap with the
basic motivations for an encryption protocol, which is what TLS provides
too. So, why two similar protocols? Is your goal primarily to tunnel the
DTCP protocol within the TLS protocol? While authorization can be understood
in several ways, protocol tunneling is a not typical meaning for
authorization. Or is the primary goal to "determine the type of protected
data to be exchanged"? If so, please describe the authorization decision
that might take place in this determination, and document the semantics of
"access_denied" alert messages for your authorizations.
 
3. Section (1): Which security/encryption features do you need? DTCP seems
to require mutual authentication (my quick read is that it always uses EC
Difffie Hellman key agreement between two non-X.509 certificates under a
DTLA-lite certificate authority [CA]). However, DTCP does not provide TLS's
flexibility and it uses mismatched key strengths (80bit EC vs. 128 bit AES,
see, e.g. http://www.nsa.gov/business/programs/elliptic_curve.shtml ).
Asking, "Why use TLS at all?" might help clarify. Are you interested in the
flexibility or strength of its ciphersuites, or its history of vulnerability
and protocol analysis, or its history of standard use?  If so, which
protocol's session keys and encryptors will you use, and what do the keys
mean to the overall security argument? Why does the DTCP certificate need to
be "cryptographically tied to the X.509 certificate being used during the
TLS [handshake]"?  Why not create the X.509 cert already bound to the DTCP
cert? I think you should clarify your purpose and then document it in a
revised Introduction.
 
4. Regarding DTCP nonstandard certificates (4.2.3.1, Fig 7) vs. X.509
certificates: IMHO, and perhaps DTCP agrees, ASN.1 BER/DER seems like
language overkill for simple certs. Parsing ASN.1 found in Certificate
handshake messages is an arcane, complex, software-oriented, and risky
(read: pointer-arithmetic-rich) operation that can mix up tasks of
first-time validation with every-time verification. But if you plan on
generating both a DTLA certificate and an X.509 certificate for the same
keypair, then you might consider simply using the existing TLS client
(mutual) authentication instead of separately signing just your
authorization token. Just look at the CertificateVerify (CV) message already
defined for TLS, which runs a hash over the client's and the server's
nonces, the rest of the handshake, and your SupplementalData, then signs. If
you use the existing TLS CV message, then your DTCP protocol should be able
to offload the standardized certificate validations onto the TLS protocol,
for which ASN.1 parsers are already present in implementations, including
management of the CA lists and OCSP checking. 
 
Best regards,
--mark

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Darshak Thakore
Sent: Tuesday, November 06, 2012 10:09 AM
To: [e-mail]
Subject: [TLS] New Authz extension to use DTCP certificates in TLS SD
handshake message

 

Folks,

I am sending this email to obtain feedback and guidance on the following
I-D, which proposes a new Authorization Data Format to the TLS
SupplementalData Handshake extension to use DTCP certificates as
authorization data. If this WG is not the forum to seek feedback on this
proposal, please redirect me accordingly.

 

http://tools.ietf.org/html/draft-dthakore-authz-01

 

>From the Abstract:

  "This document specifies the use of DTCP certificate as an
   authorization extension in the Transport Layer Security Handshake
   Protocol, according to guidelines in RFC 5878.  Extensions carried in
   the client and server Hello messages confirm that both parties
   support the desired authorization data types.  Then if supported by
   both the client and server, DTCP certificates are exchanged in the
   supplemental data handshake TLS handshake message as specified in
   RFC4680."
Thanks in advance 
Regards,
Darshak Thakore