Subject: RE: [TLS] Comments on TLS identity protection

From: Peter Williams <[email-masked]>
Date: Wed, 27 Dec 2006 12:23:04 -0800

> > There's no way in TLS to currently have a NULL MAC algorithm.> > I doubt there is lilkely to be one soon.
 
if we look at the text of SSLv3, it discussed null mac functions in the architecture:-
 
If the CipherSuite is SSL_NULL_WITH_NULL_NULL, encryption consists of the identity 
operation (i.e., the data is not encrypted and the MAC size is zero implying that 
no MAC is used). SSLCiphertext.length is SSLCompressed.length plus 
CipherSpec.hash_size. 
 
I'd claim that a complete, SSL-patent implementing state machine (E.g TLS ) therefore
supports null MAC algorithms. As TLS implies SSLv3 fallback capability...the capability needs
to be provided to be complete. I think we can allow for "no MAC is used" (spec) to be equivalent to 
"NULL MAC algorithm" (peter-speak), linguistically.
 
if we consider
 
"The encryption and MAC algorithms are set to SSL_NULL_WITH_NULL_NULL at the beginning of the SSL 
Handshake Protocol,  indicating that no message authentication or encryption is performed. The handshake 
protocol is used to negotiate a more secure CipherSpec and to generate cryptographic keys. "
 
So perhaps the truthful political-appropriate statement would be that https (vs TLS) supports NULL 
MAC (as https tends to include the SSLv3 fallback modes of TLS)
 
_________________________________________________________________
Fixing up the home? Live Search can help.
http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&locale=en-US&source=wlmemailtaglinenov06

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

---

From: EKR <[email-masked]>
Date: Wed, 27 Dec 2006 17:22:22 -0800

> no MAC is used). SSLCiphertext.length is SSLCompressed.length plus 

Yes, but TLS explicitly forbids you to negotiate this algorithm
(i.e., it's only useful for performing the handshake).

   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
   TLS connection during the first handshake on that channel, but must
   not be negotiated, as it provides no more protection than an
   unsecured connection.

So, it's basically a different way of expressing "do your first
handshake in the clear".

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Thu, 28 Dec 2006 13:59:48 +0100 (MET)

> So, it's basically a different way of expressing "do your first

TLS_NULL_WITH_NULL_NULL does not provide per-message MAC.  
It is sort-of a hack for the SSL protocol engine to cover
the initial phase when there is not yet a shared secret.

It is OK to use for the messages of the SSL handshake -- which
do not need a per-message MAC as they're protected by the
full handshake MAC of the Finished messages.

-Martin

---

From: <[email-masked]>
Date: Fri, 29 Dec 2006 09:52:43 -0800

TLS does indeed forbid the _negotiation_ of this defined ciphersuite. (This 
is
why I phrased my claim in terms of SSLv3, which allows it. Furthermore,
for a mixed TLS/SSL protocol entity, completeness demands the feature
be negotiable, for certain versions)

So the claims of all 3 parties are true :-) But we are not yet
getting to the crux.

Regardless of the modes under which NULL MAC is negotiated/conforming, it
exists. It properly exists, furthermore. (A decent conformance checker
should be testing for it.)

In SSLv3 one can choose to changeCipherSuite to a null encryption and
null mac state, and merely use the fragmentation, sequencing and reassembly
functions of the SSL protocol machine. (Nothing in SSLv3 states how the
seq_num is calculated , note. It can be simple or fancy (provided it starts
at zero, when the connection state is initialized or assigned).)

In TLS, one can define and negotiate a local ciphersuite that does the same,
of course. PC->server does TLS RSA handshake and Netscape privacy-enhanced
step-up renegotiation (from Eric's book). Server->PC initiates a tunelled
SSL_NULL_WITH_NULL_NULL handshake, to negotiate a SSL_NULL_WITH_NULL_NULL
SSL Connection that gives us a record layer protocol with variable-length
framing, alerts and the ClientHello-signalled type-extensibility (over a
reliable bearer known as the outer TLS Connection). This is all very useful!

---

From: EKR <[email-masked]>
Date: Fri, 29 Dec 2006 13:54:40 -0800

<[email-masked]> wrote:
> TLS does indeed forbid the _negotiation_ of this defined
> ciphersuite. (This is
> why I phrased my claim in terms of SSLv3, which allows it.

Another way of looking at this is that it's a bug in the
SSLv3 spec that was fixed in TLS. Are you aware of any
implementation that in fact allows you to negotiate this
cipher suite?

> functions of the SSL protocol machine.

The what? SSL offers no capabilities here that are not offered
by the reliable transport it must ride on top of.

> (Nothing in SSLv3 states how the

I don't have the v3 spec in front of me, but if that's true, it's
a bug in the spec, IMO.

-Ekr

---

From: <[email-masked]>
Date: Fri, 29 Dec 2006 21:15:56 -0800

> by the reliable transport it must ride on top of.

Your missing my point.

Im not putting SSL record layer over TCP.... My SSL application is not 
https, it is
itself an SSL Connection, sending record_layer records data over... 
record_types of
an currently active (underlying) TLS Connection.

Like Ldap and HTTP1.1 update an TCP session to turn TLS Connection's on and 
off
for certain TCP fragments, I do the same with my outer SSL connection. When 
my upper layer
(inner SSL connection) sends a certain custom record_type into the stream, 
this is
recognized by the outer SSL Connection which does a certain class and type 
of handshake...

I'm doing nothing here that TLS Evidence is not suggesting (albeit by 
abusing alerts!)

Hopefully, I can read the 2nd half of your TLS/SSL book tomorrow, focusing 
on the
engineering discussion, rather than the protocol discussion.

> I don't have the v3 spec in front of me, but if that's true, it's

Perhaps!

"Each party maintains separate sequence numbers for transmitted and received 
messages for each connection. When a party sends or receives a change cipher 
spec message, the appropriate sequence number is set to zero. Sequence 
numbers are of type uint64 and may not exceed 264-1. "

For TLS1.0, one may assume that increment means uint64++ (which seems 
reasonable, when writing a
conformance/value/state checker)

    "Sequence numbers are of type uint64 and may not
       exceed 2^64-1. A sequence number is incremented after each
       record: specifically, the first record which is transmitted under
       a particular connection state should use sequence number 0."

I think SSLv3 is clearer than TLS, concerning when sequence number is set to 
zero. FOr SSL3,
its changedfor any variant of the change cipher spec message. For TLS, its
the :first: message under "a particular connection state". If TLS Evidence
changes the notion of Connection state (which it seems to do, being an
extension of connection state machine), we now now have alerts setting 
seq_num=0.
They jury is only going to ask what went before .... if the seq_num for
the audited handshake starts at 9225.

Hmm.

---

From: EKR <[email-masked]>
Date: Fri, 29 Dec 2006 21:26:48 -0800

>> by the reliable transport it must ride on top of.

Obviously.

> itself an SSL Connection, sending record_layer records data
> over... record_types of

SSL requires that the transport over which it is carried be a reliable
stream transport. For starters, it's implicit in the design of the
crypto (the use of stream ciphers and CBC chaining between
records).

> "Each party maintains separate sequence numbers for transmitted and
> received messages for each connection. When a party sends or receives
> a change cipher spec message, the appropriate sequence number is set
> to zero. Sequence numbers are of type uint64 and may not exceed
> 264-1. "
>

I believe that it is the consensus of pretty much all SSLv3 and TLS
implementors that it means start at zero and increment by one for all
versions of the spec.

> FOr SSL3,

The anti-replay guarantees of SSL/TLS (and the security guarantees if
you have an IV that depends on record seq #) depend on the property that
any given set of cryptographic keys may only be used once with a given
record sequence number. Since the Evidence extensions do not change
the cryptographic keys, they cannot allow the sequence number to
be reset.

-Ekr

---

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

> implementation that in fact allows you to negotiate this

I see no reason to see why one should not evaluate EAP-TLS as being
other containing a valid TLS protocol run. While RFC 2716 is marked
experimental, I see no non-standard uses of TLS. The custom
key derivation is in the EAP-TLS layer, assumes access
to the master_secret and nonces in much the same way as NSA/Eric are
proposing in current standards work on PRFs, here. The derivation
is not part of the SSL security state.

So, upon change cipher spec selecting the null ciphersuite, 
we know this has no impact on the EAP-TLS key derivation
for the per-connection keys/ivs/secrets. It does
however set the mechanism requirements for the PPP 
peer, when then negotiating ECP - if required.

So, when EAP-TLS simply do mutual auth, not requiring
any ECP SA session keys, do folks negotiate the NULL ciphersuite, or
do they negotiate the RSA ciphersuite and then just ignore the rule
carrying forward the TLS Connection state to the ECP state?