Sean Turner | 31 Mar 18:20 2015

(draft) WG adoption call: draft-bmoeller-tls-falsestart


There’s been some interested expressed in having adopted as a TLS WG item.  If you
would like for this draft to become a WG document, and you are willing to review drafts as it moves through
the process please indicate as much on this thread.  If you are opposed to this being a WG document, please
say so (and say why). Thanks in advance.

RFC Errata System | 31 Mar 01:06 2015

[Errata Rejected] RFC7366 (4284)

The following errata report has been rejected for RFC7366,
"Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)".

You may review the report below and at:

Status: Rejected
Type: Technical

Reported by: Tomasz Sobczyk <dottomi <at>>
Date Reported: 2015-03-02
Rejected by: Stephen Farrell (IESG)

Section: 3

Original Text
The overall TLS packet [2] is then:

   struct {
          ContentType type;
          ProtocolVersion version;
          uint16 length;
          GenericBlockCipher fragment;
          opaque MAC;
          } TLSCiphertext;

   The equivalent DTLS packet [4] is then:
(Continue reading)

RFC Errata System | 31 Mar 01:05 2015

[Errata Verified] RFC7366 (4212)

The following errata report has been verified for RFC7366,
"Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)". 

You may review the report below and at:

Status: Verified
Type: Technical

Reported by: Peter Gutmann <pgut001 <at>>
Date Reported: 2014-12-27
Verified by: Stephen Farrell (IESG)

Section: 3

Original Text
   In TLS [2] notation, the MAC calculation for TLS 1.0 without
   the explicit Initialization Vector (IV) is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       TLSCipherText.length +
       ENC(content + padding + padding_length));

   and for TLS 1.1 and greater with an explicit IV is:

(Continue reading)

IETF Secretariat | 30 Mar 16:58 2015

ID Tracker State Update Notice: <draft-ietf-tls-session-hash-04.txt>

Last call has been made for draft-ietf-tls-session-hash and state has been changed to In Last Call
ID Tracker URL:
internet-drafts | 28 Mar 20:16 2015

New Version Notification - draft-ietf-tls-negotiated-ff-dhe-08.txt

A new version (-08) has been submitted for draft-ietf-tls-negotiated-ff-dhe:

The IETF datatracker page for this Internet-Draft is:

Diff from previous version:

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

IETF Secretariat.
internet-drafts | 28 Mar 20:16 2015

I-D Action: draft-ietf-tls-negotiated-ff-dhe-08.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           : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS
        Author          : Daniel Kahn Gillmor
	Filename        : draft-ietf-tls-negotiated-ff-dhe-08.txt
	Pages           : 25
	Date            : 2015-03-28

   Traditional finite-field-based Diffie-Hellman (DH) key exchange
   during the TLS handshake suffers from a number of security,
   interoperability, and efficiency shortcomings.  These shortcomings
   arise from lack of clarity about which DH group parameters TLS
   servers should offer and clients should accept.  This document offers
   a solution to these shortcomings for compatible peers by using a
   section of the TLS "EC Named Curve Registry" to establish common
   finite-field DH parameters with known structure and a mechanism for
   peers to negotiate support for these groups.

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:

(Continue reading)

Stephen Farrell | 28 Mar 16:39 2015

AD review of draft-ietf-tls-session-hash-04

Nothing to say really:-) I've asked for IETF LC.

Paterson, Kenny | 27 Mar 17:10 2015

Re: Importance of ECDSA for TLS (was: PSS for TLS 1.3)

Dear Ilari,

On 24/03/2015 12:11, "Ilari Liusvaara" <ilari.liusvaara <at>> wrote:

>On Mon, Mar 23, 2015 at 07:42:26PM +0000, Paterson, Kenny wrote:
>> Just a quick heads-up with my CFRG hat on. We should soon be making a
>> start over there on defining signature schemes for use with the curves
>> that we have now selected; our DH deliberations are nearing completion.
>> One quick question for this group: how important is it to you to have
>> ECDSA - or something very close to it (e.g. a derandomised version) -
>> TLS use, and how much appetite is there for adopting schemes that
>> more significantly from ECDSA (e.g. EdDSA)?
>My personal view (I have also looked at what this would take):
>Not important, I would very much like a modern signature system (esp.

Thanks for this feedback. This was also the view at the CFRG meeting this
week in Dallas, but we will take it to the CFRG list for further
discussion in the near future.

>But I would want:
>- Both curves usable in the same signature framework.
>- Only use common hash function propeties for both curves[2], especially
>  for verification interop[3].
(Continue reading)

Jeffrey Walton | 27 Mar 02:58 2015

Cipher suite values for ChaCha20/Poly1305?
does not list cipher suite values for ChaCha20 and Poly1305. I hope
the page is outdated and missing updates.

Do we have cipher suite values for ChaCha20/Poly1305? If not, when can
we expect them?

Related: if not, does anyone know why it is taking so long? (I don't
want to appear cynical, but I find it hard to believe it takes months
and years to agree on an unsigned short value(s)).
Aaron Zauner | 26 Mar 22:51 2015

comment on draft-ietf-tls-pwd-06


Sorry for being terse: I'm wondering why the Document still supports
AES-CBC. Is compatibility down to TLS 1.0 or 1.1 desired? If not; Why
not reduce the number of (vulnerable) ciphersuites by removing AES-CBC?


TLS mailing list
TLS <at>
Tero Kivinen | 26 Mar 20:48 2015


In Honolulu I verified that the primes generated in the
draft-ietf-tls-negotited-ff-dhe correctly, i.e. I generated them
again, and got same results. I also verified that they are primes
using primo. This morning I checked that the new 2048 bit group added
after that is also correct, but found problem there.

The actual hex number in the draft is correct, but the formula for the
numebr is wrong.

I.e. A.1. ffdhe2048 says:

   The modulus is: p = 2^2048 - 2^1984 + {[2^1918 * e] + 560315 } * 2^64
   - 1

but that does not match the hex number, there is off-by-one error. The
number 560315 should be 560316 instead.^2048+-+2^1984+++{trunc(2^1918+*+e)+++560315+}+*+2^64++++-+1+in+hex^2048+-+2^1984+++{trunc(2^1918+*+e)+++560316+}+*+2^64++++-+1+in+hex

I also put all the primo primality proof certificates on my web page
(along with the IKE primality certificates): 

kivinen <at>