Salz, Rich | 8 Feb 19:36 2016


Is anyone else using JPAKE?  I found old I-D, but my search-engine-skillz must be atrophied as I can’t find any final RFC on it.


It’s currently “experimental” code in OpenSSL and we might drop it in the next release.



Senior Architect, Akamai Technologies

IM: richsalz <at> Twitter: RichSalz


TLS mailing list
TLS <at>
Yaron Sheffer | 6 Feb 21:36 2016

Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-01.txt

The draft describes using an opaque ticket (similar to a session resumption ticket) to pin the identity of a TLS server. The new version addresses several comments on this list, in particular regarding the message syntax, and requesting a comparison with TACK - thanks Dave and Daniel.


-------- Forwarded Message -------- Subject: Date: From: To:
New Version Notification for draft-sheffer-tls-pinning-ticket-01.txt
Sat, 06 Feb 2016 12:25:54 -0800
internet-drafts <at>
Yaron Sheffer <yaronf.ietf <at>>

A new version of I-D, draft-sheffer-tls-pinning-ticket-01.txt has been successfully submitted by Yaron Sheffer and posted to the IETF repository. Name: draft-sheffer-tls-pinning-ticket Revision: 01 Title: TLS Server Identity Pinning with Tickets Document date: 2016-02-06 Group: Individual Submission Pages: 16 URL: Status: Htmlized: Diff: Abstract: Fake public-key certificates are an ongoing problem for users of TLS. Several solutions have been proposed, but none is currently in wide use. This document proposes to extend TLS with opaque tickets, similar to those being used for TLS session resumption, as a way to pin the server's identity. That is, to ensure the client that it is connecting to the right server even in the presence of corrupt certificate authorities and fake certificates. The main advantage of this solution is that no manual management actions are required. 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>
Stephen Farrell | 4 Feb 01:47 2016

Re: [Unbearable] Early code point assignment requests for "Transport Layer Security (TLS) Extensions" registry

Hi All,

(Adding the TLS wg list, just in case.)

I think this is fine and IANA should allocate a codepoint as


On 02/02/16 23:50, John Bradley wrote:
> The Tokbind WG would like to ask for an early allocation of an IANA
> code point for the "TLS Extension for Token Binding Protocol
> Negotiation"
> (
> <>).
> This document defines a new TLS extension "token_binding", which
> needs to be added to the IANA "Transport Layer Security (TLS)
> Extensions" registry.
> Please note that this document also seeks to establish a registry for
> identifiers of Token Binding key parameters entitled "Token Binding
> Key Parameters" under the "Token Binding Protocol" heading. This new
> registry is not part of the early assignment request.
> At this point, authors do not expect major changes in the "TLS
> Extension for Token Binding Protocol Negotiation" specification.
> There are at least two prototype implementations of this
> specification being worked on (by Google and Microsoft). An early
> IANA code point assignment would facilitate implementation and
> deployment experience prior to the publication of the RFC.
> Regards John Bradley
> _______________________________________________ Unbearable mailing
> list Unbearable <at> 
internet-drafts | 2 Feb 00:01 2016

I-D Action: draft-ietf-tls-rfc4492bis-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2
and Earlier
        Authors         : Yoav Nir
                          Simon Josefsson
                          Manuel Pegourie-Gonnard
	Filename        : draft-ietf-tls-rfc4492bis-06.txt
	Pages           : 31
	Date            : 2016-02-01

   This document describes key exchange algorithms based on Elliptic
   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
   protocol.  In particular, it specifies the use of Ephemeral Elliptic
   Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
   use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards
   Digital Signature Algorithm (EdDSA) as new authentication mechanisms.

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

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

Internet-Drafts are also available by anonymous FTP at:
Salz, Rich | 1 Feb 16:01 2016

Interop for X25519

If you have X25519 key exchange for TLS and are willing to help OpenSSL interop (soon), please drop me a line.



Senior Architect, Akamai Technologies

IM: richsalz <at> Twitter: RichSalz


TLS mailing list
TLS <at>
Martin Thomson | 27 Jan 04:51 2016


4472bis has a TBD regarding a missing "E" in the name of ECDHE_anon
cipher suites.

I raised an issue:
David Benjamin | 27 Jan 03:02 2016

Backwards-compatibility of 0-RTT data

Instead of putting 0-RTT data in a ClientHello extension, the current draft has the client send extra records in the first flight, right? (I see an early_data extension, but it seems only be an indicator. There's also mention of requiring trial decryption which only makes sense if it were appended.) Was there a reason not to put it into an extension? It's uglier, but the current scheme has compatibility risks and may force clients into a fallback dance.

Although a TLS 1.3 client won't make 0-RTT handshakes to a service until it's managed to speak TLS 1.3 to it once, services aren't made of one machine. Many services span multiple machines, changes are deployed incrementally, etc. Even single-machine services may need to roll back a change. This kind of statefulness means that one cannot enable 0-RTT on *any* machine until *all* machines in the fleet have enabled TLS 1.3. And TLS 1.3 may not be rolled back once 0-RTT is enabled (at least not until all server configs have expired).

I would not expect all deployments to get this right. Large companies with TLS experts might, but most people will idly take updates from their operating system with (hopefully!) TLS 1.3 and 0-RTT enabled by default. They won't realize fleets must "set" at TLS 1.3 without 0-RTT before enabling TLS 1.3 with 0-RTT.

This is the same flavor of problems in session resumption that motivated That bug wasn't hypothetical. At the time I filed that issue, was two wildly different servers. One spoke up to TLS 1.0 and the other up to TLS 1.2. OpenSSL on the client has some bugs around resumption which gives similar version stickiness effects. Until I reworked the version negotiation code, Chrome + BoringSSL would fail to connect sometimes.

Having the 0-RTT data delimited in the ClientHello should hopefully also avoid the trial decryption step on 0-RTT miss which seems kind of silly.

TLS mailing list
TLS <at>
David Benjamin | 27 Jan 01:46 2016

0-RTT, server Application Data, and client Finished

It's possible I'm reading the draft wrong, so this thread may be a very short one.

(t here is in units of RTT, so t=0 is when the client sends ClientHello and t=0.5 is when the server receives ClientHello and sends ServerHello, t=1 is when the client receives ServerHello, etc.)

Looking at the Zero-RTT exchange here:

Is the intention that the client, even in the successful 0-RTT case, send two Finished messages (one at t=0 and one at t=1) and that the server not send application data until receiving the second of these at t=1.5? If so, does this not defeat the purpose of 0-RTT? Although the client now eagerly sends at t=0, it will not see the response until t=2, which is no better than the resumption case (in TLS 1.2 or 1.3) where the client doesn't send until t=1.

TLS mailing list
TLS <at>
Sean Turner | 25 Jan 17:30 2016

Fwd: [dns-privacy] Call for Adoption: draft-dgr-dprive-dtls-and-tls-profiles

This is a draft that might be of some interest to the mailing list, but please send your comments to the DPRIVE mailing list.


---------- Forwarded message ---------
From: Tim Wicinski <tjw.ietf <at>>
Date: Tue, Jan 12, 2016 at 4:56 PM
Subject: [dns-privacy] Call for Adoption: draft-dgr-dprive-dtls-and-tls-profiles
To: dns-privacy <at> <dns-privacy <at>>

The chairs realized earlier today that we encouraged this draft to be
created, but once it was, we forgot to start a formal Call for Adoption.
  With the feedback already, this document looks ready for adoption and
being worked on.

This starts a Call for Adoption for draft-dgr-dprive-dtls-and-tls-profiles

The draft is available here:

Please review this draft to see if you think it is suitable for adoption
by DPRIVE, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends 26 January 2016

tim wicinski
DPRIVE co-chair

dns-privacy mailing list
dns-privacy <at>

TLS mailing list
TLS <at>
Michael StJohns | 24 Jan 21:04 2016

Fwd: Re: Require deterministic ECDSA

Sorry - I hit the wrong "reply to" button.

-------- Forwarded Message -------- Subject: Date: From: To:
Re: Require deterministic ECDSA
Sat, 23 Jan 2016 20:52:53 -0500
Michael StJohns <msj <at>>
Geoffrey Keating <geoffk <at>>

On 1/23/2016 8:05 PM, Geoffrey Keating wrote: > Michael StJohns <msj <at>> writes: > >> On 1/23/2016 2:13 PM, Joseph Birr-Pixton wrote: >>> Hi, >>> >>> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA. >>> >>> For discussion, here's a pull request with possible language: >>> >>> >>> >>> Cheers, >>> Joe >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS <at> >>> >>> >> Correct me if I'm wrong but: >> >> 1) A receiver of an deterministic ECDSA signature verifies it EXACTLY >> like they would a non-deterministic signature. >> 2) A receiver of an ECDSA signature cannot determine whether or not >> the signer did a deterministic signature. >> 3) A TLS implementation has no way (absent repeating signatures over >> identical data) of telling whether or not a given signature using the >> client or server private key is deterministic. >> >> All that suggests that this is a completely unenforceable >> requirement with respect to TLS. > A test suite can easily determine, if it knows the private key in use > by the implementation under test, whether that implementation is > generating RFC 6979 deterministic signatures or not. That seems to me > an adequate enforcement mechanism. Um.. not really. The actual worked example is FIPS. There are lots of FIPS TLS implementations and they all go through testing (your proposed enforcement mechanism), and there is exactly NO way for one FIPS implementation to ensure that it is talking to another FIPS implementation. The best they can do is limit the offer and acceptance of specific crypto suites. MUST or "Required" in IETF parlance is usually reserved for choices that have to be made to have interoperable products. Neither FIPS nor deterministic ECDSA rise to that level. FIPS at least recognizes that and imposes its requirements on the buyers (US Gov't and US Gov't contractors) who then ask for FIPS capable products. And people who want to sell to the government then make FIPS capable products that ... wait for it... interoperate with non-FIPS products. >From 2119: > In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. Or would you argue that I'm misinterpreting the above and the impact of your suggested change? (Um.. in the above "causing harm" has usually been interpreted to mean "harm to the network" - not preventing stupidity in implementation). Later, Mike

TLS mailing list
TLS <at>
Joseph Birr-Pixton | 23 Jan 20:13 2016

Require deterministic ECDSA


I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA.

For discussion, here's a pull request with possible language: