Erik Nygren | 2 Jul 23:40 2015

TLS Client Puzzles

Following a discussion last year in Denver, I've written up a proposal
for a TLS Client Puzzles extension.  It is specific to TLS 1.3 in that
it is constructed using the HelloRetryRequest request flow (although
it could be adapted to HelloVerifyRequest with prior versions of DTLS).

The puzzles here are placeholders meant as a starting-point for discussion
(and also take in some feedback from discussions on this list last year)
and will likely evolve.


---------- Forwarded message ----------
From: <internet-drafts <at>>
Date: Thu, Jul 2, 2015 at 5:30 PM
Subject: New Version Notification for draft-nygren-tls-client-puzzles-00.txt
To: Erik Nygren <erik+ietf <at>>

A new version of I-D, draft-nygren-tls-client-puzzles-00.txt
has been successfully submitted by Erik Nygren and posted to the
IETF repository.

Name:           draft-nygren-tls-client-puzzles
Revision:       00
Title:          TLS Client Puzzles Extension
Document date:  2015-07-02
Group:          Individual Submission
Pages:          12

   Client puzzles allow a TLS server to defend itself against asymmetric
   DDoS attacks.  In particular, it allows a server to request clients
   perform a selected amount of computation prior to the server
   performing expensive cryptographic operations.  This allows servers
   to employ a layered defense that represents an improvement over pure
   rate-limiting strategies.

   Client puzzles are implemented as an extension to TLS 1.3
   [I-D.ietf-tls-tls13] wherein a server can issue a HelloRetryRequest
   containing the puzzle as an extension.  The client must then resend
   its ClientHello with the puzzle results in the extension.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

The IETF Secretariat

TLS mailing list
TLS <at>
Sean Turner | 2 Jul 15:17 2015

soliciting agenda topic for the ietf 93 tls sessions


The IETF 93 agenda is out.  We’re scheduled for Tuesday 1520-1720 in Congress Hall II and Wednesday
0900-1130 in the Grand Hilton Ballroom.  We requested two slots because a) we didn’t have an interim
between IETF meetings and b) even with an interim between meetings last time we were still rushing at the end.

Please send in agenda requests to tls-chairs <at>  But, please note that TLS 1.3-related
issues and previously adopted drafts will be given a priority during the sessions.  We’re also going to
give preferential treatment to items that got bumped last time as well as drafts that generated
discussion on the list.


Arnaud KAISER | 1 Jul 14:08 2015

New version of draft-lonc-tls-certieee1609-01.txt

Dear members of TLS WG,


A new version (-01) of draft-lonc-tls-certieee1609 has been submitted. The draft can be found here:


The proposal of this draft is to extend the TLS protocol to support ITS-specific certificates defined by IEEE and ETSI.


Any comments are welcome. Also, if possible, we can do a short presentation of the draft at the 93rd IETF meeting.


Best regards,

Arnaud Kaiser



Arnaud Kaiser

Research Engineer

IRT SystemX

8, Avenue de la vauve

91120 Palaiseau, France


TLS mailing list
TLS <at>
Eric Rescorla | 1 Jul 00:23 2015

TLS 1.3 draft-07 sneak peek


Yesterday, I posted the -06 draft which snapshots the consensus changes
made since -05, specifically:

- Prohibit RC4 negotiation for backwards compatibility.
- Freeze & deprecate record layer version field.
- Update format of signatures with context.
- Remove explicit IV.

In the background, I've also been working with Hugo, Hoeteck, Karthik,
and others to develop a new draft using semi-ephemeral DH based on
Hugo's ideas as discussed in Dallas. I'm planning to merge this into
master soon and submit it as draft-07 next week, but I wanted to
e-mail the list and give people a chance to comment before I do
that. I've provided a summary of the major changes and open issues
below. Remember, this is a WIP so if you see something wrong, don't
panic, but do let me know.

1. Move ClientKeyShare into an extension so that the ClientHello
   is the only message in the client's first flight. This removes
   a bunch of ugliness around the "early_data" extension which
   could encapsulate handshake and application data.

2. Added a mechanism for the server to indicate a known (EC)DHE
   key/configuration which the client can then use in subsequent
   handshakes (via the known_configuration extension). The net
   effect here is that the client and server can skip over the
   signature in subsequent handshakes, which provides benefit
   when signatures are much slower than key exchange, as with
   RSA; it also enables 0-RTT.

3. Added support for 0-RTT data, both with and without
   client authentication.

4. Removed most of the support for resumption in favor of
   a mechanism proposed by Karthik where you just establish
   a PSK in connection N which you then use to key a PSK
   cipher suite in connection N+1.

All of these keying mechanisms use a unified key schedule based on two
keys the "Ephemeral Secret" (ES) and the "Static Secret"
(SS). Depending on the exact handshake type, these may be equal, but
the logic is the same regardless. In the process, I also converted
the key schedule to use HKDF (per WG consensus).

There are still a number of known open issues to discuss:

1. The present known_configuration mechanism allows the client to
resurrect the handshake parameters (though not the keys) which were
negotiated in a previous handshake, but this is done implicitly,
i.e., the server provides a label and the client returns it on
the next connection. This has the advantage of keeping things short
but the disadvantage the it means that you can't have a static
configuration ID for everyone (instead, the server has to somehow
embed the properties in the configuration ID). There are (at least)
three potential alternative designs:

   (a) Have the client indicate in his first flight "these are the
       parameters I expect you to negotiate", along with the
       configuration identifier, based on what the server
       negotiated the previous time. [Optionally, the server
       can run the same negotiation locally and abort on mismatch.]

   (b) As in (a) but with no indication of the expected parameters,
       just the configuration ID, and the client just preemptively
       uses the parameters from the last time and if the negotiation
       ends up differently, all the data is undecryptable
       (ugh) and you somehow fall back.

   (c) Have the server provide a preference list in his
       ServerConfiguration (this can be the same as in the
       ClientHello) and have the client do the negotiation based on
       that rather than the server (as in QUIC). This is a little odd
       in that it means that sometimes the server selects the
       parameters and sometimes the client does, but it's not that
       hard to make this code symmetrical.

As I think this through, I am leaning towards (a) but other people's
opinions on this topic would be welcome.

2. Should we require that PSK cipher suites where the PSK is used for
resumption use compatible ciphers? This is the way it was in TLS 1.2
and below for resumption and tickets, but once you have a PSK, that's
not really necessary [0]. So, for instance, if you had the following
cipher list order:

    ECDHE + ChaCha/Poly
    PSK + ChaCha/Poly

You could potentially negotiate one connection with GCM, use it
to establish a shared key, and then reconnect with ChaCha/Poly.
This seems like it probably should be something we avoid, though
I'm not sure we have a concrete reason why, and it means a
weird special case for PSK. Note that this issue might be
ameliorated some (though not completely) with a la carte negotiation.

3. I don't currently have PSK/Resumption + 0-RTT working, because you
need a way to indicate the expected parameters (see point #1 above).

4. I plan to rewrite the Handshake Protocol Overview (S 6.2)
to be clearer. I hope to do this before submitting -07.

5. Security Considerations is badly out of date, so I plan to
rewrite that soon, but probably not before Prague. I also intend
to do a pretty substantial editorial cleanup pass and potentially
some restructuring after Prague.

As indicated above, this is still a WIP, so no doubt contains
a number of errors, potentially serious ones. Comments and PRs


[0] With the exception of cryptographic concerns about the use
of the same IKM with different hash functions for HKDF, but this
is a problem that applies to any use of PSK, not just this one.

TLS mailing list
TLS <at>
Martin Rex | 30 Jun 22:26 2015

RFC7301 ALPN conflicting objectives about app-specific server certificates

I'm currently implementing support for ALPN in our middlware,
and I'm wondering how to account for ALPN in the client side session caching
management, because rfc7301 describes two mutually exclusive objectives
and the ALPN protocol does not provide a means for the server to
disambiguate the desired semantics in the ServerHello response.


Section 1. last sentence of paragraph 2 (end of page 2):

                                           Further, it would be
   advantageous to allow certificate selection based on the negotiated
   application protocol.

Section 1, last sentence of paragraph 4 (last paragraph):

                         The application protocol negotiation can thus
   be accomplished within the TLS handshake, without adding network
   round-trips, and allows the server to associate a different
   certificate with each application protocol, if desired.

is in conflict with

Section 3.1, last paragraph

   Unlike many other TLS extensions, this extension does not establish
   properties of the session, only of the connection.  When session
   resumption or session tickets [RFC5077] are used, the previous
   contents of this extension are irrelevant, and only the values in the
   new handshake messages are considered.

Currently, my client-side session cache management, and the decision whether
to propose a TLS session to the server for resumption, is based on a match
of the application supplied "target name" which is usually an fqdn hostname,
but could also be an abbreviated hostname or an IP address.

When the server does not resume the proposed session, and performs a
full handshake instead, my client purges the previous cached session and
adds the newly established session to the client-side session cache

If the server uses distict server certificates per application protocol
and properly(!!) performs a full handshake if the server certificate
does not fit the requested application protocol, then alternating
requests with two different protocols to the same server will result
in constant full TLS handshakes.

But what can also easily happen, is that the server is inappropriately
sharing the server-side session cache an incorrectly resuming sessions
associated with the wrong server certificate (a different certificate
than what the server would select if it would perform a full TLS handshake),
and if the different server certificate attributes are relevant to the
application protocol, then this would result in random client-side
errors (failed server certificate validation) when there is already
a session for the _other_ app in the client-side session cache.

I've seen incorrect server-side session cache pooling before, e.g.
a few years ago between and

Essentially, I believe that tagging of the session with the ALPN
negotiated protocol to result in more "predictable" behaviour, because
it will not interfere with client-side session cache management
and not result in occasional confusion should other server implementors
ever make their servers use different server certificates for
different ALPN-negotiated protocols.

Melinda Shore | 30 Jun 07:13 2015


Hi, all:

We've submitted a initial draft describing a TLS extension for
the transport of a DNS record serialized with the DNSSEC
signatures needed to authenticate that record.  This would
allow DANE clients to perform DANE authentication of a
TLS server certificate without performing additional
DNS lookups and incurring the performance costs associated
with them.  There are some additional benefits around
things like middlebox traversal, and allowing a TLS client
to validate DANE records without needing secured access to a
validating DNS resolver.

Please have a look at it and get comments or suggestions
to us.  We're planning on getting one more revision out
prior to the Prague meeting, and on having a test
implementation available in Prague.
The draft is available at:




Melinda Shore
No Mountain Software
melinda.shore <at>

"Software longa, hardware brevis."
Simon Josefsson | 30 Jun 00:02 2015

PKIX drafts on EdDSA/Ed25519 and Curve25519/Curve448

Hi all,

(I'm cross-posting pkix <at>  and tls <at>  because there is cross-WG coordination
involved here -- please redirect followups appropriately.)

Symantec kindly donated two OIDs for Ed25519 keys/signatures.  I have
updated the EdDSA/Ed25519 draft to use them, together with some other
minor tweaks.  Please find the updated document here:

Symantec also offered for other curves or
signature schemes, as they are defined, which will shave off a couple of
bytes for us.  Coordination of allocation is handled by Rick Andrews.

A couple of people suggested to define encodings for Curve25519/Curve448
(the CFRG curves) public keys.  I didn't see that this necessarily had
to be in the above document, so I put it in a separate document.  I'm
not entirely sure how useful this is, or if I may have completely
misunderstood what people had in mind.  Please find a new document here:

The document is short and a bit rough at the moment; all feedback is

TLS mailing list
TLS <at>
John Mattsson | 29 Jun 13:49 2015

Re: New Version Notification for draft-mattsson-tls-ecdhe-psk-aead-00.txt


We have submitted a new draft defining several new PSK_ECDHE cipher
suites. The cipher suites are all based on the Ephemeral Elliptic Curve
Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with
the Authenticated Encryption with Associated Data (AEAD) algorithms
AES-GCM and AES-CCM. Pre-Shared-Key authentication is used in several
deployments, e.g. 3GPP and IoT.

Ericsson has recently proposed that 3GPP makes significant updates to the
3GPP profiles for TLS and DTLS. Among other things: Reference RFC7525 and
mandate implementation of TLS 1.2, DTLS 1.2, and

During this work we identified that the PSK cipher suites that we would
like to implement were not defined. We think that the natural choice for
anyone wanting PSK authentication should be to use ECDHE together with the
AEAD algorithms AES-GCM and AES-CCM.

Comments appreciated.


John Mattsson
MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator
Senior Researcher, Security

Ericsson AB                          Phone +46 10 71 43 501
Ericsson Research                    SMS/MMS +46 76 11 53 501
Färögatan 6                          john.mattsson at
SE-164 80 Stockholm, Sweden


On 29/06/15 13:18, "internet-drafts <at>" <internet-drafts <at>>

>A new version of I-D, draft-mattsson-tls-ecdhe-psk-aead-00.txt
>has been successfully submitted by John Mattsson and posted to the
>IETF repository.
>Name:		draft-mattsson-tls-ecdhe-psk-aead
>Revision:	00
>Title:		ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport
>Layer Security (TLS)
>Document date:	2015-06-29
>Group:		Individual Submission
>Pages:		5



>   This memo defines several new cipher suites for the Transport Layer
>   Security (TLS) protocol.  The cipher suites are all based on the
>   Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
>   (ECDHE_PSK) key exchange together with the Authenticated Encryption
>   with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
>   provides light and efficient authentication, ECDHE provides perfect
>   forward secrecy, and AES-GCM and AES-CCM provides encryption and
>   integrity protection.
>Please note that it may take a couple of minutes from the time of
>until the htmlized version and diff are available at
>The IETF Secretariat

TLS mailing list
TLS <at>
Joseph Salowey | 29 Jun 05:16 2015

Adding Curve448-Goldilocks to draft-ietf-tls-curve25519

Does anyone have an objection to adding Curve448-Goldilocks to draft-ietf-tls-curve25519?  Please respond by July 5, 2015.  


TLS mailing list
TLS <at>
Attila Molnar | 27 Jun 01:48 2015

New cipher suites for SRP


Currently SRP cannot be used with newer crypto primitives such as ciphers in
AEAD mode or SHA-2 due to the lack of cipher suites enabling these.
There's only 3DES and AES-CBC with SHA-1.

Would there be support for expanding the SRP cipher suites?

Regards, Attila
Jeffrey Walton | 25 Jun 23:04 2015

Origin Bound Certificates extension?

Forgive my ignorance... What happened with the Origin Bound
Certificates extension