On 09/25/2015 02:11 PM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 7:23 PM, David M. Lloyd <david.ll...@redhat.com> wrote:
The application protocol implementation chooses only valid cipher suites for
the protocol. Why would it choose one that is not valid, considering that
the protocol implementation itself is the only thing that "knows" what is
valid or not?
The cipher could fail for the number of reasons it fails in
trySetCipherSuite(), even if the application has chosen the right
combination of (application protocol, cipher, whatever else).
At that point you have to try another application protocol.
From my reading of that code, it can only fail if you specifically set
up invalid combinations of cipher suite, protocol, and credentials. The
application code should have all the information it needs to set up a
correct configuration though.
This validation should have happened before the JDK ever has a chance to be
involved.
See above.
Unless it is verified that trySetCipherSuite() cannot *ever* fail
after a cipher has been chosen (but then the method should return
void), then I don't see how your proposal could work.
The method isn't magical; it is just working off of known inputs. If
you give inputs that will ultimately result in a correct negotiation
(and nothing leads me to believe that there is any reason that the
application protocol user cannot do this), then you will get a
successful output. On the other hand, if (for example) the user selects
a cipher suite that is incompatible with their credentials, or which is
incompatible with the protocol which the user *also* selected, I don't
see any good reason to give them another chance.
In other words, you're assuming that the only way to know if a
configuration is correct is to try it, but that just isn't true.
Have you written an implementation already ? That would help.
No.
--
- DML
