Re: [TLS] TLS 1.2 draft comments

[<home_pw@xxxxxxx>]

----- Original Message -----
From: "EKR" <ekr@xxxxxxxxxxxxxxxxxxxx>
To: <home_pw@xxxxxxx>
Cc: <tls@xxxxxxxx>
Sent: Saturday, December 30, 2006 2:09 PM
Subject: Re: [TLS] TLS 1.2 draft comments

> <speaking for mysef....>


Well, there are only two listed authors of the TLS1.2 text... and I know
how Tim thinks. Lets assume no ghost authors. But, you cannot stop being 
IAB, EKR.
The role exists to render intuitive judgment to the engineering process.

1. NONCES, KDF, EVIDENCE

in TLS1.2 we need to consider what the security section says about nonce 
generation.
Folks are known to claim that being public, they do not need a known-safe 
PRNG process.
Id claim (a) the random component (and time) are not always public (in 
renegotiation)
(b) the random component is specified for use in TLS PRF(s) acting as a KDF 
SEF
and an HMAC SEF.

We have to be careful, as there is assurance "feedback". The nonces protect 
the handshake, by
generating keying material for the encryption of the finished message, which
provides the integrity protection for the handshake's activation of pending
state that gates the very encryption mechanism logic unit. In TLS Evidence, 
this
is a major auditable semantic event, furthermore, and Russ evidently intends 
the
times and nonces to become part of the uncompressed-plaintext-handshake 
evidence
that is stored, under US data retention laws.

How long is the ClientHello random anyways? One book says it stored in 28 
opaque bytes,
on the wire, as does http://ietf.org/rfc/rfc2246.txt. However, Section 6.1 
of the I-D list
connection state as:
 client random
      A 32 byte value provided by the client.

Is the master_secret KDF implmented on the message from in socket queue, or 
from
the connection state?

This is important as (computations on the ) master_secret may be limited to 
the
kernel, in the privileged ring of the CPU. The hello messages may well be in
user mode space by now.

Concerning 7.4.1.1
" Note: This message MUST NOT be included in the message hashes which are
      maintained throughout the handshake and used in the finished
      messages and the certificate verify message"

this will need to go in the connection state maintaining the hash for TLS
Evidence digital signatures.


2. CIPHERSPEC, EXPORT

If the 40-bit export ciphersuites are being deprecated, will the standard 
maintain
the rest of the strengh-limitation (export reg.) apparatus that IESG 
endorsed?
(the changecipherspec process leading to the final derivation of keying 
material in
non MISSI ciphersuites?)

We might leave it as is, bind the traditional function(s) associated with 
the
current value of cipherspec (1), and introduce a second value (2) - to be
associated with the expected practices hereonafter. A fatal alert might
be introduced for a modern implementation to react to value=1.



3. RSA CIPHERSUITES WITH NEW KDFs, LOCAL RSA CIPHERSUITES

Does IETF intend to now standardize any RSA ciphersuite that define their
own KDFs? Or is IETF going to limit itself to only addressing ciphersuites
that use the TLS PRF as a KDF?

The following text may need updating, as KDFs per ciphersuite now may
or may not be using (in the handshake layer) "HMAC, keyed MACs, or
secure digesting of data that is protected by a secret"

"A number of operations in the TLS record and handshake layer required
  a keyed MAC; this is a secure digest of some data protected by a
  secret. Forging the MAC is infeasible without knowledge of the MAC
  secret. The construction we use for this operation is known as HMAC,
  described in [HMAC]."

"In TLS the entire output of the hash function is used as the MAC tag."
Interesting to see such a "govt term" in the spec. This is not
typical netscape-era use of language. but the following is done well:

"Note that if new cipher suites are added that do not use HMAC, and
  the session negotiates one of these cipher suites, this extension
  will have no effect."

The main problem is that we have locally-defined ciphersuites these days,
FORMALLY. The  style of language still often assumes ciphersuite are defined
in the "standard document" (e.g. "added"). The standard has to adapt - the
architecture now assumes the record layer may be being protected using
non-IETF-endorsed ciphersuites.


4. AEAD

I still don't understand the objective for introducing AEAD. It seems to
exist to provide a explicit data origin authentication service tied a 
confidentiality
service. Unlike the DOA that traditionally provided by assured 
writer-to-reader
confidentiality service, the implied DOA is then tied to the error signaling 
in
and of the record layer. At second reading, I still don't like AEAD as a 
construction,
and I still don't like the tying of a confidentiality service state to any 
error
signaling. My first impression was correct: a lot more rationale is 
required,
both function claims and then assurance claims/arguments.

(a) can the DOA properties of non-AEAD-based confidentiality services also 
be tied
to the (authenticated) error signaling

(b) once the AEAD internal error state is detected on the read subchannel, 
does the
standard intend the encryption mechanism in the HSM to stay active, ... so 
it can
now be used authenticate/encrypt/DOA the fatal alert on the write 
subchannel?

c) is it non-conforming for an AEAD cipersuite to specify a NULL MAC 
component?

We need an authoritative reference for AEAD, not just some I-D. All this 
draft
document chasing is like Tom chasing Jerry chasing Tom, right now. I assume
with AEAD added, TLS will now have to stay at Proposed for 7 more years... 
till
we understand its impact.



5.PKIX

7.4.2 "All certificate profiles, key and cryptographic formats are defined
  by the IETF PKIX working group [PKIX]."

This needs to go. TLS1.2 introduces non X.509 certificates, very clearly. 
And,
one assumes PKIX WG has to die one day, too. We don't want references to
working groups in standards.







_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls