Subject: [TLS] Downgrade protection, fallbacks, and server time

From: David Benjamin <[email-masked]>
Date: Wed, 01 Jun 2016 22:29:06 +0000

In case folks hoped we could bump the ClientHello version without those
dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much
exists. (Maybe we should just give up on ClientHello.version and use an
extension? Extensions have rusted less.)

I picked a large list of top sites and tried connecting to them. Just under
2% of them could handle a TLS 1.2 ClientHello, but not the same ClientHello
with the version switched to 1.3 (no other changes, so I haven't tested a
real 1.3 ClientHello). They're not unknown hosts either. I expect if you
probe any top site list, you'll very quickly find some.

Fortunately, the ServerHello.random trick fixes this. But it currently
clobbers the old server timestamp which tlsdate[1] uses for clock
synchronization. There really should be a less silly secure timestamping
protocol, but, today, tlsdate has users. Any servers which expect to be a
tlsdate target can't honor this MUST without tlsdate gone.

(FALLBACK_SCSV works fine as well, but I gather people prefer the
ServerHello.random one and would be unhappy having to implement both in
clients with a fallback because not all servers do the latter.)

I mentioned this before, but rather than clobbering the first 8 bytes, the
last 8 bytes seems as reasonable and avoids this unnecessary complication
to TLS 1.3 deployment. If folks agree now that the fallback's resurrection
is more certain, I'm happy to put together a PR.

David

[1] https://github.com/ioerror/tlsdate

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 1 Jun 2016 15:43:07 -0700

2% is actually pretty good, but I agree that we're going to need fallback.

I'd be fine with moving the 8 bytes to the end, but I wonder if it would be
better to
instead have the *client* indicate its max version and the server check.
That would
have the advantage that it would leave more of the server random intact.

-Ekr

P.S. The FALLBACK_SCSV isn't a substitute because it isn't signed by the
server.

On Wed, Jun 1, 2016 at 3:29 PM, David Benjamin <[email-masked]>
wrote:

> I picked a large list of top sites and tried connecting to them. Just
> under 2% of them could handle a TLS 1.2 ClientHello, but not the same
> ClientHello with the version switched to 1.3 (no other changes, so I
> haven't tested a real 1.3 ClientHello). They're not unknown hosts either. I
> expect if you probe any top site list, you'll very quickly find some.
>
> to TLS 1.3 deployment. If folks agree now that the fallback's
> resurrection is more certain, I'm happy to put together a PR.
>
> David
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: David Benjamin <[email-masked]>
Date: Wed, 01 Jun 2016 22:53:24 +0000

On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla <[email-masked]> wrote:

> I'd be fine with moving the 8 bytes to the end, but I wonder if it would
> be better to

That sounds reasonable to me. I'd probably suggest still putting it at the
end since there's no reason to risk things, but I'm not aware of anything
that uses the client timestamp. (None of the clients I maintain send it.)

> P.S. The FALLBACK_SCSV isn't a substitute because it isn't signed by the

Yeah, FALLBACK_SCSV only gives us TLS 1.0-1.2-level downgrade protection
(otherwise the version fallback even loses that one). I only mean in terms
of mitigating the additional damage done by the fallback, not replacing the
entire mechanism.

(Although, do we actually get the stronger protection if the client accepts
plain RSA key exchange? I've never been very clear on that. Realistically,
clients will be accepting plain RSA for a long while.)

David

>> I mentioned this before, but rather than clobbering the first 8 bytes,
>> the last 8 bytes seems as reasonable and avoids this unnecessary
>> complication to TLS 1.3 deployment. If folks agree now that the
>> fallback's resurrection is more certain, I'm happy to put together a PR.
>>
>> David
>>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 1 Jun 2016 15:56:41 -0700

> that uses the client timestamp. (None of the clients I maintain send it.)

Putting it at the end of the client gives the client options, so that would
be fine.

> (Although, do we actually get the stronger protection if the client
> accepts plain RSA key exchange? I've never been very clear on that.
> Realistically, clients will be accepting plain RSA for a long while.)
>

Yes, that's correct. I don't believe we have a good plan for plain RSA.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Jun 2016 11:42:00 +1000

> Yes, that's correct. I don't believe we have a good plan for plain RSA.

The best plan involves lots and lots of fire.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 02 Jun 2016 09:31:31 +0200

> 2% is actually pretty good, but I agree that we're going to need

Please not. Lets let these fallbacks die. Not every client is a
browser. TLS 1.3 must be a protocol which doesn't require hacks to
operate. CBC was removed, lets do the same for insecure fallbacks.

regards,
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Jun 2016 11:39:20 +0300

> On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> 
 
Not every client is a browser, but some are. So what does the browser do when a server resets the connection after seeing the ClientHello?

Blank screen with a failure message?

---

From: Hubert Kario <[email-masked]>
Date: Thu, 02 Jun 2016 12:39:57 +0200

On Wednesday 01 June 2016 22:29:06 David Benjamin wrote:
> In case folks hoped we could bump the ClientHello version without
> those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance
> very much exists. (Maybe we should just give up on
> ClientHello.version and use an extension? Extensions have rusted
> less.)
> 
> haven't tested a real 1.3 ClientHello). They're not unknown hosts
> either. I expect if you probe any top site list, you'll very quickly
> find some.

there are also servers which choke on large extensions (say 4096 bit DH 
client key share with 384 bit ECDH key share), so avoiding the bump in 
version number won't solve all the problems either...

Speaking of version number, does the text say that a server _MUST_ 
accept any version higher than the one that is specified in the RFC, but 
reply with 0x03,0x04 in case it doesn't support any future version of 
the protocol? It would be nice to have some kind of stick for the broken 
implementations...

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Hubert Kario <[email-masked]>
Date: Thu, 02 Jun 2016 12:43:48 +0200

On Thursday 02 June 2016 11:39:20 Yoav Nir wrote:
> > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos
> > <[email-masked]> wrote:> 
> Not every client is a browser, but some are. So what does the browser
> do when a server resets the connection after seeing the ClientHello?
> 

fallback to check if the connection failure is caused by TLSv1.3, and if 
it is, display error message and put the blame squarely on the server

---

From: David Benjamin <[email-masked]>
Date: Thu, 02 Jun 2016 14:49:52 +0000

> version number won't solve all the problems either...

TLS 1.3 doesn't require clients offer a KeyShare for all groups in the
first ClientHello. It costs a HelloRetryRequest and another round-trip, but
I think that's fine. Clients can limit FFDHE in the initial ClientHello to
servers they've spoken to before or something. For unknown servers, if you
only predict a couple of EC groups, it shouldn't blow it up too badly, but
of course we'll just have to see.

(Or clients can just not bother with FFDHE to begin with. I don't see the
point and am not very interested in implementing it at all.)

> the protocol? It would be nice to have some kind of stick for the broken

I'm not sure I follow. The specification certainly spells out how version
negotiation is supposed to work. That hasn't stopped servers from getting
it wrong. Fundamentally this is the sort of thing where bugs don't get
noticed until we make a new TLS version, and we don't do that often enough
to keep rust from gathering.

David

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Jun 2016 10:59:45 -0400

> On Jun 2, 2016, at 10:49 AM, David Benjamin <[email-masked]> wrote:
> 
> I'm not sure I follow. The specification certainly spells out how version negotiation is supposed to work. That hasn't stopped servers from getting it wrong. Fundamentally this is the sort of thing where bugs don't get noticed until we make a new TLS version, and we don't do that often enough to keep rust from gathering.

A better way to keep rust from gathering is to not instutionalize fallback,
force the broken sites to deal with the issue.  While 2% is noticeable, you
can probably drive 1.3 version intolerance out of the ecosystem relatively
quickly if Chrome implements fallback for a limited time (say 6 months after
TLS 1.3 RFC is done) and with a diminishing probability (60% first month, 10%
less each month thereafter), season to taste.

-- 
	Viktor.

---

From: David Benjamin <[email-masked]>
Date: Thu, 02 Jun 2016 15:07:53 +0000

> it is, display error message and put the blame squarely on the server

We browser folk hate these fallbacks just enough as much as you do, if not
more. I personally spent quite a lot of time and effort getting rid of it
in Chrome (and I'm happy to say, as of Chrome 50, I seem to have
succeeded). I'm sure my counterparts at Mozilla went through similar pains.

But reality is what it is. The Law of the Internet is the last thing that
changed is blamed. We have a limited "budget" we can spend breaking things
(otherwise I'd have removed almost everything by now!) and there is no
chance I can break all the hosts I found.

I have been reaching out to figure out the broken vendors, but this is a
slow process. It will not be flushed this out anytime soon. With TLS 1.3 as
it stands, I think a browser fallback in the short to medium term is a
certainty. (If your clients don't need it, then by all means don't add one!
I envy you.)

David

---

From: David Benjamin <[email-masked]>
Date: Thu, 02 Jun 2016 15:16:56 +0000

On Thu, Jun 2, 2016 at 10:59 AM Viktor Dukhovni <[email-masked]>
wrote:

> > I'm not sure I follow. The specification certainly spells out how
> version negotiation is supposed to work. That hasn't stopped servers from
> getting it wrong. Fundamentally this is the sort of thing where bugs don't
> get noticed until we make a new TLS version, and we don't do that often
> enough to keep rust from gathering.
>

I've mused on something like that (I was the main driver behind
painstakingly removing the existing version fallback in Chrome), but I
don't think non-determinism is a good idea. Site owners need to be able to
reproduce the failures their users see.

But, yes, I will of course be monitoring the true metrics (my probing a
list of sites is only an approximation) and seeing what can be done here,
as I did previously.

David

---

From: Hubert Kario <[email-masked]>
Date: Thu, 02 Jun 2016 17:20:35 +0200

On Thursday 02 June 2016 14:49:52 David Benjamin wrote:
> > there are also servers which choke on large extensions (say 4096 bit
> > DH client key share with 384 bit ECDH key share), so avoiding the
> > bump in version number won't solve all the problems either...
> 
> first ClientHello. It costs a HelloRetryRequest and another
> round-trip, but I think that's fine. Clients can limit FFDHE in the
> initial ClientHello to servers they've spoken to before or something.
> For unknown servers, if you only predict a couple of EC groups, it
> shouldn't blow it up too badly, but of course we'll just have to see.

isn't one of the main selling points of TLSv1.3 the 1RTT? and if 1RTT 
doesn't work, you still have to do a fallback dance, to a modified 
TLSv1.3 but you still do

given that TLSv1.2 intolerance is not completely eradicated yet, there 
will always be some servers that do not support any kind of extensions 
or changes to client hello's that worked before (see the 256-512byte 
Client Hello problems caused by cipher suite additions)
 
> (Or clients can just not bother with FFDHE to begin with. I don't see
> the point and am not very interested in implementing it at all.)

quantum computing, and while you may not agree, NIST has a different 
opinion on the matter and that's enough of a reason for many people

> > accept any version higher than the one that is specified in the RFC,
> > but reply with 0x03,0x04 in case it doesn't support any future
> > version of the protocol? It would be nice to have some kind of
> > stick for the broken implementations...
> 
> version negotiation is supposed to work. That hasn't stopped servers
> from getting it wrong. Fundamentally this is the sort of thing where
> bugs don't get noticed until we make a new TLS version, and we don't
> do that often enough to keep rust from gathering.

yes, but I don't see it spelling out anywhere that a server MUST accept 
higher numbers, it just describes how the mechanism works up to this 
point, not how it will continue to work

---

From: David Benjamin <[email-masked]>
Date: Thu, 02 Jun 2016 15:22:03 +0000

>> it is, display error message and put the blame squarely on the server
(We already do that, by the way. That's exactly what
ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION in Chrome is.)

---

From: David Benjamin <[email-masked]>
Date: Thu, 02 Jun 2016 15:27:06 +0000

> point, not how it will continue to work
I added an entry here a bit ago:
https://tlswg.github.io/tls13-spec/#rfc.appendix.B.4
"When processing a ClientHello containing a version of { 3, 5 } or higher,
do you respond with the highest common version of TLS rather than requiring
an exact match?"

The ServerHello section says:
https://tlswg.github.io/tls13-spec/#rfc.section.6.3.1.2
"This field [server_version] will contain the lower of that suggested by
the client in the ClientHello and the highest supported by the server. For
this version of the specification, the version is { 3, 4 }. (See Appendix C
for details about backward compatibility.)"

Although the ClientHello section says:
https://tlswg.github.io/tls13-spec/#rfc.section.6.3.1.1
"The version of the TLS protocol by which the client wishes to communicate
during this session. This SHOULD be the latest (highest valued) version
supported by the client. For this version of the specification, the version
will be { 3, 4 }. (See Appendix C for details about backward
compatibility.)"

I'll go put together a PR to change that to say the highest version
supported or something. "which the client wishes to communicate" is
somewhat ambiguous...

David

---

From: Hubert Kario <[email-masked]>
Date: Thu, 02 Jun 2016 17:28:15 +0200

On Thursday 02 June 2016 15:07:53 David Benjamin wrote:
> > > >> 2% is actually pretty good, but I agree that we're going to
> > > >> need
> > > >> fallback.
> > > > 
> > fallback to check if the connection failure is caused by TLSv1.3,
> > and if it is, display error message and put the blame squarely on
> > the server
> We browser folk hate these fallbacks just enough as much as you do, if
> not more. I personally spent quite a lot of time and effort getting
> rid of it in Chrome (and I'm happy to say, as of Chrome 50, I seem to
> have succeeded). I'm sure my counterparts at Mozilla went through
> similar pains.
> 
> But reality is what it is. The Law of the Internet is the last thing
> that changed is blamed. We have a limited "budget" we can spend
> breaking things (otherwise I'd have removed almost everything by
> now!) and there is no chance I can break all the hosts I found.

that's why I said that the browser should diagnose the issue and put the 
blame where blame is due

user can't make an informed decision if he or she is not informed, 
printing "Alert: Fatal, invalid_parameter" or a "server aborted 
connection" is not information needed to make the decision

> I have been reaching out to figure out the broken vendors, but this is
> a slow process. It will not be flushed this out anytime soon. With
> TLS 1.3 as it stands, I think a browser fallback in the short to
> medium term is a certainty. (If your clients don't need it, then by
> all means don't add one! I envy you.)

for customers that need it, we explain the problem and provide option to 
override the maximum version supported to a lower one

---

From: Hubert Kario <[email-masked]>
Date: Thu, 02 Jun 2016 17:32:55 +0200

> ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION in Chrome is.)

the rest of the information on such error page definitely doesn't give 
that impression

Correct me if I'm wrong, but isn't the full text on it:

"""
The web page at https://example.com might be temporarily down or it may 
have moved permanently to a new web address.

Error code: ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION
"""

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Jun 2016 11:33:10 -0400

> On Jun 2, 2016, at 11:16 AM, David Benjamin <[email-masked]> wrote:
> 
> I've mused on something like that (I was the main driver behind painstakingly removing the existing version fallback in Chrome), but I don't think non-determinism is a good idea. Site owners need to be able to reproduce the failures their users see.
> 
> But, yes, I will of course be monitoring the true metrics (my probing a list of sites is only an approximation) and seeing what can be done here, as I did previously.

Opening a new window or tab and trying again a couple of times is not
a major reproducibility barrier.  The odds of failure would increase
with time, and would not be small to start with.

It would be important to roll the dice just once for a given site within
a given window or tab (at least until the user navigates to a new domain)
so that once contact is successful, further disruption does not render the
site unusable.  Basically, resume with the highest protocol that worked
consistently until such state is safe to flush, but reduce the odds of
initial success over a well publicized time-frame.

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Jun 2016 13:29:31 +1000

> chance I can break all the hosts I found.

FWIW, I agree.  This has a bit of an explanation of the forces at play
here: https://annevankesteren.nl/2016/05/client-server

---

From: Dave Garrett <[email-masked]>
Date: Fri, 3 Jun 2016 00:17:20 -0400

Allrighty then; time to dust off and rebase an old changeset I was fiddling with last year on this topic:
https://github.com/davegarrett/tls13-spec/commit/058ff1518508b094b8c9f1bd4096be9393f20076
(I cleaned up a bit when rebasing, but it probably needs some work; was just a WIP branch, never a PR)

This was the result of prior discussions on-list about TLS version intolerance. The gist of the proposal:
1) Freeze all the various version number fields.
2) Send a list of all supported versions in an extension. (version IDs converted to 16-bit ints instead of 8-bit pairs)
3) Use short (1 or 2 value, based on hello version) predefined lists for hellos from old clients not sending the extension.
4) Compare lists to find highest overlap, avoiding guesswork or problems with noncontinuous lists.
5) Forget the old mess of version intolerance existed.

Do we want to consider scrapping the old version negotiation method again?

Dave

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 03 Jun 2016 08:37:34 +0200

On Fri, 2016-06-03 at 00:17 -0400, Dave Garrett wrote:
> 2) Send a list of all supported versions in an extension. (version
> IDs converted to 16-bit ints instead of 8-bit pairs)
> 3) Use short (1 or 2 value, based on hello version) predefined lists
> for hellos from old clients not sending the extension.

I had originally similar thoughts, but doesn't that introduce a 4th
version negotiation mechanism? We already have the current version
negotiation mechanism(1), the extension mechanism(2), the ciphersuite
negotiation(3), and we are getting a new version negotiation mechanism
based on extensions(4).

Note that (1),(2) and (3) aren't getting away if we introduce (4). The
code will stay in implementations for more than a decade.

A simpler proposal is:
Consider TLS 1.3 as a feature, and negotiate it using an empty
extension. If the extension is present a server assumes TLS 1.3.

regards,
Nikos

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 3 Jun 2016 11:33:54 +0300

> extension. If the extension is present a server assumes TLS 1.3.

Well, AFAIK, in current editor's draft, key_share or pre_shared_key
is always present and none are meaningful in TLS.1.2.

-Ilari

---

From: Hubert Kario <[email-masked]>
Date: Fri, 03 Jun 2016 11:28:05 +0200

> extension. If the extension is present a server assumes TLS 1.3.

If anything, it should be this.

Extension with version negotiation introduced because version 
negotiation is commonly gotten wrong doesn't look like a solution to 
me...

That being said, I would prefer the solution to be a compliance test 
suite that checks if servers do handle correctly future versions, future 
extensions and future ciphersuites correctly.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Xiaoyin Liu <[email-masked]>
Date: Fri, 3 Jun 2016 07:39:06 -0400

> Date: Fri, 3 Jun 2016 11:33:54 +0300
> From: [email-masked]
> To: [email-masked]
> Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
> 
But they cannot be used to distinguish TLS 1.3 with any future versions, if these two extensions still exist in TLS 1.4, 1.5, ... .
Best,Xiaoyin

---

From: Hubert Kario <[email-masked]>
Date: Fri, 03 Jun 2016 15:28:59 +0200

On Friday 03 June 2016 07:39:06 Xiaoyin Liu wrote:
> > Subject: Re: [TLS] no fallbacks please [was: Downgrade protection,
> > fallbacks, and server time]> 
> But they cannot be used to distinguish TLS 1.3 with any future
> versions, if these two extensions still exist in TLS 1.4, 1.5, ... .

TLSv1.4 and TLSv1.5 can introduce their own extensions, empty ones in 
worst case
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Jun 2016 06:39:58 -0700

My opinion on this hasn't really changed since the last time. This seems
like it's more complicated and it's not clear to me why it won't lead to
exactly the same version intolerance problem in future.

-Ekr

On Thu, Jun 2, 2016 at 9:17 PM, Dave Garrett <[email-masked]> wrote:

> 2) Send a list of all supported versions in an extension. (version IDs
> converted to 16-bit ints instead of 8-bit pairs)
> 3) Use short (1 or 2 value, based on hello version) predefined lists for
> hellos from old clients not sending the extension.

---

From: Andrei Popov <[email-masked]>
Date: Fri, 3 Jun 2016 17:28:14 +0000

It’s not that the existing version negotiation mechanism doesn’t work; the problem is that implementers got it wrong. Similarly, implementers can mess up the new negotiation mechanism. Especially since we have to support it at the same time as the old one.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Friday, June 3, 2016 6:40 AM
To: Dave Garrett <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

My opinion on this hasn't really changed since the last time. This seems like it's more complicated and it's not clear to me why it won't lead to exactly the same version intolerance problem in future.

-Ekr

On Thu, Jun 2, 2016 at 9:17 PM, Dave Garrett <[email-masked]<mailto:[email-masked]>> wrote:
Allrighty then; time to dust off and rebase an old changeset I was fiddling with last year on this topic:
https://github.com/davegarrett/tls13-spec/commit/058ff1518508b094b8c9f1bd4096be9393f20076
(I cleaned up a bit when rebasing, but it probably needs some work; was just a WIP branch, never a PR)

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Jun 2016 10:32:37 -0700

That's a clearer version of what I was trying to say.

-Ekr

On Fri, Jun 3, 2016 at 10:28 AM, Andrei Popov <[email-masked]>
wrote:

> It’s not that the existing version negotiation mechanism doesn’t work; the
> problem is that implementers got it wrong. Similarly, implementers can mess
> up the new negotiation mechanism. Especially since we have to support it at
> the same time as the old one.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Eric Rescorla
> *Sent:* Friday, June 3, 2016 6:40 AM
> *To:* Dave Garrett <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [TLS] no fallbacks please [was: Downgrade protection,
> fallbacks, and server time]
>
>
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 3 Jun 2016 17:40:50 +0000

> exactly the same version intolerance problem in future.

Doing version negotiation through extensions would be a major
implementation burden.  At present the client version appears early
in the ClientHello at a fixed position in the packet, and the server
can quickly grab the version, compute the highest shared version
and branch to the protocol implementation for that version to parse
the rest of the ClientHello.

Putting the client version in an extension dramatically complicates
server-side processing.  So my view is that this would not be
progress.  This is IMNSHO even less likely to interoperate than
what we have now.

-- 
	Viktor.

---

From: David Benjamin <[email-masked]>
Date: Fri, 03 Jun 2016 18:19:52 +0000

I think I could be convinced in either direction right now.

It is definitely ugly and more of a nuisance to implement. The alternative
is a fallback and then painfully driving it out later. We've done that
before and we have FALLBACK_SCSV and the server_random trick now.

At the same time, I am rather bored of this fallback game. We can actually
avoid the intolerance problem with this mechanism. Suppose we used empty
indicator extensions, one for each new version. Then as long as servers
tolerate unknown extensions, we'll be fine. So far this has not rusted yet,
and we can defend it from rust by having clients send random fake
extensions out of a range of values we burn for this purpose[*] (or private
use area). If one extension with a list of values, we can do something
similar.

(Strictly speaking, the version already does not appear at a fixed position
because a ClientHello may be pathologically fragmented. OpenSSL even had
CVE-2014-3511 here. I believe the master branch no longer has a sniff-based
version negotiation. BoringSSL hasn't for a while now. But rejecting such
pathologically fragmented ClientHellos is reasonable and OpenSSL 1.0.x does
it now.)

David

[*] I'm planning on writing something up here soon.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 3 Jun 2016 16:16:13 -0400

The idea of using an empty extension as an indicator really isn't fundamentally different from what I'm suggesting here. We'd just have an arbitrary set of new version indicators mixed in with extensions instead of inside a new generalized basket. My replacement was (again, it's over a year old) designed to be a general purpose long-term solution that could handle 1.3, 1.4, draft versions, experiments, etc, without special-casing. I'm not fundamentally against just adding a TLS 1.3 version indicator extension and freezing the old version number to 1.2. It just feels a little more hacky to me, though in the short-term it's simpler.

With respect to the concern of version numbers being moved to a non-fixed position, we could just require that the new version list extension be first or last in the extensions list. Being required to be last would also permanently mitigate the known issue of some buggy servers choking with an empty extension last. Conversely, with an empty extension indicator for each 1.3+ version, we'd probably want to require that to be first in the list to avoid that bug. (servers would of course still have to parse as an extension as not all clients will be sending 1.3+, so it's not reliably placed like the current hello version)

Dave

---

From: Bill Frantz <[email-masked]>
Date: Sat, 4 Jun 2016 08:08:44 -0700

On 6/3/16 at 2:28 AM, [email-masked] (Hubert Kario) wrote:

>That being said, I would prefer the solution to be a compliance 
>test suite that checks if servers do handle correctly future 
>versions, future extensions and future ciphersuites correctly.

I agree with Hubert. The big question is how you get the bug 
report to the server operator.

With servers which are currently maintained, it should be 
possible, although difficult in specific instances to contact 
the owner. With servers which aren't being maintained, e.g. 
those in imbedded devices, the problem becomes much harder.

If the client has a UI, it could explain the problem to the user 
and ask if the user wants to continue with degraded security. If 
so, then always use the remembered highest supported version 
with that server domain name, with perhaps occasional reminders 
to the user of the situation.

In any case, we should be addressing our efforts to getting bugs 
fixed, not just coding around them.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | The first thing you need when  | Periwinkle
(408)356-8506      | using a perimeter defense is a | 16345 
Englewood Ave
www.pwpconsult.com | perimeter.                     | Los Gatos, 
CA 95032

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 4 Jun 2016 19:46:09 +0300

On 02/06/16 18:16, David Benjamin wrote:
> On Thu, Jun 2, 2016 at 10:59 AM Viktor Dukhovni <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>      > On Jun 2, 2016, at 10:49 AM, David Benjamin
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >
> don't think non-determinism is a good idea. Site owners need to be able
> to reproduce the failures their users see.
>
> list of sites is only an approximation) and seeing what can be done
> here, as I did previously.
>
> David
>

Taking Viktor's proposal in a different direction, you could gradually 
increase the probability of version intolerance on the client side while 
still remaining deterministic from the user's point of view. You could 
do it by choosing a random distribution over server names (e.g., a hash 
of the SNI value). This means every month a few new servers would break. 
And you would want the client's beta channel to run several steps ahead 
of the production version.

Thanks,
	Yaron

---

From: Stefan Winter <[email-masked]>
Date: Mon, 6 Jun 2016 11:08:43 +0200

Hi,

>
>
>
> I agree with Hubert. The big question is how you get the bug report to
> the server operator.

Automated mail to webmaster@domain_of_requested_hostname?

Maybe a few thousand new mails in the operator's inbox of sorts "we have
encountered a situation where your version intolerance broke things. Fix
it." (with all the technical details you can dump on an admin and expect
him to understand; which is more than a user can take) wakes them up.

That is, for domains still using webmaster@ like they should.

Greetings,

Stefan Winter

>
> With servers which are currently maintained, it should be possible,
> although difficult in specific instances to contact the owner. With
> servers which aren't being maintained, e.g. those in imbedded devices,
> the problem becomes much harder.
>
> If the client has a UI, it could explain the problem to the user and
> ask if the user wants to continue with degraded security. If so, then
> always use the remembered highest supported version with that server
> domain name, with perhaps occasional reminders to the user of the
> situation.
>
> (408)356-8506      | using a perimeter defense is a | 16345 Englewood Ave
> www.pwpconsult.com | perimeter.                     | Los Gatos, CA 95032
>

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Hubert Kario <[email-masked]>
Date: Mon, 06 Jun 2016 12:48:20 +0200

On Friday 03 June 2016 16:16:13 Dave Garrett wrote:
> The idea of using an empty extension as an indicator really isn't
> fundamentally different from what I'm suggesting here. We'd just have
> an arbitrary set of new version indicators mixed in with extensions
> instead of inside a new generalized basket. My replacement was
> (again, it's over a year old) designed to be a general purpose
> long-term solution that could handle 1.3, 1.4, draft versions,
> experiments, etc, without special-casing. I'm not fundamentally
> against just adding a TLS 1.3 version indicator extension and
> freezing the old version number to 1.2. It just feels a little more
> hacky to me, though in the short-term it's simpler.

The reason why we want to add this is because there are programmers that 
get the normal version negotiation wrong.

What makes you think that a new version negotiation that works more or 
less in the same way will _not_ be implemented incorrectly?

Counter example: there are servers which handle TLSv1.2 and do not 
handle TLSv1.3 (e.g. ebay.com), and there are implementations that do 
not handle multiple names in SNI extension. Both are supported only by 
either recent or very recent implementations.

And don't forget that what we are proposing here is significantly 
complicating implementations that most likely _are_ behaving properly 
and _are_ handling unknown versions/extensions/ciphersuites correctly; 
just because there are few bad apples.

> With respect to the concern of version numbers being moved to a
> non-fixed position, we could just require that the new version list
> extension be first or last in the extensions list.

it's still after the variable-length list of ciphersuites...

---

From: [email-masked] (Martin Rex)
Date: Mon, 6 Jun 2016 18:25:18 +0200 (CEST)

The IMO most reasonable way forward would be to side-step the
TLS version negotiation through ClientHello.client_version
entirely, because of the well-known interop problems.

Simply use the presence of *ANY* TLSv1.2+ TLS cipher suite in the
offered list of TLS cipher suites as an indication that a TLS client is
capable and willing to actually _use_ TLSv1.2, even when
ClientHello.client_version might indicate (3,2) or (3,1) for
better interop.  The same approach will work for TLSv1.3,
where the presence of a TLSv1.3 could be used to tell the server
that the client is capable and willing to talk TLSv1.3, even when
ClientHello.client_version might indicate a lower version of the
protocol.

Only the client is in the position to decide whether aborting
the TLS handshake and retrying with a more feature-creeping ClientHello
could provide additional benefits to the client (that it previously
didn't offer, for whatever reason), and only the client is in the
position to know how many TLS handshake attempts with which properties
it previously attempted, and when to better stop retrying automatically
and silently and to perform risk management (such as warning user/admin
that something odd is going on).

To get a smooth migration to using newer TLS protocol versions, we
first need to define a scheme that lets new implementations recognize
each other without upsetting the installed base.  We know what works,
the code points already exist, we will just have to align the documented
semantics to provide a more forward-interoperable and more reasonable
behaviour.

Viktor Dukhovni wrote:
> 
>> David Benjamin <[email-masked]> wrote:
>> 
> force the broken sites to deal with the issue.

It's not the sites, but rather the software vendor providing the
underlying TLS implementation.  Sometimes you don't actually have
a choice and an alternative to using what exists.

>
> While 2% is noticeable, you can probably drive 1.3 version intolerance
> out of the ecosystem relatively quickly if Chrome implements fallback
> for a limited time (say 6 months after TLS 1.3 RFC is done) and with
> a diminishing probability (60% first month, 10% less each month
> thereafter), season to taste.

There exist various different flavour of TLS version intolerance,
and the amount of defective servers out there is probably much larger.

The entire installed base of Windows 2008R2 and Windows 20012R2
is TLS version intolerant with respect to TLSv1.2.

If you send propose TLSv1.2 inside an SSLv2Hello to such a server,
it will negotiate TLSv1.1 (rather than TLSv1.2).  If you send
an extensionless SSLv3 Hello proposing TLSv1.2, these Windows
server with choke and close the network connection.  An extension-less
SSLv3 Hello with at client_version = TLSv1.1 or TLSv1.0 will succeed.

-Martin

---

From: Dave Garrett <[email-masked]>
Date: Mon, 6 Jun 2016 14:53:53 -0400

> less in the same way will _not_ be implemented incorrectly?

The list-based extension doesn't work in quite the same way. The current mechanism compares two values and picks the lower one. This new mechanism compares two lists and picks the highest mutually listed. Also note that I wish to officially drop any meaning from the version IDs such that we're using an arbitrary 16-bit serial number rather than two 8-bit major & minor numbers. The new supports discontinuous lists, e.g. support of 1.0, 1.2, & 1.4, but not 1.1 or 1.3, without risking accidental negotiation of a lower version that isn't desired. (if 1.3 is eventually declared less ideal than 1.2 or 1.4 due to some unforeseen problem, this gives us a safe mitigation, and it extends to arbitrary future scenarios) Also, as with any new system, we now have the ability to loudly stress to TLS 1.3+ implementers to not screw it up and test for future-proofing this time around. At a minimum, implementations will not be able to use the exact same code to negotiate in both systems and would have to go out of there way to add intolerance stupidly, rather than stumble into it stupidly again. Just sticking a new field in an extension lets implementers route it into the same code and risk the same mistakes; adding a bit of complexity here is an unfortunate cost of fixing this mess. Just adding a new _empty_ extension, as was more recently proposed, is something I think could also work ok. Again, if we're more likely to get consensus on that, I think it's viable too.

The idea of a compliance test suite has come up before and I will again say: YES, PLEASE!

I certainly don't claim anything proposed here is perfect, but nothing is or will be in a 20 year old protocol.

Dave

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 6 Jun 2016 15:32:38 -0400

>> That being said, I would prefer the solution to be a compliance test suite
>> that checks if servers do handle correctly future versions, future
> I agree with Hubert. The big question is how you get the bug report to the
> server operator.
>
> With servers which are currently maintained, it should be possible, although
> difficult in specific instances to contact the owner. With servers which
> aren't being maintained, e.g. those in imbedded devices, the problem becomes
> much harder.

There are two ways. First, use the Administrative and Technical
contacts in the WHOIS database. They are ICANN contractual
requirements, and they must be valid. Second, RFC 2142, MAILBOX NAMES
FOR COMMON SERVICES, ROLES AND FUNCTIONS.

Jeff

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 7 Jun 2016 06:00:33 +0000

Dave Garrett <[email-masked]> writes:

>Also, as with any new system, we now have the ability to loudly stress to TLS
>1.3+ implementers to not screw it up and test for future-proofing this time
>around. 

I think that's the main contribution of a new mechanism, it doesn't really
matter whether it's communicated as a single value, a list, or interpretive
dance, the main thing is that there needs to be a single location where the
version is given (not multiple locations that can disagree with each other as
for TLS < 1.3), and the spec should include a pseudocode algorithm for dealing
with the version data rather than just "implementations should accept things
that look about right".

Peter.

---

From: Kyle Rose <[email-masked]>
Date: Tue, 7 Jun 2016 10:22:20 -0400

I'm a big fan of the idea of a very strict qualification suite, as well, to
try to head off some of these problems before (faulty) implementations
proliferate.

Hackathon?

Kyle

---

From: Hubert Kario <[email-masked]>
Date: Tue, 07 Jun 2016 16:34:06 +0200

On Tuesday 07 June 2016 10:22:20 Kyle Rose wrote:
> I'm a big fan of the idea of a very strict qualification suite, as
> well, to try to head off some of these problems before (faulty)
> implementations proliferate.
> 
> Hackathon?

I have two approaches I'm working on, they are missing a nice interface 
though.

The first one is:
https://github.com/tomato42/tlsfuzzer
and aims to be a comprehensive test suite 

and the other one, simpler (aimed only at detecting incompatibilities) 
is cscan that lives here:
https://github.com/tomato42/cipherscan/tree/cscan-2

Both require just python and have minimal dependencies.

> > >Also, as with any new system, we now have the ability to loudly
> > >stress to> 
> > TLS
> > 
> > >1.3+ implementers to not screw it up and test for future-proofing
> > >this> 
> > time
> > 
> > >around.
> > 
> > I think that's the main contribution of a new mechanism, it doesn't
> > really matter whether it's communicated as a single value, a list,
> > or interpretive dance, the main thing is that there needs to be a
> > single location where the version is given (not multiple locations
> > that can disagree with each other as
> > with the version data rather than just "implementations should
> > accept
> > things
> > that look about right".
> > 
> > Peter.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 7 Jun 2016 17:36:01 +0300

I’m not sure this helps. 

I’ve never installed a server that is version intolerant. TLS stacks from OpenSSL, Microsoft, Java, and most any implementation we can name have been version tolerant forever. Certainly none of us can name any implementation that at any point had a version out that was tolerant (or implementing) TLS 1.2 but intolerant of TLS 1.3.

And these are the same implementations we’re likely to participate in a bakeoff or run the suite we create in the hackathon.

Yoav

> On 7 Jun 2016, at 5:22 PM, Kyle Rose <[email-masked]> wrote:
> 
> I'm a big fan of the idea of a very strict qualification suite, as well, to try to head off some of these problems before (faulty) implementations proliferate.
> 
> Hackathon?
> 
> Kyle
> 
> On Jun 7, 2016 2:00 AM, "Peter Gutmann" <[email-masked] <mailto:[email-masked]>> wrote:
> Dave Garrett <[email-masked] <mailto:[email-masked]>> writes:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 7 Jun 2016 14:47:39 +0000

> I’m not sure this helps. 

I'm pretty sure it wouldn't help at all, for the reasons you list.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 7 Jun 2016 18:05:49 +0300

> On 7 Jun 2016, at 5:47 PM, Salz, Rich <[email-masked]> wrote:
> 
>> I’m not sure this helps. 
> 

Which isn’t to say it’s not worth doing. I’d love to test my implementation against a test suite rather than just making sure it’s working with the five most popular browsers.

It’s just that it won’t solve this particular problem.

Yoav

---

From: Hubert Kario <[email-masked]>
Date: Tue, 07 Jun 2016 19:33:39 +0200

On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote:
> I’m not sure this helps.
> 
> I’ve never installed a server that is version intolerant. TLS stacks
> from OpenSSL, Microsoft, 

are you sure about that Microsoft part?

there is quite a long thread on the filezilla forums about TLS version 
tolerance in IIS:
https://forum.filezilla-project.org/viewtopic.php?f=2&t=27898

> Java, and most any implementation we can
> name have been version tolerant forever.

tls version intolerance is only one thing, then we have:

 * old-ish Java is intolerant of 2048 bit DH key share
 * many versions of OpenSSL are intolerant to very big Client Hello 
   messages (over ~1500 bytes)
 * old-ish IIS is intolerant to placing RC4 ciphersuites very low in 
   order

and so on...

> Certainly none of us can
> name any implementation that at any point had a version out that was
> tolerant (or implementing) TLS 1.2 but intolerant of TLS 1.3.

I don't know for sure what ebay.com is running, but it certainly is TLS 
1.3 intolerant

tls_prober[1] identifies it at Microsoft IIS 7.5

> And these are the same implementations we’re likely to participate in
> a bakeoff or run the suite we create in the hackathon.

if bugs get fixed, then we have achieved something

1 - https://github.com/WestpointLtd/tls_prober

> > On Jun 7, 2016 2:00 AM, "Peter Gutmann" <[email-masked]
> > <mailto:[email-masked]>> wrote:> 
> > >stress to TLS 1.3+ implementers to not screw it up and test for
> > >future-proofing this time around.
> > 
> > that can disagree with each other as for TLS < 1.3), and the spec
> > should include a pseudocode algorithm for dealing with the version
> > data rather than just "implementations should accept things that
> > look about right".
> > 
> > Peter.
> > <https://www.ietf.org/mailman/listinfo/tls>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Jun 2016 00:06:23 +0300

> On 7 Jun 2016, at 8:33 PM, Hubert Kario <[email-masked]> wrote:
> 

That’s surprising.

The last time I tested with an IIS servers it was Windows Server 2003 and 2008. They did not support TLS 1.2, so I wanted to check if they could tolerate a TLS 1.2 ClientHello. They did. Of course, they replied with TLS 1.0, but that was expected.

It’s strange that this behavior would degrade for much newer versions of Windows that came out at a time where several browsers were already offering TLS 1.2. I wonder if it’s just the FTP or also IIS.

Yoav

---

From: David Benjamin <[email-masked]>
Date: Tue, 07 Jun 2016 21:08:00 +0000

On Tue, Jun 7, 2016 at 5:06 PM Yoav Nir <[email-masked]> wrote:

> The last time I tested with an IIS servers it was Windows Server 2003 and
> 2008. They did not support TLS 1.2, so I wanted to check if they could
> tolerate a TLS 1.2 ClientHello. They did. Of course, they replied with TLS
> 1.0, but that was expected.
>
> It’s strange that this behavior would degrade for much newer versions of
> Windows that came out at a time where several browsers were already
> offering TLS 1.2. I wonder if it’s just the FTP or also IIS.
>

This is the first I've heard of this and I believe neither Chrome nor
Firefox accept TLS 1.2 intolerance and below anymore. To my knowledge, that
has successfully been driven out of the ecosystem.

David

---

From: Andrei Popov <[email-masked]>
Date: Tue, 7 Jun 2016 21:14:32 +0000

Jumping to the end of the thread, it looks like this is an FTP issue that repros when TLS 1.2 is negotiated. Not a TLS version intolerance.
The conclusion seems to be that https://support.microsoft.com/en-us/kb/2888853 resolves the issue, by updating FTP binaries.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of David Benjamin
Sent: Tuesday, June 7, 2016 2:08 PM
To: Yoav Nir <[email-masked]>; Hubert Kario <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]

On Tue, Jun 7, 2016 at 5:06 PM Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:

> On 7 Jun 2016, at 8:33 PM, Hubert Kario <[email-masked]<mailto:[email-masked]>> wrote:
>

That’s surprising.

This is the first I've heard of this and I believe neither Chrome nor Firefox accept TLS 1.2 intolerance and below anymore. To my knowledge, that has successfully been driven out of the ecosystem.

David

---

From: Yuhong Bao <[email-masked]>
Date: Tue, 7 Jun 2016 21:23:18 +0000

I hope that this fix is in the GDR branch now. TLS 1.2 is important.

________________________________
From: TLS <[email-masked]> on behalf of Andrei Popov <[email-masked]>
Sent: Tuesday, June 07, 2016 2:14:32 PM
To: David Benjamin; Yoav Nir; Hubert Kario
Cc: [email-masked]
Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]

Cheers,

Andrei

On Tue, Jun 7, 2016 at 5:06 PM Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:

>> I'm not sure this helps.
>> I've never installed a server that is version intolerant. TLS stacks
>> from OpenSSL, Microsoft,
>

That's surprising.

It's strange that this behavior would degrade for much newer versions of Windows that came out at a time where several browsers were already offering TLS 1.2. I wonder if it's just the FTP or also IIS.

David

---

From: Dave Garrett <[email-masked]>
Date: Tue, 7 Jun 2016 17:40:57 -0400

> has successfully been driven out of the ecosystem.

<insert sarcastic laughter here> ;)

Driven out of the higher traffic mainstream ecosystem, maybe, but there will be a long tail of junk servers that stay around for entirely too long (read: "forever"), in spite of current versions of clients not accepting it anymore. My tracking meta-bug in Mozilla's Bugzilla may have finally been closed last month, but that's just tickets filed by people who can actually get a report into the thing. Most people just see such brokenness as the browser's fault and switch to any (older) browser with compatible brokenness, and to any of us they're invisible.

The non-trivial population of servers that are TLS 1.0-1.2 version tolerant but not TLS 1.3+ version tolerant is a far more worrying problem, though.

Dave

---

From: Hubert Kario <[email-masked]>
Date: Wed, 08 Jun 2016 11:58:22 +0200

On Tuesday 07 June 2016 21:14:32 Andrei Popov wrote:
> Jumping to the end of the thread, it looks like this is an FTP issue
> that repros when TLS 1.2 is negotiated. Not a TLS version
> intolerance.
> The conclusion seems to be that
> https://support.microsoft.com/en-us/kb/2888853 resolves the issue, by
> updating FTP binaries. 
> Cheers,

yes that thing should be fixed now

that being said, I've seen reports that IIS 7.5 does support TLSv1.2 
while at the same time being intolerant to TLS 1.3 Client Hello.

Unfortunately I don't have access to a server that I'm certain is 
running IIS 7.5 that I could test this hypothesis with.

To continue my reply to Yoav, so just because we sometimes not see 
different intolerancies, doesn't mean they are not there. TLS library 
programmers do actively shape their Client Hello's to trigger as little 
issues as possible.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 9 Jun 2016 05:48:15 +0000

>and aims to be a comprehensive test suite

Very nice, just setting it up now.  One minor request, it'd be useful to have
a run-evening wrapper script that steps through each test reporting what's
happening, so first to a standard connec to make sure all is OK, then run the
various tests.  I'll hack toether a shell script in a minute, but having an
official way of doing it would be nice.

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Thu, 09 Jun 2016 11:43:57 +0200

On Thursday 09 June 2016 05:48:15 Peter Gutmann wrote:
> Very nice, just setting it up now.  One minor request, it'd be useful
> to have a run-evening wrapper script that steps through each test
> reporting what's happening, so first to a standard connec to make
> sure all is OK, then run the various tests.  I'll hack toether a
> shell script in a minute, but having an official way of doing it
> would be nice.

run _everything_ is not really possible as some tests actually require 
mutually exclusive server settings - e.g. some require the server not to 
ask for client certificate while others do

later in tests I've started adding a "sanity check" test case (see 
"test-certificate-verify.py"), but I didn't yet have time to do that for 
all

all in all, I won't hide that they are very rough, but this is not the 
intended user interface; the scripts are just proof-of-concept for the 
test engine, there will be two levels above it before the real user 
interface will come into play

finally, while I do look forward to any contributions (just ideas for 
tests would be huge help!) I do want the tool to be as platform 
independent as possible (require just Python runtime, be it 2.6, 3.5 or 
anything in-between), so if you do plan to write the script, may I ask 
you to do that in python too?
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 10 Jun 2016 05:31:06 -0400 (EDT)

I'm actually surprised you mention the microsoft servers as being 
version negotiation tolerant. They were the most prominent examples
of terminating the handshake if TLS 1.2 was offered to them (that 
was much time before TLS 1.2 was implemented in browsers).

regards,
Nikos

----- Original Message -----

That’s surprising.

Yoav

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 10 Jun 2016 18:11:12 -0400

On Friday, June 10, 2016, Nikos Mavrogiannopoulos <[email-masked]> wrote:

> of terminating the handshake if TLS 1.2 was offered to them
>

Personally I'd give that award to F5 BIG-IP devices

-- 
Tony Arcieri

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 13 Jun 2016 19:47:09 +0000

Hubert Kario <[email-masked]> writes:

>mutually exclusive server settings - e.g. some require the server not to ask
>for client certificate while others do

Ah, OK.

>finally, while I do look forward to any contributions (just ideas for tests
>would be huge help!) I do want the tool to be as platform independent as
>possible (require just Python runtime, be it 2.6, 3.5 or anything in-
>between), so if you do plan to write the script, may I ask you to do that in
>python too?

I don't really speak python, it was just a quick "for f in *.py do ... done",
I was just checking whether there was something less crude available.

Peter.

---

From: David Benjamin <[email-masked]>
Date: Wed, 29 Jun 2016 20:51:04 +0000

On Wed, Jun 1, 2016 at 6:57 PM Eric Rescorla <[email-masked]> wrote:

>> That sounds reasonable to me. I'd probably suggest still putting it at
>> the end since there's no reason to risk things, but I'm not aware of
>> anything that uses the client timestamp. (None of the clients I maintain
>> send it.)
>>
>
> Putting it at the end of the client gives the client options, so that
> would be fine.
>

To get this thread back on the original point, I put together a PR here for
the minimal change which just moves it to the end of server_random. This
would be sufficient to fix the problem which prevents today's 1.2 servers
from implementing 1.3.

https://github.com/tlswg/tls13-spec/pull/508

I don't particular care whether it's moved to the client or not. If you
think that's better, I'm happy to change it or defer to a different PR. (I
wasn't sure exactly what construction you were thinking for the
client_random version.)

David