Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-wireless-00.txt

From: "Simon Blake-Wilson" <[email-masked]>
Date: Tue, 28 Nov 2000 11:48:28 -0500

Hi folks,

Magnus Nystrom and I posted this draft to try and get some discussion going
about the possibility of extending TLS to make life easier for wireless clients.
It seemed a little long to post straight to the mailing list ...

We'd really appreciate positive and negative comments (well okay, we'd prefer
positive comments, but ...)

Best regards. Simon

---------------------- Forwarded by Simon Blake-Wilson/Certicom on 11/28/2000
11:43 AM ---------------------------

[email-masked] on 11/28/2000 06:01:58 AM

Please respond to "IETF Transport Layer Security WG"
      <[email-masked]>

To:   "IETF Transport Layer Security WG" <[email-masked]>
cc:   [email-masked] (bcc: Simon Blake-Wilson/Certicom)
Subject:  [ietf-tls] I-D ACTION:draft-ietf-tls-wireless-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the
IETF.

     Title          : Wireless Extensions to TLS
     Author(s) : S. Blake-Wilson
     Filename  : draft-ietf-tls-wireless-00.txt
     Pages          : 13
     Date      : 27-Nov-00

This document suggests extensions to TLS designed to make TLS more
amenable to use within wireless environments. The extensions may be
used by TLS clients and servers. The extensions are backwards
compatible - communication is possible between TLS 1.0 clients
that support the extensions and TLS 1.0 servers that do not
support the extensions, and vice versa.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-wireless-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-tls-wireless-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
     [email-masked].
In the body type:
     "FILE /internet-drafts/draft-ietf-tls-wireless-00.txt".

NOTE:     The mail server at ietf.org can return the document in
     MIME-encoded form by using the "mpack" utility.  To use this
     feature, insert the command "ENCODING mime" before the "FILE"
     command.  To decode the response(s), you will need "munpack" or
     a MIME-compliant mail reader.  Different MIME-compliant mail readers
     exhibit different behavior, especially when dealing with
     "multipart" MIME messages (i.e. documents which have been split
     up into multiple messages), so check your local documentation on
     how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

mailto:[email-masked]
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-wireless-00.txt

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Andreas Sterbenz" <[email-masked]>
Date: Wed, 29 Nov 2000 15:05:10 +0100

I like the draft, here are my comments:

 . Although not related to wireless environments, I believe the initial set
of extensions should include the DNSname extension.

 . Maximum record size extension:
   . The maximum record size for TLS is not 2^14 bytes, that is the maximum
amount of application data per record. The maximum record size is header +
plain data size + compression size increase + padding + mac. The wording
should clarify this.
   . I think the server should be allowed to respond with a size different
than that requested by the client. The client can still accept the size
selected by the server of abort the handshake.
   . Some maximum record sizes (e.g. 256 bytes) may be smaller than some
handshake messages (e.g. certificate message). This is not a problem during
the initial handshake because the document specifies that the maximum record
size does not take effect until after the change cipher spec messages have
been sent. However, this may be a problem during a renegotiating handshake
which needs to be addressed in some way.

 . Client certificate URL extension:
   . The document seems to imply that the URL points to a certificate chain
in the usual TLS format although this is not explicitly said. This should be
clarified.
   . It may also makes sense to make recommendations wrt the protocols for
the URL (http, etc.)

 . There seems to be the assumption that the handshake is a full handshake.
Although there seem to be no changes required for an abbreviated handshake
this should be stated explicitly.

 . The document does not specify if the negotiated parameters, in particular
max. record size and MAC truncation, are associated with this connection
only or with the session. I.e. do the parameters have to be negotiated again
for subsequent connections using the same master secret?

 . Truncated MACs may be better suited to the next TLS version, however, it
may take some time before that arrives.

 . It should be more clearly defined what "clients MAY abort the handshake,"
etc. means, i.e. which alert is to be sent. That may include defining new
alert messages.

Regards,

 Andreas Sterbenz              mailto:[email-masked]

----- Original Message -----
From: "Simon Blake-Wilson" <[email-masked]>
To: "IETF Transport Layer Security WG" <[email-masked]>
Sent: Tuesday, November 28, 2000 5:48 PM
Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-wireless-00.txt

---

---

From: Magnus Nystrom <[email-masked]>
Date: Thu, 30 Nov 2000 11:39:04 +0100 (MET)

Andreas,

Thanks for your insightful comments.

> of extensions should include the DNSname extension.

If there is a consensus on this, we could certainly include it (actually,
this is the reason to reserve (0) in the ExtensionType enumeration...).

> plain data size + compression size increase + padding + mac. The wording

Yes, will do.

> selected by the server of abort the handshake.

Why? The client has indicated its maximum size, what would the reason be
for the server to use a smaller size?

> which needs to be addressed in some way.

This is a good observation, but will it become a problem in practice? I.e.
even if a 256-bit maximum record size has been negotiated, won't the
effect (during a re-negotiation) b just less-than-optimal number of
handshake messages?

> in the usual TLS format although this is not explicitly said. This should be

Actually, no. The intent is to point to _a_ client certificate. In this
case, the server will have to do the chaining itself.

>    . It may also makes sense to make recommendations wrt the protocols for

True. And also the kind of schemes that must be supported by servers. We
will include this in the next revision.

> this should be stated explicitly.

Good point.

> for subsequent connections using the same master secret?

That was not the intent. Basically, all negotiated parameters should be
part of the state for the connection. We discussed whether or not to
include a description of this in this version of the memo, but decided not
to (perhaps a bad decision), while we realized that it must be done at
some point.

> etc. means, i.e. which alert is to be sent. That may include defining new

Yes, will be done.

Thanks,
-- Magnus

 ----- Original Message -----
> You are currently subscribed to ietf-tls as: [email-masked]
> To unsubscribe send a blank email to [email-masked]
>

-- Magnus
Magnus Nyström
RSA Security

---