[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

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

[Yoav Nir]

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

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

[Hubert Kario]

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

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

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

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

[David Benjamin]

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

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

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


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

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

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

[Viktor Dukhovni]

> On Jun 2, 2016, at 10:49 AM, David Benjamin  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.

___
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] Downgrade protection, fallbacks, and server time

[David Benjamin]

On Thu, Jun 2, 2016 at 10:59 AM Viktor Dukhovni 
wrote:

>
> > On Jun 2, 2016, at 10:49 AM, David Benjamin 
> 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.


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

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

[Hubert Kario]

On Thursday 02 June 2016 14:49:52 David Benjamin wrote:
> On Thu, Jun 2, 2016 at 6:40 AM Hubert Kario  wrote:
> > 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.)
> > > 
> > > 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.
> > 
> > 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...
> 
> 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.

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

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

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

-- 
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] Downgrade protection, fallbacks, and server time

[David Benjamin]

On Thu, Jun 2, 2016 at 11:20 AM Hubert Kario  wrote:

> > > 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...
> >
> > 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.
>
> 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
>
>
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
___
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] Downgrade protection, fallbacks, and server time

[Viktor Dukhovni]

> On Jun 2, 2016, at 11:16 AM, David Benjamin  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.

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

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

[Dave Garrett]

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]

[Xiaoyin Liu]

I strongly support this proposal.

Best,
Xiaoyin



From: Dave Garrett
Sent: Friday, June 3, 2016 12:17
To: tls@ietf.org
Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, 
and server time]

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