RE: [TLS] question: decode_eror

Concerning RFC 4366 updates to TLS1.1

The document state that "...clients MUST abort the handshake if they receive   an extension type in the extended server hello that they did not   request in the associated (extended) client hello."

it also asserts that:   " In the event that a client requests additional functionality using   the extended client hello, and this functionality is not supplied by   the server, the client MAY abort the handshake."
how does one "abort the handshake", in each case?

For example:- Does one send handshake_failure alert, at warning or fatal? Lets assume warning.

Upon "abort the handshake", does the updated TLS1.1 standard require either client or server 
implementations to perform a warning-level close_notify?
Peter.

From: home_pw@msn.comTo: tls@ietf.orgDate: Wed, 20 Dec 2006 12:43:03 -0800CC: Subject: [TLS] question: decode_eror

is the TLS1.0 procedure for creating alerts well established AND uniform in practice, for the last case below:-       In the interests of forward compatibility, it is permitted for a       client hello message to include extra data after the compression       methods. This data must be included in the handshake hashes, but       must otherwise be ignored. This is the only handshake message for       which this is legal; for all other messages, the amount of data       in the message must match the description of the message       precisely.For example, are folks required to send the alert: decode_error (mandatory fatal)? What does the IETF require of implementors concerning WHEN this is alert is sent, given the server.write queue may have data?

View Athletes' Collections with Live Search. See it! 
_________________________________________________________________
Try amazing new 3D maps
http://maps.live.com/?wip=51