On Fri, Nov 27, 2015 at 3:15 AM, Ilari Liusvaara <[email protected]>
wrote:
> On Thu, Nov 26, 2015 at 11:37:12PM +0800, Xuelei Fan wrote:
> > > This wouldn't work if one had to downnegotiate TLS 1.2. That is going
> to
> > > happen A LOT.
> > >
> > > I think, "supported_groups" extension still can be sent for TLS 1.2,
> but
> > can be ignored for TLS 1.3. And "key_share" extension can be extended to
> > support TLS 1.2 and previous versions.
>
> Given the slowness even _security_ _fix_ extensions get deployed,
> planning any sort of transition is not IMO a good idea.
>
> Agreed.
If "supported_groups" extension is only for compatibility, it can be
not-mandatory. However, if it is defined to define the supported groups
and preferences (see bellow), it can be mandatory.
> > > Also, one can support curve, but not prefer to send share on it (the
> > > server can call for it, at cost of extra RTT).
> > >
> > The scenarios may be not effective because of the extra RTT. As if the
> > client want to negotiate the curve, it may be more effective to provide
> the
> > key information in the beginning. Or, maybe the generation of the key
> > exchange information is more expensive?
>
> Yes, generating key exchanges can be expensive (even if it is cheaper
> for each group then performing the actual key exchange). Especially for
> P-384, P-521 and larger DH groups.
>
> Also, the shares can get large if many are sent. "Xmas tree" client
> keyshare is 3384 bytes by quick calculation (whereas the one containing
> P-256 and X25519 is just 109). That's many times the rest of the
> ClientHello, and might already cause problems.
>
> Better plan might be to guess, as the cost of wrong guess is mostly
> just 1 RTT.
>
> Agreed.
> > > Plus, some of the curves are of special purpose and won't ever have
> > > shares.
> > >
> > I missed this point. Is it possible to update the shares to tolerate the
> > special purpose? For example, allowing empty shares.
>
> The current grammar does not allow empty value, so it is free. But
> considering one needs supported_groups for backward compat., one can
> just rely on that to signal that group is supported but no share is
> given.
>
> >
> > > Also, IIRC, if client has no shares, it omits key_share. If server
> wants
> > > FS cipher suite, it then has to signal retry.
> > >
> > That's may be the point I missed, too. Where and when the shares come
> > from? Looks like there are two cases:
> > 1. client generate the shares and wrap them in the initial ClientHello
> > message.
> > 2. client omits the key_share, but still request for (EC)DHE cipher
> suites.
> > If server want to negotiate (EC)DHE cipher suite, need an extra RTT.
> > Client generate the shares on server request.
>
> I actually looked at the Editors's Copy. The description is a mess: It
> seemingly first requires key_share extension, even for the first
> ClientHello... Now, that extension can't be empty... And then proceeds
> to say to omit it if client has no shares to send... Which looks like
> it is mutually contradictionary.
>
> > I think the cases answer my confusing of the two extensions. Suppose, if
> > the shares can be optional, maybe it is easier to use key_share only. If
> > client has no shares, using key_share with no shares (function as
> > supported_groups); if client has shares, using key_share with shares.
>
> I think two extensions are needed for backward compatiblity: One needs
> to use supported_groups, but one can't extend it, so two extension it
> is.
>
> TLS 1.3 (without 0-RTT) is supposed to be possible to downnegotiate at
> least to TLS 1.2.
>
> Version down-negotiation is OK, but define "supported_groups" extension as
mandatory may be too strong, unless there are other considerations (See
bellow).
> > > > The "supported_groups" extension defines the groups, while the
> > > "key_share"
> > > > extension defines both the groups and the key exchange information.
> Both
> > > > extension has its own preferences for the supported named groups.
> It's
> > > > easy to get conflicted if the two preferences are not consistent.
> The
> > > > "key_share" extension contains the information of the supported named
> > > > groups. So, the information can be used to indicate the client
> supported
> > > > named groups. Maybe, for TLS 1.3, it is not necessary to use the
> > > > "supported_groups" extension any more.
> > >
> > > The only way to be conflicted would be to send key share for group not
> in
> > > supported_groups. Sending supported_group for group not in key_shares
> is
> > > not a conflict[1].
> > >
> > The preferences may be not consistent, too. For example, the
> > supported_groups prefer ffdhe2048, but the key_share prefer ffdhe4096.
> > Using two preferences would make the implementation inconsistent between
> > vendors if no clearly specification about the preference of the two.
>
> Only supported_groups are perference-ordered. Key_shares is unordered,
> with special exception for retry (the added group always goes last).
>
>
In section 6.3.2.3:
client_shares
A list of offered KeyShareEntry values in descending order of
client preference.
I think, key_share is ordered too. If considering both key_share and
supported_groups together, looks like there are two options:
1. key_share defines the preferences and supported named groups, which is
overlap with supported_groups. supported_groups is used for version
down-negotiation purpose. Don't define supported_groups as mandatory any
more.
For this case, empty key_share vector can be used to indicate to request
server choice shares.
2. key_share won't defines the preferences any more. The named groups in
key_share MUST exist in supported_groups extensions. supported_groups is
used to define the supported named groups and preference, and key_share is
used to define the shares. Both are mandatory.
For this case, key_share can be omitted to indicate to request server
choice shares.
> > > [1] In fact, I expect many clients to send shares for P-256 and X25519,
> > > plus offer P-384 and X448 (without shares unless requested).
> > >
> > >
> > I like this scenarios more. It might be more clear if TLS 1.3 support
> > this scenarios, but not the scenarios that sending shares before
> > requested. For the TLS vendors, client implementation may only consider
> > one option. While a server implementation need to consider both, the
> effort
> > doubles.
>
> Basically, with some groups, sending on request is the only workable
> option, given how slow or large some shares are.
>
> Now, if PQ key exchanges were added, things would get worse, because
> those methods tend to either have large keys or slow key exchange/
> generation.
>
> Agreed.
Thanks,
Xuelei
>
>
> -Ilari
>
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
