
Enforcing TLS protocol invariants by rolling versions every six weeks - fanf2
https://www.ietf.org/mail-archive/web/tls/current/msg26385.html
======
niftich
This is part of Chrome's scheme to avoid protocol ossification -- where you
realize you can't deploy any enhancements because of widespread non-standards-
compliant (but likely, for the original implementer, "good enough") behavior.

The idea is to catch them early by simulating future versions now, which in
their belief is best done by perpetuating traffic that contains bullshit
versions on the wire. It's fairly clever, in that any implementer who doesn't
want to break significant portions of web traffic now must code their
implementation in a way that anticipates Chrome's future versions, which is
most sanely done by coding their implementation in a way that happens to match
what's in the spec. Meanwhile, noncompliant implementations will likely break
for a huge amount of users, causing widespread uproar and, presumably,
pressure to fix the problem.

Google's clients (e.g. Chrome, Android) and servers originate and receive a
high enough portion of traffic that they could pull this off on their own
without anyone else's buy-in, and still achieve the intended effect, but
they're reaching out to the community to build consensus. It's a hacky idea,
but one that backs noncompliant implementations into a corner now, instead of
them sticking around forever and causing incompatible changes later down the
road.

~~~
LoSboccacc
meanwhile who designed their stack properly enjoy running their software for
decades across multiple platforms without modifications.

I guess we just have to relearn all the lesson from the 80's

~~~
jaas
So if someone deployed SSLv3 when it was the secure version and left that
running for decades, you would describe this as proper and an ideal scenario
that we should strive for?

I sure hope that's not a lesson we learn in any decade.

~~~
LoSboccacc
only because the current mess forces network encryption to be enrolled within
the application at it's layer doesn't mean that's the ideal solution.

~~~
geofft
Er, one of the lessons from the '80s was the end-to-end principle.
Applications are the right place to handle encryption, and network encryption
solutions like IPsec are full of layering violations.

~~~
simias
Don't you think it ought to be handled by the kernel though? The same way TCP
is not handled in userland nowadays. It's a shame that every app has to
reinvent the wheel when it comes to crypto (even if most of them de-facto
standardize around a few library implementations). I wish SSL/TLS was just one
setsockopt away. You'd have one central point to handle certificate
authorities, exception, debugging etc...

~~~
geofft
Absolutely not - there's a ton of complexity in parsing certificates, checking
Certificate Transparency signatures, contacting OCSP responders, chasing
Authority Information Access references to intermediate certs (the latter two
immediately require having a full HTTP client), parsing name constraints, etc.
There are already too many ASN.1 decoders in my kernel and I don't want
another one. And I can upgrade my userspace libraries much more easily than I
can upgrade my kernel.

Importantly, the big reason for TLS to be at the endpoint and not use
IPsec/tcpcrypt/etc. is because the important thing to verify in TLS is the
hostname, not the IP address, and DNS resolution is in userspace everywhere
(as far as I know). You could imagine a design which pushed both DNS
resolution and TLS verification into the kernel, but it would be too
monolithic of a kernel for even UNIX's tastes.

TCP is a relatively simple protocol (in the sense that it doesn't have too
many moving parts, not in the sense that it's uninteresting) and fits fine in
the kernel. But even for reliable transport, there are plenty of apps using
their own thing over UDP (RTP, Mosh's SSP, QUIC, etc.) that are never going to
get into a kernel. And even for TCP alone there's a bunch of potential
complexity you can put into the kernel (DCTCP, New Reno, fq_codel, etc.) that
have been hard to deploy precisely because they require a kernel patch.

~~~
LoSboccacc
what has certificate management anything to do with communication encryption?

if you keep conflating responsibilities, you'll keep ending up with the same,
flawed, "solutions".

besides, everyone and their dog now has a "certificate" from the likes of
let's encrypt, so even their role as identity trust is basically moot.

~~~
geofft
> _what has certificate management anything to do with communication
> encryption?_

What's the point of encrypting something if you don't know who you're
encrypting to?

> _besides, everyone and their dog now has a "certificate" from the likes of
> let's encrypt, so even their role as identity trust is basically moot._

Yes, everyone should have a certificate, and I'm not sure why you think this
means "identity trust" isn't working. Certificates mean that you probably are
who you say you are. They don't mean that you're a good person.

------
marshray
Never expect old code to handle new protocol elements. If it's not exercised
regularly, it's not going to work.

Very few developers (outside of Google) are going to write randomized fuzzers
to test for compatibility with theoretical future extensions. They're going to
test that it works with existing stuff and then ship it.

So, the fuzzing has got to become part of the public ecosystem.

~~~
Narkov
Why can't you code you implementation to safely ignore new protocol elements?
They aren't asking you to support the new elements, just ignore them.

~~~
namibj
You can. But who is going to make sure you don't skip this part and make more
profit than your competitor?

~~~
pdkl95
Anybody that doesn't want to introduce crashing/fatal bugs that disrupt
productivity? Skipping checks[1] and making assumptions about input[2] is an
irresponsible disregard for basic security.

This is about basic programmer competence, not time a consuming feature that
might impact your development costs relative to your competitor. You are not
going to make more profit by leaving out the "default:" case to your
switch/case statements that skips parsing for unrecognized elements.

[1]
[https://archive.org/details/The_Science_of_Insecurity_](https://archive.org/details/The_Science_of_Insecurity_)

[2] [https://media.ccc.de/v/31c3_-_5930_-_en_-
_saal_6_-_201412291...](https://media.ccc.de/v/31c3_-_5930_-_en_-
_saal_6_-_201412291400_-_funky_file_formats_-_ange_albertini)

~~~
caf
The problem isn't leaving out the 'default' case. The problem is coding it as

    
    
      default:
          return DROP_CONNNECTION_AND_BAIL;

~~~
pdkl95
Yes, which is why I really like the idea of proactive enforcement with random
expected-to-be-ignored tags/parameters. I'm arguing against the idea that
leaving out the last part of this

    
    
        for (item = params->head; item; item = item->next) {
            switch (item->type) {
            case KNOWN_PARAM_TYPE_FOO:
                // do normal stuff
                break;
    
            /* ... etc ... */
    
            IGNORE_KNOWN_PARAM_TYPE_BAR:
                // fallthrough - BAR explicitly uses default handling
            default:
                continue;  // skip unknown parameters
            }
        }
    

is evidence of incompetence, not a strategy that will "make more profit than
your competitor".

Also, as the BAR constant suggests, you probably already have code that skips
unrelated fields. While the difference in programmer time is almost always
trivially small, sometimes it might be _zero_.

~~~
mathw
Unfortunately incompetence can sometimes lead to increased profits in the
short term. Why else is there so much horrendous software out there?

------
Analemma_
I think that middleware boxes will still find some way to make our lives
miserable next time we try to upgrade— this seems like another instance of
"build an idiot-proof system, and the universe will just supply a better
idiot"— but this is still a great idea. This is so good I want to start doing
it with my company's internal stuff.

~~~
tialaramex
Company internal stuff generally isn't facing as hostile an environment as
HTTPS.

The famous "Alice and Bob After Dinner Speech" mentions

"Now most people in Alice's position would give up. Not Alice. She has courage
which can only be described as awesome. Against all odds, over a noisy
telephone line, tapped by the tax authorities and the secret police, Alice
will happily attempt, with someone she doesn't trust, whom she cannot hear
clearly, and who is probably someone else, to fiddle her tax returns and to
organize a coup d'etat, while at the same time minimizing the cost of the
phone call.

A coding theorist is someone who doesn't think Alice is crazy."

HTTPS is like Alice. In cryptography a theoretical attacker is often given
seemingly outrageous abilities, like they can send you huge numbers of
arbitrary messages to see what happens, they can time everything, they can see
messages you were sending and try sending other messages that are just a tiny
bit different, they can collect your messages and re-send them later, and so
on. In many systems a real attacker would struggle to pull these things off,
but in HTTPS thanks to things like cookies and Javascript it's actually not
difficult at all.

Your internal stuff almost certainly doesn't have arbitrary clients running
code from arbitrary other participants like the Web does. It also almost
certainly doesn't have a dedicated reliability team who can go change
everything every six weeks to keep up. If you do such changes every six weeks
for a few months, then get bored and stop, the last set rust shut and you've
gained nothing. Google is essentially promising their teams would undertake to
carry on indefinitely.

Google essentially proposes an artificial Red Queen's Race, with the goal
being to tire out middlebox vendors and/or their customers and have them
choose to exit the race.

~~~
chadnickbok
I hadn't heard of Red Queen's Race before, and your use of it in a somewhat
novel way was awesome. That was 15 minutes well wasted.

------
_old_dude_
You have the same kind of idea in the JDK to be sure that a user code does not
work if it relies on the iteration order of an immutable Set, the JDK use a
SALT [1] so the iteration order of the Set is different each time you start a
new VM allowing the code of the JDK to be changed in the future.

[1]
[http://hg.openjdk.java.net/jdk/jdk/file/f36d08a3e700/src/jav...](http://hg.openjdk.java.net/jdk/jdk/file/f36d08a3e700/src/java.base/share/classes/java/util/ImmutableCollections.java#l56)

~~~
ec109685
Salt is mostly there to prevent attackers that control program input from
exploiting the hashing algorithm to construct pathological worse case datasets
(e.g. ensuring every input hashes to same bucket).

------
tialaramex
Context:

1\. So called "Security" companies (middlebox vendors) advise customers to
write what are effectively firewall rules that bake ossification into their
systems using, I kid you not, regular expressions

[https://www.fidelissecurity.com/threatgeek/2018/02/exposing-...](https://www.fidelissecurity.com/threatgeek/2018/02/exposing-x509-vulnerabilities)

This type of nonsense is why one of the optional TLS 1.3 features is
certificate compression. It seems like a no-brainer to offer this for earlier
versions, but it turns out that middleboxes snoop the certificate and make
decisions about it so compressing it causes them to freak out. Why can we
(hopefully) fix that with an optional extension in TLS 1.3? Because in TLS 1.3
now the certificate is encrypted, so the middleboxes can't see it in the first
place.

2\. In about 2016 when it originally looked like TLS 1.3 was almost finished,
the middlebox vendors finally noticed something was happening and began
yelling about how their products had "legitimate" ‡ uses that would be blocked
by these improvements and it all needed re-thinking.

Fortunately (or perhaps inevitably) the middlebox vendors have no idea how the
IETF works, so they spent a lot of effort on trying to "win votes" which
should have anybody who was somehow unaware of this drama but involved with
the IETF smiling since there are no votes and you can't win. They also, like
typical business people, figured they could fly in to meetings in say,
Singapore or London, and spin up at the meeting, but of course those meetings
are just a temporary physical incarnation of the IETF, it exists all the time
as mailing lists, so if you aren't following those lists you're basically
always a kid who wandered into a room where people are having grown-up
discussions you can't understand.

3\. After a surprisingly long time the middlebox vendors got the hint and went
to ETSI to make their own alternative. ETSI is a traditional SDO which is
perfectly happy to work on a standard without any messy ethical
considerations. It is also, like most traditional SDOs, closed door, so we
have only limited visibility of what they're up to. So far it looks like TLS
1.2 (so, bad) but with the ability for an arbitrary number of middleboxes to
interact with all the packets on path (so, worse).

It's OK though because under their ETSI proposal the user will "Consent" to
this. If you've spent the last month mindlessly clicking through GDPR-inspired
boxes on US web sites you regularly visit, or indeed if you're the new hire
who has just this moment realised why the big boss decided he needed her with
him on this trip, and is now calculating whether to say "No" and risk losing
everything or to close her eyes and pretend this is happening to somebody else
you have a very good idea what "Consent" means in this context.

‡ "Legitimate" is a word you use when it's important for people to accept that
what you're doing is OK, without them thinking about what you were actually
doing because they might throw up. "Bribe officials to ignore flagrant safety
violations" makes you angry but "Legitimate facilitation payment" sounds very
respectable.

------
yuhong
Personally, I understood when the ClientHello was changed to deal with TLS
version intolerant servers, but disliked the middlebox changes in the
ServerHello.

------
tlb
Interesting idea, but why inflict this churn on all Chrome users? Just make a
standalone client that runs through all possible variations so that server
developers can test against it.

~~~
kkirsche
Companies like Symantec implementing devices like Bluecoat proxies are
notorious for not doing their due diligence on their network stack. This
ensures that it’s actually tested against devices and has the support of users
to be fixed rather than a few developers who won’t be able to move the needle.
At least that’s how I read this

------
forapurpose
I'm surprised that nobody is concerned that Google (or whoever) is spamming
the Internet to make everyone do what Google / TLS devs want them to do.

First, it's coercive. Second, it's in principle spam, even if the cost is
affordable in this case. Third, it sets three bad precedents:

* Google can do whatever they want

* Hijacking user computers for ulterior purposes (by utilizing Chrome) is ok

* Spam and coercion are ok. And if you argue it's ok in this instance, you aren't thinking past your nose.

Imagine if Symantec or Microsoft tried it; how would people react? Well you
don't have to wonder, because they will.

~~~
tptacek
You have to really want an anti-Google story to find it in this, the bit where
Google is using its market position on the server and clientside _to help make
sure vendors don 't break the TLS standard_.

~~~
forapurpose
What about the second precedent in the GP, and what about my point, _if you
argue it 's ok in this instance ..._?

~~~
staticassertion
Would you argue against Chrome sending out random LLMNR requests at boot to
detect attackers on the network? They aren't "hijacking" computers of users
who voluntarily installed chrome - in part due to the promise of a safer
browsing experience, which this is all about.

~~~
forapurpose
> Would you argue against Chrome sending out random LLMNR requests at boot to
> detect attackers on the network?

Good question.

No, I wouldn't, because it serves that user directly. Google could argue that
the TLS 'GREASE' benefits users, but that benefit, and let's assume it exists,
is very indirect: That user won't see any benefit that day, that week, and
maybe never; Google is using their users' computers to advocate something that
Google thinks is a good idea. To demonstrate GREASE can be taken too far,
imagine the extreme case where Google has Chrome send messages to U.S.
Congresspeople advocating against some policy - Google could argue that they
believe it's in the users' interests, but that would be highly disingenuous.
Again, that's extreme and not going to happen.

More realistically, imagine Microsoft had Windows 10 insert something in
network traffic to compel compatibility with some proprietary technology of
theirs. Imagine vendors disagreed about some standard, and different products
used GREASE to compete for different outcomes.

Where do you draw the line? I think GREASE violates end-user control or
autonomy. They become pawns in a standards competition. It's very arrogant of
Google and support of it betrays an arrogance perspective here at HN: users
are pawns, and their computers are ours to use as we see fit. (It's also
intentionally bad engineering, which makes me very uncomfortable.)

~~~
staticassertion
I disagree with the idea that users won't see benefits - the benefit is that
upgrades to a critical protocol can be rolled out more smoothly in the face of
compliant middleware. This benefit will be significant for end users.

Sending messages to Congress would be very different - that's squarely outside
of the purview of a browser. TLS is not.

As for Microsoft having Windows 10 insert things to support a proprietary
technology, again, this is a flawed analogy - it's simply not what's happening
here.

Why draw the line if we know that we haven't crossed it? You have put forth
two cases that seem obviously on the other side. This case seems obviously on
the 'we good' side.

Would you say A/B testing means 'users are pawns'? I really disagree with
that. Again, this is all in the interest of end users who have voluntarily
installed this software, at least in part because of the secure reputation.

