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

From: <[email-masked]>
Date: Fri, 1 Dec 2000 09:46:52 -0000

As I can't be at the SD meeting, I remotely signal support and interest for
the I-d, just in case there is a straw poll on this at the meeting.

Agree with Andreas that there is a need for new error alerts for the new
abort situations that the I-d gives rise to, e.g. client abort if server
indicates support of an extension the client did not indicate support of
(see section 2.3 of the I-d).  

I thought there was an issue of a server that didn't support the new
extensions not understanding the new alerts, but we can get round this by
specifying that if the server indicates support of any extensions in
ServerHello it must recognise all the new alerts and if the server does not
indicate support of the extensions in ServerHello then the situations
requiring the new alerts would not arise in any case.

These new alerts would be, with suggested titles:

- client must abort if receive extension in ServerHello that they did not
put in ClientHello, "unsupported_extension" (section 2.3)

- client and server must abort if receive extension list with extensions in
the wrong order, "bad_extension_order" (section 2.3)

- server abort if receive max record size negotiation request for
non-admissible values, "bad_record_size_request" (section 3.1)

- client abort if receive max record size negotiation response different
from requested (but perhaps this is open if we follow Andreas's suggestion
of allowing server to do this.  Agree with Magnus that we should not -
what's the point of the extension otherwise?), "bad_record_size_response"
(section 3.1)

- do we need a new condition and alert for the server to indicate that the
Cert URL, though of valid format, did not point to a cert, represented a
defunct domain, server down etc?  I think it would be useful to define such
a new alert, "cert_unobtainable", rather than use "unknown_certificate"
(section 3.2)

- server abort if client makes bad truncated MAC request,
"bad_truncated_mac_request", (section 3.5)

- client abort if server sends bad truncated MAC response,
"bad_truncated_mac_response", (section 3.5)

- client abort if server sends bad OCSP response, "bad_ocsp_response"
(section 3.6)

tim

---
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: Fri, 1 Dec 2000 15:45:17 +0100

> >    . 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.
>
> Why? The client has indicated its maximum size, what would the reason be
> for the server to use a smaller size?

I was actually thinking of a larger size, e.g. 512 byte instead of 256 byte
because the server does not implement the requested size. Although I think
this will hardly happen in reality it would be an extra feature that does
not complicate the protocol.

> >    . Some maximum record sizes (e.g. 256 bytes) may be smaller than some
> > handshake messages (e.g. certificate message). This is not a problem
[...]
> 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?

You are right, I was thinking about our implementation which currently
assumes that a handshake message is not split over multiple records.

> >  . Client certificate URL extension:
[...]
> Actually, no. The intent is to point to _a_ client certificate. In this
> case, the server will have to do the chaining itself.

I am not sure this is a good idea. IMHO certificate chains are always
better.

Regards,

 Andreas Sterbenz              mailto:[email-masked]

---

---

From: "Khaja E. Ahmed" <[email-masked]>
Date: Fri, 1 Dec 2000 08:58:25 -0800

> I am not sure this is a good idea. IMHO certificate chains are always

Is it a good idea to rely on the ability of a server to do path discovery
and chain building on its own?  I was under the impression that in practice
this is a not a viable option.

I would suspect that is it better for the standard to mandate that the
client submit its entire cert chain.  This should be a non issue for PC type
clients.  It might even work reasonably for storage space and bandwidth
constrained devices like cell phones with smart cards.  Or perhaps to
accommodate such devices submission of the entire chain can be the default
behavior and submission of just the EE cert can be allowed.  That way
servers that "know" they have to deal with such devices can do a better job
of implementing path discovery and chain building capability.

Khaja

---

---

From: Kat Hopwood <[email-masked]>
Date: Sat, 02 Dec 2000 01:03:55 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Andreas Sterbenz wrote:
> > > different than that requested by the client. The client can still
> > > accept the size selected by the server of abort the handshake.
> >
> because the server does not implement the requested size.

Why would that happen? Support for the extension should mean implementing all
possible record sizes (2^8..12 and 2^14), IMHO.

The only reason I can think of for allowing the server to change the record
size is if the server were also memory-limited, to a greater extent than the
client. This doesn't happen very often for typical uses of TLS, and in any
case using the extension mechanism for that case wouldn't solve anything,
because the server wouldn't be able to limit the record size if the client
does not suggest the extension.

While I remember, are the maximum lengths of TLSCompressed.fragment and
TLSCiphertext.fragment still to be record_size+1024 and record_size+2048
respectively? If they are, that makes the smaller record sizes (e.g. 2^8)
ineffective, because the client will still have to handle a buffer of 2304
bytes in the worst case.

> > even if a 256-[byte] maximum record size has been negotiated, won't the
> > effect (during a re-negotiation) be just less-than-optimal number of
> > handshake messages?
> 

Emphasize in the new draft that an implementation MUST handle handshake
messages that are split over multiple records (in fact RFC 2246 already
implies that it must, in section 6.2.1 by my reading, but obviously some
implementors haven't understood that).

> I am not sure this is a good idea. IMHO certificate chains are always

I agree - the contents of the URL should be the same as what would be sent
in the client Certificate message, i.e. a certificate chain.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

---

From: "Andreas Sterbenz" <[email-masked]>
Date: Mon, 4 Dec 2000 11:55:30 +0100

> does not suggest the extension.

For an AES ciphersuite (without MAC truncation) and a 256 record size the
average protocol overhead per record would be 33 byte or about 12%. This may
reduce the maximum number of concurrent connections for bandwidth limited
servers which is something they might want to avoid. This may be contrived,
but as I said before I was only suggesting the change because it is an extra
feature at no extra cost. If it does not happen, fine.

> ineffective, because the client will still have to handle a buffer of 2304

The 1024 for compression only apply when compression is active, which can
easily be avoided by the client by not requesting compression. The
additional 1024 for TLSCiphertext are just a theoretically allowed maximum
number for padding and MAC. For all RFC2246 plus the proposed AES
ciphersuites the maximum size of a TLSCiphertext (with null compression) is
data size + 5 (header) + 16 (padding) + 20 (MAC), i.e. for max. data 256
bytes this would be 297 byte or required memory.

Regards,

---

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Mon, 4 Dec 2000 10:27:41 -0500

Thanks for the comments, everyone!

> implementors haven't understood that).

Will do.

> in the client Certificate message, i.e. a certificate chain.

This seems like a tricky issue to me. I agree it may be a burden to expect the
server to retrieve an acceptable certificate chain. At the same time, I don't
like the idea that clients will have to store multiple urls to different
certificate chains.

When client authentication happens today, what's the average length of client
certificate chains?

Best regards. simon

---

---

From: David Hopwood <[email-masked]>
Date: Wed, 06 Dec 2000 00:56:58 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Andreas Sterbenz wrote:
> David Hopwood wrote:
> > Why would that happen? Support for the extension should mean implementing
> > all possible record sizes (2^8..12 and 2^14), IMHO.
> >
> > The only reason I can think of for allowing the server to change the
> > record size is if the server were also memory-limited, to a greater extent
> > than the client. This doesn't happen very often for typical uses of TLS,
> > and in any case using the extension mechanism for that case wouldn't solve
> > anything, because the server wouldn't be able to limit the record size if
> > the client does not suggest the extension.
> 
> For an AES ciphersuite (without MAC truncation)

I suggest simply making the AES ciphersuites use 80 bit MACs instead of
negotiating MAC truncation; I'll explain why in another post.

> and a 256 record size the average protocol overhead per record would be
> 33 byte or about 12%. This may reduce the maximum number of concurrent
> connections for bandwidth limited servers which is something they might
> want to avoid. This may be contrived, but as I said before I was only
> suggesting the change because it is an extra feature at no extra cost.
> If it does not happen, fine.

It does have a cost, in both complexity and interoperability problems.
What happens if a client has less than 2^14 bytes of memory remaining for
use by TLS? The server has no way to know just how tight the client is
on memory, other than trusting what the client says in the extension.

> The 1024 for compression only apply when compression is active,

No, the maximum size of a TLSCiphertext.fragment is currently defined to be
2^14 + 2048 regardless of whether compression is active or not. Remember
that the padding can be longer than one block, in order to obscure the
length of the plaintext record.

> which can easily be avoided by the client by not requesting compression.

That's an ugly kludge, and it doesn't solve the problem anyway. Why not
change the maximum TLSCompressed and TLSCiphertext fragment sizes to
record_size + 64 and record_size + 128 respectively when record_size != 2^14?

> The additional 1024 for TLSCiphertext are just a theoretically allowed
> maximum number for padding and MAC.

If it's theoretically allowed then the client MUST be able to allocate
that amount of memory (otherwise it may find that the 2048 additional bytes
are actually used, which is valid according to the spec, and not be able to
continue with the session).

> For all RFC2246 plus the proposed AES ciphersuites the maximum size of
> a TLSCiphertext (with null compression) is data size + 5 (header) +
> 16 (padding) + 20 (MAC), i.e. for max. data 256 bytes this would be
> 297 byte or required memory.

No, this is not correct. The overall maximum size of a TLSCiphertext
record would be 5 + 256 + 2048 = 2309 bytes (the MAC is counted in the
256 + 2048), unless the amount of extra space allowed for padding is
reduced.

- -- 

---

---

From: David Hopwood <[email-masked]>
Date: Wed, 06 Dec 2000 00:57:17 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Simon Blake-Wilson wrote:
> David Hopwood wrote:
> > I agree - the contents of the URL should be the same as what would be
> > sent in the client Certificate message, i.e. a certificate chain.
> 
> This seems like a tricky issue to me. I agree it may be a burden to
> expect the server to retrieve an acceptable certificate chain.

I don't see how it would be done at all. When there are 3 or more
certificates in the complete chain, how is the server to know where to
find the middle ones (assuming it does not know what they should be
already)?

> At the same time, I don't like the idea that clients will have to store
> multiple urls to different certificate chains.

Each certificate is normally associated with a single chain (i.e. the
X.509 certificate hierarchy is a tree, not a directed graph), so AFAICS
the client wouldn't have to store any more data than it would if an
URL only pointed to a single certificate.

- -- 

---

---

From: "Andreas Sterbenz" <[email-masked]>
Date: Wed, 6 Dec 2000 10:34:45 +0100

> 256 + 2048), unless the amount of extra space allowed for padding is

You are right about the padding being 256 byte max, but the rest still
holds. The TLS limits do not matter if the ciphersuites used define tighter
limits. If you want to prove me wrong show it in an example.

TLS client sends client hello: NULL compression, ciphersuite
TLS_RSA_WITH_AES_128_CBC_SHA (add others if you want), record size 256.
Now explain how a TLS compliant server (assuming it accepts the 256 byte
maximum record size) can send a record in excess of 5 + 256 + 256 + 20 = 537
byte or why a client would need more storage for the record than 537 byte.

---

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 7 Dec 2000 11:42:15 +0100

On Tue, Nov 28, 2000 at 06:01:58AM -0500, [email-masked] wrote:

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

< 2.3. Hello Extensions
< 
< The extension format for extended client hellos and extended server
< hellos is:
< 
<           struct {
<               ExtensionType extensionType;
<               opaque unknown_extension<0..2^16-1>;
<           } Extension;
< 
< Here:
< 
< - "extensionType" identifies the particular extension type.
< 
< - "unknown_extension" contains information specific to the particular
<   extension type. 

Why do you call it "unknown_extension"?  One would hope that client
and server do know the extensions that they actually use.
Why not call it

              opaque extension_data<0..2^16-1>

or

              opaque extension_parameters<0..2^16-1>

or something like that?

< 3.1. Maximum Record Size Negotiation

< Once a maximum record size other than 2^14 has been successfully
< negotiated during a TLS handshake, both the client and server pass the
< negotiated maximum record size value to the TLS record layer along with
< the negotiated security parameters. (Note that it may be desirable in
< the future to update the TLS security parameters to include the maximum
< record size value.) During the subsequent session after exchange of
< change cipher spec messages, the client and server MUST ensure that no
< messages larger than the negotiated size are sent.

What exactly does "Once a maximum record size ... has been
.. negotiated" mean?  Since possibly the client cannot handle large
records at all, the ServerHello message should already be sent using
small records.  The other "negotiated security parameters" to be
passed to the TLS record layer have not yet been determined at this
stage, though, so if the maximum record size is passed to the record
layer along with these security parameters, then the handshake
might contain records that are too large for the client to handle.

What is supposed to happen if a renegotiation is performed?
Does the maximum record size survive into the new session
without having to be negotiated again?

< 3.2. Client Certificate URLs
   
< Servers receiving "CertificateorURL" shall attempt to retrieve the
< client's certificate chain from the URL (if necessary), and then process the
< certificate chain as usual.

The specification should give some details on what the data to be
obtained from the URL should look like -- just a DER-encoded octet
stream, or a TLS "Certificate" object as defined in RFC 2246, or
whatever.

< 3.3. Trusted CA Indication

< Wireless clients which, due to memory limitations, possess only a small
< number of CA root keys, may wish to indicate to servers which root keys
< they possess, in order to avoid repeated handshake failures.

< Here "TrustedAuthorities" provides a list of CA root key identifiers
< that the client possesses. Each CA root key is identified via either:
< 
< - "null" - no CA root key identity supplied.
<        
< - "key_hash_sha" - contains the SHA-1 hash of the CA root key. (For DSA
<   and ECDSA keys, this is the hash of the "subjectPublicKey" value. For
<   RSA keys, this is the hash of the byte string representation of the
<   modulus.) 
<        
< - "x509_name" - contains the X.509 distinguished name of the CA.

By giving just one of these, it is not necessarily possible to
uniquely determine the intended issuer and key.  A CA may have two
certificates using exactly the same distinguished name (RSA and DSA
certs, say), but there might also be certificates naming different
issuers and containing identical keys -- so in extreme cases both the
"key_hash_sha" and "x509_name" would have to be specified.  In less
pathological situations where giving just one of these is enough, the
client usually still cannot know which one it should use.  Maybe the
CA has started to issue DSA certs, so "key_hash_sha" should be used.
But maybe a new root certificate uses the same key and a different
distinguished name (I'm not really sure why anyone would want to do
this -- trademark disputes, possibly; anyway, it certainly is legal),
so "x509_name" might be necessary.

For the "key_hash_sha" case, why not hash all of "subjectPublicKey"
for RSA keys?  A CA might use related RSA keys (same modulus,
different exponents) for different roles, so hashing just the
modulus may not suffice.

< 3.5. Truncated MACs

< In order to negotiate the use of truncated MACs, clients MAY include an
< extension of type "truncated_MAC" in the extended client hello. The
< "unknown_extension" field of this extension shall contain
< "MACTruncations", where:
< 
<           MACTruncation MACTruncations<0..2^8-1>;
< 
<           struct {
<               MACAlgorithm mac_type;
<               uint16 trucation_size_in_bits
<           } MACTruncation;
< 
<           enum { null(0), md5(1), sha1(2), (255) } MACAlgorithm;
< 
< Here "MACTruncations" contains a list of MAC truncation sizes suggested
< by the client. [...]

This allows for rollback attacks if the *minimum* of truncated MAC
sizes that are acceptable to both the client and the server has become
unsecure.

To make sure that the server and not the attacker can decide which MAC
size of those that are acceptable to both the client and the server is
used (e.g., the maximum), the server's signature in the
ServerKeyExchange message should cover all of the ClientHello message
instead of just ClientHello.random.  Similarly (at least if no
ServerKeyExchange message is used) the EncryptedPreMasterSecret
message should contain a hash of the ClientHello message instead of
just client_version.

(These changes are desirable for other reasons anyway: Attackers who
can crack export-weakend ephemeral DH or RSA keys in real-time [i.e.,
before the server switches to a new ephemeral key] currently can force
clients and servers that are not export-crippled to use export ciphers
suites.  If the signature in the ServerKeyExchange and the encrypted
data in the EncryptedPreMasterSecret are changed as above, this
problem can be avoided; however, backwards compatibility will allow
for protocol version rollback attacks, so we cannot really solve this
existing problem in the near future.  But we can avoid similar
problems for new protocol variants, such as TLS with truncated MACs.)

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

---

---

From: David Hopwood <[email-masked]>
Date: Fri, 08 Dec 2000 05:26:09 +0000

-----BEGIN PGP SIGNED MESSAGE-----

[email-masked] wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-tls-wireless-00.txt
> 
>                         Wireless Extensions to TLS
>                      <draft-ietf-tls-wireless-00.txt>

This draft will be referred to for all extensions, including those
that don't have anything to do with wireless, so it should probably be
called just something like "Extensions to TLS" (especially if the
dns_name extension is also included).

For example:

                             Extensions to TLS
                    <draft-ietf-tls-extensions-00.txt>

...

1. Introduction

This document describes an extension mechanism that can be used
to add functionality to the Transport Layer Security protocol [TLS].
The focus of most of the extensions defined here is on support for
wireless and limited memory environments. An extension designed to
support virtual hosting of TLS servers is also defined.

Wireless environments often suffer from a number of constraints not
commonly present in wired environments - these constraints may include
bandwidth limitations, computational power limitations, memory 
limitations, and battery life limitations.

Use within wireless environments was not one of the initial design
criteria of the TLS protocol. As a result, implementations of TLS
within wireless environments face a number of challenges.

The extensions described here focus on extending the functionality
provided by the TLS protocol message formats. Other issues, such as
the addition of "wireless-friendly" cipher suites, are deferred or
left to other specifications.

Although not an extension as such, this document also encourages
servers to use small session identifiers; this is again motivated
by support for limited memory environments.

...
> - Allow TLS clients and servers to negotiate the use of truncated MACs.
>   This functionality is desirable in order to conserve bandwidth in
>   wireless networks.

I strongly feel that this should not be negotiated separately from the
ciphersuite. We can specify that the new AES ciphersuites always use an
80-bit MAC; that would not result in any loss of security (given that
SSL/TLS requires the session to be immediately aborted if a MAC is
incorrect, so the forgery probability would be limited to 2^-80 per
session).

Reasons for not negotiating MAC size separately:

 - The security and efficiency effects of truncating the MAC to a
   particular size will vary between different MAC algorithms (for
   example they vary between HMAC and UMAC, and it's quite possible
   that UMAC-based ciphersuites will be added to TLS at some point).
   Even though the proposed mechanism allows different sizes for
   different MAC algorithms, configuring that could be quite
   complicated for users and server administrators.

 - Future ciphersuites might merge the encryption and MAC into a
   single algorithm for efficiency (e.g. using one of the modes
   described in the recent AES modes conference; see
   <http://csrc.nist.gov/encryption/aes/modes/>). In that case it is
   not clear that specifying the MAC output size makes sense.

 - Negotiating different parts of the ciphersuite orthogonally has been
   discussed before and rejected, IMHO for sound reasons. In particular,
   requiring each combination to be defined explicitly limits the
   number of combinations that have to be considered in analysis.

 - APIs for SSL/TLS libraries may assume that a list of ciphersuites
   is all that needs to be given in order to specify a policy on which
   algorithm variants are considered secure. In general, this would not
   be true any more if separate MAC size negotiation was added.

 - In practice making new ciphersuites have truncated MACs is just as
   good as being able to negotiate them for any ciphersuite, since any
   (client, server) pair that both implement the extension would also
   presumably implement at least some of the AES ciphersuites, and
   would probably negotiate one of them almost all the time.

I.e. I suggest removing the truncated_MAC extension, and making the
AES ciphersuites always use 80-bit MACs (i.e. *_SHA_80).

I also think dns_name should be included. Here is a suggested syntax,
taking into account the previous discussions on this topic:

   opaque DNSName<1..2^16-1>;
   enum { success(0), unrecognised_name(1), (255) } DNSStatusCode;

   The extension sent by the client is of type DNSName, which
   represents the fully qualified domain name of the server, as
   understood by the client. This value is intended to be used by
   servers which support multiple "virtual" servers on a single
   underlying network address. A server that understands this
   extension MAY use this value to decide which certificate to use
   in subsequent negotiations.

   A DNS name is represented as an octet string using UTF-8 encoding,
   subject to any further standardisation by the IETF DNS working
   group of how non-ASCII names are handled. [[reference to DNS RFC?]]

   [[Are dotted-decimal IP addresses allowed/useful?]]

   The response by the server is of type DNSStatusCode. A 'success'
   response means that the server has taken the name into account in
   deciding which certificate to use. An 'unrecognised_name'
   response means that although the server implementation understood
   the extension, it does not recognise the DNS name as belonging to
   a (possibly virtual) server it is responsible for.

   Clients SHOULD include a dns_name extension whenever they locate
   a server by its domain name, unless an application profile for
   the protocol being used over TLS specifies otherwise.

The defined extension types would then be

   enum { 
      dns_name(0),
      max_record_size(1), 
      client_certificate_url(2),
      trusted_key_ids(3), 
      status_request(4), (65535) 
   } ExtensionType;

> Finally note that it is possible to alternatively define
> "unknown_extension" using a selection on "extensionType" (instead of
> just defining it as type "opaque"). This approach appears to have pros
> and cons - using a selection is more restrictive and thus less prone to
> implementation errors, but using "opaque" ensures inclusion of the
> length and thus ensures that users can skip extensions they don't
> understand. We would particularly welcome comments on this issue.

The length has to be included, because it's essential that extensions
that are not understood can be skipped. The above paragraph should not
appear in the next draft, of course.

> 3. Wireless Extensions

Just say "Extensions", since they're not specific to wireless.

> 3.1. Maximum Record Size Negotiation

An example of maximum TLSCompressed and TLSCiphertext sizes should be
added (see my other post).

> 3.2. Client Certificate URLs

I think the contents of the URL should be a complete certificate chain.

>          struct{
>               Certificate_or_URL certificate_transport_type;
>               select (Certificate_or_URL) {
>                   case certificate: 
>                       ASN.1Cert certificate_list<0..2^24-1>;
>                   case url: 
>                       opaque url<0..2^8-1>;
>               } certificate_transport_body;
>          } CertificateorURL;

Should this say URI rather than URL?

>          enum{ certificate(1), url(2), (255) } Certificate_or_URL ;
> 
> (Nevertheless, the handshake message is identified as being of type
> "certificate".)  

Since it is encoded differently, it should be given a new handshake
message type. Even though it would not matter much in this particular
case, in general I don't think that overloading a message type to
contain different information depending on whether an extension has
been accepted is a good idea.

> 3.3. Trusted CA Indication

>           struct {
>               IdentifierType identifier_type;
>               select (identifier_type) {
>                   case null: struct {};
>                   case key_hash_sha: KeyHash;
>                   case x509_name: DistinguishedName;

Add here
                    default: opaque unknown_identifier<0..2^16-1>;

for future extensibility, and make KeyHash variable length so that
all the types are encoded the same.

>               } identifier;
>           } TrustedAuthority;
> 
>           enum { null(0), key_hash_sha(1), x509_name(2),(255)}
>               IdentifierType;
> 
>           opaque DistinguishedName<1..2^16-1>;
> 
>           opaque KeyHash[20];
> 
> Here "TrustedAuthorities" provides a list of CA root key identifiers

> that the client possesses. Each CA root key is identified via either:
> 
> - "null" - no CA root key identity supplied.

I don't see the point of this. It appears to only be used in section
3.6, and there it would be simpler for the case where the authorities
are implicitly known to be encoded as a zero-length sequence of
TrustedAuthorities.

(It is not useful to be able to represent the fact that a client does
not trust any authorities, since then it could never accept a connection.)

> - "key_hash_sha" - contains the SHA-1 hash of the CA root key. (For DSA
>   and ECDSA keys, this is the hash of the "subjectPublicKey" value. For
>   RSA keys, this is the hash of the byte string representation of the
>   modulus.)

IMHO this should be the hash of an unambiguous encoding. The above isn't
unambiguous:
 - an RSA key has a public exponent as well as a modulus,
 - technically an RSA modulus might have the same representation as a
   DSA/ECDSA SubjectPublicKey value.

Although there doesn't appear to be any attack as a result of this, it
would be more straightforward for the hash to be of the SubjectPublicKey
value for RSA as well as DSA/ECDSA keys (DER-encoded, i.e. exactly as it
appears in the certificate). Alternatively it could be a hash of the whole
certificate.

...
> The syntax used by TLS for session identifiers is:
> 
>           opaque SessionID<0..32>;
> 
> In order to encourage use of small session identifiers, servers SHOULD
> select session identifiers whose length is 8 bytes or less.

Session identifiers MUST have negligable probability of being repeated
within, say, 24 hours, since if a client tries to connect with an
identifier that has been reused, the handshake will break.

Since use of small session identifiers is not (and does not need to be)
an extension, it should probably be moved out of section 3 to its own
section.

> 3.5. Truncated MACs

As explained above, I think this should be removed. If it is not removed,
though, the padding of MAC sizes that are not a multiple of 8 bits is
ambiguous.

> 3.6. OCSP

> (Nevertheless, the handshake message is identified as being of type
> "certificate".) 

Same comment here as for CertificateorURL.

> Here "ocsp_response" contains a complete, DER-encoded OCSP response.

Specify the name of the ASN.1 type from [OCSP].

> Clients requesting an OCSP response, and receiving an OCSP response in
> a "CertificateAndOCSPResponse" field:
> 
> - MUST process the certificate as if it was received in a "Certificate"
>   message, and;
> 
> - MAY check the OCSP response and abort the handshake if the response
>   is not satisfactory.

For the security considerations:

If a client requests an OCSP response, it must take into account that
an attacker's server using a compromised key could pretend not to support
the extension.

In that case it should either try to verify the certificate by some
other method (e.g., using OCSP directly, so that this extension is just
treated as an optimisation), or its reaction should be the same as if
the OSCP response was invalid. In particular, it is *never* reasonable
to simply ignore the fact that a server appeared not to support
status_request, and proceed anyway.

- -- 

---

---

From: David Hopwood <[email-masked]>
Date: Fri, 08 Dec 2000 05:26:54 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Andreas Sterbenz wrote:
> holds. The TLS limits do not matter if the ciphersuites used define
> tighter limits.

I stand corrected - as you say the maximum size is at most
5 + 256 + 256 + 20 = 537 bytes for all currently defined ciphersuites
with NULL compression. I was thinking that the TLSCiphertext had to be
decrypted before checking the length, but in fact there is no problem
(security or otherwise) if an implementation aborts with a
decryption_failed alert whenever a TLSCiphertext.length is greater
than possible for a valid record.

(On a strict reading of the spec, the alert should be record_overflow
when the length is > 2^14 + 2048, and otherwise decryption_failed when
it is > max_record_size + 512 + mac_size for a block cipher or
> max_record_size + 256 for a stream cipher, but it doesn't really
matter which alert is used.)

Since it took 3 tries for us to arrive at the correct method of
determining the maximum size, it must not be obvious, though, so
perhaps there needs to be a paragraph in the draft saying that the
maximum record sizes depend on the negotiated ciphersuite and
compression method, and giving an example. It should also clarify
that a fatal decryption_failed *or* record_overflow abort occurs when
a record is larger than that.

- -- 

---