RE: [TLS] question: decode_eror

[Peter Williams <home_pw@xxxxxxx>]

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@xxxxxxx
To: tls@xxxxxxxx
Date: Wed, 20 Dec 2006 12:43:03 -0800
CC:
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 Check it out!
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls