Martin Thomson | 29 Jan 06:04 2015

1.0 or else (was Re: Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00)

On 28 January 2015 at 15:31, Martin Rex <mrex <at>> wrote:
> That's not quite true.  There es little, if any stuff outside of the
> browser world that could go to > extension-less TLSv1.0, because there
> are still too many servers out there that will abort the handshake
> when extensions are present or when the version is > TLSv1.0.

Our limited survey thus far has identified only a small number (0.27%)
of sites [1][2] that can't handle our TLS 1.2 handshake [3], even
though they will tolerate our TLS 1.0 handshake.  In contrast,
disabling SSL3 affected more than twice this amount.

Note that we don't drop extensions now that SSL3 is disabled, so we
have no information on Martin's claims of extension intolerance.

[3] We use a TLS 1.0 record layer, 1.2 ClientHello and a modest set of
Salz, Rich | 27 Jan 20:45 2015

Questions about some expired drafts

OpenSSL includes at least the opaque-prf one.  Any reason to keep the code?  (I’m ripping out all sorts of old stuff now)



Principal Security Engineer, Akamai Technologies

IM: rsalz <at> Twitter: RichSalz

TLS mailing list
TLS <at>
Martin Rex | 24 Jan 08:49 2015

ClientHello and record layer version interop

I'm seeing an increase in customer messages about newly
appearing TLS interop problems.  There seem to be TLSv1.0 servers
who threw out the baby with the bathtub and started rejecting
ClientHellos with client_version = (3,1) that come in SSLv3 records.

One of the servers identifies itself as "Sun-ONE-Web-Server/6.1"
and exhibits the following crazy behaviour:

   SSLv2-record with SSLv2 CLIENT-HELLO offering TLSv1.0:  TLSv1.0 ServerHello
*> SSLv3-record   with ClientHello offering TLSv1.0 ==>  Handshake failure
   TLSv1.0-record with ClientHello offering TLSv1.0 ==>  TLSv1.0 ServerHello
   TLSv1.2-record with ClientHello offering TLSv1.2 ==>  TLSv1.0 ServerHello

How widespread is that disease?  Does anyone know which kind of
servers/software exhibit this flaw and how many of them exist?

Server configuration changes (disabling SSLv3) in "response" to Poodle
seem to get applied slowly to production servers. 

Sean Turner | 23 Jan 21:04 2015

WG adoption of draft-agl-tls-padding


WG adoption of draft-agl-tls-padding [0] seems to have fallen through the cracks.  Back in January 2014,
the chairs did a call for an early code point assignment [1], some changes were discussed and adopted in
-03, and an early code point assignment was made.  Early code point assignments are only temporary (1 year)
and to get it permanently assigned we need to progress the draft.  Back in January 2014, there was a call for
objections to WG adoption [2].  There were no objections and the draft should have been adopted, but we (the
chairs) dropped the ball and we’d like to remedy that by:

- Requesting that Adam submit an -00 WG draft version based on the -03
  of his individual draft to resuscitate it (i.e., change the name to
  draft-ietf-tls-padding - I’ve already pre-approved that name)
- Adopting -00 as a WG item
- WGLCing -00 shortly thereafter



Joseph Salowey | 23 Jan 20:54 2015

TLS Face-to-Facce Interim in March

We'd like to have another face-to-face interim in March.  I'm proposing to have the interim Seattle area.  The preferred dates are 3/5 and 3/6, but 3/9-3/11 are options as well.  I've set up a Doodle poll to see how many folks can make this time.  

If you are interested in attending this meeting please enter your availability by Friday, January 30, 2015. 


TLS mailing list
TLS <at>
Sean Turner | 23 Jan 20:30 2015

WGLC: draft-ietf-tls-negotiated-ff-dhe-05

This is the WGLC (working group last call) for draft-ietf-tls-negotiated-ff-dhe-05:
Please send comments on this draft to the TLS list before February 16, 2015.

The chairs and our AD are curious about whether switching to use of “e” as opposed to “pi”, as RFC
3526 did, is an issue.  The draft provides rationale for the change, but Stephen asked about this
particular point  <at>  our Hawaii session.

Joseph Salowey | 23 Jan 20:29 2015

Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00

This is a working group last call for draft-ietf-tls-sslv3-diediedie-00.  Please reply to the TLS working group list with an indication of whether or not the draft is ready for publication and any other comments you may have.  Please respond by February 16, 2015.  


S & J 
TLS mailing list
TLS <at>
Sean Turner | 23 Jan 17:10 2015

(draft final) ITU Q3/16 Liaison Response


We received a liaison from ITU-T Q3/16 that contain some questions that we need to reply to.  Joe and I have
drafted a response but would like to know if you have any comments on the following before 2015-01-30.  On
the 30th, we’ll craft some appropriate liaison language as boiler plate and ship it back to the ITU.

Q1-Q4 are their questions and A1-A4 are our responses.





[What is] 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).


A TLS session is shared cryptographic state established by a full TLS handshake between two peers.  The
session’s cryptographic state is used to establish the cryptographic key material for a TLS
connection.  A TLS connection is a transport relationship established between two peers that contains
the cryptographic state to cryptographically protect data sent and received on the connection
established through a full or abbreviated (session resumption) TLS handshake.  A TLS session may span one
or more TLS connections.  Every TLS connection is associated with one TLS session.  If session resumption
(abbreviated handshake) is not used then the TLS session and TLS connection will essentially be the same. 
A TLS session is identified by a Session ID in the client and server hellos.  A TLS connection is usually
identified by a host addresses and port numbers.


The DTLS association concept, e.g., is it equivalent to a DTLS session or DTLS connection or something in addition?


They are the same.


The TLS renegotiation procedure: what is the definition and at which level (TLS session or TLS connection
level) does this procedure occur?


The TLS renegotiation procedure establishes new cryptographic state for the TLS connection.  It may also
establish a new TLS session if the renegotiation uses the full TLS handshake.  

Please note that renegotiation is an optional feature for pre-TLS 1.3 clients and servers.

Please also note that renegotiation is being dropped in TLS 1.3.  Clients and servers will use a different
mechanism to update the cryptographic state.  


The TLS resumption procedure: what is the definition and relation to TLS renegotiation?


Resumption refers to the use of the state from an existing TLS session to establish a new TLS connection
using an abbreviated handshake.  During resumption the cryptographic parameters (algorithms etc.)
remain the same.  TLS renegotiation is the process of executing a new TLS handshake to establish new
cryptographic parameters for a TLS connection (effectively a new TLS connection using the same host
addresses and ports as the previous one).  If the handshake is a full handshake then both a new session and a
new connection are established and the renegotiated session may have different parameters.  

Please note that session resumption is an optional feature.
Watson Ladd | 22 Jan 17:34 2015

The Web Security model vs.TLS (was Re: Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard)

On Wed, Jan 21, 2015 at 10:11 PM, Martin Rex <mrex <at>> wrote:
> Bodo Moeller wrote:
>> If even just a *single* high-value site that you, personally, use does
>> support the SCSV, you'll benefit from the SCSV (provided that you're using
>> a browser that does a downgrade dance for compatibility with other servers
>> and sends the SCSV in downgraded Client Hello messages).
> I've been looking long and hard, but I'm having difficulties
> to see a noticable benefit.   OK, a Poodle demonstration of the CBC
> padding weakness will no longer work, and maybe a minor fraction of
> the script kiddies will spend their time on other activities.
> But for the security of the typical web browser, and I'm not currently
> aware of any TLS clients other than web browsers that are doing
> downgrade dances.  I'm not seeing a measurable benefit from fallback-scsv.
> The real problem, that is a prerequisite to Browser attacks like Poodle
> (and BEAST and CRIME predecessors) are
>    1) a browsers aggressive willingness to execute *ANYTHING* from
>       *ANYWHERE* that looks like active content
>    2) provisioning of a cross-site-request-forgery (CSRF) facility,
>       where the browser will share/insert the user's authentication
>       credentials into *EVERY* GET/POST, irrespective where that
>       request originates
> For a number of sites, being able to perform crafted GETs and POSTs,
> for which the browser will automatically provide/perform the
> authentication on behalf of the user, will provide ample room
> to cause trouble or damage to the end user.  No existing nor future TLS
> protocol version and no existing or future TLS cipher suites
> can prevent exploitation of such a Browser (mis)feature.

Go ahead and exploit this "vulnerability" you are discussing against
Paypal, Gmail, Facebook, or Amazon. You won't be able to. While there
is much to criticize the web security model for, and plenty of
websites are open to CSRF, characterizing the issue as unresolved is
wrong: there are standard, effective, protections that are regularly

Would you use the fact that ASN.1 parsers routinely give RCE as an
argument against deployment of TLS, or removing broken ciphers? What
about the significant information leaks caused by TLS's disclosure of
timing and sizes of data transfers between client and server?
Ultimately, if you want to look for excuses, the failure of operating
systems to even attempt to provide basic security properties is a

Is there any historic or imaginable security issue in TLS, which this
logic can't be employed to dispose of? Renegotiation bug: well, it's a
consequence of internal layering we can't possibly be expected to know
about. Triple handshake: oh, the real problem is not validating every
certificate chain you see during the events. The fact that the
implementers were never advised of these issues in the first place is
conveniently omitted.

There is plenty to be said about the languid pace with which the IETF
addresses known security issues, the general apathy with which
designing for security is greeted in general, and the slow adoption of
known solutions, but none of this is an excuse for worsening the

I agree that if browsers could use existing extensions as indicators
of functioning servers, that would be a better approach that provides
security benefit to far more connections.

> A single Poodle attack on a browser requires the attacker to be on-path
> between browser and server, for which the attacker intends to recover the
> users basic authentication credentials or SSL session cookie through
> repeated guessing -- and to perform active attacks on thousands of
> network connections between browser and server, creating thousands
> of otherwise quite rare TLS MAC errors in the server's logfile.

You assume people a) read logs, b) recognize these errors c) connect
them to an attack, d) have an action to take and e) take it. This is

You also assume that being "on-path" is a constraint. It isn't.
Sitting in between the user and the website are dozens of poorly
secured routers, many with default passwords and hard coded SSH keys.
These routers are more than capable of mounting Poodle.

> When (ab)using the browsers CSRF facility directly, rather than for noisy
> and boring Poodle, it will be sufficient to piggy-back one single arbitrary
> page that the user's browsers happens to load (or can be lured to load).
> When properly done, the attack will be indistinguishable from a genuine
> action of the user for the server, and be noticable for the user only
> by forensic inspection.  The browser's CSRF facility may even
> allow (ab)use of TLS PSK credentials or TLS client certificates,
> a form of credential that can not be attacked/recovered by Poodle.

I hadn't thought of that last idea. Should be easy enough to test.

> Attacking an *arbitrary* page is still quite trivial depressingly often,
> because so many sites force their users to use plaintext HTTP for at
> least parts of their stuff -- effectively throwing all security
> overboard each time.
> lots of online shops.  a popular auction site.
> Today I visited the site of a popular video/phone/chat software.
> Even when accessing their site via https: the "Sign in" and "Join us"
> URLs (at the upper right of all pages of the site) will _force_ the
> user through plaintext-HTTP.   The link to their Download section
> is https, but in the download section, the actual green software
> download button, again, forces you through plaintext-HTTP -- OUCH!

So what? I don't see why Johnny with the screen door on his house
means that the bank shouldn't have a bank vault. There are plenty of
outdated Wordpress versions out there: does that mean we shouldn't
stop SQL injections?

Watson Ladd

> -Martin
> _______________________________________________
> TLS mailing list
> TLS <at>


"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin
Stephen Farrell | 19 Jan 21:56 2015

Fwd: Stephen Farrell's Discuss on draft-ietf-tsvwg-sctp-dtls-encaps-08: (with DISCUSS and COMMENT)


Please see my DISCUSS on a document below - the interesting
question relates to which version of DTLS to mandate for
WebRTC in general, as I think once this document is done,
others will just copy the relevant text.

I don't think there are any major security issues involved,
but that this is more to do with implementations. But I'd
welcome any opinions or information about any important
security differences or about whether or not current
implementations mean DTLS1.2 should be ok to mandate here
today or not.

I've set reply-to as my address and not the TLS list as
I don't think the TLS WG need to debate this much and I'm
really just checking, so please don't bother the WG list
unless there's a real point of interest for the WG. And
to repeat: I'm just checking more thoroughly than usual
on this one since this will I think set a precedent for

Feedback is also needed by this Thursday 22nd to be useful.
Sorry about that but thanks in advance if you do manage to
send some:-)


-------- Forwarded Message --------
Subject: Stephen Farrell's Discuss on
draft-ietf-tsvwg-sctp-dtls-encaps-08: (with DISCUSS and COMMENT)
Date: Mon, 19 Jan 2015 12:48:11 -0800
From: Stephen Farrell <stephen.farrell <at>>
To: The IESG <iesg <at>>
CC: Gorry Fairhurst <gorry <at>>

Stephen Farrell has entered the following ballot position for
draft-ietf-tsvwg-sctp-dtls-encaps-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I'll clear once we've checked on this. Section 5 says
DTLS1.0 (from 2006) is MTI and DTLS1.2 (2012) is a
SHOULD. I could imagine that being reasonable when
DTLS1.2 was newish, say when this work was getting
started 2 years ago, but now a couple of years have
passed, it might well be just fine to require DTLS1.2 -
a lot has happened since and TLS1.2 deployment is now
far ahead of where it was in 2012, and most specs have
tended to include text like this because some
implementers only had the older TLS version. So the
DISCUSS is - is the 9 year old RFC still needed as MTI
- can we not just say to use 1.2 now?  (Note: since
this is sort-of a WebRTC spec, I think it's worth
quickly re-visiting this question now to be sure we're
taking the right approach, as the answer we pick here
is quite likely to be followed by other WebRTC docs
over the next year or so. I think this is the first
relevant WebRTC protocol spec with this bit of text
isn't it?  Apologies to the authors of this one for
landing the discuss on them:-)


- Figure 1: Couldn't ICE/UDP be somewhat confusing for
someone unaware that ICE is more of an algorithm than a
wire protocol? Might be nice to clarify that here in
the intro. (If you want to be nice, if you don't that's
ok too and can be the right decision.)

- section 3: Isn't "complete SCTP packet" a teeny bit
ambiguous? It could mean including the IP and other
lower headers but I guess you do not. But that's a nit
since it's probably clear enough that you don't put an
IP or layer 2 header into the DTLS payload:-)

- Given heartbleed, and the use here of RFC6520 I think
some note of that famous implementation bug would be
wise. Just to a pointer to how to not have that
problem. But it's not a protocol bug so I'm not trying
to insist, i.e. no need for us to argue the toss on

- I'm also wondering if the text here on 6520 is
sufficiently clear given this week's discussion of that
on the rtcweb list. (I'm not on tsvwg <at>  so would
appreciate an update on how the thread [1] pans out on
the tsvwg list before we approve this.)

Phillip Rogaway | 15 Jan 00:02 2015

Inclusion of OCB mode in TLS 1.3

A couple of colleagues were kind enough to tell me that there 
were discussions going on on this mailing list about including 
OCB in TLS 1.3; but that there were still some IP-related 
concerns.  I'd like to quell those as best I can.  So let 
me go on record as indicating that I think it would be great 
if TLS supported OCB; and that I'm happy to freely and 
automatically license any IP of mine for OCB under TLS.

I suspect that most use-cases for TLS-with-OCB would 
already be covered by one of the prior patent-grants 
I've done.  But, for anything that might fall in a gap, 
the simplest thing, I suspect, is for me to do an 
"IETF Patent Disclosure and Licensing Declaration" 
specifying royalty-free licensing for use of OCB in 
compliance with a TLS-specifying RFC.  I'm happy to 
submit one of those.  I might need some help to identify
what RFC number(s) to cite.

Thanks for all your hard work on advancing crypto
standards and improving TLS.