always store CH in ConnectionState

Fixes a bug. On a server side, ConnectionState.ClientHello was filled
only in case server was handling TLSv1.3

* removes useless variable

* [sike] Adds X25519-SIKEp503 with cSHAKE

Previously there where two methods used for key agreemnt
tls.Conn::generateKeyShare and tls.Conn::deriveDHESecret. Both were
used on client and server side. Boolean flag is used in order to
differentiate between key agreement performed on client and on server
side. Which sucks badly.
In order to implement shared secret agreement with KEM it is better to
add method which implements server specific key agreement and provide
default implementation which reuses tls.Conn::generateKeyShare followed
by tls.Conn::deriveDHESecret.
Now, it is possible for most of the DH-style key agreements to reuse
default implementation and for KEM-style key agreement to provide server
specific implementation.

Tris tries to connect to BoringSSL over TLS 1.2 with X25519-SIDH
as prefered DH group. As this is not supported by BoringSSL it must
fall back to P-256 (second preference on the list)

Also refactors tris test client

* SIDH/P503-X25519
* adds interop tests

generateKeyShare has nothing to do with Config receiver. It doesn't
configure anything. It has everything with connection so moved to Conn.
Making deriveECDHESecret also a method of Conn will make it possible to
access 'isClient' field.

Drops support for delegated credentials with TLS 1.2 and adds the
protocol version and signature algorithm to the credential structure.

What's left are the minimal API changes required to use the delegated
credential extension in the TLS handshake.

This complies with the standard, currently an Internet draft:
https://tlswg.github.io/tls-subcerts/draft-ietf-tls-subcerts.html

It also adds a minimal interface for generating new delegated
credentials.

Tris uses signature_algorithms_cert in order to advertise that it
doesn't support RSA-PSS. See GH#86 for more detailed discussion.

* Implements verifyPeerCertificate common for client and server
* Removes processCertsFromServer13 and processCertsFromClient13
  and implements getCertsFromEntries common to server and client
  which is used instead.

Send/Skip CCS, set legacy record version to 3,3 and echo session ID.
CCS must be ignored while the handshake is running, but not thereafter:
https://tools.ietf.org/html/draft-ietf-tls-tls13-22#section-5

Unconditionally send CCS as server because bogo requires it, even if no
session ID is included in the Client Hello. TLS 1.3 clients MUST ignore
it anyway, so it should not hurt.

Fixes interop with boringssl and openssl and passes bogo.

Draft 21 changed end_of_early_data from an alert into a handshake
message to allow it to integrate better with the handshake. This change
does that, rather than handling EOD at the record layer, it moves
processing up to the actual readers of (early) application data.

D19: use early_data instead of custom ticket_early_data_info extension
codepoint. D21: new ticket nonce field and change in PSK calculation.
This nonce provides some minor security advantage in case one of the PSK
is compromised (which would leak the resumption master secret).

Rename "resumptionSecret" to "pskSecret" in sessionState13 to reflect
the D21 change and use constant-time comparison for the secret.

Also fix potential panic if the ticket is large enough, but the
extensions are missing.

D19 added an additional pre-extract Derive-Secret stage. D20 shortened
labels. Bump from D18 to D21 with no backwards compat option for now
since older drafts are considered undeployable.

Support validation of ECDSA and RSASSA-PSS signatures. Explicitly do not
support PKCS1-v1_5 signatures since these are not allowed for handshake
messages.

Advertise TLS 1.3 in supported_versions and send a key share for the
first preferred curve. Missing are HRR, certificate validation and
Encrypted Extensions processing (see TODO notes).

For simplicity only a single key share is remembered. This key share
should be updated with a HRR (when implemented).

This change splits handshake processing for TLS 1.3, reindenting the TLS
1.2 code path and splitting initializationg of the handshake hash. No
equivalent is added for processServerHello because session resumption is
not supported yet.

All TLS 1.3 cipher suites so far use a nonce length of 12, but that does
not have to be the case. Correct the cipher suite definition and use it.
Spec: https://tools.ietf.org/html/draft-ietf-tls-tls13-22#section-5.3

Note: there is no functional change, the values were previously unused.

Fixes: ("[dev.tls] crypto/tls: implement TLS 1.3 cipher suites")

Disable 0.5-RTT as it has weaker security properties than 1-RTT. The
same security considerations from TLS False Start (RFC 7918) apply.

Currently the server Handshake method returns as soon as it has sent its
parameters, but it does not wait for the client to authenticate the
handshake via a Finished message. This broke a test that assumed that
the Handshake message performs a full handshake and also
(unintentionally?) enabled the server to send application data before
the handshake is complete ("0.5-RTT data").

Fix this by moving the implicit Finished message check in the handshake
message reader to the server handshake itself (previously readRecord
would process the Finished message as a side-effect of requesting
recordTypeApplicationData). And in the special case where 0-RTT data is
actually desired, process the Finished message in the ConfirmHandshake
and Read functions.

NOTE: 0.5-RTT is not disabled when the server enables 0-RTT. It is the
server responsibility to use ConfirmHandshake before writing anything.

Explicitly panic when ConfirmHandshake is used for client connections,
this is not the intended use of that API.

Merge serverHelloMsg13 into serverHelloMsg in preparation for draft 22.
This will also simplify the client implementation since only one
structure has to be checked.

Also fixed potential out-of-bounds access with keyShare unmarshal.

This makes it easier to validate the handshake contents using Wireshark.

Use the new keySchedule13 type instead of hash.Hash to avoid tracking
the hashContext and intermediate secrets manually.

checkPSK is modified not to return the calculated early secret, this is
internal to keySchedule13 now. The caller just learns whether it was
resumed using a PSK or not.

In order to reduce repetitive complexity (extract handshake context,
pass the right secrets around to calculate a secret and build a cipher),
create a new type that tracks the hash type, the handshake context and
intermediate secrets.

Advantages: facilitates reuse between client and server code, makes it
easier to update labels for draft-19, makes it easier to add central
KeyLogWriter functionality.

#23 -- CLA ok -- re-author to me+google@tomthorogood.co.uk

In particular move it to after cipher suite negotiation and after
HelloRetryRequest check.

There should be no data in the Handshake buffer on encryption state
changes (including implicit 1.3 transitions). Checking that also blocks
all Handshake messages fragmented across CCS.

BoGo: PartialClientFinishedWithClientHello