Subject: [TLS] TLS extension

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Sat, 20 Jan 2007 19:08:48 -0500

Hi,

What is the cleanest (or clean enough) way to extend TLS on server and on
the client? I recall reading in some posts about even an RFC to do it.
TIA,
Omirjan.

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

---

From: Mike <[email-masked]>
Date: Sat, 20 Jan 2007 16:31:54 -0800

> the client? I recall reading in some posts about even an RFC to do it.

There is an extension mechanism, but you can't use it for private
extensions.  All extensions must be approved by the IETF since
they could compromise the security of TLS.  See RFC 4366.

Mike

---

From: <[email-masked]>
Date: Sun, 21 Jan 2007 03:13:10 -0800

Take this with a pinch of salt, Mike - that IESG must 
approve your extension. National authorities are NEVER 
BEHOLDEN to an unrepresentative committee.

If they start to get all formal on you, just abuse the OCSP 
extension. It has its own extensibility model that you can 
abuse all day. And never forget you can define you own 
record_type whenever you want.

Now, more properly, in terms of commenting on actual 
documents:- overall extensibility policy for TLS, as issued 
by IESG, is looking weak. On the one hand you can define 
your own private messages types, your own private 
certificate types, private ciphersuites, but you cannot 
define your own extensions!?

When I looked at the flight of the standards, from TLS 1.0 
onwards, it all got less precise and controlled from TLS1.0 
onwards. TLS1.0 was a VERY tight spec. Then it all went into 
more typical IETF style with a flurry of updates and 
rewrites. Now there is a mix of tight and not-tight spec, a 
mix of editing styles, and some confusing policy signals due 
to the mix of mandate style(s).

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.

If someone has the formal WTLS spec for the modern WAP2.0 
spec on a public link, please supply it. I want to see how 
it evolved further, to merge with TLS extensions, tickets, 
DTLS etc (assuming that happened).

[http://www.wmlclub.com/docs/especwap1.2/SPEC-WTLS-19991105.pdf]

----- Original Message -----
From: "Mike" <[email-masked]>
To: <[email-masked]>

All extensions must be approved by the IETF since

---

From: <[email-masked]>
Date: Sun, 21 Jan 2007 11:59:44 -0800

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.

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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 Jan 2007 12:15:44 -0800

Peter,

<chair hat on>
WTLS is not an IETF standard. Discussions of WTLS are not
really on-topic for this mailing list.
</chair hat off>

To answer a few points you raise about DTLS.

<[email-masked]> writes:
> which has counter modes and AEAP to allow for (wide-area) routing of
> the datagrams 

DTLS does not depend on TLS 1.2 in any way.

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

ICMPs are not handled by DTLS one way or the other. Rather, 
they are handled by the transport layer and/or the consuming
application, as with TLS.

-Ekr