Eric Rescorla | 21 Oct 16:52 2014

Should we require compressed points

Today we discussed the possibility of requiring support for compressed points
in TLS 1.3 now that the IPR has expired.

Specifically, I propose that for TLS 1.3, we:

- Use only compressed points for the existing curves (and presumably
  whatever superior format is defined for the CFRG-recommended
  curves, as appropriate).

- Deprecate the Supported Point Formats extension for TLS 1.3

For RFC 4492-bis, we might also consider requiring support for compressed
points as well as uncompressed (already required) but this seems like a
separable issue, since it's mostly in service of optimization rather than

What do people think?

TLS mailing list
TLS <at>
Salz, Rich | 21 Oct 16:44 2014

Minutes from Tuesday

Here’s the draft minutes for today’s interim.  Please post corrections to the list.


Should we remove SSLv3 from the session hash draft?  Various points about why SSLv3 is either not being used, or in devices that aren’t being updated. One more update to remove SSLv3, some other cleanups, and then go to WG LC. Sean will try to force out any issues for discussion in Hawaii.


Bodo slides are at   Based on list feedback, going to add some clarifications (no changes to the mechanism).  False start I-D needs to be updated since attacker can force a version; Bodo to do that. Discussion of distinguishing between TCP reset (in FF) and version intolerance. Discussion of when to ‘guess’ failure is transient or version intolerance. Need to add some guidance to the I-D: mixing SCSV and version-intolerant servers will cause a pain. Sean went through issues raised on mailing list.


What is status of false-start? Was held back by Google for interop concerns. MSFT always tries based on cipher-suite (says MT); others do it conditional on NPN or ALPN and a modern cipher like a DH. It’s in wide use. Bodo will update the draft and ask the WG to adopt


Dkg on named groups. No longer an extension; allocating points within the namedcurve list, they are finite-field groups. Interacts with cipher-suite list.  Discussion about adding ordering semantics between the two lists. Change: clients that wish to express an ordering may order the curves/groups in their order of preference.


Discussion of RC4 draft.  Andrei via phone. Room strongly supports prohibiting RC4. Discussion about being able to address concerns raised by a few. Chair will close discussion and move it forward. Sean to include text about “just upgrade to TLS 1.2” as we considered alternatives and rejected them in his shepard notes or equivalent. Mention that youtube encodes video streams using RC4 only.


Return to DH named groups.  Dkg prefers not-using IKEv2 primes, so that national-scale adversaries workload doubles. We’ll ask CFRG “do you have a problem with these groups?” Decided that SRP re-use of IKEv2 groups is not an issue. Discussion of sizes.  Sean going to straw poll the list for 2048 or 2432, will work with dkg to draft the message. Proposed sizes 20xx 3032 4096 8192. Discussion of having server return the full key.  Dkg to come back to the mailing list. Discussion of how to do PSK with PFS; neat hack/thought, treat it like a resumption.


Compressed points. Certicom says no IPR coverage any more. Likely to drop uncompressed points (and their negotiation) from TLS 1.3  ekr to do a straw poll on the mailing list.




Principal Security Engineer, Akamai Technologies

IM: rsalz <at> Twitter: RichSalz


TLS mailing list
TLS <at>
Martin Thomson | 21 Oct 10:21 2014

Operational consideration for downgrade SCSV draft

As discussed, something like this might be good:

"Note: Upgrading servers to support this SCSV in a cluster containing
version intolerant nodes can result in excessive numbers of failures.
Clients that learn of version intolerance from the intolerant nodes
will cause upgraded nodes to generate inappropriate_fallback alerts."
Brian Smith | 21 Oct 02:40 2014

POODLE applicability to TLS 1.0+ (was Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

On Fri, Oct 17, 2014 at 2:56 AM, Bodo Moeller <bmoeller <at>> wrote:
Brian Smith <brian <at>>:
If version downgrades during False Start are to be tolerated, then at
a minimum the security considerations of this draft must point out
that the mechanism is simple to subvert (partially, at least) when
False Start is used.

Exactly, but the detailed recommendations should go into an updated False Start I-D instead; I can do that.  Specifically, that spec could say that if the client sends TLS_FALLBACK_SCSV in the client hello, False Start SHOULD be disabled for that handshake. And then we'll also have to say that the client similarly should not use False Start with any protocol version for which it would send TLS_FALLBACK_SCSV in fallback retries (since otherwise the former recommendation wouldn't achieve anything.)  The TLS_FALLBACK_SCSV spec's Security Considerations, then, will include a reminder that allowing False Start with older protocol versions can be problematic, and that this is a (general) problem that TLS_FALLBACK_SCSV can't address.

I agree with you. However, please consider changing some of these SHOULDs to MUSTs. As it is, every implementation already trivially conforms to the current drafts, because all client implementations implement all the MUSTs (the only MUST is that they MUST NOT send the TLS_FALLBACK_SCSV when ClientHello.client_version is the highest version they support). That isn't helpful.

Note that POODLE, or variants thereof, may apply also to TLS 1.0+ implementations. For example, back in 2010, I fixed a bug in NSS where NSS did not verify all the padding bytes in TLS 1.0 records [1]. Thus, any server that is using a version of NSS released prior to June 2010 is likely vulnerable to POODLE-like attacks even if SSL 3.0 is completely disabled. Further, note that the TLS 1.0 specification [2] does NOT say that implementations must check the padding; that requirement was only added in TLS 1.1 and TLS 1.2. Thus, an implementation could completely conform to TLS 1.0 but still vulnerable to POODLE. Finally, even though the TLS 1.1 and TLS 1.2 specifications do say that implementations must check the padding, it isn't necessarily the case that otherwise-working implementations actually conform to that requirement, and there's no way for the client to check that in a reliable, high-performance, and accurate way.

Consequently, I think that:

1. Browsers must abandon the non-secure version rollback to versions prior to TLS 1.2 completely.

2. The downgrade-scsv draft should be changed to say that implementations MUST always send the TLS_FALLBACK_SCSV when ClientHello.client_version indicates TLS 1.1 or lower if the client supports TLS 1.2.

So, I believe that your suggestion for client behavior is absolutely spot on. My point is just that the very same issue w.r.t. False Start and version downgrades exists if the client doesn't do any fallback retries -- and those who implement such clients shouldn't have to read the TLS_FALLBACK_SCSV spec to find out when to allow False Start: this belongs into the False Start spec.

I agree that the False Start RFC should be updated to include this and other considerations.
Again, to be clear, I am not saving the downgrade SCSV is bad. I'm
saying it is surprising that the downgrade SCSV doesn't prevent
version downgrades, and that should be fixed.

Right. I'll mention that potential surprise with False Start in TLS_FALLBACK_SCSV Security Considerations, and specify how to avoid it in the False Start specification.


TLS mailing list
TLS <at>
Salz, Rich | 20 Oct 22:11 2014

Unifying tickets and sessions

It's proposed that we unify tickets and sessions at the protocol level.


For 1.3 we bring in the extension definitions from 5077. For the wire format, it doesn't matter if the
information is a session identifier (a short string, referring to state maintained on the server) or a
ticket (the actual crypto state, stored on the client). Perhaps to be general, we call it session token.

A TLS 1.3 client MUST send an empty session_id field. It may send a ticket extension. If the server is willing
to accept the crypto state, it sends a "1" in the returned session_id field, otherwise it sends an empty
session_id. This is the only use of session_id in TLS 1.3.

The session token may either be an opaque identifier of local server state, or a serialization of the state
the server needs, encrypted with some key. General security considerations require that this
information not be kept on long-lived media, and that the identifier or encryption key be rotated
periodically. These are server-side implementation details.

The session token can be used to tie together multiple transactions with a loss of forward secrecy. Clients
can always omit the session token. Servers SHOULD set the lifetime to an appropriate value (and MUST NOT be
more than nn hours).  [Where nn is TBD; either 24 or 48.]

"MUST NOT" for more than 24 hours seems to strict. If you rotate keys every 24 hours, session tickets end up
being valid for up to 2 * 24 hours (+ fudge) unless you start to reject them while the server still has the key,
which seems pointless. Depending on how you set up cron, that could be 49 hours+ in practice due to DST.
Watson Ladd | 20 Oct 21:31 2014

Re: PSK in 1.3?

On Oct 20, 2014 12:20 PM, "Dan Harkins" <dharkins <at>> wrote:
> On Mon, October 20, 2014 11:06 am, Manuel Pégourié-Gonnard wrote:
> > On 20/10/2014 19:06, Dan Harkins wrote:
> >>   There is nothing to flesh out because you seem to not understand
> >> what a dictionary attack is-- but you're in company because neither
> >> did the editors of that RFC.
> >>
> >>   Protocols that use a static, symmetric credential like a PSK (or a
> >> password, the difference is semantic) are all flawed because the
> >> adversary is always assumed to have access to a pool from which
> >> the PSK (or password is drawn. Resistance against dictionary attack
> >> is then a demonstration that the advantage gained by the adversary
> >> is due to _interaction_ and not _computation_.
> >>
> >>   Merely making the pool from which the PSK is drawn, for instance
> >> by making it a bigger or including mixed case, etc, does not make
> >> the protocol resistant to dictionary attack.
> >
> > From a theoretical standpoint, the PSK key exchange is indeed vulnerable
> > to a
> > dictionary attack with this definition. In practice, if your keys are
> > 128-bit
> > long and chosen uniformly at random using a good source of entropy, I
> > doubt any
> > real-world adversary is able to gain a non-negligible advantage in the
> > foreseeable future.
>   The justification for these ciphersuites is some constrained device that
> has a small data and code size. But if you can not only generate 128-bit
> long uniformly random keys from a good source of entropy and also
> securely provision them on 2 (or more) devices then you don't need TLS.
> Just do static keyed symmetric crypto and you save even more data
> and code by eliminating TLS!
>   In practice, these things are deployed by people who probably do not
> read the RFC in question, are in a hurry, and don't understand the
> security implications of their use of TLS. The PSKs that get provisioned
> are the ones that are easy to enter with a low probability of error-- i.e.
> something considerably less than uniformly random 128-bit key
> generated from a good source of entropy.
>   This is not (only) a theoretical issue. It's practical reality.

I dissent here: interoperability and firewall traversal are good reasons not to homebake something, and if this WG had done it's job, security would likely be better then a home brewed protocol.
> > Also, it should be noted that with this definition, the TLS session keys
> > are
> > vulnerable to a dictionary attack too. In practice, it's not a problem
> > either
> > for the same reason. Obviously the difference between the pre-shared key
> > and the
> > TLS session keys is that the later is short-term while the former is
> > long-term.
> > Which basically boils down to the point that PSK lacks FS.
> >
> > Are you sure you have point besides:
> > - pre-shared key must be chosen with sufficient entropy and
> > - PSK does not offer FS?
>   Yes, I'm absolutely sure. It's:
>   - you can't ensure security with MUSTs and SHALLs; and,
>   - the use case that you say compels PSK ciphersuites actually argues
>      against you.
> TLS should be as misuse resistant as possible. That is, it should be as
> hard as possible to use improperly and that means no PSK ciphersuites.

I concurr.
>   regards,
>   Dan.
> _______________________________________________
> TLS mailing list
> TLS <at>

TLS mailing list
TLS <at>
Sean Turner | 20 Oct 21:21 2014

20141021/22 TLS Interim: Remote Participant Details


The interim meeting is scheduled for:
2014-10-21 from 9am-4pm
2014-10-22 from 9am-4pm
Please note that this is CEST = Central European Summer Time UTC +02:00

All participants are bound by the note well:

The proceedings (agenda, minutes, proceedings) can be found here (look for the 2014-10-21 tls row):  

The only slides uploaded so far are the administrivia slides.  As/If I receive slides decks, I’ll upload them.

For those participating remotely, a TLS jabber room is available as well as a Webex session; details follow:

1) Jabber

tls <at>

Will will draft a jabber scribe to make sure remote questions/comments are channeled in to the room.  The
scribe will likely not provide a transcription of the conversations at the interim but will make sure
remote participants are at a minimum kept abreast of what topic/slide is being discussed.

NOTE: The jabber room logs are archived.

2) Webex (I hope this works)

NOTE: If you are not speaking please *MUTE* your phone to minimize the chance for disruptions during the call.

NOTE: Webex has a chat facility too, but it’s probably best to use the tis <at> room instead.

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other
materials exchanged or viewed during the session to be recorded. By joining this session, you
automatically consent to such recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the session. Please note that any
such recordings may be subject to discovery in the event of litigation.

TLS Interim Meeting
Tuesday, October 21, 2014 & Wednesday, October 22, 2014
9:00 am  |  Europe Summer Time (Paris, GMT+02:00)

Join WebEx meeting
Meeting number:	641 550 329
Meeting password:	1234

Join by phone:
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 641 550 329

Manuel Pégourié-Gonnard | 20 Oct 21:08 2014

Re: I-D Action: draft-ietf-tls-session-hash-02.txt


On 06/10/2014 15:27, Alfredo Pironti wrote:
> We've set up a test server, available at The running
> implementation is miTLS, with experimental support for the extended master
> secret extension.
Thanks! I just had a go at implementing it, and interop with your test server
works fine for TLS 1.2 down to 1.0 included, but fails for SSL 3.0 (server
rejects Finished with bad_record_mac, most likely we didn't compute the MS in
the same way).

It may very well be a stupid mistake on my side, since I'm getting a bit tired
now, but I thought I'd just check with you if the test server is implementing
the latest (02) version of the draft for SSLv3, just to be sure.


PS: I noted a typo in section 4.2: "SSL 3.0 does not defne a PRF function" defne
-> define. Also, arguably "function" is redundant after PRF.
Manuel Pégourié-Gonnard | 19 Oct 11:30 2014

PSK in 1.3?


Sorry if this was discussed previously and I missed it, but I was wondering
about the fate of PSK in TLS 1.3. The RSA and (EC)DH key exchanges were removed
because they do not offer forward security. PSK does not offer FS either. OTOH,
it has very interesting performance properties, namely it's the only key
exchange that does not require asymmetric crypto.

It seems to me it makes a lot of sense to keep it, even if it doesn't give FS.

The reason I'm asking this now is the parallel discussion about new handshake
flows and possibly proving them secure. If we're keeping PSK, maybe it's good to
keep it in mind in this discussion, since it may have different properties than
(EC)DHE for the proofs/security discussion.

Manuel Pégourié-Gonnard | 18 Oct 20:18 2014

Re: Refactoring client auth/re-key

On 18/10/2014 16:32, Eric Rescorla wrote:
> Currently TLS has a single Master Secret which is used to compute
> directional traffic keys. Instead, we should have two unidirectional
> MSs, each initially generated from the initial PMS. E.g.,
>       master_secret_client = PRF(pre_master_secret, "master secret_client",
>                                  ClientHello.random + ServerHello.random)
>                                  [0..47];
>       master_secret_server = PRF(pre_master_secret, "master secret_server",
>                                  ClientHello.random + ServerHello.random)
>                                  [0..47];
When you write "ClientHello.random + ServerHello.random", don't you rather mean
"transcript so far"?

Eric Rescorla | 18 Oct 18:16 2014

Fate of resumption


I wanted to get the discussion going on whether we need resumption [0] or not
for TLS 1.3. This may be a quick discussion as I suspect the answer is
yes, but I figure we should decide it rather than just assuming it.

The argument for resumption seems pretty straightforward: it requires
significantly less computation (in the form of asymmetric operations)
than a full handshake. I suspect that this argument is less powerful
than it used to be for two reasons:

- Increased computational power.
- Faster algorithms in the form of ECC.

Nevertheless, we still have constrained devices, both in the form of
low-power phones and IOT-type devices. OTOH, it's not clear to me
how many of those devices actually (a) do public key cryptography
as opposed to PSK and (b) do session resumption.

Conversely, resumption adds complexity to the protocol both since you
have to implement both the full and resumed state machines and because
the client has uncertainty about whether a server will accept

Another problem with resumption is that it is a threat to PFS.  In the
current TLS resumption design, if a session is resumable, then both
the client and the server retain the MS in their session caches [1].
Thus, even if you use a PFS cipher suite and destroy the traffic keys
and the asymmetric keys after the connection is over, an attacker who
attacks the session cache can decrypt your connection. As noted in my
previous message, it's not too difficult to separate the MS stored in
the session cache from the MS used for the initial connection that
initiated the session, but it's much harder to do so between multiple
resumptions of the same session, though perhaps we could do figure out
how to do so [2].

I'm hoping to get people's opinions on this (and we can discuss more
next week). How important is resumption to you as a performance
optimization? Is it still important when you can do all-ECC (which
it seems likely we will require clients to do for TLS 1.3).


[0] For purposes of this discussion I'm using "resumption" to mean
both ordinary resumption [RFC 5246; Figure 2] and session tickets
[RFC 5077]. I tend to agree with the comments from others that if
we retain resumption we should unify these mechanisms, but that
seems like a question to be answered after we have decided
whether to retain resumption at all.

[1] Technical note: with RFC 5077 tickets the server retains the
ticket master key (TMK) in its memory, but since the attacker is
assumed to have the ticket, an attacker who successfully attacks the
server and recovers the TMK key can recover the MS. It's true that you
could store the TMK in secure storage, but you could also implement a
session cache where the entries are encrypted under some kind of
master key which is in secure storage, so I would argue that the
security properties vis-a-vis PFS are similar.

[2] For clarity, what I mean here is:

    Connection 1 does a full asymmetric exchange and establishes
    session X with MS key M, storing M in the session cache and
    using M to generate its keys.

    Connection 2 resumes session X and uses M to generate its keys.

    Connection 3 resumes session X and uses M to generate its keys.

It's fairly straightforward to have connection 1 generate two keys,
M and M' from its PMS, use M to generate its keys and store M'
in the session cache. But this still leaves both connection 2 and
3 sharing M'.


TLS mailing list
TLS <at>