Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

always require key_share extension with (EC)DHE suites #349

Merged
merged 3 commits into from Dec 15, 2015
Merged

always require key_share extension with (EC)DHE suites #349

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e03fa75
always require key_share extension with (EC)DHE suites
davegarrett Nov 26, 2015
f91d3bc
reconcile group priorities & clarify retry requirement
davegarrett Nov 27, 2015
3662a37
specify response to bogus key share
davegarrett Dec 12, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
53 changes: 40 additions & 13 deletions draft-ietf-tls-tls13.md
View file
Open in desktop
Expand Up @@ -2419,14 +2419,17 @@ must consider the supported groups in both cases.
The "key_share" extension contains the endpoint's cryptographic parameters
for non-PSK key establishment methods (currently DHE or ECDHE).

Clients which offer one or more (EC)DHE cipher suites
MUST send at least one supported KeyShare value and
servers MUST NOT negotiate any of these cipher suites unless a supported
Clients which offer one or more (EC)DHE cipher suites MUST send this
extension and SHOULD send at least one supported KeyShareEntry value.
Servers MUST NOT negotiate any of these cipher suites unless a supported
value was provided.
If this extension is not provided in a ServerHello or retried ClientHello,
If this extension is not provided in a ServerHello or ClientHello,
and the peer is offering (EC)DHE cipher suites, then the endpoint MUST close
the connection with a fatal "missing_extension" alert.
(see {{mti-extensions}})
Clients MAY send an empty client_shares vector in order to request
group selection from the server at the cost of an additional round trip.
(see {{hello-retry-request}})

%%% Key Exchange Messages
struct {
Expand Down Expand Up @@ -2465,12 +2468,12 @@ The "extension_data" field of this extension contains a

client_shares
: A list of offered KeyShareEntry values in descending order of client preference.
This vector MUST NOT be empty. Clients not providing a KeyShare MUST instead
omit this extension from the ClientHello.
This vector MAY be empty if the client is requesting a HelloRetryRequest.
The ordering of values here SHOULD match that of the ordering of offered support
in the "supported_groups" extension.

server_share
: A single KeyShareEntry value for the negotiated cipher suite. Servers
MUST NOT send a KeyShareEntry value for a group not offered by the client.
: A single KeyShareEntry value for the negotiated cipher suite.
{:br }

Servers offer exactly one KeyShareEntry value, which corresponds to the
Expand All @@ -2481,11 +2484,22 @@ a single set of key exchange parameters. For instance, a client might
offer shares for several elliptic curves or multiple integer DH groups.
The key_exchange values for each KeyShareEntry MUST by generated independently.
Clients MUST NOT offer multiple KeyShareEntry values for the same parameters.
Clients MAY omit this extension from the ClientHello, and in response to this,
servers MUST send a HelloRetryRequest requesting use of one of the
groups the client offered support for in its "supported_groups"
extension. If no common supported group is available, the server MUST
produce a fatal "handshake_failure" alert. (see {{hello-retry-request}})
Clients and servers MUST NOT offer any KeyShareEntry values for groups not
listed in the client's "supported_groups" extension.
Servers MUST NOT offer a KeyShareEntry value for a group not offered by the
client in its corresponding KeyShare.
Implementations receiving any KeyShare containing any of these prohibited
values MUST abort the connection with a fatal "illegal_parameter" alert.

If no mutually supported group is available between the two endpoints' KeyShare
offers, yet there is a mutually supported group that can be found via the
"supported_groups" extension, then the server MUST reply with a
HelloRetryRequest (unless there is a mutually supported cipher suite not
requiring this extension which is offered by the client at a higher priority
than all those requiring this extension, in which case that cipher suite
SHOULD be negotiated instead, and this section is not applicable).
If there is no mutually supported group at all, the server MUST abort the
connection with a fatal "handshake_failure" alert.

[[TODO: Recommendation about what the client offers.
Presumably which integer DH groups and which curves.]]
Expand Down Expand Up @@ -3907,6 +3921,19 @@ TLS protocol issues:
past the start of the cleartext in the event that the peer has sent
a malformed plaintext of all-zeros?

- Have you ensured that forward secrecy is always negotiated when it
is supported and prioritized over non-FS cipher suites?
In particular:
When both endpoints support an (EC)DHE cipher suite and a plain PSK
cipher suite at a lower priority, and both endpoints support a group
offered via the client's "supported_groups" extension which is
compatible with the former, yet no corresponding KeyShareEntry was
provided via the client's "key_share" extension, does the server
correctly respond with a HelloRetryRequest for the prioritized
(EC)DHE cipher suite and the required group? Does the client respond
to this HelloRetryRequest with a new ClientHello which successfully
negotiates this cipher suite with this group?

Cryptographic details:

- What countermeasures do you use to prevent timing attacks against
Expand Down