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.