Subject: [TLS] Refactoring the negotiation syntax

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Jul 2016 10:12:54 -0700

Hi folks,

There have been a lot of discussions about whether we should try to
refactor cipher-suite negotiation to be less monolithic in the cipher
suite. I've generally been on the "no" side of that on cost/benefit
grounds as well as not quite seeing how it would fit into the rest
of the infrastructure. However, now that we're starting to get full
implementations, and it's becoming clearer how the new elements
(principally PSK-resumption and key_shares) interact with cipher
suites, I've started to think that in fact we may be able to clean
things up. One proposal for this is below [0]. I know this is
pretty late in the process, but if we do want this change it's
better to do it now.

I'm sure we'll need to discuss this in Berlin, but in the meantime,
fire away.

The basic idea here is to factor out the TLS 1.3 negotiation into three
mostly orthogonal axes.

- Symmetric cipher/PRF  -- indicated by the cipher suite list as in TLS 1.2
- Key exchange -- indicated by the key_shares and pre_shared_key extensions
- Authentication -- indicated the signature_algorithms and pre_shared_key
  extensions

A proposal for how to do this is below. See the end for other options,
caveats, etc.

If we take PSK out of the picture, this gives us a very simple structure:

- The client offers a set of key_shares and the server picks one that it
  likes [1].
- The client offers a list of signature_algorithms and the server picks
  a certificate/key that matches that list and signs with it.

In other words, we just eliminate the redundancy with the cipher suite
indications. This leaves is with the question of how to handle the
existing TLS 1.2 cipher suites. We can either assign new cipher suites
or say that any cipher suite with *_aead_alg_hash means that we
support aead_alg_hash. Matter of taste.

PSK is handled by extending the concept of PSK flags that we already
have in NewSessionTicket to also include uses of PSKs where you
indicate the way in which you are using the PSK (or want it to be
used). There a bunch of ways to encode this. I'll give you the one I
mostly prefer below and then a one that's a smaller change but I think
a little less elegant at the end [note #4].

First, we replace the flags word of the different KE modes for the
ticket with lists of code points, as below:

   enum {
     psk_ke(0),          // PSK key exchange
     psk_dhe_ke(1),      // PSK + DHE key exchange
     (255)
   } PskKeModes;

And then add new code points for being able to use the PSK with and
without signatures (from the server). We had pretty rough consensus in
B-A that we needed this mode and [draft-thomson-tls-0rtt-and-certs-01]
is part of the motivation for this idea.

   enum {
     psk_auth(0),        // PSK only
     psk_sign_auth(1),   // PSK + a signature (as in draft-thomson) [5]
     (255)
   } PskAuthModes;

This gives us the following NewSessionTicket message where we have
replaced the flags word with two (potentially ordered) lists:

   struct {
       uint32 ticket_lifetime;
       PskAuthModes auth_modes<1..255>;
       PskKeModes ke_modes<1..255>;
       TicketExtension extensions<2..2^16-2>;
       opaque ticket<0..2^16-1>;
   } NewSessionTicket;

We now need a way to indicate that the server will do 0-RTT (previously
in the flags word) so we add a new 0-RTT extension:

   struct {
       uint32 ticket_age_add;
   } TicketEarlyDataInfo;

This has two nice properties:

- You don't need to provide ticket_age_add when you don't do 0-RTT
  (and it is silly if you don't).
- It exercises this extension mechanism, which is good for future-proofing.

PreSharedKeyExtension becomes:

    struct {
       PskAuthMode auth_modes<1..255>;
       PskKeModee ke_modes<1..255>;
       opaque identity<0..2^16-1>;
    } PskIdentity;

    struct {
         select (Role) {
             case client:
                 PskIdentity identities<2..2^16-1>;
              case server:
                 PskAuthMode auth_mode;
                 PskKeMode ke_mode;
                 uint16 selected_identity;
         }
     } PreSharedKeyExtension;

The way to interpret these is as follows:

- With each identity, the client indicates to the server which modes
  it can be used with.
- When the server responds with an identity, it tells you how it
  used it.

You might ask why you need the server to indicate what it did.  The
reason is that we would like the client to know in advance (at the
time of the ServerHello) whether the server has sent
Certificate/CertificateVerify rather than having to figure it out from
what messages the server sends. The ke_mode field is redundant
(because you also infer it from the server key_shares) but I added it
for parity.

I haven't implemented this yet (am going to try to take a crack at that
before Berlin) but I believe based on experience with the NSS
negotiation that it will be simpler. I know it removes a bunch of odd
edge cases which have accumulated over the years, but maybe it adds
others.

-Ekr

BONUS MATERIAL
0. I've discussed this with and/or borrowed ideas from Richard Barnes,
David Benjamin, Karthik Bhargavan, Dave Garrett, Nick Sullivan, Martin
Thomson, and others. Thanks to those guys, but blame me if you think
this is bad.

1. The other major encoding option here is to have dummy
group/signature_algorithm indicators that tell you whether you can use
a pure PSK. When I and others discussed this, the consensus was that
that was less clean.

2. One question that comes up at the same time is whether we should
allow multiple key shares to be used, which is a structure that this
makes pretty easy. Basically, the server would just supply as many
counter-shares as it wanted and then we'd need a defined order for how
they were inserted into the key schedule. This feature would be nice
for enabling post-quantum, but probably better to just define
<PQ-Algorithm + Curve> code points.

3. Note that because of this PSK-PRF interaction, PSK isn't totally
orthogonal with AEAD/PRF. I.e., you cannot use the same PSK with
HKDF-SHA256 and HKDF-SHA384 if you want to be on the cryptographic
fairway, but I think it should be easy enough to filter out the cipher
suites to make that work.

4. The other major alternative is just to use the flags bits. So we
would extend and generalize the flags as shown below.

   enum {
     early_data(1),
     dhe_psk_ke(2),
     psk_ke(4),
     psk_auth(8),         // New (no server cert)
     sig_psk_auth(16)     // New (sign with server cert)
   } PskUsageFlags;

These new flags have the expected meaning, namely:

psk_auth         The server will do connections with just
                 PSK authentication (equivalent to PSK now)

sig_psk_auth     The server will do connections with PSK
                 plus signature (not currently specified).

Then we update the PreSharedKeyExtension as follows:

    struct {
          uint32 usage_flags;
          opaque identity<0..2^16-1>;
    } PskIdentity;

    struct {
         select (Role) {
             case client:
                 PskIdentity identities<2..2^16-1>;
              case server:
                 uint32 usage_flags;  // New (one from each category)
                 uint16 selected_identity;
         }
     } PreSharedKeyExtension;

The idea here is:

- The client indicates how each PSK can be used (by flags, which
  need to be a subset of the ticket flags).
- The server can pick a PSK and indicate how it was actually
  used.

For instance, if the client wants to do PSK w/ ECDHE it would indicate
dhe_psk_ke. If it only wants PSK it would indicate psk_ke. If it was
willing to do both, it would indicate the bitwise OR.

Similarly, if the client wants PSK for auth, it would indicate
psk_auth. If it wants the server to sign, it indicates sig_psk_auth,
and so on (indicating neither is silly because it makes the key
unusable).

By contrast, the server just sets the bits that it actually used.
I.e., if it sets psk_auth, that means it won't be signing and
there is no Certificate/CertificateVerify. OTOH if it sets
sign_psk_auth, that means it will be signing and there will
be a Certificate/CertificateVerify.

This leaves early data. As above, the client uses the early_data
bit to indicate that the PSK was used to encrypt early data
(obviously, this can just be one key) and the server uses it to
indicate that it accepted early data. ticket_age needs to go in
its own extension, but that's easy enough.

5. Note: this would allow for modes where the server signs over a PSK
handshake with no DHE at all. The resumption_ctx mechanism is intended
to ensure that that is OK, but we'd need to confirm with analysis.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Jul 2016 10:21:38 -0700

Replying to myself:
We obviously don't *need* to do this. We have working implementations that
use the current syntax, so we know it can be done, and "finished is a
feature", so we have to balance against that whether this is a better
syntax. OTOH, if you think this is a worse syntax, then it's easy. :)

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Wed, 13 Jul 2016 14:01:12 -0400

>   a certificate/key that matches that list and signs with it.

Your proposal ignores the supported_groups extension. The requirement of this is one of the wrenches that causes the complexity of this whole system to increase. HelloRetryRequest is the other wrench here. We very much could do everything supported_groups does in key_share; just stick unsent supported groups in the share with null keys. The desire to maintain backwards compatibility with a different mechanism using the old version of supported_groups is what makes this a problem. (back compat is not free)

As to the PSK side of things, one idea which I brought up at some point is to merge the PSK extension into the key share extension to create one unified key exchange extension. We just assign some group ID to PSK, then the identity is just its equivalent of a key to be in the bag of keys. One less new extension to worry about, and instead one new extension that is 100% required for all TLS 1.3 requests, without exceptions that might need to be handled. (blending into the other current list thread, here) The special handling of PSK is another one of these metaphorical wrenches that increases the design complexity in various places.

As to the actual core proposal, it could work. I too am not ideally in favor of redoing everything at this late stage, but I'm not against reconsidering it, if we can all actually agree on an alternative.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Jul 2016 13:23:01 -0700

On Wed, Jul 13, 2016 at 11:01 AM, Dave Garrett <[email-masked]>
wrote:

> Your proposal ignores the supported_groups extension.

I don't think it affects it either way.

The requirement of this is one of the wrenches that causes the complexity
> of this whole system to increase. HelloRetryRequest is the other wrench
> here. We very much could do everything supported_groups does in key_share;
> just stick unsent supported groups in the share with null keys.

David suggested this offline, but I don't think this makes things
significantly simpler, because now.

As to the PSK side of things, one idea which I brought up at some point is
> to merge the PSK extension into the key share extension to create one
> unified key exchange extension. We just assign some group ID to PSK, then
> the identity is just its equivalent of a key to be in the bag of keys. One
> less new extension to worry about, and instead one new extension that is
> 100% required for all TLS 1.3 requests, without exceptions that might need
> to be handled. (blending into the other current list thread, here) The
> special handling of PSK is another one of these metaphorical wrenches that
> increases the design complexity in various places.
>

I think this actually makes matters *worse* because then you have one
situation where (ECDHE) where the server sends one key share and one
(ECDHE-PSK) where the server has to send/acknowledge two

-Ekr

As to the actual core proposal, it could work. I too am not ideally in
> favor of redoing everything at this late stage, but I'm not against
> reconsidering it, if we can all actually agree on an alternative.
>
>
> Dave
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 13 Jul 2016 23:36:14 +0300

> A proposal for how to do this is below. See the end for other options,

Those axes aren't properly orthogonal. IMO, the most orthogonal axes
are:

- Key exchange main type: PSK vs. GDHE-PSK vs. GDHE-CERT.
- Key exchange function (for GDHE-*)
- Signature algorithm (for GDHE-CERT)
- Record protection
- PRF-hash.

And the most logical way to choose from above list is to first choose
the major type, and then mostly independently (might want to tweak
protection/PRF priorities based on key exchange function strength) the
rest (also, might want to check ther is OK choice for kex function
before chosing main type).

Now, the issue is that orthogonality is completely broken in TLS 1.2.
The factors that most break it are group types and legacy signature
types and how those can interact with record protection or PRF.

Send a ClientHello that does not have cartesian product of group types,
legacy signature types and protections/prfs and you can get some very
surprising results (or at worst, bugs where server selects ciphersuite
that isn't on your list!).

OTOH, the problem with changing it is that TLS 1.2 and 1.3-14 parameter
negotiation works mostly the same way (other than lack of the broken
RSA key exchange and the DHE downnegotiation issue, which is mostly client
problem rather than server problem)

So any dual 1.2/1.3 server would have to implement both mechanisms if
those are changed. So only 1.3-only servers would benefit.

> support aead_alg_hash. Matter of taste.

Yes, that's the key exchange function and signature algorithm parts
from the above.
 
>      psk_dhe_ke(1),      // PSK + DHE key exchange

In the orthogonalization above, the second entry would be PSK+GDHE
(any supported key exchange function), but that's probably what you
meant already.

>      psk_sign_auth(1),   // PSK + a signature (as in draft-thomson) [5]

I think that PSK+signature modes are so different that those warrant
promotion to a new major key exchange type.

Depending on the actual implementation, those might have some new message
sequence (e.g. omitting Certificate if the key can't change).

>                  uint16 selected_identity;

This seems somehow bit questionable to me (taking this as clean-
slate design), but I can't quite put my finger on it...

OTOH, if one wants to combine PSK and auth, one probably want's
to keep it separate like it is done above...

> (because you also infer it from the server key_shares) but I added it

Well, figuring out from ServerHello (and even EncryptedExtensions)
would not be so bad if the rules were clear.

> edge cases which have accumulated over the years, but maybe it adds

Maybe I could take a crack too (maybe)...

> <PQ-Algorithm + Curve> code points.

In order of group number? Or in order of server reply?

(Both orders would be well-defined). Would also avoid the bit of
special case of zero key in pure-PSK mode...

> suites to make that work.

The 0-RTT locking the protection/prf is surprisingly easy (other than
the checks if such locking can give anything sane due to couplings
in ciphersuites).
 
> - The server can pick a PSK and indicate how it was actually

Based on quick look, I like this less than the decoupled version...
 
> to ensure that that is OK, but we'd need to confirm with analysis.

I should also figure out all the attacks I figured out against server
auth in pure-PSK (at most sidenotes, given how TLS 1.3 hasn't supported
any such modes).

Yeah, if resumption_ctx stuff is actually used, it should do the trick,
as it binds the PSK key used (and the normal handshake hash binds the
negotiation).

The resumption_ctx would also bind the key if one kept it as constant
and omitted Certificate message.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Jul 2016 15:07:46 -0700

> (any supported key exchange function), but that's probably what you

Yes, we're using "dhe == GDHE"

> promotion to a new major key exchange type.

Hmm...  Why?

> would not be so bad if the rules were clear.

Yes, that's what I'm hoping for.

> special case of zero key in pure-PSK mode...

I was thinking in order of group number, but if you do combined code points
you don't
need to do this.

> and omitted Certificate message.

Definitely like to hear about this.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 14 Jul 2016 11:32:00 +0300

> > promotion to a new major key exchange type.
 
Or might be better to have those as add-ons like in your proposal. The
above look to be independent.

If you think chinese menus are problematic, coupled choices are way
more so...

> I was thinking in order of group number, but if you do combined code points

I was thinking of just scanning the server key_share in order the groups
appear... With no mixing if no key_share is absent.

This would unify DHE-PSK and PSK for purposes of later handshake.

Would need a way to ensure that some mixing happened tho!

> Definitely like to hear about this.

One thing that comes to mind is (this is not mode that is presently
supported or discussed to be added): Say you had a mode where server
could send a public key in NewSessionTicket and then have client do
key transport with that key to agree "SS key" for 0-RTT and as second
key (useful for PQC purposes, since this lets you use PQEncryption
instead of PQKeyAgreement, and the first seems to be in better shape
than the latter). Now you are in cryptographic weeds and resumption_ctx
won't help.

Also, need to check the extension rules in case of PSKwCERT. More
annoyingly, those depend on the exact semantics of the certificate
authentication in that case.

Certificate is constant (in addition to base ALPN and SNI):
- If status_request was originally present, now status_request or
  status_request_v2 has to be present. Contents can be different.
- server_authz must not be present
- cert_type/server_certificate_type negotiation has to have the same
  result (including the implicit "X509" case)..
- signature_algorithms from client has to contain the signature
  algorithm used on parent connection.
- If status_request_v2 was originally present, it has also be
  present now. Contents can be different.

Key is constant (in addition to ALPN and SNI):
- signature_algorithms from client has to contain the signature
  algorithm used on parent connection.
- If using implcit-key: trusted_ca_keys, status_request,server_authz,
  cert_type,status_request_v2,signed_certificate_timestamp and
  server_certificate_type must not be negotiated.

No constraints (in addition to ALPN and SNI):
- (No additional constraints on extensions)

Each mode from above has its strengths and weaknesses:

Certificate is constant:
- Limits 0-RTT to lifetime of parent certificate (or less!)
+ Revocation works as well as usual (which isn't very!)
- Problems with farms
+- Implicit-key would save chunk of bandwidth, but need to check if it
   is safe (should be, since resumption_ctx covers it)..

Key is constant:
+ 0-RTT lifetime can extend beyond certificate lifetime.
- No workable key revocation.
- Problems with farms
+- Implicit-key would save chunk of bandwidth, but need to check if it
   is safe (should be, since resumption_ctx covers it)..

No constraints:
- Weakest assurances.
- No implicit-key bandwidth savings.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 14 Jul 2016 14:44:43 +0300

> Would need a way to ensure that some mixing happened tho!

Thinking some more about this:

- The initial value for the chain secret should be empty string, not
  L zeroes. If hash function is well-behaved (and most are), then
  empty and L zeroes are the same if passed as salt to HKDF-Extract,
  but empty string would cause an internal fault in derive_secret.
- One should ensure that the default type is "certificate
  authentication" and that this can't be changed without mixing in
  a secret.
- One needs to require that at least one secret mixing occurs in
  processing of CH/SH.

-Ilari

---

From: Kyle Rose <[email-masked]>
Date: Mon, 18 Jul 2016 15:27:28 +0200

> - Authentication -- indicated the signature_algorithms and pre_shared_key

Tl;dr: I think this is a good approach because it eliminates much of the
existing negotiation redundancy/complexity and combinatorial explosion in
the 1.3+ ciphersuite menu.

The longer version: the argument I made in Prague (though IIRC not very
clearly) was that while it would be nice to limit the ciphersuite options
to agreed-upon "good" combinations based on some sane notion of
forward-looking security margin (notwithstanding the practical inability to
see the future), the reality on the ground is that authentication is based
on something pre-existing---the server has one or two long-term keys of a
fixed length (e.g., one RSA-2048 and one P-256) that it can't augment on
demand---so it really only makes sense for the client to indicate what it
supports and to deal with whatever the server chooses to send it on that
basis. So I'd argue that this one is orthogonal based on that constraint,
and so it should be negotiated separately.

AEAD and PRF OTOH don't come with built-in keys, so they can always be
chosen as a pair as a function of the desired security margin.

Key agreement is not clearly in either category: when it's PSK, it's based
on what you have, so it's similar to authentication; but when it's (EC)DHE,
it's not, and so ideally you'd like the chosen group to be tied to the
AEAD/PRF security margin. But, since the client has to offer specific
groups rather than specifying general support for ECDHE or EdDHE, both
because ideally we want the client key share sent in the first flight and
because unlike RSA or FFDHE a client can't generalize to key sizes it
hasn't seen before, it actually still shares a lot in common with the auth
case of being sort-of something you have rather than something you can
choose on the fly. So I'm also in agreement that this is mostly orthogonal
and should be negotiated separately.

So now you have several grab bags and need to choose one from each. Is it
necessary to tie the various bits together by security margin? Not clear.
It's probably fine to assume a client isn't going to announce support for
anything it doesn't think is secure enough, so the only practical downside
to using e.g. AES256-GCM-SHA384 with P-256 ECDSA is the unnecessary
additional CPU consumption of AES-256/SHA-384. The client was willing to
accept P-256 server authentication, so presumably it's happy with that
security margin; and anyway, the server could prefer ciphersuites and ECDHE
groups that better match the available auth credentials.

Additionally, aside from the situation in which a paucity of ciphersuites
is offered by a client, the one situation with no good resolution is
security margin of PSK vs. authentication in PSK+signature: both are based
on pre-existing credentials, one offered by the client and one offered by
the server, so if they disagree there's nothing to be done about it. So
maybe the server then just prefers ciphersuites (and group in PSK+DHE) that
match the minimum of the security margin of the PSK and available auth
credentials.

Or maybe prospective security margin is too complex and/or too ill-defined
to bother with, and a server should just choose the least CPU-intensive
combination of everything.

> support aead_alg_hash. Matter of taste.

Meaning that if a 1.3 client offers TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
and the server has only TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 in its
list, that they would internally map to the same ciphersuite and so the
server would agree on and offer up the client's code point? It might be
cleaner just to have new suites for 1.3, if for no other reason but to
reduce confusion when someone looks at this ten years from now.

Kyle

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 18 Jul 2016 18:07:50 +0300

> the 1.3+ ciphersuite menu.

I recently tried to write code to handle this ciphersuite negotiation, so
that it always negotiates a valid choice if any valid choice exists.

I think the end result was insane. The problem that makes it so difficult
is that legacy signature types, group types and protection/PRFs interact,
so not all supported offers that server has enabled are actually possible
to chose.

> and so it should be negotiated separately.

If you are talking about "strength-matching", there is no sane notion of
security equivalence with protection, key exchange and signatures (due to
different sub-threshold, multi-key and period properties).

And coupling those in a way that doesn't lead to great difficulty (even
greater than currently) REALLY causes the ciphersuite space to
combinatorially explode.

> chosen as a pair as a function of the desired security margin.

Except in some situations (e.g. 64-bit systems with hardware AES and
CLMUL) it actually would make some sense to use AES-128-GCM with SHA-384.

The "match security" is IMO about not having the weakest algorithm not
being too weak, or "paying too much" for algorithm that is much above
anything else.

But what it doesn't consider is what if the stronger algorithm is
actually cheaper? This actually happens on 64-bit on SHA-256 vs. SHA-384.

Or if on 32-bit hardware where you don't have hw AES? Then
X25519/Ed25519/Chacha20Poly1305/SHA256 is the cheapest (or ECDSA P-256
if you don't have Ed25519), nevermind that it has "256-bit" symmetric cipher,
but everything else at "128-bit" level...

> and should be negotiated separately.

"Security matching" between groups and symmetric ciphers is already highly
problematic, and depends on all sorts of assumptions (and is generally
biased towards symmetric ciphers being less secure than they seem).

Sure, the server might bias choices, but actually enforcing anything here
is IMO unwise.

> groups that better match the available auth credentials.

IMO, no it is not necressary to tie the security margins. In case of
authentication and encryption, there is also the issue that authentication
is good if it is unbroken at that moment, whereas key exchange and encryption
must remain unbroken for long time since.

So that someone thinks ECDSA P-256 is OK for authentication does not mean
that the same entity thinks ECDHE P-256 is OK for key exchange. Or to think
that 128-bit symmetric encryption is OK.

> combination of everything.

Well, yeah, it is ill-defined. Of course, there can be bad algorithms
that one wants to disable.

However, interactions between bad algorithms are much less likely than
actual bad algorithms causing problems by themselves.

-Ilari

---

From: Kyle Rose <[email-masked]>
Date: Mon, 18 Jul 2016 17:51:15 +0200

> so not all supported offers that server has enabled are actually possible

It may also be that combinatorial explosion in ciphersuites just isn't a
problem in reality: that there should be so few choices offered in the
standard, with those believed to be secure, and new ones introduced only
when they are actually needed, not simply when there is something shiny and
new.

> ....

Yeah, this is a really good point. This argues for a complete separation of
authentication (over which the client has no control) from the rest of the
security parameters. In some sense, the KX and symmetric cipher are still
tied together as a break in either in the future will reveal confidential
data, but I'll concede the point that there is no sane way to tie security
margins between KX and cipher suite.

> greater than currently) REALLY causes the ciphersuite space to

The combinatorial explosion I was referring to was that of consuming code
points for multiple combinations of things that have a separate negotiation
mechanism (e.g., SignatureAlgorithms). But maybe it's not a problem in
practice.

> actual bad algorithms causing problems by themselves.

I'm more concerned about the a la carte approach admitting bad ciphers or
PRFs that then get implemented naïvely by completists, but I suppose that
problem still exists when they are tied together. And maybe this won't be a
problem in practice in the presence of a "recommended" column in the
registry.

Kyle

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Jul 2016 18:03:08 +0200

> so not all supported offers that server has enabled are actually possible

Can you say more about this?

I spent some time mocking up an implementation locally and it was pretty
clean.

Perhaps what made it easier is that I did:

1. Define new cipher suites that were totally agnostic about the key
exchange
and signature.

2. Assume everything was orthogonal except for the PSK/signature/key
exchange
interaction...

-Ekr

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 18 Jul 2016 19:19:36 +0300

> Can you say more about this?

I was referring to the scheme in TLS 1.2 and 1.3-14.

The problem is, that even if X is "locally" possible (enabled on both sides,
the algorithm and its "class" is advertised) does not guarantee that X is
"globally" possible (there is actual configuration using X that meets all
TLS constraints and algorithm enables).

> exchange and signature.
> exchange interaction...

Both should eliminate the really nasty parts, as it would mean that
unless server wanted to, any X is "locally" valid is also "globally"
valid. Modulo key exchange types, but those aren't that bad usually.

-Ilari