Re: [TLS] TLS extension

[<home_pw at msn.com>]

This is purely FYI, concerning mostly the client key id 
extension implications, in WTLS. I've been comparing alert 
signaling of DTLS with WTLS's analogous datagram mode, of 06 
Avril 2001. The alerts that differ between the two seem to 
be well specified in the WTLS text, but the associated 
procedures change the semantics of several security critical 
functions.

time_required(11),
unknown_key_id(52),
disabled_key_id(53),
key_exchange_disabled(54),
session_not_ready(55),
unknown_parameter_index(56),
duplicate_finished_received(57),

Unlike DTLS which presumably really hinges on TLS (1.2) - 
which has counter modes and AEAP to allow for (wide-area) 
routing of the datagrams - I don't see any of this kind of 
key scheduling apparatus in WAP.  At the same time, WAP is 
essentially about point to point record transfers & 
gatewaying. We do later see a key_refresh process - a 
function of seq_number handling (a scheme that presumably 
assumes small windows, appropriate to P2P links)

1. Clearly, the WTLS keyid are a shared secret regimes, much 
like WEP of the same era; we have the master_Secret KDF and 
we have 16 byte nonces in the this and final KDF, of which 
14 are random.  This 14 byte non-secret nonce is the IV, in 
some ciphersuites.

1a. Re that SuiteB I-D, in WTLS, there would be no problem 
with the resume session exchanging new (extended) nonces, 
for the opaque PRF case. In WAP, one just uses the classical 
SSLv3-era extended Client/ServerHellos for sharing 
(extended) nonces values; whereas in TLS doctrine, one must 
use handshake specific messages per TLS extension 
negotiation - which don't flow that well under the intended 
state machine of the session resume case.

2. We also have cleartext alerts (that presumably the 
network itself can introduce), that an implementation can 
choose to regard as fatal. One of the cleartext alerts may 
be time_required, which I'm not sure if it's the network or 
the wap gateway that produces this. Could we imagine a ICMP 
packet from a intermediate router influencing the sending 
DTLS in a similar way??

3. for key_exchange_disabled (for anonymous modes e.g. 
self-signed RSA certs), the alert seems to say: don't 
replace one anonymous grade authentication with another. At 
the same time, this reduces how much RSA operations one 
could be performing. Presumably, this is to stop time 
wasting on the formal rationale, and to perhaps limit RSA 
repurposing. Lots of anonymous 20 byte rsa exchanges can add 
up to a decent channel under RSA cryptostrength.

4. Now, All these seem to add up. The semantics of session 
closing change a little. One can now influence active, 
current (and duplicated) sessions, with alerts. I not 
entirely sure I understand what the equivalent regime is for 
DTLS, concerning fatal's semantics, during (1) active 
connection security state, versus (2) when 
pending=active=null

"A fatal alert only terminates the session to be created and 
leaves the existing session intact if the handshaking is 
conducted
on an existing secure session. However, there may be some 
cases that closing the existing session is desirable. A
session_close_notify MUST be sent to the peer if one of the 
parties decide to terminate the existing session immediately
after a fatal alert is sent or received during a handshake 
that intends to create a new session. Under any other
circumstances, a fatal alert is treated normally as 
described at the beginning of this section."

5. The notion of client key id leads to the PMS, at least 
for RSA. Thus pre-master secret handling is novel (to me, 
anyways, for RSA): "This random value is generated by the 
client. This value appended with the public key is used as 
the pre-master secret which is used to generate the master 
secret, as specified in Chapter 11." So, basically, only 20 
byes are unknown (unlike 48 in TLS). Why? And the PMS is 
formally these 20 bytes plus the server's public key value, 
at the start of the PRF, with a public string, and public 
nonces. Any ideas what is happening here? Handling 20 bytes 
cleartext in RSA is the ~same decipherment time as 48 
cleartext bytes, under PKCS#1 type 2. Unless there is a 
datagram explanation here, what's the rationale?

6. we see that the key_refresh function over seq_numbers 
causes the key_block to be refreshed, changing the symmetric 
key periodically. And the nonce is used as the IV, in export 
mode ciphers.

7. we have to remember that WTLS cannot do it own 
fragmentation, unlike DTLS. Upper layer stacks protocols get 
to control when keys are changed, therefore in WTLS.

by compare and contrast of connectionless TLSs, looking at 
SuiteB's GCM, the work in AEAP, I think I'm beginning to get 
a handle on TLS 1.2 era work.

> Incidentally, I have been looking at WTLS 1.2, for my 
> Bluetooth/voip project. There is a lot IETF could learn 
> from that (monotonic seq_numbers for datagrams, not 
> increasing; use of nullWithNull; multiplexed connections; 
> extensions). The design art is all open (including all the 
> debates about how to handle TCP in a wire/wireless 
> environment). It is just so NOT DOGMATIC; it just takes 
> SSLv3 and updates it for the different KDFs in the TLS-era 
> and then tunes it for the different bearers and upper 
> layer stack process. It just does several jobs, without 
> any pretension. The state machines are excellent addition 
> to the community art, as is the formal model of the 
> protocol spec.

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