Minutes for TLS at interim-2015-tls-3
minutes-interim-2015-tls-3-3

# Decisions

## Curve 25519+448 draft

Move text from draft-ietf-tls-curve25519 to draft-ietf-tls-rfc4492bis.  The
appropriate curve 25519 & 448 will be included in TLS1.3; it's going to be
nearly empty because it's going to point at the CFRG draft (soon to be RFC).

## Issue 223 - absolute or relative time

Leave as-is because a) switching to relative time is painful and it's not
standalone, b) it's not entirely clear what benefit we get from this, and c)
we're already using absolute time for other things like certificates & OCSP.

## Issue 242 - do we require alerts to be sent

There was consensus around the idea that if we're going to send an alert then
we need to say unequivocally which alert to send.

The desired requirement level for sending alerts on the list ran the gamut from
MUST NOT to MUST, so at the interim it was agreed that we should reflect
reality and make sending all alerts a SHOULD level requirement.  This will
allow for those with concerns about sending alerts for whatever reason to not
send them, but also allow those who do to send them for whatever reason to
continue to do so.  Note that we have no guarantee that the alert that gets
sent ever gets to the recipient because our threat model has always assumed
that the attacker controls the links.  See issue #254.

## PR 248 - revised KDF

We agreed to adopt this PR.  But, we also discussed how to address MSJ's
comments wrt PKCS11/HSM support so EKR will submit another PR that will include
the label + length but nothing else.  See issue #5.

## PR 231 - remove SHA-1 from handshake

Based on list discussion, the chairs have determined that there is consensus to
remove support for SHA-1 from the TLS 1.3 supported_signature_algorithms
extension.  But, there is also a desire to continue to allow TLS 1.3 clients to
interoperate with the installed base of TLS < 1.3 servers that support SHA-1,
so if a client wants to interoperate with a TLS 1.2/1/0 server it can offer
SHA-1, but it must do so as the last signature/hash pair in the
supported_signature_algorithms extensions.  Further, the server if it
absolutely positively cannot return a path signed with signature/hash algorithm
pair in the client-supplied support_signature_algorithms extension then it can
also return a chain signed with SHA-1; MD5 remains a MUST NOT and we also
agreed to include SHA-224 in the MUST NOT column as well.

## Client Authentication

We agreed that we need to support this in TLS 1.3.

### How

1. We need to continue to support the existing two modes supported by D/TLS:
        1-RTT (i.e., the "normal" way: CC/CCV + Finish in 2nd flight)
        0-RTT (i.e., send cert with CH and the need to send a cert is explicit
        in the server config)

2. We will modify the data that's signed to conform with what Andrei is
proposing provided we also terminate the transcript for key derivation before
the CC/CCV.

investigate: using the same construct for server/client sigs.

2.5.  We're going to adopt the proposal from Andrei.

3. We agreed to opaque correlators.

4. We agreed to not allow unsolicited client auth.

5. We agreed to take out the ClientCertificatType from CertificateRequest.

6. We want a consolidated certificate message and certificate verify.

### Syntax

There is currently no consensus to add the "CertificateExtension" field to the
CertificateRequest because a) for this to be properly implement the matching
rules for each extension type need to be defined, b) there is a concern that
this mechanism can be used to fingerprint the client as well as extracting
which certificate the client supports, and c) it was unclear why the CA DN
couldn't be used to scope the returned certificates.  Andrei agreed to provide
a list of more constrained certificate extensions that have been asked for.

## Encrypted Content Type and Padding

We agreed that we need to support these two features in TLS 1.3.  We also
agreed to take a conservative approach when incorporating them.

For encrypted content type, we agreed to temporalily stay consistent with the
current TLS to keep a static content type to avoid breaking middle boxes.  See
PR #51.

For padding, we reached a very rough consensus to start with the content type
followed by all zeros (insert reasons why) over the explicit length option
(insert reasons why).  DKG to propose a PR that we'll then fight out on the
list.  See PR #253.

Why: Versions of TLS prior to 1.3 had limited support for padding. This padding
scheme was selected because it allows padding of any encrypted TLS record by an
arbitrary size (from zero up to TLS record size limits) without introducing new
content types. The design also enforces all-zero padding octets, which allows
for quick detection of padding errors

For the padding policy for handshake messages, we need some more thought
because it is really hard.

## Quantum Safe Extension/CipherSuite

The prevailing feeling at the meeting was that the scheme was not well baked,
but we also acknowledged that the WG is almost entirely focused on developing
TLS 1.3.  Because, this is intended as an experiment, we felt that the quickest
way forward was for the authors to select a cipher suite from the private use
space; this does not require an RFC or an internet-draft.  Alternatively, if
the authors want a stable specification they can produce an internet-draft that
they then take to the ISE (independent stream editor) for publication and ask
for a cipher suite from the specification required space.

We acknowledged that pursing an extension is more work because it requires an
IETF consensus document (i.e., an RFC) and that in the long term we would
consider adopting a draft that relaxes this position for this registry.

## Document TLS-Unique for 1.3

Issue #228

Problem: tls-unique is too short.

Solution need a draft that says:

1. Don't use tls-unique
2. Use an exporter
3. Make the the output length of at least 32 bytes
4. Define a label per application
5. Use session hash

Who: Ask Nico to generate a draft that specifies this.

## Data transfer limitation per connection (issue 125/4)

After quibbling with the math a bit, we need to specify how much data current
ciphers can safely encrypt.

Ask David McGrew for input!

## Include randoms directly in digital signatures

Issue 224

Consensus at the interim was that this has straightforward to do by just having
the authentication server supply the ServerRandom was enough since it can
search through the handshake transcript.

# PRF designation in server certificate verify

Issue 227

Consensus was to leave as-is. A hash identifier isn't the way to solve this. 
What you really need is contributory behavior to solve this issue.

## What identity is hashed into the secrets in "anonymous" mode

Issue 219

OBE - we removed anonymous.

## Consider extensionifying ServerKeyShare

Issue 214

Consensus is to just do it.  There's a minor improvement here.

## Encrypted SNI

We're punting on trying to learn the cover server config in band.

If we learn the cover server config out-of-band, then we need a few things in
the protocol to make this work (must get 1&2 and padding, 3&4 are nice to
have): 1. encrypted extensions from the client 2. descriptions of which
extensions are allowed to be sent as encrypted extensions 3. define sekrit_SNI
extension that overrides normal one 4. define cover_server_config extension

Now we need a PR.