Re: [TLS] Comments on TLS identity protection

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!

----- Original Message -----
From: "Martin Rex" <martin.rex@sap.com>
To: <ekr@networkresonance.com>
Cc: <home_pw@msn.com>; <tls@ietf.org>
Sent: Thursday, December 28, 2006 4:59 AM
Subject: Re: [TLS] Comments on TLS identity protection

> EKR wrote:
>>
>> 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".
>
> 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
> 

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