Subject: [TLS] MUST <x> or what?

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Aug 2015 11:48:15 -0700

I've been looking at the latest TLS 1.3 spec and there are a lot of
MUSTs that are completely toothless.  To pick on a recent changeset:

> The signature algorithm and hash algorithm MUST be a pair offered in the
"signature_algorithms" extension (see {{signature-algorithms}}).

> All implementations MUST use the "signature_algorithms" extension when
offering and negotiating certificate authenticated cipher suites.

> All implementations MUST use the "supported_groups" extension when
offering and negotiating DHE or ECDHE cipher suites.

This isn't good.  "MUST" language MUST have consequences or you are
left with all sorts of variations.  If you don't stipulate
consequences, then people violate the MUST and you get interop issues.

I propose that we don't do this in future without due consideration.
In all these cases, the peer that notices a violation of the
requirement can (and I would argue MUST) fail the handshake and
probably generate a fatal alert.

The exceptions to this are where you need to permit non-compliant
behaviour for legacy interoperability reasons.  For TLS 1.3, I think
that we can limit that to the ClientHello handling and - if we feel
like we can mandate changes that affect TLS 1.2 or earlier for clients
that support 1.3 - the ServerHello.  I think only the ClientHello.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Aug 2015 12:12:37 -0700

> "signature_algorithms" extension (see {{signature-algorithms}}).

I note that we had a very extensive discussio n

> offering and negotiating DHE or ECDHE cipher suites.

This is an example of a MUST that is not always easy to enforce. Consider
what happens if you have a client which offers both ECDHE and PSK
(for resumption) and omits supported_groups. If the server picks
PSK it's a pain to check for supported groups and I'm not sure that
the world is improved by that code.

> probably generate a fatal alert.

I agree consideration of this question is good.

> that support 1.3 - the ServerHello.  I think only the ClientHello.

As noted above, I don't think that this is the only exception.

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Thu, 27 Aug 2015 15:19:49 -0400

> "signature_algorithms" extension (see {{signature-algorithms}}).

Some changes to this are now in this PR:
https://github.com/tlswg/tls13-spec/pull/231/files
(language based on list discussion)

> offering and negotiating certificate authenticated cipher suites.

Actually, I did get a strict requirement in there for that one:

https://github.com/tlswg/tls13-spec/blob/master/draft-ietf-tls-tls13.md#signature-algorithms
> All clients MUST send a valid "signature_algorithms" extension in their ClientHello when offering certificate authenticated cipher suites. Servers receiving a TLS 1.3 ClientHello offering certificate authenticated cipher suites without this extension MUST send a "missing_extension" alert message and close the connection.

I think it warrants repeating in the MTI section as well.

> offering and negotiating DHE or ECDHE cipher suites.

My initial draft had similar language, however ekr says the WG doesn't have consensus to be more strict. I would like to consider all of these extensions as mandatory to send, and malformed if not present when offering/negotiating any applicable cipher suites:
signature_algorithms, supported_groups, client_key_share, pre_shared_key, server_name (though, I'm fine with a SHOULD error on lack of SNI when applicable)

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Aug 2015 12:26:03 -0700

On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett <[email-masked]>
wrote:

> > All clients MUST send a valid "signature_algorithms" extension in their
> ClientHello when offering certificate authenticated cipher suites. Servers
> receiving a TLS 1.3 ClientHello offering certificate authenticated cipher
> suites without this extension MUST send a "missing_extension" alert message
> and close the connection.
>
> My initial draft had similar language, however ekr says the WG doesn't
> have consensus to be more strict. I would like to consider all of these
> extensions as mandatory to send, and malformed if not present when
> offering/negotiating any applicable cipher suites:
> signature_algorithms, supported_groups, client_key_share, pre_shared_key,
> server_name (though, I'm fine with a SHOULD error on lack of SNI when
> applicable

My problem is precisely the conflation of offering with negotiating. The
way that
many stacks work (for instance NSS) is that they negotiate the cipher suite
*first* and then they check for the presence or absence of the relevant
extensions.
It's not clear to me that it's an improvement to require them to check for
error
conditions that are not otherwise relevant.

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Thu, 27 Aug 2015 15:51:42 -0400

On Thursday, August 27, 2015 03:26:03 pm Eric Rescorla wrote:
> My problem is precisely the conflation of offering with negotiating. The way that
> *first* and then they check for the presence or absence of the relevant extensions.
> It's not clear to me that it's an improvement to require them to check for error

I'm not fundamentally opposed to having a hard requirement of an error check on negotiation, and basically a soft expectation on mere offering (SHOULD, MAY, or not mentioned; stern warning and shake of finger). That said, categorizing the cipher suites and just doing a quick check for which categories are there and what extensions came with it is not a very complicated requirement. I'm philosophically in the "do it right or explode so it can be found and fixed immediately" camp when it comes to very clear requirements like this, but I'm aware that this is sadly not always the dominant thought process. :|

Dave

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Aug 2015 13:01:54 -0700

The opposite in fact. NSS checks extensions first. That is how we filter
out ECC cipher suites if the named_groups extension doesn't list anything
we support.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Aug 2015 20:02:08 +0000

On Thu, Aug 27, 2015 at 12:26:03PM -0700, Eric Rescorla wrote:

> way that many stacks work (for instance NSS) is that they negotiate the
> cipher suite *first* and then they check for the presence or absence of
> the relevant extensions.
> 
> It's not clear to me that it's an improvement to require them to check
> for error conditions that are not otherwise relevant.

One issue related to "layered" negotiation, in which one first
chooses X, then with X already chosen, chooses Y, ... is that some
choices of X are not compatible with any available Y, while other
choices of X might work.

A specific example may help: Many libraries will first choose the
highest mutually supported protocol version, and only then select
a mutually supported cipher suite.  However, not all ciphersuites
are compatible with all protocols versions.

So we can have situations in which TLS 1.2 and TLS 1.3 are offered
by the client and TLS 1.3 is selected by the server, but none of
the ciphers offered by the client are AEAD.  Should the server have
chosen TLS 1.2, or MUST the client figure out that it can't do TLS
1.3 and not offer it.

There will undoubtedly be clients that naively give the server
"impossible" options along with other options that work.  Should
servers try to handle this gracefully?

Note that in the above scenario the client might offer *some* TLS
1.3 compatible ciphers, but it may happen that none are shared by
the server, while they both share common TLS 1.2 ciphers.

One way to avoid such problems is to suggest that clients that
don't offer the MTI ciphers for a particular protocol version (and
thus can't generically expect interoperability with servers that
implement that protocol) SHOULD NOT offer the protocol version.

Libraries might then have an option that is on by default, and
suppresses protocols for which the MTI ciphers are not enabled.
Clients that really want to offer only non-MTI ciphers would have
to clear the option explicitly.

Half-baked ideas aside, some discussion of the problem may be
relevant so that servers or clients avoid negotiating impossible
partial choices.

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Aug 2015 13:06:10 -0700

The statement I'd like to see is something like this...

An endpoint that receives an illegal combination of "things" MAY choose to
treat that as a fatal error.

In this case, that means that if you include an ECDHE suite without an
ECDHE named_group, don't expect to have the connection succeed.
On Aug 27, 2015 12:51 PM, "Dave Garrett" <[email-masked]> wrote:

> for error
> I'm not fundamentally opposed to having a hard requirement of an error
> check on negotiation, and basically a soft expectation on mere offering
> (SHOULD, MAY, or not mentioned; stern warning and shake of finger). That
> said, categorizing the cipher suites and just doing a quick check for which
> categories are there and what extensions came with it is not a very
> complicated requirement. I'm philosophically in the "do it right or explode
> so it can be found and fixed immediately" camp when it comes to very clear
> requirements like this, but I'm aware that this is sadly not always the
> dominant thought process. :|
>
>
> Dave
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Aug 2015 13:06:11 -0700

> out ECC cipher suites if the named_groups extension doesn't list anything

Well, yes and no. We don't for instance check for the *absence* of the
extension.

-Ekr

>>> > All clients MUST send a valid "signature_algorithms" extension in
>>> their ClientHello when offering certificate authenticated cipher suites.
>>> Servers receiving a TLS 1.3 ClientHello offering certificate authenticated
>>> cipher suites without this extension MUST send a "missing_extension" alert
>>> message and close the connection.
>>>
>>> signature_algorithms, supported_groups, client_key_share,
>>> pre_shared_key, server_name (though, I'm fine with a SHOULD error on lack
>>> of SNI when applicable
>>
>>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Aug 2015 13:06:43 -0700

> treat that as a fatal error.
This seems totally reasonable.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 27 Aug 2015 20:10:58 +0000

> An endpoint that receives an illegal combination of "things" MAY choose to treat that as a fatal error.

From the guy who wrote that Postel was wrong.

But +1 from me.

---

From: Dave Garrett <[email-masked]>
Date: Thu, 27 Aug 2015 17:36:33 -0400

PR to put this into writing:
https://github.com/tlswg/tls13-spec/pull/232

Dave

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 28 Aug 2015 04:24:36 +0000

>treat that as a fatal error.

Does that actually help?  What it's saying in full is:

  An endpoint that receives an illegal combination of "things" MAY choose to 
  treat that as a fatal error or MAY choose not to treat it as a fatal error.

which is a no-op.  Admittedly it explicitly allows you to treat it as an error 
while previously the response was left open, but it's still not terribly 
useful, anyone writing a client that submits gibberish things can claim it's 
OK and the server needs to be fixed to accept it.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 28 Aug 2015 04:29:11 +0000

Martin Thomson <[email-masked]> writes:

>The opposite in fact. NSS checks extensions first. That is how we filter out 
>ECC cipher suites if the named_groups extension doesn't list anything we 
>support.

I have to do the same thing, bouncing back and forth between cipher suites and
extensions in order to find something that fits.  That was the motivation for
the creation of the "Standardised ECC Cipher Suites for TLS" draft:

   TLS-ECC [3] provides an extremely flexible, and by extension
   extremely complex means of specifying a large number of options
   involving the use of ECC algorithms for TLS [2].  As such the "cipher
   suites" in TLS-ECC [3] and by extension TLS-ECC-Brainpool [4] aren't
   suites in the conventional TLS sense but more an indication of intent
   to negotiate a Chinese menu, with details to be decided on later via
   various TLS extensions and parameter settings.  This makes deciding
   on a particular suite nondeterministic, since later parameter choices
   and settings can negate the initial "cipher suite" choice, requiring
   returning to the suite list to try with another Chinese-menu suite in
   the hope that later parameter choices allow it to be used.

Peter.