Re: [TLS] TLS 1.2 draft comments

More detailed comments, this time to do with the protocol. These contrast with the earlier

comments on the early-doc rationale and claims (that were largely expressed in "netscape-speak",

and need further professionalization - before TLS gets too much higher in the standards track)

1. signature

"master secret
A 48 byte secret shared between the two peers in the connection."

Is it appropriate to now specify the length of this, and the client random component

of the hello nonces? If so, give a rationale for the value in light of the fundamental

PRF architecture changes going on in TLS 1.2

Right now, this all defines a particular signature for the

       key_block = PRF(SecurityParameters.master_secret,
                          "key expansion",
                          SecurityParameters.server_random +
                          SecurityParameters.client_random);

If in TLS1.2 a PRF MAY be defined by a ciphersuite and not by the standard, need it have the same

signature as the TLS PRF of old? Why should the ciphersuite not define the types for the input values? Cannot

the ciphersuite not specify the length of the master_secret

2. wrapped KEK/IVs in finished

Im dubious about the new/amended means of protecting the integrity of the handshake, in the

finished process. I cannot follow all its diddling with masks, and its impact on wrapped key/iv

mechanisms when creating the first enciphered block under a server.write key. This may be

more Peter problem, than spec problem. Perhaps I just have to read it a 100 times, more.

3. timing channels vs key

This is all funny on first reading, given all the recent discussion of NULL MAC in general!:

Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a
       timing attack on CBC padding based on the time required to
       compute the MAC. In order to defend against this attack,
       implementations MUST ensure that record processing time is
       essentially the same whether or not the padding is correct.

Mac secrets are not "key", and are therefore assured not to influence the keyed

confidentiality mechanism. if you use a secret vs key in a crypto SEF, you get what

you expect. Futzing with timing is not addressing the root cause of the design flaw.

Futz with timing in the message dispatcher in the record layer generally, not in the handling

of a particular message, or use of a mechanism.

This all looks like a hack/workaround not a standard.

4. AEAD

well at least I know what it is now, and how it relates to compression. Ill study the background issues

to this some more, offline, before commenting in detail.

But, interesting to see null length MAC getting involved, again -)

And, interesting to see the failure alert: "fatal bad_record_mac alert"

If I now calculate 2 + 2 = 5, the confidentiality service based on an AEAD mechanism is providing data origin authentication,

and that DOA can control the record_layer integrity service, and the disconnect event. Hmm.

I don’t like it, at first glance. Its smells wrong. I need further rationale, in terms of function and assurance claims.

5. "However, you SHOULD never send data over a link encrypted with 40 bit
security unless you feel that data is worth no more than the effort
required to break that encryption.

I think its time for this to go... if only because we have no "links", above the TLS. We have

channels or bridges. If its kept, perhaps consider

"However, you SHOULD never send data over a link encrypted with 40 bit OR LESS
security unless you feel that data is worth no more than the effort
required to break that encryption.

This updates the text to address ciphersuites with null confidentiality regimes.

6. I notice

case certificate_url: CertificateURL;
case certificate_status: CertificateStatus;

These need adding to the "major changes section of the summary". I can not see these in

RFC 4346.

      enum {
          hello_request(0), client_hello(1), server_hello(2),
          certificate(11), server_key_exchange (12),
          certificate_request(13), server_hello_done(14),
          certificate_verify(15), client_key_exchange(16),
          finished(20), (255)
      } HandshakeType;

Given the description (they are part and parcel of the extension mechanism from other docs

being folded into TLS 1.2) I think I see what's going on.

a) I like certificate URL, and it moves us beyond Nescape's tunnel vision on the format

of the bag of certs (forwardCertPath). The bag can now contain HSM certs, for example

from the client, where the architect has defined an "enhanced X.509 Certificate" cert type, per

the rationale. It can also be a set of SAML assertions, getting us beyond X.509's aging formats.

There is a strong danger that this extension will get badly abused, I feel. And, many

military implementations are NOT going to be willy-nilly going out and resolving URLs

sent by a (enhanced) handshake protocol, even if the handshake messages are being

protected by an active (assured and sufficiently strong) TLS Connection. I can see such

handshakes being used to ping a mgt port for a given user, and thus go collect data from certified

repositories (over TLS), stuffing their response in caches. This is just X.500 revisted, tho.

b) What nut pushed for that OCSP stuff in certificate_status? Don’t folks understand that it was just

to annoy VeriSign over the Micali patents?

With TLS extensions, we will be able to recover cert status from a TLS responder, without

bothering with OCSP. It can be authoritative as OCSP can be, once it starts putting

digital signatures on sets of record fragments.

c) concerning SAML certs

  " If the protocol used is HTTP, then the HTTP server can be configured
   to use the Cache-Control and Expires directives described in [HTTP]
   to specify whether and for how long certificates or certificate
   chains should be cached.

   The TLS server is not required to follow HTTP redirects when
   retrieving the certificates or certificate chain. The URLs used in
   this extension SHOULD therefore be chosen not to depend on such
   redirects."

I like this, as one can follow the various SAML profiles, their redirects,

session cookies; session URLs, auto postings, artifact resolution, etc. I do feel that

the SHOULD ought to be tied only to X.509 cerificate type, tho,

CLEARLY, allow other cert types to specify other constraints on required

processing behaviour, including none of that which is stated currently. Then

SAML2 can retrieve the certs, attributes properly etc. rather than fuzting around

with all this HTTP-land mime type stuff. I can get my SAML2 evaluated when

co-resident with a TLS protocol engine: little chance if I have to stick HTTP

and MIME in the boundary, tho.

More later; once I've read the back half or Eric's book, now.

Peter.