Manuel Pégourié-Gonnard | 1 Oct 00:58 2014

DTLS retransmit question

Hi all,

I'm having trouble interpreting some text from RFC 6347 section 4.2.4:

                           Although each flight of messages may consist
   of a number of messages, they should be viewed as monolithic for the
   purpose of timeout and retransmission.


   There are three ways to exit the WAITING state:
   2. The implementation reads a retransmitted flight from the peer: the
      implementation transitions to the SENDING state, [...]

Does that mean an implementation is supposed to transition from WAITING
to SENDING only when it reads the retransmission of a whole flight?
Since the underlying transport is not reliable, one of the messages of
the retransmitted flight might get lost: should that prevent from
retransmitting in return?

An option would be to retransmit as soon as a retransmitted message
from the last flight is seen, but that would result in one
retransmission per received message in the flight retransmitted by the
peer, which would result in a lot of probably useless retransmission,
which is bad for congestion.

Another option is to retransmit only when a retransmission of the last
message of the previous flight is seen, which results in less
retransmissions and is a bit less sensitive to message loss than
(Continue reading)

Michael StJohns | 29 Sep 18:28 2014

AEAD only for TLS1.3 revisit

Hi -

This isn't a proposal to change the decision to only include AEAD 
ciphers in TLS1.3.  But something crossed my desk that suggested I 
should at least mention a possible issue with this.

Background:  There are number of countries (and private networks) that 
have a requirement to decrypt any traffic passing through certain 
places.  There is not a corresponding requirement to allow them to 
imitate a sender or receiver.  This can be done through key escrow, 
LEAF-like fields or multiple encryption of the data for example.

Implication:  AEAD ciphers have a single key which is broken down for 
use both in the encryption and integrity processes.  Revealing that 
single key (to satisfy the decryption requirement) can reveal the 
credentials to allow masquerading.  If the TLS connection credentials 
are also being used as credentials for control actions (e.g. 
cyber-physical controls of power systems, control over a firewall, etc), 
fulfilling the decryption requirement provides an unintended attack 
surface for possibly life critical systems.

Thoughts:  At least one AEAD cipher (CCM) uses the exact same key for 
both integrity and encryption.  There is no way to reveal the encryption 
key without also revealing the integrity key.  But if you have the 
integrity key, you can masquerade as sender or receiver (controller or 

Question:  In light of the above, should we revisit the AEAD-only 
decision for TLS1.3?

(Continue reading)

Nikos Mavrogiannopoulos | 29 Sep 12:57 2014

comment on draft-ietf-tls-session-hash-01

 The text in draft-ietf-tls-session-hash-01 specifies:
   "Implementation note: As described in Section 4, the "session_hash"
   used in the extended master secret computation.  Hence, it must be
   possible to compute the session_hash before the master secret is
   computed.  In SSL 3.0, the master secret is first needed in the
   Client's CertificateVerify message.  Hence, it is widespread
   implementation practice to compute the master secret as soon as the
   "pre_master_secret" is available, typically immediately before or
   after sending the Client Key Exchange message."

My first comment is that this text is pretty confusing.

The second is to clarify my understanding. Does this text suggest that
for SSL 3.0 in order to calculate the "extended master secret", must
first calculate the "master secret" it is supposed to replace?

If yes, I find the argument unconvincing for the introduction of such
complexity in the master secret calculation.

I suggest the following alternatives:
1. Do SSL 3.0 extended master secret calculation as in TLS 1.0 when this
extension is present
2. Explicitly state that SSL 3.0 is not in the scope of the document;
anyway there is no real expectation of such an extension to be
implemented in an SSL 3.0-only implementation.

(Continue reading)

Joseph Salowey (jsalowey | 26 Sep 06:00 2014

Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

This is an announcement for the working group last call for draft-ietf-tls-downgrade-scsv-00.  Please
review the document and send your comments to the list by Friday, October 17, 2014.  

Ryan Carboni | 24 Sep 23:15 2014

Re: TLS Digest, Vol 122, Issue 60

One can also gain credibility by breaking the ciphers of others, which
provides a convincing argument that one understands the attacks and designed
a cipher that doesn't fall to them easily.

Mr. Jenkins discovered some biases in RC4, and was one of the first to do so.
TLS mailing list
TLS <at>
Ryan Carboni | 23 Sep 22:36 2014

Re: Ciphersuite suggestion: add ISAAC

None taken. But draft proposals can always be withdrawn. And in the case of ChaCha20-Poly1305, you don't even need to have the correct test vectors with the first draft.
TLS mailing list
TLS <at>
Ryan Carboni | 23 Sep 22:26 2014

Re: Ciphersuite suggestion: add ISAAC

Such irony, people have to be famous in the crypto community in order for their ciphers to be adopted, in order to be famous one much have ciphers adopted.

On Tue, Sep 23, 2014 at 1:21 PM, Salz, Rich <rsalz <at>> wrote:

I looked at the webpge you posted and it seemed like there was one paper by someone other than the author?  And few will argue about djb’s credentials.


More importantly, tho, is the AEAD issue.



Principal Security Engineer, Akamai Technologies

IM: rsalz <at> Twitter: RichSalz


From: Ryan Carboni [mailto:ryacko <at>]
Sent: Tuesday, September 23, 2014 4:18 PM
To: Salz, Rich
Subject: Re: [TLS] Ciphersuite suggestion: add ISAAC


Has a decade of review. Does this mean ChaCha20 won't be adopted either?


On Tue, Sep 23, 2014 at 7:27 AM, Salz, Rich <rsalz <at>> wrote:

It hasn’t had much review.  And for TLS 1.3 we’re only doing AEAD types of ciphers.



Principal Security Engineer, Akamai Technologies

IM: rsalz <at> Twitter: RichSalz


TLS mailing list
TLS <at>
Ryan Carboni | 23 Sep 08:46 2014

Ciphersuite suggestion: add ISAAC

It's slightly more secure then RC4, but much faster.
TLS mailing list
TLS <at>
Joseph Salowey (jsalowey | 22 Sep 19:21 2014

Result of draft-ietf-tls-prohibiting-rc4 working group last call

We've reviewed the discussion resulting from the WGLC for draft-ietf-tls-prohibiting-rc4-00.  The main
complaint was that the "MUST NOT" prohibition of RC4 for servers was too strong and that RC4 is still needed
to interoperate with older implementations.   The consensus of the discussion was to keep the document as
is with respect to prohibiting the negotiation of RC4.  This document will be forwarded to the IESG for

Fox Arcadia | 20 Sep 09:51 2014

RFC5487 PSK Key Exchange Algorithm with SHA-256/384. Premaster secret if ciphersuites negotiated for TLS V1.2?


For the ciphersuites defined in RFC 5487  3.1

PSK Key Exchange Algorithm with SHA-256/384

CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256 = {0x00,0xAE}; CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384 = {0x00,0xAF}; CipherSuite TLS_PSK_WITH_NULL_SHA256 = {0x00,0xB0}; CipherSuite TLS_PSK_WITH_NULL_SHA384 = {0x00,0xB1};

How is the premaster secret formed if the negotiated version is TLS 1.2?

according to RFC 4279 Pre-Shared key ciphersuites for TLS:

The premaster secret is formed as follows: if the PSK is N octets long, concatenate a uint16 with the value N, N zero octets, a second uint16 with the value N, and the PSK itself. Note 1: All the ciphersuites in this document share the same general structure for the premaster secret, namely, struct { opaque other_secret<0..2^16-1>; opaque psk<0..2^16-1>; };


Note 2: Using zeroes for "other_secret" effectively means that only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF is used when constructing the master secret. This was considered more elegant from an analytical viewpoint than, for instance, using the same key for both the HMAC-MD5 and HMAC-SHA1 parts. See [KRAWCZYK] for a more detailed rationale.

but if using a PRF defined in TLS V1.2, then HMAC-MD5 is not used but the HMAC defined by the PRF.
And, in that case, part of the used premaster is zeroes.

should we in that case reuse PSK for other_secret?
TLS mailing list
TLS <at>
Daniel Kahn Gillmor | 19 Sep 21:52 2014

Contemplated major revision to draft-ietf-negotiated-ff-dhe

Hi TLS folks--

I'm considering a radical syntactic change to the negotiated-ff-dhe
draft (though it changes the semantics very little if at all) for the
purposes of aligning 1.3 handshake with pre-1.3 handshakes.  Feedback
about this idea would be appreciated.

   The idea is to have the draft drop the proposed FF-DHE TLS extension
   entirely and instead redefine "Supported Elliptic curves" (TLS
   extension 10) [0] to be a "Supported named groups" extension.  Then
   we would allocate some of the currently unallocated codepoints in the
   NamedCurve IANA registry [1] to the proposed FF-DHE groups.

== Advantages ==

The main goal of this change is to simplify the TLS 1.3 handshake while
allowing clients to send a 1.2+1.3 compatible first flight that includes
FF DHE without excessive duplication.

TLS 1.2+1.3 handshakes will be able to reference a single registry for
their preferred groups and handle them in parallel, without an extra
extension.  We also avoid introducing new TLS extensions.  Clients
would be able to send extension 10 without needing to have implemented

== Further Considerations ==

So, for a TLS 1.2 client that wants to support named FF-DHE groups, it
would just send TLS extension 10 with only FF-DHE codepoints.  It would
include DHE ciphersuites, but need not include any ciphersuites with
ECDHE key exchange.

If a TLS 1.2 client wants to include ciphersuites with ECDHE as well, it
can do so, but can also indicate FF-DHE codepoints in the same TLS
extension that it indicates the available curves.

Servers responding to such a client will fall into two categories: those
aware of the FF-DHE entries in named-curves, and those that are not.

for unaware servers, they should ignore these entries and carry on with
a normal response.

For aware servers, if they select a DHE key exchange they should send an
SKE as indicated in the current draft, with the server's DHParams
modified appropriately.  (possibly, Alfredo's suggestion of sending an
entirely different handshake message instead of SKE in this case offers
a clearer indication to the client that the server has selected a named

== Codepoint Requests ==

The NamedCurve registry is 16 bits, which is *huge* considering the
pressure we've given to the CFRG to limit the number of proposed curves.

This proposal suggests carving out a small space of that registry for
finite field groups.  For simplicity's sake, i imagine something like
"if the high byte is 0x01, it's FF-DHE" (the draft currently only
allocates 1 byte anyway).  But i'd also be OK with just allocating some
specific codepoints and not making any block designation, if folks think
that would make more sense.

== Feedback Please! ==

Please speak up if you find this change terrible for some reason, or if
you've already implemented the proposed draft and think that backing it
out would be misery.  I don't think this proposal changes the semantics
of the draft at all, and i think it would help the 1.3 handshake to have
this established.

If i hear no shouts of horror, i hope to get a revision of
negotiated-ff-dhe published next week with these changes.

I'm likely to need some help in navigating the IANA procedures for a
change like this which isn't exactly a straightforward codepoint
request, so if anyone has suggestions or experience with that, i'd
appreciate pointers.

All the best,


TLS mailing list
TLS <at>