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

TLS Interim Meeting
===================

--------
DAY 1 - Thanks to Rich Salz for taking these.
--------

Should we remove SSLv3 from the session hash draft?  Various points about why
SSLv3 is either not being used, or in devices that aren’t being updated. One
more update to remove SSLv3, some other cleanups, and then go to WG LC. Sean
will try to force out any issues for discussion in Hawaii.

Bodo slides are at
http://www.ietf.org/proceedings/interim/2014/10/21/tls/slides/slides-interim-2014-tls-3-1.pdf
  Based on list feedback, going to add some clarifications (no changes to the
mechanism).  False start I-D needs to be updated since attacker can force a
version; Bodo to do that. Discussion of distinguishing between TCP reset (in
FF) and version intolerance. Discussion of when to ‘guess’ failure is transient
or version intolerance. Need to add some guidance to the I-D: mixing SCSV and
version-intolerant servers will cause a pain. Sean went through issues raised
on mailing list.

What is status of false-start? Was held back by Google for interop concerns.
MSFT always tries based on cipher-suite (says MT); others do it conditional on
NPN or ALPN and a modern cipher like a DH. It’s in wide use. Bodo will update
the draft and ask the WG to adopt

Dkg on named groups. No longer an extension; allocating points within the
namedcurve list, they are finite-field groups. Interacts with cipher-suite
list.  Discussion about adding ordering semantics between the two lists.
Change: clients that wish to express an ordering may order the curves/groups in
their order of preference.

Discussion of RC4 draft.  Andrei via phone. Room strongly supports prohibiting
RC4. Discussion about being able to address concerns raised by a few. Chair
will close discussion and move it forward. Sean to include text about “just
upgrade to TLS 1.2” as we considered alternatives and rejected them in his
shepherd notes or equivalent. YouTube currently allows two cipher suites for
video streams, TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA,
but Firefox doesn't support the former without ECDHE
(https://bugzilla.mozilla.org/show_bug.cgi?id=1029179).

Return to DH named groups.  Dkg prefers not-using IKEv2 primes, so that
national-scale adversaries workload doubles. We’ll ask CFRG “do you have a
problem with these groups?” Decided that SRP re-use of IKEv2 groups is not an
issue. Discussion of sizes.  Sean going to straw poll the list for 2048 or
2432, will work with dkg to draft the message. Proposed sizes 20xx 3032 4096
8192. Discussion of having server return the full key.  Dkg to come back to the
mailing list. Discussion of how to do PSK with PFS; neat hack/thought, treat it
like a resumption.

Compressed points. Certicom says no IPR coverage any more. Likely to drop
uncompressed points (and their negotiation) from TLS 1.3  ekr to do a straw
poll on the mailing list.

--------
DAY 2 - Thanks to Hannes Tschofenig for taking these.
--------

Session Hash, Resumption and Key Fresh

Original TLS: Initial session establishes the session index with session id and
establishes pre-master-secret.  If you wanted to do a re-key you do a new
handshake. But the re-negotiation feature got removed.   This removed two
features: incremental authentication and re-keying. Additionally, attacks
against the weak binding were found.

Session hash signs the entire transcript.

People want to keep session resumption for performance reasons.

Nobody was in favour of removing session resumption.

Goal: There has to be a way to re-run the key exchange without the public key
operation.

Challenge with mobility is that DTLS record layer has no additional identifier
that allows selection of the correct key in case of a client IP address change.
Ekr mentions that the use of UDP was probably wrong.

Ekr suggests to merge PSK and resumption.

Martin mentions tickets and the potential vulnerability to lots of sessions
when the key encrypting the ticket is compromised.  Rich mentions their policy
whereby the customer key gets mixed into the ticket key; session lifetime
roughly 24 hours.

Idea: Updating traffic keying material considering key compromise (useful for
long-lived connections).  Previously an issue because of certain ciphers. The
problem is compromise of keying material.

Rich and Martin mention that tickets are stored on a large number of servers in
content distribution servers. Ekr: In the design we thought it would be easier
to distribute revocation state rather than session state. Ekr+Rich: Companies
today don't do revocation.

Ekr: Just deleting your DH shares does not provide PFS. If you use session
resumption then you do not get PFS either.

Alfredo: Unify resumption and pre-shared keys.
Question: Should the PSK resumption use the same ciphersuite?
Group: Yes

Rich: Combine tickets with session Id. Could be used as a key identifier for
the PSK case. Session ID has to be sent in clear to avoid the public key
operation.

Ekr: It would be good to have a session id that it is not the same all the time.
Assumption: server keeps no state
Discussion about how a design could look like. All solution ideas seem to
require a pool of ids to be kept at the server (which is similar to how EAP-AKA
works, see http://tools.ietf.org/html/rfc4187).

Discussion about which protocols require multiple connections to the same
server; HTTP and IMAP mentioned.

The security properties are totally dependent on the servers policy.

It turns out that there is no way to provide the desire properties without
doing another DH exchange during the resumption (or to re-start the full
exchange).

Goal: Avoid public key crypto during the session resumption.

XMPP guys turn off session resumption. They have to deal with the situation
that connections break regularly. Application protocols need to be able to
handle multiple connection setups in parallel.

Network access authentication: Resumption could also be done for avoiding user
authentication.

We want to update keys: Simplest thing is to add a message that says "I am
unilaterally updating my key". This would deal with cryptographic exhaustion
(e.g., nonces with GCM) and with future compromise of the keys for the data you
have already sent. Should you also force the other side to change their keys?
It might also be useful for asymmetric key data exchange (more sending than
receiving)

XMPP: A server will often be multi-tendency but it also happens with HTTP 2.0.
There is a way to create two connections with different domains. There are
ideas about application layer delegation.

The question whether client authentication should be pushed entirely to the
update mechanism.

Questions for the group to discuss:
* refresh keying material
* adding a Diffie-Hellman exchange
* add authentication during the session
* what are we exposing to the developer?
  what is the conceptual model for the user (e.g., certificates expire during
  the lifetime of a session)

With the removal of re-negotiation ciphersuites cannot change anymore during
the lifetime of a session.

Martin: Multiple data in flight (interleaving streams) and then I add a
certificate during the connection. What happens when the server processes the
pending request should the received certificate apply to the pending data. When
an Web server receives the request it does a look-up to the identity provided
by the TLS layer.

Martin starts to draw a picture about the problem.

Argument that this topic is already covered with the Renegotiation Indication
Extension spec: https://tools.ietf.org/html/rfc5746. Is there a way a
retro-actively asserts the right order of the application protocol exchange?
There is a race condition.

Existing application don't offer this functionality (because they don't have
this renegotiation feature). This is a future-facing problem rather than a
backwards facing problem. So, it does not cause problems in past behavior.

Suggestion to use the token binding and ALPN message since it is similar to
client authentication and it is similar to session authentication:
https://tools.ietf.org/html/draft-popov-token-binding-00

Any information about what keying material the client could be using should be
pushed to the application layer. Ekr provides critique to the way how the
CertificateRequest could look like (since it is incomplete; CA list is empty or
populated from the system root store, which is large). It would be better to
move that part of the logic to the application layer.

It is easier for the client to indicate what it wants to talk to (other than
SNI). The type of certificate the client is supposed to present is very
application.

Ekr suggests for the IoT case that the client just sends it.

This would require an update to the HTTP stack rather than just a TLS stack
update.

Ekr suggests that we should abandon PAKE. Others agree. The problem seems to be
in the interaction with the user interface.

Suggestion to look at SSH since it also follows a similar pattern.

Sean: Should we annotate the IANA registry to indicate what can and cannot be
used with TLS 1.3? Ekr: We should add another text field in there (a new
column).

Key hierarchy

Ekr draws a diagram with the key hierarchy and how the UPDATE and the ACK
message is used. --> UPDATE (nonce) <-- ACK (H(UPDATE))

The ACK is needed for DTLS. Using the UPDATE to trigger an update by the other
side; it allows the party that has better information about the cipher lifetime
can dictate how often the key to change.

Discussion about the use of a Diffie-Hellman exchange incorporated. Dan raised
the idea of re-using old key shares to have new keys available right after
sending the first message.

--> UPDATE (Yc)
<-- ACK (Ys)

Issue surfaced that there is a need to add another exchange:

C -> S: Ya
S -> C: Yb
S -> C: Update
C -> S: UpdateAck

UpdateMsg: {
  type: dh_req | rekey | ack
  case (type)
     dh_req: Yx
     rekey: nonce
         dh_resp:  Yx || tid
         ack: hash(over-something)

GCM: Argument by Stephen Kent to guarantee no nonce re-use.
(GCM: carried the nonce on the wire)
http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf

Some others wanted to get rid of the info carried over the wire.

* 0-Roundtrip

Point of session resumption is to remove the DH exchange.
The purpose of the 0-roundtrip is to send data on the first flight of data
(i.e., roundtrip latency)

For a PK-based exchange there have to be multiple ways to learn the keys
upfront (e.g., previous exchange, DNS, etc.)

If we have a non-trivial connection error rate then we should tell service
operator to connect to a 1.3 server and to also have 1.2 servers in the same
clusters. It is theoretically safe to send a TLS client hello to any server.

Requirement: have extension tolerance across your cluster.

0-roundtrip: Goal is that resumption leads to no worse behaviour than an
ordinary exchange if it fails.

Suggestion is to use a PSK combined with a DH-exchange (PSK for authentication
and DH for PFS) so that the server can choose in case something got wrong.

The server could publish his DH share in the DNS.

Ekr claims that 0-roundtrip could also work for resumption.

Hugo says that PSK and static DH is the same. In the PSK there is a identity
hint to select the key and in the second case there is Ys as a pointer to the
private key.

Discussion about how the API would look like for distinguishing the early data
vs. complete exchange. Ekr says that he implemented early data and it was
complicated due to special handling of the code path for finished message.

Hugo draws a 0-roundtrip and a 1-roundtrip exchange on the whiteboard. Hugo
suggested a solution to have certificates for static Diffie-Hellman by taking a
regular certificate that is then used to sign the public Diffie-Hellman key.
Dan says that this is similar to proxy-Certs that just don't use the X.509
structure.

In response to whether this is a new design Hugo said that a similar design
goes back to the above paper (from
NDSS'96:http://webee.technion.ac.il/~hugo/skeme-lncs.ps) which had actually
many of the same motivations than the current proposal (PFS, identity
protection, a uniform treatment of pre-shared key and re-key, etc). On the
other hands, there are some significant differences in the new proposal such as
the support of 0-RTT and server-only authentication. In cryptography little
changes can introduce vulnerabilities so OPTLS needs to be considered as a new
design for the sake of analysis (and there are important details to be nailed
down, especially the key derivation definitions).

* FlexTLS

Alfredo presented their work on FlexTLS. He demonstrated the ability to
re-produce the Early CCS attack. The attack is described here:
https://www.imperialviolet.org/2014/06/05/earlyccs.html
http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html

----

ssl_send_flight_completed: function executed every time last message of
exchange is sent out.

 --> call ssl_write_record (the message is already in ssl->out_msg)