[TLS] TLS extensions in ServerHello
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[TLS] TLS extensions in ServerHello



Hello,

currently, the TLS 1.2 draft says about the server_hello_extension_list:
"A list of extensions. Note that only extensions offered by the client
can appear in the server's list.". And for the client_hello_extension_list
is says "Clients MAY request extended functionality from servers by
sending data in the client_hello_extension_list."

As a consequnece, it is impossible for a server to e.g. tell a client to 
set certain things, if the client did not offer them before. In my case 
I have a server with very limited resources and a client running on a 
normal PC with almost no limitations. So the client will usually not 
send a max_fragemnt_length extension, because it does not really care 
about this. However, my server cares, but there is no way for it to 
tell this to the client. 

Should the spec force the clients to send a list of all supported 
extensions? Should the server be allowed to send anything in its
server_hello_extension_list, if the client said it supports TLS1.2?
And if so, how does the client confirm it accepted the extensions
send by the server?



---
Mit freundlichen Grüssen / Best regards

Axel Heider
NB4, Research and Development / Division New Business
Giesecke & Devrient GmbH, Prinzregentenstrasse 159, 81677 München, Germany
Tel.: +49-(0)89-4119-2693, E-Mail: axel.heider[at]gi-de.com , 
http://www.gi-de.com

Creating Confidence.
--------------------------------------------------------------

Vorsitzender des Aufsichtsrats: Dr. Peter Mihatsch
Geschäftsführer: Dr. Karsten Ottenberg (Vorsitzender, CEO),
Michael Kuemmerle, Hans Wolfgang Kunz,
Dr. Walter Schlebusch, Dr. Peter Zattler (CFO)
Gesellschaftssitz: München, Handelsregister Amtsgericht München HRB 4619. 


_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.