Subject: [ietf-tls] TLS extensions comments

From: "Simon Blake-Wilson" <[email-masked]>
Date: Fri, 19 Jan 2001 10:38:40 -0500

Hi folks,

Many thanks for all the comments on the TLS extensions draft. Magnus and I are
in the process of producing an updated draft folding in all the suggestions we
received for improvements. There are a few issues where we'd like to solicit
comments on proposed resolutions or seek feedback with a view to getting
consensus. Comments please.

1. Truncated MACs ... our original draft supported truncated MACs via the
general hello extension mechanism. We received a number of comments in support
of this approach (which avoids ciphersuite explosion), and a number of comments
in favour instead of defining truncated MACs via new cipher suites (which avoids
addressing cipher suite issues outside of cipher suite definition). Our
inclination is to leave definition as an extension mechanism, but leave the door
open for future cipher suites to define truncated MACs as part of the cipher
suite for cipher suites involving new algorithms like AES.

2. Certificate URLs ... our draft allowed a single cert to be referenced rather
than a cert chain (placing the burden for chain building on servers). Again
several comments supported this approach to save complexity on constrained
clients, while several comments felt chain building was an unacceptable burden
to place on servers and therefore favoured using a single URL to reference a
cert chain. We'd like to propose a compromise solution in which each URL
references a single cert, but a list of URLs corresponding to a cert chain may
be transmitted by clients.

3. Maximum record size negotiation ... the draft was unclear on whether
negotiated maximum record sizes apply during session resumption. We propose to
clarify that the negotiated size does apply during resumption, but remove the
smallest sizes to avoid substantial fragmentation of handshake messages during
resumption.

4. Trusted key ids ... several comments suggested that it may be desirable to
identify trusted key ids by both DN and key hash. We're open to allowing this
possibility while continuing to allow the options to identify via only DN and
only key hash when these options are sufficient to uniquely identify the keys
... but are concerned about the potential increase in complexity. Note that RFC
2246 currently identifies trusted keys held by the server simply by the
ditinguished name, right? Comments please.

5. DNS name extension ... several comments requested to add the proposed DNS
name extension to the draft. We agree and will approach the original proponents
of this extension to see if they would like to be added as co-authors of the
draft.

6. New error messages ... it's been pointed out that the draft should add new
error messages to support errors that may arise as a result of the extensions.
We propose to add new messages, along with rules for when these error messages
may be sent in order ot avoid the new messages breaking existing clients and
servers.

7. Short session ids ... the draft recommended the use of short session ids (in
order to potentially save some bandwidth and memory on clients). Eric Rescorla
commented that he felt this recommendation did not offer significant benefits,
and that the cost of updating existing server implementations to follow the
recommendation was therefore not justified. We'd appreciate any other opinions
on this issue in order to try and gain a sense of the overall feeling within the
group.

Best regards. Simon

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