1330618 - Non-compliance with RFC 7919 (FFDHE)

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect, P3)

Description

[Hubert Kario]

Description of problem:
the NSS server does not comply with the RFC 7919 MUST requirement in  Section 4

Version: 3.28.0

How reproducible:
always

Steps to Reproduce:
git clone https://github.com/tomato42/tlsfuzzer.git
pushd tlsfuzzer
git checkout ffdhe # won't be necessary in future
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa
git clone https://github.com/tomato42/tlslite-ng.git .tlslite-ng
pushd .tlslite-ng
git checkout ffdhe # won't be necessary in future
popd
ln -s .tlslite-ng/tlslite tlslite
popd
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -nodes -batch -subj /CN=localhost
openssl pkcs12 -export -passout pass:  -out localhost.p12 -inkey localhost.key -in localhost.crt
mkdir nssdb
certutil -N -d sql:nssdb --empty-password
pk12util -i localhost.p12 -d sql:nssdb -W ''
./selfserv -d sql:./nssdb -p 4433 -V tls1.0: -H 1 -n localhost
# in another terminal, same directory
PYTHONPATH=tlsfuzzer python tlsfuzzer/scripts/test-ffdhe-negotiation.py 'no overlap between groups'


Actual results:
no overlap between groups ...
Error encountered while processing node <tlsfuzzer.expect.ExpectAlert object at 0x1e18b90> (child: <tlsfuzzer.expect.ExpectClose object at 0x1e18bd0>) with last message being: <tlslite.messages.Message object at 0x1e1c350>
Error while processing
Traceback (most recent call last):
  File "tlsfuzzer/scripts/test-ffdhe-negotiation.py", line 295, in main
    runner.run()
  File "/tmp/tmp.y0pmCSjuzr/tlsfuzzer/tlsfuzzer/runner.py", line 168, in run
    node.process(self.state, msg)
  File "/tmp/tmp.y0pmCSjuzr/tlsfuzzer/tlsfuzzer/expect.py", line 542, in process
    raise AssertionError(problem_desc)
AssertionError: Alert description 40 != 71



Expected results:
no overlap between groups ...
OK

Additional info:
RFC 7919 MUST requirement in Section 4:

   If the extension is present
   with FFDHE groups, none of the client's offered groups are acceptable
   by the server, and none of the client's proposed non-FFDHE cipher
   suites are acceptable to the server, the server MUST end the
   connection with a fatal TLS alert of type insufficient_security(71).

Comment 1

[Kai Engert (:KaiE:)]

EKR, Martin, do you agree with Hubert's report?

Comment 2

[Eric Rescorla (:ekr)]

I'm not sure yet. I agree that this is a specification requirement, but as written, its silly because it requires a server which:

1. Supports this extension and knows about FFDHE
2. Is configured to only have RSA cipher suites

To reject with insufficient_security rather than handshake_failure. And that just seems plain wrong.
So I'm inclined to call this a specification error.

Comment 3

[Hubert Kario]

(In reply to Eric Rescorla (:ekr) from comment #2)
> I'm not sure yet. I agree that this is a specification requirement, but as
> written, its silly because it requires a server which:
> 
> 1. Supports this extension and knows about FFDHE
> 2. Is configured to only have RSA cipher suites
> 
> To reject with insufficient_security rather than handshake_failure. And that
> just seems plain wrong.
> So I'm inclined to call this a specification error.

I understand it as a server that does support FFDHE and has it enabled, and it does have some RSA ciphers enabled, but those are different ciphers than what client has advertised.

E.g. server supports TLS_DHE_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_AES_128_CBC_SHA256 with all known FFDHE groups, while client supports TLS_DHE_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_AES_128_CBC_SHA with some unknown group (say, 511).

Comment 4

[Eric Rescorla (:ekr)]

I agree that one *could* interpret it that way, but I don't think it literally says that.

The specific (edge) case I am discussing is:

- Server supports the FFDHE extension but (say) only supports FF2048
- The client only offers FFDHE and the server only supports RSA (by configuration

Then we go to the text, which has the following conditions.

   If the extension is present
   with FFDHE groups [it is]

   none of the client's offered groups are acceptable
   by the server [true]

   and none of the client's proposed non-FFDHE cipher
   suites are acceptable to the server [true]

then:
   the server MUST end the
   connection with a fatal TLS alert of type insufficient_security(71)
 
More generally, this seems like a case of the RFC being over-prescriptive about server-side processing order, and we shouldn't change our behavior here (though an update to the RFC might make sense).

Comment 5

[Hubert Kario]

If server enables only RSA ciphersuites, I don't think the RFC applies in the first place. It talks only about "compatible TLS servers", i.e. ones that can negotiate FFDHE, even if with only one cipher and one group.

Note the full paragraph (below) specifically calls out that this applies to groups unassigned as of now - that is, it is about backwards and forwards compatibility, not redefining RFC 5246...

RFC 7919 Section 4:
   If a compatible TLS server receives a Supported Groups extension from
   a client that includes any FFDHE group (i.e., any codepoint between
   256 and 511, inclusive, even if unknown to the server), and if none
   of the client-proposed FFDHE groups are known and acceptable to the
   server, then the server MUST NOT select an FFDHE cipher suite.  In
   this case, the server SHOULD select an acceptable non-FFDHE cipher
   suite from the client's offered list.  If the extension is present
   with FFDHE groups, none of the client's offered groups are acceptable
   by the server, and none of the client's proposed non-FFDHE cipher
   suites are acceptable to the server, the server MUST end the
   connection with a fatal TLS alert of type insufficient_security(71).

Comment 6

[Eric Rescorla (:ekr)]

I did read the whole paragraph, but I don't agree with your interpretation.

In any case, I do not believe that NSS should change its behavior.

Comment 7

[Martin Thomson [:mt:]]

I agree with ekr.  The real requirement should be:
 if the client includes an FFDHE group (i.e., it supports FFDHE),
 and the server doesn't have an FFDHE group in common,
 then the server MUST NOT select a DHE cipher suite.

That is a requirement we comply with.

BTW, I can't make any sense of comment 0.  It would be better if the problem could be stated in terms of what happened and how NSS reacts.

Comment 8

[Hubert Kario]

(In reply to Martin Thomson [:mt:] from comment #7)
> I agree with ekr.  The real requirement should be:
>  if the client includes an FFDHE group (i.e., it supports FFDHE),
>  and the server doesn't have an FFDHE group in common,
>  then the server MUST NOT select a DHE cipher suite.
> 
> That is a requirement we comply with.

correct, but this is just the first part of Section 4.

> BTW, I can't make any sense of comment 0.  It would be better if the problem
> could be stated in terms of what happened and how NSS reacts.

See comment #3:
server (NSS) supports TLS_DHE_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_AES_128_CBC_SHA256 with all known FFDHE groups, while client (tlsfuzzer) supports TLS_DHE_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_AES_128_CBC_SHA with some unknown group (say, 511). The server replies with handshake_failure(40) alert instead of the RFC specified insufficient_security(71).

Comment 9

[Martin Thomson [:mt:]]

ekr, I think that this is correct behaviour (we sent handshake_failure when we can't negotiate a cipher suite and that's what happened here).  Should we open an erratum on RFC 7919?

Comment 10

[Eric Rescorla (:ekr)]

Yes, and mark this WONTFIX IMO

Comment 11

[Tim Taubert [:ttaubert] (inactive)]

Not sure if the erratum was already filed, and whether we can WONTFIX this already. Leaving open, please close when we can.

Comment 12

[Martin Thomson [:mt:]]

https://www.rfc-editor.org/errata/eid4908 was filed.