Kazu Yamamoto | 18 Nov 03:22 2014

a type in the charter


The charter page of this working group[1] includes "v1.2 [RFC5346]"
but I think that it should be "v1.2 [RFC5246]".

[1] http://datatracker.ietf.org/wg/tls/charter/

Sean Turner | 16 Nov 00:49 2014

WG adoption: draft-thomson-sslv3-diediedie


This message serves as a WG call for adoption of "Deprecating Secure Sockets Layer Version 3.0":


Please let us know by November 29th whether you object to adopting this draft as a WG item (and why).

Martin Thomson | 13 Nov 21:05 2014

FFDHE and SHOULDs on usage

The thesis here is that strong groups (and 2048 isn't that strong) are
extremely expensive to verify, and folks are unlikely to do that
verification.  Therefore, the pick-your-own-group method is not just a
bad idea, but an invitation to attack.

The draft as written, however, allows all sorts of escapes in the form
of SHOULD-based statements for clients and servers to negotiate FFDHE
ciphersuites with the server doing PYOG.

Clients who want to do PYOG can simply not support (or pretend to not
support) this draft.

## Details:

The draft says that, for servers:

   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 SHOULD NOT select an FFDHE ciphersuite.

I think that this needs to be a MUST.  If the client is willing to
take the servers choice of group, then it would not be including the
fixed groups.

Similarly, all the SHOULDs in the client behaviour section needs to be hardened.

   The compatible client that wants to be able to negotiate strong FFDHE
(Continue reading)

Eric Rescorla | 13 Nov 20:13 2014

PRs for this morning

Hi folks. At the interim, people asked to see initial treatments of some
proposed changes to TLS 1.3 via the update mechanism. I've
uploaded Work in Progress (i.e., not ready for merging) versions
of these and put them up for comment as pull requests:

Update mechanism:

Moving client auth to update:

Merging session resumption and tickets and moving ticket
establishment to a update:

Warning: both of the latter two build on the first but they are independent
for ease of understanding.

If we have time, we'll be talking about these in the meeting today and
then on the list. If people are generally happy with this approach I'll prepare
new PRs for WG review (i.e., you will get another chance to take a look).

TLS mailing list
TLS <at> ietf.org
Martin Thomson | 11 Nov 22:26 2014

Downgrade SCSV info

I realize that this new information is late, but this is my
understanding of how Internet Explorer implements version fallback.
Rob, please correct me if I'm wrong.

TLS 1.2 (no RC4)
TLS 1.0 (no RC4)
TLS 1.0 (with RC4)

It is my opinion that this is not that large a risk.  We are highly
likely - in my opinion, and based on the numbers we have - to have few
TLS 1.1 servers that are both intolerant to the TLS 1.2 handshake AND
implement the downgrade SCSV.
Sean Turner | 11 Nov 05:23 2014

20141109 TLS interim minutes posted

Drafts minutes for the 11 November 2014 TLS Interim meeting can be found here:


Oleg Gryb | 11 Nov 05:02 2014

Twist security for brainpoolp256r1

Hi Daniel and TLS community,

I was going through SafeCurves pages recently and wanted to ask a question about brainpoolP256r1's twist security. According to this research http://safecurves.cr.yp.to/twist.html,,  a combined cost of attacks on brainpoolP256t1, which is a P256r1's "twist" is rather low. At the same time it's obvious that small-group-attack is not applicable, because "h=1" is a requirement for all brainpool curves including the one under consideration.

The other two "invalid-curve" attacks should be mitigated by openssl controls, since latter does have a point-on-the-curve validation (e,g. see EC_POINT_is_on_curve function and its usage in the latest openssl stable versions).

Given all that, can I consider the curve as secure? Are there any other attacks that I should consider before adopting the curve as a standard?

Thank you also for the wonderful research related to Curve25519 and Curve41417. They both seem to be perfect. I hope openssl community will adopt them soon.

TLS mailing list
TLS <at> ietf.org
Sean Turner | 11 Nov 04:17 2014

WG adoption: draft-nir-tls-rfc4492bis


This message is confirming the WG consensus we reached in Toronto about producing an updated RFC4492 that
is bound for standard track.* Yoav has produced an individual draft that can be found here:


that we would like the WG to consider adopting.  Please let us know by November 18th whether you object to
adopting Yoav’s draft (and why).


* This is for pre-TLS 1.3 because the 1.3 spec is going to incorporate the EC text directly in the base spec.  
Martin Thomson | 11 Nov 00:17 2014

Deprecating SSLv3

(UTA on BCC)

The POODLE attack has been used across the industry to justify disabling SSLv3.

For some of us, this was just the excuse, but others might need more
motivation.  A statement from the IETF might help move some people.

Richard, Alfredo, Adam and I have proposed such a statement:

Bodo Moeller | 10 Nov 21:17 2014

Adopt False Start spec as WG document? (draft-bmoeller-tls-falsestart-01)

At the TLS Interim meeting in Paris, I was asked to update the False Start Internet-Draft (http://www.ietf.org/proceedings/interim/2014/10/21/tls/minutes/minutes-interim-2014-tls-3), first in the light of TLS_FALLBACK_SCSV, and second because it describes behavior deployed by multiple vendors and it would be good to have this described in an (Experimental) RFC.

draft-bmoeller-tls-falsestart-01 is now available (see below). I'm asking the Working Group to consider adopting this document as a Working Group Internet-Draft.


A new version of I-D, draft-bmoeller-tls-falsestart-01.txt
has been successfully submitted by Bodo Moeller and posted to the
IETF repository.

Name:           draft-bmoeller-tls-falsestart
Revision:       01
Title:          Transport Layer Security (TLS) False Start
Document date:  2014-11-10
Group:          Individual Submission
Pages:          11
URL:            http://www.ietf.org/internet-drafts/draft-bmoeller-tls-falsestart-01.txt
Status:         https://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/
Htmlized:       http://tools.ietf.org/html/draft-bmoeller-tls-falsestart-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-bmoeller-tls-falsestart-01

   This document specifies an optional behavior of TLS implementations,
   dubbed False Start.  It affects only protocol timing, not on-the-wire
   protocol data, and can be implemented unilaterally.  The TLS False
   Start feature leads to a latency reduction of one round trip for
   certain handshakes.
TLS mailing list
TLS <at> ietf.org
Dan Brown | 10 Nov 18:58 2014

rm Hello.random w/ (EC)DHE [was OPTLS: Signature-less TLS 1.3]

When using (EC)DHE (inc. OPTLS below), the TLS random nonces (ClientHello.random and ServerHello.random) seem redundant (unless one re-uses ephemeral secret keys (but then maybe a counter or secure time would be almost as good a nonce as a random in this case), or perhaps for some other reason I’m missing), and perhaps even a point of fragility (e.g. if a common generator for nonces and keys is weak, or corrupted). So, does it make sense to remove these Hello.randoms, when using (EC)DHE, or to replace them with something milder, like Hello.time, Hello.counter, or just Hello.nonce?


Best regards,




From: TLS [mailto:tls-bounces <at> ietf.org] On Behalf Of Hugo Krawczyk
Sent: Friday, October 31, 2014 8:54 PM
To: tls <at> ietf.org
Cc: Hoeteck Wee
Subject: [TLS] OPTLS: Signature-less TLS 1.3


During the TLS interim meeting of last week (Oct 22 2014) I suggested that TLS
1.3 should abandon signature-based authentication (other than for certificates)
and be based solely on a combination of ephemeral Diffie-Hellman for PFS and
static Diffie-Hellman for authentication. This has multiple benefits including
major performance gain (by replacing the per-handshake RSA signature by the
server with a much cheaper elliptic curve exponentiation), compatibility with
the mechanisms required for forward secrecy, natural accommodation of a 0-RTT
option, and a simple extension without signatures for client authentication.

Below I present a schematic representation of the proposed protocol referred
to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three. 
The presentation is sketchy and omits the exact procedure for key derivation.
The latter is a crucial component for the security of the protocol, but
before getting into these details we want to get a sense of whether the WG is
interested in this approach. In the meantime, Hoeteck Wee and myself are
working on the details of the protocol and the security proof.

We describe a setting with optional 0-RTT and server-only authentication.
Client authentication can be added as a further option or as an extension
(similar to the current 1.3 proposal) - see below.


[K] symbols represent pointers to key material whose exact derivation is not
included here except for specifying the basic DH values from which the key is
derived (actual derivation will include further information similar to the
extended hash mechanisms or SessionHash proposal considered for 1.3).
Asterisks represent optional fields that the WG can decide to leave as optional,
mandatory, or simply remove without changing the core cryptographic security of
the protocol. All references to encryption mean "authenticated encryption"
using the encrypt-then-mac paradigm (or any other secure AEAD mechanism). 

KeyShare's represent ephemeral Diffie-Hellman values exchanged by the parties.
All the public key and Diffie-Hellman operations are assumed to happen over a
cyclic group with generator g of order q (typically implemented by an elliptic
curve group). We use multiplicative notation where ^ denotes exponentiation as
in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y), etc.
Omitted from the current high level description is a mechanism for testing group
membership of DH values or cofactor exponentiation (the specific mechanism
depends on the group type and is typically very efficient for elliptic curves).


The server has a long term private-public key pair denoted by (s,g^s) where
s is uniform random in [0..q-1] (we refer to s and g^s as "static keys").
We assume that the server has a certificate that includes the server's public
key g^s and a CA-signed binding of this key to the server's identity.
We discuss the implementation of such certificates below.


ClientData* [K0]       -------->
                                           ServerCertificate* [K1]
                                           ServerFinished [K2]
                       <--------           ServerData* [K2]
ClientFinished* [K2]   -------->

            Protected Application Data [K3]


The basic 1-RTT case omits the ClientData* field. It includes a ClientKeyShare
g^x and a ServerKeyShare g^y and an optional (encrypted) server certificate.
If the certificate is sent (it can be omitted if the client has indicated that
it knows the server key as in the case in the 0-RTT scenario) and is encrypted,
the encryption key K1 is derived from g^{xy}.

Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is used to
authenticate-encrypt the ServerFinished and ClientFinished messages (which
include a hash of the previous traffic) and to encrypt data from the server if
such data is piggybacked to the second message.

Key K3 is the "application key" used to derive key material for protection of
application data.  This key material will include (directional) Authenticated
Encryption keys and, possibly, keys for derivation of further re-key material.
K3 is computed from  both g^{xs} and g^{xy} similarly to K2, but its derivation
will be different than K2, e.g., using a separating key expansion technique.


The above protocol is compatible with a 0-RTT protocol such as QUIC. In this
case, the client is assumed to have information about the server's public key
and other security parameters. The server is assumed to have some mechanism in
place for detecting replay (e.g., via timestamps, stored client nonces, etc.).
The resulting protocol is as described above where the ClientData field is sent
encrypted under key K0 derived from g^{xs}. 
The rest of the protocol is identical to the above. 
Note: In this case, ServerCertificate is not sent as the client had to know
the server's public key before the first message (one can imagine a setting
where the server may send a different certificate in the second message - if
desired, this can be accommodated too as an option or extension).


Client authentication can be supported via an option or extension. It would
include a client certificate for a static DH key g^c sent in the third message
(the certificate can be encrypted under key K2 to provide client's identity
protection). In this case, the key for computing the ClientFinished message and
the application key K3 would be derived from a combination of the values g^xy,
g^xs, g^yc (and possibly also g^{cs}).


Note on Finished messages: The above spec sets ServerFinished as mandatory and
ClientFinished as optional. The latter option is needed for a 1-RTT protocol.
In principle, both Finished messages could be omitted and still obtain security
via implicit authentication (assuming the inputs to key derivation are chosen
appropriately). But given the advantages of ServerFinished for providing
explicit authentication, key confirmation, and active forward secrecy (see
below), it seems advisable to always include it. Including ClientFinished
provides key confirmation from client and also explicit client authentication
when client certificate is included. ClientFinished also provides Universal
Composable (UC) security (this is a result of the Canetti-Krawczyk proof that
CK security implies UC security when a client confirmation step is included). 

Note on certificates: Since in current practice servers hold certificates for
RSA signature keys rather than for static DH keys, the certificate field in the
above protocol will be implemented by a pair consisting of (i) the server's RSA
signature certificate and (ii) the server's signature using this RSA key on the
server's static public DH key g^s. The latter signature by the server is
performed only when a new static DH key is created (how often this happens and
how many such keys are created is completely up to the server - it has the
advantage that these keys can be changed often to increase security against
leaked keys). This use of RSA also enjoys the high efficiency of RSA
verification for the client. 
The handling of Client certificates would be similar.

Note on forward security (a.k.a. as PFS for Perfect Forward Security):
PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys.
The meaning of PFS is that an attacker that finds the (long-term) static
private keys of the parties cannot compromise past session keys. Without the
ServerFinished message the above protocol ensures forward secrecy against
passive attackers (i.e., for sessions where the attacker did not choose g^y).
With ServerFinished, PFS holds also against active attackers.  A similar
consideration applies to ClientFinished.

Client certificates in the first message: We note that in cases where client
certificates can be sent in the clear in the first message of the protocol, one
can provide PFS and mutual authentication in a 1-RTT at essentially the same
cost of an unauthenticated DH exchange (i.e., a cost of little more than two
exponentiations). In such a setting one can also obtain mutual authentication in
a 0-RTT protocol (with forward secrecy with respect to the client's key). 
These options, however, require HMQV-like mechanisms and may raise IP issues (this
can be investigated further if the WG is interested).

Attachment (smime.p7s): application/pkcs7-signature, 8 KiB
TLS mailing list
TLS <at> ietf.org