[TLS] Proposed changes to draft-ietf-tls-rfc4366-bis

["Joseph Salowey (jsalowey)" <[e-mail]>]

Below are proposed changes to resolve open items with
draft-ietf-tls-rfc4366-bis.  If these are OK then we should submit a new
revision and move the document forward.  

Add to Section 3 after the pseudo-code structure to resolve possible
ambiguity with multiple names of the same type:

"The ServerNameList MUST NOT contain more than one name of the same 
name_type. If the server understood the client hello extension but
does not recognize any of the server names, it SHOULD send an
unrecognized_name(112) alert (which MAY be fatal)." 



Add to section 3 before the last paragraph to clarify session resumption
behavior:

"When the server resumes a session, the server_name extension is
ignored." 

TO clarify use of SHA-1 without agility:

Section 11.3:
ADD:
   This extension continues to use SHA-1 (like in RFC 4366), and does
   not provide algorithm agility. The property required of SHA-1 is
   second pre-image resistance, not collision resistance.
   Furthermore, even if second pre-image attacks against SHA-1 are
   found in the future, an attack against client_certificate_url 
   would require a second pre-image that is accepted as a valid
   certificate by the server, and contains the same public key.

Section 11.4:
OLD:
   The use of the SHA-1 certificate hash alternative ensures that each
   certificate is specified unambiguously.  As for the previous
   extension, it was not believed necessary to use both MD5 and SHA-1
   hashes.
NEW:
   The use of the SHA-1 certificate hash alternative ensures that each
   certificate is specified unambiguously. This context does not
   require a cryptographic hash function, so the use of SHA-1 is
   considered acceptable, and no algorithm agility is provided.