Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Tony Arcieri]

On Friday, June 10, 2016, Nikos Mavrogiannopoulos  wrote:

> 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
>

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


-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Jeffrey Walton]

>> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Hubert Kario]

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...

-- 
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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Bill Frantz]

On 6/3/16 at 2:28 AM, hka...@redhat.com (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


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Dave Garrett]

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


On Friday, June 03, 2016 02:19:52 pm David Benjamin wrote:
> 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.
> 
> On Fri, Jun 3, 2016 at 1:40 PM Viktor Dukhovni 
> wrote:
> 
> > On Fri, Jun 03, 2016 at 06:39:58AM -0700, Eric Rescorla wrote:
> > > 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.
> >
> > 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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[David Benjamin]

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.

On Fri, Jun 3, 2016 at 1:40 PM Viktor Dukhovni 
wrote:

> On Fri, Jun 03, 2016 at 06:39:58AM -0700, Eric Rescorla wrote:
>
> > 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.
>
> 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.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Viktor Dukhovni]

On Fri, Jun 03, 2016 at 06:39:58AM -0700, Eric Rescorla wrote:

> 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.

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Eric Rescorla]

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

-Ekr


On Fri, Jun 3, 2016 at 10:28 AM, Andrei Popov 
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:tls-boun...@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Friday, June 3, 2016 6:40 AM
> *To:* Dave Garrett 
> *Cc:* tls@ietf.org
> *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 
> 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)
>
> 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
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Andrei Popov]

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:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Friday, June 3, 2016 6:40 AM
To: Dave Garrett 
Cc: tls@ietf.org
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 
> 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)

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Eric Rescorla]

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  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)
>
> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Hubert Kario]

On Friday 03 June 2016 07:39:06 Xiaoyin Liu wrote:
> > Date: Fri, 3 Jun 2016 11:33:54 +0300
> > From: ilariliusva...@welho.com
> > To: tls@ietf.org
> > Subject: Re: [TLS] no fallbacks please [was: Downgrade protection,
> > fallbacks, and server time]> 
> > On Fri, Jun 03, 2016 at 08:37:34AM +0200, Nikos Mavrogiannopoulos 
wrote:
> > > 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.
> > 
> > Well, AFAIK, in current editor's draft, key_share or pre_shared_key
> > is always present and none are meaningful in TLS.1.2.
> 
> 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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Xiaoyin Liu]

> Date: Fri, 3 Jun 2016 11:33:54 +0300
> From: ilariliusva...@welho.com
> To: tls@ietf.org
> Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, 
> and server time]
> 
> On Fri, Jun 03, 2016 at 08:37:34AM +0200, Nikos Mavrogiannopoulos wrote:
> 
> > 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.
> 
> Well, AFAIK, in current editor's draft, key_share or pre_shared_key
> is always present and none are meaningful in TLS.1.2.
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
  ___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Hubert Kario]

On Friday 03 June 2016 08:37:34 Nikos Mavrogiannopoulos wrote:
> 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.

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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Nikos Mavrogiannopoulos]

On Fri, 2016-06-03 at 00:17 -0400, Dave Garrett 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/058ff1518508b094b8c9
> f1bd4096be9393f20076
> (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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Martin Thomson]

On 3 June 2016 at 01:07, David Benjamin  wrote:
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Hubert Kario]

On Thursday 02 June 2016 15:22:03 David Benjamin wrote:
> On Thu, Jun 2, 2016 at 11:07 AM David Benjamin 
> wrote:
> > On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario  
wrote:
> >> On Thursday 02 June 2016 11:39:20 Yoav Nir wrote:
> >> > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos
> >> > >  wrote:>
> >> > > 
> >> > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote:
> >> > >> 2% is actually pretty good, but I agree that we're going to
> >> > >> need
> >> > >> fallback.
> >> > > 
> >> > > 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.
> >> > 
> >> > 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?
> >> 
> >> 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 already do that, by the way. That's exactly what
> 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
"""

-- 
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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Hubert Kario]

On Thursday 02 June 2016 15:07:53 David Benjamin wrote:
> On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario  wrote:
> > On Thursday 02 June 2016 11:39:20 Yoav Nir wrote:
> > > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos
> > > >  wrote:>
> > > > 
> > > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote:
> > > >> 2% is actually pretty good, but I agree that we're going to
> > > >> need
> > > >> fallback.
> > > > 
> > > > 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.
> > > 
> > > 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?
> > 
> > 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

-- 
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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[David Benjamin]

On Thu, Jun 2, 2016 at 11:07 AM David Benjamin 
wrote:

> On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario  wrote:
>
>> On Thursday 02 June 2016 11:39:20 Yoav Nir wrote:
>> > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos
>> > >  wrote:>
>> > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote:
>> > >> 2% is actually pretty good, but I agree that we're going to need
>> > >> fallback.
>> > >
>> > > 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.
>> >
>> > 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?
>>
>> 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 already do that, by the way. That's exactly what
ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION in Chrome is.)


> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[David Benjamin]

On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario  wrote:

> On Thursday 02 June 2016 11:39:20 Yoav Nir wrote:
> > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos
> > >  wrote:>
> > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote:
> > >> 2% is actually pretty good, but I agree that we're going to need
> > >> fallback.
> > >
> > > 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.
> >
> > 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?
>
> 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.

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Hubert Kario]

On Thursday 02 June 2016 11:39:20 Yoav Nir wrote:
> > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos
> >  wrote:> 
> > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote:
> >> 2% is actually pretty good, but I agree that we're going to need
> >> fallback.
> > 
> > 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.
> 
> 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?

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

-- 
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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Nikos Mavrogiannopoulos]

On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote:
> 2% is actually pretty good, but I agree that we're going to need
> fallback.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls