The IESG | 26 Nov 15:16 2014

Last Call: <draft-ietf-tls-prohibiting-rc4-01.txt> (Prohibiting RC4 Cipher Suites) to Proposed Standard

The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'Prohibiting RC4 Cipher Suites'
  <draft-ietf-tls-prohibiting-rc4-01.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> mailing lists by 2014-12-10. Exceptionally, comments may be
sent to iesg <at> instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.


   This document requires that Transport Layer Security (TLS) clients
   and servers never negotiate the use of RC4 cipher suites when they
   establish connections.  This applies to all TLS versions, and updates
   [RFC5246], [RFC4346], and [RFC2246].

The file can be obtained via

IESG discussion can be tracked via

No IPR declarations have been submitted directly on this I-D.
Sean Turner | 26 Nov 05:46 2014

2nd WGLC: draft-ietf-tls-downgrade-scsv


This message initiates the 2nd WGLC for draft-ietf-tls-downgrade-scsv-02.   Please review the document
and send your comments to the list by Friday, December 12, 2014.

Version -00 was the subject of the 1st WGLC and there have been two version since then addressing issue
raised during WGLC.  As result, normative language was added to the draft and the chairs believe this
warrants a 2nd WGLC.  The scope of this WGLC is however limited to making sure that the text that has been
added represents WG consensus.  For example, rehashing whether the documented solution should use an
extension or cipher suite is not in scope of this review.

J&S (as chairs)
Michael StJohns | 26 Nov 00:25 2014

Two Decisions?

First item:

A/O TLS 1.2 the PRF function changed to be negotiable.   During 
discussions for things like session hash, the question was brought up 
(or at least I brought it up) as to whether or not the PRF function 
always needed to be a hash function (vs say a block cipher function) and 
I think the general consensus was that it was too difficult to remove 
due to its use in the finish message and session hash.   Would that be a 
fair assessment?  And if so, should text be added to make this clear?  
(Specifically, the PRF negotiation specifies a hash, and the KDF and 
various other derived functions are based on the HMAC construct of that 

[Side comment - as I've stated before, I really would have liked to have 
the possibility of having a block cipher only PSK TLS implementation, 
but I think that given the general trend toward PFS suites which have 
public key type requirements, I would guess that that ship has sailed, 
even in the constrained device space.]

Second item:

The Master Secret has always been 48 bytes long.  A/O TLS1.2 wouldn't it 
make more sense to have the output of the Pre-Master Secret to MS key 
derivation be a key of the native length for the KDF function?  E.g. 64 
bytes for HMAC SHA256?

Right now, each round of the PRF function produces 32 octets (assuming 
HMAC-SHA256) each round so the function is run twice to get 64 octets, 
then left truncated to get 48 octets of the Pre Master Secret.  When you 
get to the MS to session key negotiation, the 48 octets is right zero 
(Continue reading)

Eric Rescorla | 25 Nov 23:38 2014

Editorial process

[Starting a new thread to change topics]

On Tue, Nov 25, 2014 at 2:19 PM, Watson Ladd <watsonbladd <at>> wrote

... The current proposal has two distinct client auth mechanisms, one in the handshake and the other in update.

Making sure the actual proposal is in the draft, and not spread out across pull requests would make life a lot easier for analyzing the protocol.

A few notes on the process here from my perspective:

The way I think about this is that there is a current proposal which is what's
in Github and then people (whether me or someone else) suggest changes.
These changes go in Pull Requests so that the WG can see what exactly
is being proposed and then if the WG is happy, those PRs get merged
into the main document. Obviously, no process is perfect, but my experience
and my read of the experience with HTTP is that this is better than the
alternatives, which mostly involve big document revisions and then
comments on the whole document [0].

With regard to the specific question of client auth, the state is as follows:
The existing document (i.e., the I-D and the version in git master) contains
a single client auth mechanism in the handshake. We have a proposal to
remove that and instead have client auth in an Update [1]. The intention is that
we would only have one client authentication mechanism.

FWIW, I recognize that there are a lot of PRs outstanding right now and it
can be confusing. I plan on merging a number of them in over the next week
or two.


[0] Note that it's easy to get git/github to give you the state of the document
as a whole after a PR is merged.

[1] The PR in question doesn't do that, but that's because I was asked to
do an initial treatment to see if people liked it and s I tried to do the minimum
to accomplish that.

TLS mailing list
TLS <at>
Joseph Salowey | 25 Nov 20:32 2014

TLS Minutes for IETF-91

The minutes for the TLS meeting in IETF-91 are available here:

Please let the chairs know if there are any corrections.  


TLS mailing list
TLS <at>
Stephen Farrell | 25 Nov 18:20 2014

AD review of draft-ietf-tls-prohibiting-rc4-01


I have a question to ask before starting IETF LC. I don't
care much what answer you provide but we will be asked
later and I don't recall it being discussed here, so let's
get it out of the way:

This says there are no IANA actions, which is consistent
with how e.g. export ciphersuites were handled I think.
But would the WG like to add a column saying "deprecated"
or similar to [2]?

My assumption is the answer is "no" or at least "not in
this document" so unless the chairs tell me to hold off
again I'll start IETF LC tomorrow. (OTOH, a part of me
would be happy to see a draft that deprecated a whole
nice big pile of ciphersuites;-)


Yuhong Bao | 25 Nov 12:07 2014

MS14-066 and the TLS premaster secret version check

Has the incorrect premaster secret version check described in this been fixed in MS14-066:

Yuhong Bao 		 	   		  
Adam Langley | 25 Nov 07:55 2014

Signed messages should be prefixed with a NUL-terminated context string.

I generally recommend that, whenever signing a message, a
NUL-terminated, ASCII context string is prepended to the message to
ensure that the verifier isn't confused about the context.
(NUL-terminated, ASCII strings have the property that none is a prefix
of any other.)

I think that TLS 1.3 provides a good demonstration of why:

Mavrogiannopoulos, Vercauteren, Velichkov and Preneel[1] showed a
near-miss in the design of TLS <= 1.2 due to a lack of context in
ServerKeyExchange messages resulting in an ambiguity about whether a
specific message was DHE or ECDHE.

TLS 1.3 has the server return a CertificateVerify message[2] that
signs the handshake so far, similar to TLS <= 1.2's message of the
same name. However, consider a client that implements any version of
TLS and a server that implements TLS 1.3:

An attacker watches for the ClientHello from the client. Assume, as is
quite common now, that the client generates its client_random with 32
random bytes (i.e. there's no timestamp). With probability 2^-32, the
client_random will start with 0x0100 and bytes 4 and 5 will be 0x03
and 0x04.

The attacker now connects to the TLS 1.3 server and sends a
ClientHello such that the prefix of the message (including handshake
message type and length) is equal to the victim client's client_random
value. (Most of the bytes can be put into the attacker's client_random
value and the restriction on the victim client's message ensures that
the handshake type, length and protocol version are taken care of.)

With the rest of the ClientHello, the attacker is free to make the TLS
1.3 handshake look like a TLS 1.2 ServerKeyExchange message. An
obvious choice is to stuff a dummy server_random into the session ID
and specify a small p and g such that a discrete-log is easy, then
consume the rest of the handshake with a huge Y. (The length of the
TLS 1.3 handshake from the server is predictable.)

Some clients might check that Y < p but, if they do the obvious thing,
then the TLS 1.3 server's signature over the handshake can be used as
a TLS 1.2 ServerKeyExchange signature and the client compromised.

I may have missed something and, even if not, the restrictions on the
client's client_random value make it an expensive attack to pull off.
But it's still another near-miss.

Thus I suggest that signed messages in TLS 1.3 be prefixed with
context strings. For example, "TLS 1.3 CertificateVerify message from
server\x00" in this case.

However, since TLS <= 1.2 provides an attacker the ability to get a
signature for a message with a 32-byte, chosen prefix via the
ServerKeyExchange, I additionally suggest that the context string
start with 48-64 bytes of "PADTLS" repeated, in order to clear that
prefix and cover part or all of the server_random.

(And that signature oracle in TLS <= 1.2 provides another reason,
should any be needed, not to run a CA:TRUE certificate on a server.)





Adam Langley agl <at>
TSB SG16 Secretariat, ITU | 21 Nov 16:21 2014

COM 16-LS 133 - Outgoing LS from Rapporteur Group meeting of ITU-T Q3/16 & ITU-T Q5 /16 (Seoul, 3-7 November 2014)

Dear All,


Kindly find attached the Liaison Statement COM16 - LS 133 with title “LS on TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4]” agreed at the Rapporteur Group meeting of ITU-T Q3/16 & ITU-T Q5 /16, held in Seoul , Rep. of Korea, from 3 to 7 November 2014 inclusive.


Best regards,


Rosa Angeles-León de Vivero

Administrative Assistant for ITU-T Study Group 16, IPTV-GSI, JCA- IPTV & IRG-AVA
ITU - Telecommunication Standardization Bureau (TSB
SG 16 e-mail: tsbsg16 <at>
IPTV-GSI e-mail: tsbiptv <at>

Tel.  +41-22 730 5445
Fax +41-22 730 5853





Attachment (ls133-16.docx): application/vnd.openxmlformats-officedocument.wordprocessingml.document, 39 KiB
Attachment (ls133-16.pdf): application/pdf, 206 KiB
TLS mailing list
TLS <at>

New Liaison Statement, "LS on TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4]"

Title: LS on TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4]
Submission Date: 2014-11-21
URL of the IETF Web page:
Please reply by 2015-02-01
From: ITU-T Q3/16 (Rosa De Vivero <rosa.angelesleondev <at>>)
To: Transport Layer Security (Sean Turner <turners <at>>, Joseph Salowey <joe <at>>)
Cc: Stephen Farrell <stephen.farrell <at>>,Kathleen Moriarty <Kathleen.Moriarty.ietf <at>>,tls <at>
Response Contact: christian.groves <at>
Technical Contact: 
Purpose: For comment

Body: ITU-T Q3/16 works on support for the TLS and DTLS protocols in decomposed gateways using ITU-T H.248
as gateway control protocol. Initial support of these protocols is available, see published
Recommendations ITU-T H.248.90 (10/2014) for TLS and ITU-T H.248.93 (10/2014) for DTLS. Initial
support means that the (D)TLS protocols were modelled by so-called H.248 bearer connections (termed as
"TLS bearer session" / "DTLS bearer session" in the Recommendations). These are abstractions, not
necessarily equivalent to real (D)TLS sessions or (D)TLS connections, but sufficient for basic support
by H.248 gateways.

However, additional support in the area of security and multiplexed protocol stacks ("WebRTC") imply a
more precise model of TLS and DTLS protocol objects.

ITU-T Q3/16 would appreciate if you could provide clarifications particularly with respect to:

1.	the distinction between (D)TLS session and (D)TLS connection (which implies a definition for each
term, beyond the available descriptions / glossary from RFC side)
2.	the DTLS association concept, e.g., is it equivalent to a DTLS session or DTLS connection or something
in addition?
3.	the TLS renegotiation procedure: what is the definition and at which level (TLS session or TLS
connection level) does this procedure occur?
4.	the TLS resumption procedure: what is the definition and relation to TLS renegotiation?

The location of TLS or DTLS endpoints in terminal and gateway equipment is slightly different due to the
decomposition approach of H.248 gateways and their internal, hierarchical model of H.248 terminations
and H.248 stream endpoints. Support of (D)TLS procedures (beyond the pure establishment and release)
demand for the unambiguous detection of events (such as the differentiation between TLS renegotiation
and TLS resumption from TLS establishment). As part of the support of (D)TLS endpoints, the H.248 media
gateways are able to determine the TLS profile and protocol capabilities via so called auditing
capabilities procedures. However it is unclear which protocol capabilities are related to a (D)TLS
session and (D)TLS connection and thus the MGC and MG may have different interpretations. T
 he results of auditing TLS protocol capabilities and parameter values should be based on a common object
model between the H.248 media gateway and its controller.

ITU-T Q3/16 is appreciative for your cooperation.

    LS on TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4]
Sean Turner | 23 Nov 20:49 2014

WGLC: draft-ietf-tls-session-hash

This is the working group last call for  Please review the document and
send your comments to the list by Friday, December 12, 2014.