Subject: [TLS] TLS 1.2 draft comments

From: <[email-masked]>
Date: Sat, 30 Dec 2006 13:21:14 -0800

Inline comments, for 7 fragments of the I-D:-

1.     -  The connection is private. Symmetric cryptography is used for
       data encryption (e.g., DES [DES], RC4 [SCH], etc.). The keys for
       this symmetric encryption are generated uniquely for each
       connection and are based on a secret negotiated by another
       protocol (such as the TLS Handshake Protocol). The Record
       Protocol can also be used without encryption.

There are errors both technical and semantic in the above. Fortezza connections
don't have unique keys per connection. We also need to stop including within
'key' objects such as "mac secrets." Furthermore, the secret
may always not be "negotiated" by TLS. Furthermore, if the Record Protocol
can be used without encryption, we can hardly have the privacy asserted
in the topic sentence: without encryption, its hard to get the data
origin authentication of the TLS application messages that allows for 
expressing the very expectation of pairwise privacy!

 2.    -  The connection is reliable. Message transport includes a message
       integrity check using a keyed MAC. Secure hash functions (e.g.,
       SHA, MD5, etc.) are used for MAC computations. The Record
       Protocol can operate without a MAC, but is generally only used in
       this mode while another protocol is using the Record Protocol as
       a transport for negotiating security parameters.

Keep the point about  RP can operate without a MAC, strike 
the general qualifier. Either one can or cannot...operate without 
MacTags. We readers don't need protocol design advice from TLS WG 
stuffed  into an interoperability spec, thanks!

3. One such encapsulated protocol, the TLS Handshake
   Protocol, allows the server and client to authenticate each other and
   to negotiate an encryption algorithm and cryptographic keys

While we are at it, lets get this accurate."One such encapsulated protocol, the TLS Handshake
   Protocol, allows the server and client to authenticate each other and
   to negotiate a __ciphersuite, key, and varios secrets.__" If I argue with myself,
the word negotiate should really become "agree". In combination
with the first use of the ciphersuite and keys, the final KDF executes
an "agreement" between the named parties roles, as to those objects. One
is forced to (I) use, (2) rely, and (3) agree, in the final protocol.

4. The peer's identity can be authenticated using asymmetric, or
       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
       authentication can be made optional, but is generally required
       for at least one of the peers.

how about: The peer's identity can be authenticated using asymmetric, or
       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
       authentication can be made optional, but is generally required
       for at least one of the peers __in order to establish appropriate assurance for
 the key exchange component of a ciphersuite.__"

5. The negotiation of a shared secret is secure: the negotiated
       secret is unavailable to eavesdroppers, and for any authenticated
       connection the secret cannot be obtained, even by an attacker who
       can place himself in the middle of the connection.

How about: The negotiation of a shared secret is secure: the negotiated
       secret is unavailable except to the server and client, each party can confirm
       the other possesses the secret, and for any authenticated
       connection the secret cannot be _obtained from the wire_ , even by an attacker who
       can place himself in the middle of the connection.

6. One advantage of TLS is that it is application protocol independent.
   Higher level protocols can layer on top of the TLS Protocol
   transparently. The TLS standard, however, does not specify how
   protocols add security with TLS; the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left up to the judgment of the designers and
   implementors of protocols which run on top of TLS.

To address EAP-TLS session resumption rules and TLSPSK rules on self-signed certs etc: 
   the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left up to the judgment of the designers and
   implementors of protocols which run on top of _or below_ TLS.

7. Concerning section 1.1:

"     - Allow the client to indicate which hash functions it supports.

     - Allow the server to indicate which hash functions it supports

     - Addition of support for authenticated encryption with additional
     data modes."

distinguish indicating hash functions, from mac functions. hash functions used in securing
the handshake are not the same as mac functions used in the record-layer. Without
reading further, I don't know which are being referred to in this summary.

I don't know what "authenticated encryption" is, only that support for it has
been added. Apparently, it has "data modes". Its presumably not a confidentiality
service. Its presumably not the privacy service. Its X. From the form of the
summary, it may be an X.800 mechanism, not a service.

Peter.

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: EKR <[email-masked]>
Date: Sat, 30 Dec 2006 14:09:13 -0800

<speaking for mysef....>

>        can place himself in the middle of the connection.

In general, I don't agree that your proposed changes improve the
situation. This text (or minor variants) dates back to TLS 1.0 (and I
suspect back to SSLv3). Does anyone else in the WG support these
changes.

>    implementors of protocols which run on top of _or below_ TLS.

I don't see the virtue of this change either. TLS-PSK doesn't run
below TLS and this WG is not in the business of standardizing 
anything EAP.

> reading further, I don't know which are being referred to in this summary.

I'll put this on the list of things to change.

> summary, it may be an X.800 mechanism, not a service.

"authenticated encryption wiht additional data". It's combined
confidentiality and message integrity in a single algorithm, as is
explained later in the document.

-Ekr

---

From: <[email-masked]>
Date: Sat, 30 Dec 2006 15:01:47 -0800

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.

---

From: EKR <[email-masked]>
Date: Sat, 30 Dec 2006 15:11:07 -0800

> PRF architecture changes going on in TLS 1.2

I don't think there really is a rationale. At some level, this is arbitrary,
but the chosen values are fine ones.

> signature as the TLS PRF of old?

At the Montreal IETF, the consensus was to keep the signature/API the
same.

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

What section are you talking about?

> you expect. 

That's not what's going on here. I suggest you read the referenced
paper for the background.

> 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.

This is a chartered work item, so I think you're going to need to make
a stronger case if you want it removed.

>    required to break that encryption.

Well, the 40-bit algroithms have been deprecated in TLS, so this 
section should simply be removed.

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

They're being moved back out again, so not really 

> digital signatures on sets of record fragments.

TLS Extensions is already a Proposed Standard (RFC 3546). It just
got moved into this document for editorial reasons.

-Ekr

---

From: <[email-masked]>
Date: Sun, 31 Dec 2006 06:12:04 -0800

----- Original Message -----
From: "EKR" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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.

---

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Sun, 31 Dec 2006 10:56:34 -0500

> 2. CIPHERSPEC, EXPORT
>
> If the 40-bit export ciphersuites are being deprecated,

But some constrained enviroments do need 40-bit "export" ciphersuites.
Besides since the NULL encryption ciphersuites exist why can't 40-bit
"export" ciphersuites exist too? If needed the TLS client and server always
can neogtiate a stronger encryption so why the depreciation (and what it
would exactly mean to the implementations).
This depreciation would also weaken WTLS statement that it is based on TLS.

> will the standard

---

From: EKR <[email-masked]>
Date: Sun, 31 Dec 2006 08:01:37 -0800

>   secret. The construction we use for this operation is known as HMAC,

Yes, I'll clean this up.

> service.

I would advise you to read draft-mcgrew-auth-enc-01, which describes
the rationale for this kind of primitive.

> 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.

Huh? Data origin authentication failures in TLS always occured at
the record layer. We're just replacing two algorithms at the
record layer with one.

> (a) can the DOA properties of non-AEAD-based confidentiality services
> also be tied

I don't know what this means.

> (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

The behavior here is exactly like it always has been for TLS.
You generate a protected MAC on the write channel and then 
abort. (Note that DTLS behaves differently since MAC errors
are not fatal.)

> We need an authoritative reference for AEAD, not just some I-D.

Yes. This creates a normative dependency on that I-D.

> All
> this draft
> with AEAD added, TLS will now have to stay at Proposed for 7 more
> years... till

TLS staying at Proposed for 7 years had to do primarily with 
WG inertia. And the reason that 1.2 will not go to Draft is
that we are making major technical changes.

> This needs to go. TLS1.2 introduces non X.509 certificates, very
> clearly. And,

The reference is to an RFC.

   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
            Public Key Infrastructure: Part I: X.509 Certificate and CRL
            Profile", RFC 3280, April 2002.

-Ekr

---

From: EKR <[email-masked]>
Date: Sun, 31 Dec 2006 08:37:03 -0800

> But some constrained enviroments do need 40-bit "export" ciphersuites.

I'm not aware of any such environment. Can you please name them?

> "export" ciphersuites exist too?

Because there's no good reason for them to exist and the key
weakening primitive adds substantial complexity to the 
protocol.

> If needed the TLS client and server always

Here's the relevant text from 4346. So, actually, they're already
deprecated.

   When SSLv3 and TLS 1.0 were designed, the United States restricted
   the export of cryptographic software containing certain strong
   encryption algorithms.  A series of cipher suites were designed to
   operate at reduced key lengths in order to comply with those
   regulations.  Due to advances in computer performance, these
   algorithms are now unacceptably weak, and export restrictions have
   since been loosened.  TLS 1.1 implementations MUST NOT negotiate
   these cipher suites in TLS 1.1 mode.  However, for backward
   compatibility they may be offered in the ClientHello for use with TLS
   1.0 or SSLv3-only servers.  TLS 1.1 clients MUST check that the
   server did not choose one of these cipher suites during the
   handshake.  These ciphersuites are listed below for informational
   purposes and to reserve the numbers.

-Ekr

---

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Sun, 31 Dec 2006 16:02:43 -0500

see inserted:

> I'm not aware of any such environment. Can you please > name them?

Some embeded systems, for example cheap EPC RFID tag. The Generation 2 tag
today does not even have a cryptographic hash function, etc.

---

From: EKR <[email-masked]>
Date: Sun, 31 Dec 2006 13:21:05 -0800

> today does not even have a cryptographic hash function, etc.

The TLS 40-bit ciphersuites don't provide any advantage here.  They're
just the ordinary ciphers (RC4 and DES) with pre-processing to reduce
the key to 40 bits of entropy. They're no faster and no smaller (gate
count, memory footprint) than the ciphers they are derived from.

-Ekr

---

From: <[email-masked]>
Date: Sun, 31 Dec 2006 14:39:38 -0800

Its true, they have gone, as has the calculation. And I didn't
even notice. Wow. After:-

All that crap about no RSA standard (1986 Geneva, State)
All that crap about LEAFs on IVs (1993 Fort Meade, NSA/NSC)
All that crap about dual certs & cross-certs (1992/1994 Ottawa, CSE)
All that crap about low entropy KDFs. (1995 Mountain View, Commerce)
All that crap about TTP CAs enforcing key escrow (1996 935 Pennsylvania 
Avenue, FBI)
All that crap about dual channel keying (1996 Royal Holloway, F&CWO)
All that crap about Bridge CA Assurance enforcement (2000 Washington, GSA)

Talk about shunting a bad policy around the agencies, to get rid of it!
I mean, it was just a career killer!

We need rapidly to bring back Fortezza technology back into a general
purpose SSL ciphersuite: KEA and key wrapping are well worth having. Now
Rumsfeld has gone, someone get DoD to put CAC firmware for javacards
(and driver libraries) into the open source community, where they
belong. It will go far, and will multiply. Keep the PIV stuff proprietary
and controlled for now, till public confidence is higher.

All we need now is dissolution of the stooge ANSI X9 RSA group, and
some test vectors from NIST for RSA key transport.

And, is IESG ready to have a look at moving SSL beyond Proposed, yet!?

----

The real test is of course Microsoft Windows, looking at the China
distribution of Vista next month.

Does it conform (I.e. refuse to negotiate export ciphers, with a TLS 1.1 
client)
Does it conform (I.e. perform negotiation with them, with a TLS 1.0 client)

But, I have the highest regard for Microsoft on cryptopolicy matters.

Lets wait and see how they do.

-----

 ----- Original Message -----
From: "Omirjan Batyrbaev" <[email-masked]>
To: "EKR" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Sunday, December 31, 2006 1:02 PM
Subject: Re: [TLS] TLS 1.2 draft comments

>> weakening primitive adds substantial complexity to the

There are lots of good reasons now to have lots of different KDFs
for setting connection state! There are many dual purposes of
the control technology used in export enforcement, for business &
legal purposes (not just the obvious purposes of mandatory data
retention, wiretapping etc).

I think Ill bring back my connection-NR for TLS, where handshakes punctuate
the transaction, like Russ's alerts do. With TLS Evidence also making
a signature, we gets lots of assurance toys to play with and apply
to a wide range of orchestrated business flows.