Subject: [TLS] Suspicious behaviour of TLS server implementations

From: "Andreas Walz" <[email-masked]>
Date: Fri, 09 Sep 2016 16:23:52 +0200

Dear all,

we are working on an approach/framework for testing TLS implementations (currently only servers, but clients are planned for the future as well). While running our tests against a bunch of different TLS (server) implementations, we found several types of suspicious behaviour (see below). As the TLS specification left me with doubts on what the correct behaviour should be, I'd like to raise this questions here (please let me know if this is not the appropriate place or this has been answered before).

(1) Several server implementations seem to ignore the list of proposed compression methods in a ClientHello and simply select null compression even if that has not been in the ClientHello's list. The specification is rather clear that null compression MUST be part of the list. However, I'm not aware of any clear statement about what a compliant server should do in case it receives a ClientHello without null compression. My best guess would have been that in such cases the server should abort the handshake (at least if it does not support whatever the client proposed).

(2) In a ClientHello several server implementations don't ignore data following the extension list. That is, they somehow seem to ignore the length field of the extension list and simply consider everything following the list of compression methods as extensions. Aside from this certainly being a deviation from the specification, I was wondering whether a server should silently ignore data following the extension list (e.g. for the sake of upward compatibility) or (as one could infer from RFC5246, p. 42) send e.g. a "decode_error" alert.

(3) If a ClientHello contains multiple extensions of the same type, several server implementations proceed with the handshake (even if they parse these specific extensions). The specification again is clear that "there MUST NOT be more than one extension of the same type". However, what should a server do in case there are? Again, my guess would be that it should abort the handshake. Should this also be the case for extensions that a server simply ignores (as it e.g. doesn't know them)?

Thank you very much.

Cheers,
Andi

---

From: [email-masked] (Martin Rex)
Date: Fri, 9 Sep 2016 17:29:01 +0200 (CEST)

My personal take on your questions:

Andreas Walz wrote:
> 
> (1) Several server implementations seem to ignore the list of proposed
> compression methods in a ClientHello and simply select null compression
> even if that has not been in the ClientHello's list.

Sounds like reasonable behaviour (improving interop) which does not cause
any security issues.

>
> The specification is rather clear that null compression MUST be part of
> the list.  However, I'm not aware of any clear statement about what a
> compliant server should do in case it receives a ClientHello without
> null compression. My best guess would have been that in such cases the
> server should abort the handshake (at least if it does not support
> whatever the client proposed).

The requirement is about the Client.  The Server behaviour is un(der)specifed.
The server choosing null compression anyway and continuing looks pretty
reasonable to me (least amount of code, so the safest to implement).

Aborting by the server would be OK with the specification, but not
necessarily reasonable.  Consider that there was a time when compression
within TLS was available and widely used.  A server that wanted and would
use TLS compression when offered would behave sort-of unrational when
complaining about an absence of a compression method it does not intend
to use (in presence of the compression method it wants to use).

The actual problem is the design flaw in TLS that availability of 
null compression is not implied, but rather given a seperate codepoint,
and the server choosing null compression and continuing even when it
is not explicitly asserted by the client, is a server silently making up
for that design flaw in the TLS spec.

> 
> (2) In a ClientHello several server implementations don't ignore data
> following the extension list. That is, they somehow seem to ignore the
> length field of the extension list and simply consider everything
> following the list of compression methods as extensions.  Aside from this
> certainly being a deviation from the specification, I was wondering
> whether a server should silently ignore data following the extension
> list (e.g. for the sake of upward compatibility) or (as one could infer
> from RFC5246, p. 42) send e.g. a "decode_error" alert.

Up to TLSv1.2, TLS extensions were purely optional, so an implementation
that unconditionally ignores everything following compression methods is
at least fully conforming to SSLv3, TLSv1.0 and TLSv1.1.

For an TLS implementation that parses TLS extensions, the behaviour of
what to do about trailing garbage is a different matter.  Personally
I prefer aborting in case of garbage trailing TLS extensions.

When I looked at OpenSSL's implemenation of the extensions parser a few
years ago, I noticed that it was ignoring (I believe up to 3) trailing bytes.
(the shortest possible TLS extension is 4 bytes).

>
> (3) If a ClientHello contains multiple extensions of the same type,
> several server implementations proceed with the handshake (even if they
> parse these specific extensions). The specification again is clear that
> "there MUST NOT be more than one extension of the same type".
> However, what should a server do in case there are? Again, my guess
> would be that it should abort the handshake. Should this also be the
> case for extensions that a server simply ignores (as it e.g. doesn't
> know them)?

What the server does in presence of multiple TLS extensions of the same type
is implementation defined.  I think it would be extremely reasonable for a
server to perform a simple plausibility check on decode whether it is decoding
the same TLS extension more than once, and then abort with a decode_error
alert, in order to have ambiguities caught early.
Recognizing duplicate TLS extensions that the server does not
support/implement does not (yet) create ambiguities (for that server)
and requires more complex code, so I would not implement that check.

-Martin

---

From: Martin Thomson <[email-masked]>
Date: Sat, 10 Sep 2016 20:38:52 +1000

I think that Martin (R) provided you with the answers I would have.

Have you filed bugs against the servers in question for the issues
that you have seen?

On 10 September 2016 at 00:23, Andreas Walz
<[email-masked]> wrote:
> Dear all,
>
> we are working on an approach/framework for testing TLS implementations
> (currently only servers, but clients are planned for the future as well).
> While running our tests against a bunch of different TLS (server)
> implementations, we found several types of suspicious behaviour (see below).
> As the TLS specification left me with doubts on what the correct behaviour
> should be, I'd like to raise this questions here (please let me know if this
> is not the appropriate place or this has been answered before).
>
> compression methods in a ClientHello and simply select null compression even
> if that has not been in the ClientHello's list. The specification is rather
> clear that null compression MUST be part of the list. However, I'm not aware
> of any clear statement about what a compliant server should do in case it
> receives a ClientHello without null compression. My best guess would have
> been that in such cases the server should abort the handshake (at least if
> it does not support whatever the client proposed).
>
> length field of the extension list and simply consider everything following
> the list of compression methods as extensions. Aside from this certainly
> being a deviation from the specification, I was wondering whether a server
> should silently ignore data following the extension list (e.g. for the sake
> of upward compatibility) or (as one could infer from RFC5246, p. 42) send
> e.g. a "decode_error" alert.
>
> (3) If a ClientHello contains multiple extensions of the same type, several
> server implementations proceed with the handshake (even if they parse these
> specific extensions). The specification again is clear that "there MUST NOT
> be more than one extension of the same type". However, what should a server
> do in case there are? Again, my guess would be that it should abort the
> handshake. Should this also be the case for extensions that a server simply
> ignores (as it e.g. doesn't know them)?
>
> Thank you very much.
>
> Cheers,
> Andi
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Andreas Walz" <[email-masked]>
Date: Mon, 12 Sep 2016 07:58:17 +0200

Hi,

thanks for your detailed answers. Yes, we are in contact with the developers of the implementations in question and fixes are going to be implemented. I just wanted to get an idea of what is considered the correct or at least most appropriate behaviour in each case.

Thanks and Cheers

>>> Martin Thomson <[email-masked]> 10.09.16 12.39 Uhr >>>

---

From: Hubert Kario <[email-masked]>
Date: Mon, 12 Sep 2016 18:56:12 +0200

> (currently only servers, but clients are planned for the future as well).

are you aware of the tlsfuzzer framework?
https://github.com/tomato42/tlsfuzzer

> e.g. a "decode_error" alert.

It is explicit in RFC 3546, section 2.1:
https://tools.ietf.org/html/rfc3546#section-2.1

   A server that supports the extensions mechanism MUST accept only
   client hello messages in either the original or extended ClientHello
   format, and (as for all other messages) MUST check that the amount of
   data in the message precisely matches one of these formats; if not
   then it MUST send a fatal "decode_error" alert.  This overrides the
   "Forward compatibility note" in [TLS].

-- 
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: Wed, 14 Sep 2016 11:38:31 +0000

Martin Rex <[email-masked]> writes:

>The actual problem is the design flaw in TLS that availability of null
>compression is not implied, but rather given a seperate codepoint, and the
>server choosing null compression and continuing even when it is not
>explicitly asserted by the client, is a server silently making up for that
>design flaw in the TLS spec.

Yup, and I'd say it's perfectly valid behaviour.  Compression is an optional
extra, but you need to explicitly specify that you don't want it, something
that's popular in the PKI world where you have a supposedly optional
capability that isn't actually optional so you need to fill it with a dummy
value to indicate that you don't care about it.

>Up to TLSv1.2, TLS extensions were purely optional, so an implementation that
>unconditionally ignores everything following compression methods is at least
>fully conforming to SSLv3, TLSv1.0 and TLSv1.1.
>
>For an TLS implementation that parses TLS extensions, the behaviour of what
>to do about trailing garbage is a different matter.  Personally I prefer
>aborting in case of garbage trailing TLS extensions.

My code checks for extensions all the way down, but I could quite easily be
persuaded that ignoring trailing garbage is OK too, based on what earlier
versions of TLS did.  Like RFC 3546 originally did for extensions, some future
RFC might add a new field at the end, so not failing on finding more data may
be a good thing.  Or at least I can't see why it would be a bad thing.

>server to perform a simple plausibility check on decode whether it is
>decoding the same TLS extension more than once, and then abort with a
>decode_error alert, in order to have ambiguities caught early. Recognizing
>duplicate TLS extensions that the server does not support/implement does not
>(yet) create ambiguities (for that server) and requires more complex code, so
>I would not implement that check.

+1.  Remembering that you've already done a known extension is one thing, but
having to track a potentially arbitrary number of extensions that you don't
know what to do with anyway doesn't seem worthwhile.  And then there's the
same problem as with ignoring extra data at the end of the hello, at some
point a future RFC may define an extension where having duplicate copies makes
sense or is even required for things to work.  So you don't really gain
anything by ignoring duplicate unknown extensions, and will potentially break
things in the future if you do reject them.

Having said that, some extensions are purely signalling extensions, like EMS
and EtM.  I'm not sure if there's any problem with accepting doubles of those,
it could just be the other side being emphatic.  Consider how you'd need to
report this to the user, "shut down the TLS connection because I saw two
copies of some extension you've never heard of before", you can imagine what a
user who sees that would think of the anal-retentive &^@#* who added special
code to the handshake in order to reject it if this condition is encountered.

Peter.

---

From: "Andreas Walz" <[email-masked]>
Date: Wed, 14 Sep 2016 15:35:16 +0200

Hi,

>>> Hubert Kario <[email-masked]> 09/12/16 6:56 PM >>>

@Hubert Kario: Thanks for pointing me to tlsfuzzer. I had a look at the repository before and I skimmed through the code. However, I didn't run the code and I don't know details about the way it is generating input. Is there some paper or presentation about it? 

>>> Peter Gutmann <[email-masked]> 09/14/16 1:39 PM >>>

@Peter Gutmann: Thanks for your take on that. Actually, and I might easily be missing something here, I do see some issues with adding new fields to the ClientHello in the future (i.e. following the "client_hello_extension_list"). As far as I can see, there is no way within a ClientHello to convey some kind of a version of the ClientHello format itself (as the ClientHello's version field is just indicating the highest version the client supports). That is, the only mechanism I see here is the same as the one that allowed to add extensions to a ClientHello message with RFC3546. However, that door has explicitly been closed therein in section 2.1 (as Hubert Kario pointed out)

A similar statement is given in RFC5246, section 7.4.1.2.:

    A server MUST accept ClientHello
    messages both with and without the extensions field, and (as for all
    other messages) it MUST check that the amount of data in the message
    precisely matches one of these formats; if not, then it MUST send a
    fatal "decode_error" alert.

Thus, to my understanding, any new field in the ClientHello would automatically break backward compatibility (at least with older compliant servers or unless everyone explicitly skips a MUST check in the interest of forward compatibility).

___________________________________

Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics (ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany

>>> Peter Gutmann <[email-masked]> 09/14/16 1:39 PM >>>

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 14 Sep 2016 16:02:42 +0200

On Wednesday, 14 September 2016 15:35:16 CEST Andreas Walz wrote:
> @Hubert Kario: Thanks for pointing me to tlsfuzzer. I had a look at the
> repository before and I skimmed through the code. However, I didn't run the
> code and I don't know details about the way it is generating input. Is
> there some paper or presentation about it?

there are presentation slides in the docs/ directory

Decision which messages are to be generated is done using scenarios that 
describe conversations between client and server. See in scripts/ for them; a 
simple example is scripts/test-conversation.py while an example of negative 
test would be scripts/test-early-application-data.py

in tlsfuzzer/messages.py is the code that generates the messages, client hello 
is here:
https://github.com/tomato42/tlsfuzzer/blob/master/tlsfuzzer/messages.py#L306

Example of a test case you were asking about (the one with data extending past 
extensions) would be scripts/test-truncating-of-client-hello.py

The messages themselves are generated through a combination of sensible 
defaults and "guessing" expected values by inspecting already exchanged 
messages (think TLS state machine that explicitly has support for any state 
transitions).

In general, it allows you to both negotiate connections and send arbitrary 
messages (through changing their order, modifying them pre or post encryption, 
or sending raw values). In particular, it does support renegotiation despite 
the the fact that the underlying tls library doesn't.
-- 
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: "Andreas Walz" <[email-masked]>
Date: Wed, 21 Sep 2016 09:21:10 +0200

Dear all,

sorry for bringing up this thread again. We were doing some further studies with TLS implementations (all TLS 1.2) for embedded systems and found more cases where, within substructures of handshake messages, trailing data without any associated field in the specification is *not* rejected. One example is the "Supported Elliptic Curves Extension" [RFC4492]:

struct {
    NamedCurve elliptic_curve_list<1..2^16-1>;
} EllipticCurveList;

which is parsed as if there was an additional field "trailing" absorbing all remaining data:

struct {
    NamedCurve elliptic_curve_list<1..2^16-1>;
    opaque trailing[];
} EllipticCurveList;

(There are various other places where this happens.)

I must say I'm having hard times finding any rationale behind ignoring such data rather than rejecting it (and aborting the handshake). In fact, most implementations do reject such messages and send a "decode_error" alert.

Do you see any argument why ignoring such trailing data would be acceptable (or even desirable)?

Thanks again and Cheers,
Andi Walz

Andreas Walz
Research Engineer

>>> "Andreas Walz" <[email-masked]> 09/14/16 4:20 PM >>>
Hi,

Andreas Walz
Research Engineer

Peter.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Sep 2016 17:25:11 +1000

> Do you see any argument why ignoring such trailing data would be acceptable

No.

Well, we exploited that to add extensions to the protocol once, so I
won't categorically rule it out, but in the case of
supported_groups/supported_curves, no good can come of ignoring
rubbish.  Of course, it's hard to point to this being harmful as well
:)

---

From: "Andreas Walz" <[email-masked]>
Date: Wed, 21 Sep 2016 11:45:15 +0200

Ok, thanks. This is close to my sense of it. Actually, I wasn't aware of the fact that
 the TLS 1.3 draft now  explicitly addresses this in the Presentation Language section:

     "Peers which receive a message which cannot be parsed according to the syntax
     (e.g., have a length extending beyond the message boundary or contain an
     out-of-range
length) MUST terminate the connection with a "decoding_error" alert."

Cheers,
Andi

>>> Martin Thomson <[email-masked]> 09/21/16 9:25 AM >>>

No.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 21 Sep 2016 12:30:55 +0200

On Wednesday, 21 September 2016 11:45:15 CEST Andreas Walz wrote:
> Ok, thanks. This is close to my sense of it. Actually, I wasn't aware of the
> fact that the TLS 1.3 draft now  explicitly addresses this in the
> Presentation Language section:
> 
>      "Peers which receive a message which cannot be parsed according to the
> syntax (e.g., have a length extending beyond the message boundary or
> contain an out-of-range

technically TLSv1.2 also is like this, it's just not explicit. All the 
messages and structures must match their definitions exactly, that means any 
kind of trailing data is an encoding error and as such should cause connection 
abort.

at least in theory if implementation does not reject such malformed fields or 
messages, it may be possible to trick it into talking with a different 
protocol that just happens to be parseable as TLS. Multiple checks on self-
consistency of messages make that unlikely.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 21 Sep 2016 15:53:33 +0000

Andreas Walz <[email-masked]> writes:

>Actually, I wasn't aware of the fact that the TLS 1.3 draft now explicitly
>addresses this in the Presentation Language section:
>
>  contain an out-of-range length) MUST terminate the connection with a
>  "decoding_error" alert."

And how many implementations are going to do this?  Consider the error-message
litmus test I proposed earlier, reasons for failing to connect to (say)
amazon.com:

  Error: Couldn't connect to Amazon because its certificate isn't valid.
  
  Error: Couldn't connect to Amazon because no suitable encryption was
         available.

  Error: Couldn't connect to Amazon because <explanation for 
         decoding_error alert>.

What would you put for the explanation for this case?  And if you say "decode
error" the user's response will be to switch to some less buggy software that
doesn't have problems connecting.

If you're writing a strict validating protocol parser than disconnecting in
this case is a valid response, but if it's software that will be used by
actual humans then failing a connect based on something like this makes no
sense.

Peter.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 21 Sep 2016 19:12:39 +0300

> doesn't have problems connecting.

Well, valid response...
 
> actual humans then failing a connect based on something like this makes no

decode_error only happens if either end is buggy (the receiver parsing
can also be buggy), or if data is corrupted in transport.

It is meant for errors where length of something is wrong (and such
errors would likely be non-recoverable anyway)..

-Ilari

---

From: "Andreas Walz" <[email-masked]>
Date: Wed, 21 Sep 2016 19:32:56 +0200

>>> Peter Gutmann <[email-masked]> 21.09.16 17.54 Uhr >>>

> actual humans then failing a connect based on something like this makes no

Wouldn't this argument apply to any "decode_error"?

Andi

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Sep 2016 09:54:02 +1000

You describe the observation that leads to Postel's maxim, namely that
if you found the internet in a mess when you got there, then you have
to be tolerant of rubbish.

The advantage with deploying a new protocol is that you can be strict.
If, for example, all of the browsers implement TLS 1.3 and are strict,
then Amazon won't be able to deploy a buggy 1.3 implementation without
noticing pretty quickly.  You might suggest that that's aspiration to
the point of delusion, but in fact it worked out pretty well with
HTTP/2 deployment.  We didn't squash ALL of the nasty bugs, but we got
most of them.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 22 Sep 2016 05:00:07 +0000

>Wouldn't this argument apply to any "decode_error"?

Nope.  There's a big difference between "I can't continue" and "I can 
continue without any problems but don't want to".  The example I gave of
"Couldn't connect to Amazon because no suitable encryption was available"
would be the error message to display in the case of a decode error that
garbled the cipher suites, an "I can't continue" condition.  The current
thread starter was a case of "I can continue without any problems but don't
want to", which pretty much any user of the product will perceive as a buggy
product, meaning they'll drop it and switch to something that works.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 22 Sep 2016 05:11:39 +0000

Martin Thomson <[email-masked]> writes:

>The advantage with deploying a new protocol is that you can be strict. If, 
>for example, all of the browsers implement TLS 1.3 and are strict, then 
>Amazon won't be able to deploy a buggy 1.3 implementation without noticing 
>pretty quickly.  You might suggest that that's aspiration to the point of 
>delusion, but in fact it worked out pretty well with HTTP/2 deployment.  We 
>didn't squash ALL of the nasty bugs, but we got most of them.

It also means you're going to be in for a rude shock when you encounter the
ocean of embedded/SCADA/IoT devices with non-mainstream TLS implementations.
The reason why HTTP/2 "works" is that it essentially forked HTTP, HTTP/2 for
Google, Amazon, etc, and the browser vendors, and HTTP 1.1 for everything 
else that uses HTTP as its universal substrate.  As a result there will be 
two versions of HTTP in perpetuity, HTTP 1.1 and HTTP-whatever-the-current-
version-is.

(Should I mention TLS-LTS here? :-).

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 22 Sep 2016 09:34:37 +0300

> On 22 Sep 2016, at 8:11 AM, Peter Gutmann <[email-masked]> wrote:
> 

Perhaps. But if at some point all websites use HTTP-whatever-the-current-version-is then maybe browsers can remove support for HTTP/1.1 and then your embedded/SCADA/IoT devices won’t give us that rude shock.

I honestly don’t think that having two protocols for these two radically different use cases is a bad outcome.

Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 22 Sep 2016 09:54:41 +0300

> ocean of embedded/SCADA/IoT devices with non-mainstream TLS implementations.

That did not check for interop with any mainstream TLS library?

Also, code to "recover" tends to introduce security issues if used in
security protocols. Just because I don't have to deal with simple bugs
like buffer overflows leading to RCE or data races does not mean I can
do whatever I want and expect the code to have low number of security
issues. The existing stuff is way more than enough.

(Just fixed a bug where NotBefore/NotAfter of dedicated OCSP responder
certificate were not validated... Not related to recovery in any way,
but still some special code).

> two versions of HTTP in perpetuity, HTTP 1.1 and HTTP-whatever-the-current-

Well, the problem you encounter first with HTTP/2 is that it really
dislikes unencrypted operation. Which impiles you pretty much need 
encryption. Which impiles you pretty much need the WebPKI certificate
model... Which tends to be poor match for anything except named servers
on the internet, which tends not be suitable for IoT stuff...

> (Should I mention TLS-LTS here? :-).

Ugh...

-Ilari

---

From: Hubert Kario <[email-masked]>
Date: Thu, 22 Sep 2016 13:41:28 +0200

On Wednesday, 21 September 2016 15:53:33 CEST Peter Gutmann wrote:
> And how many implementations are going to do this?  Consider the
> error-message litmus test I proposed earlier, reasons for failing to
> connect to (say) amazon.com:
> 
>          decoding_error alert>

"received data was malformed."

> actual humans then failing a connect based on something like this makes no

We are talking about a cryptographic protocol. Being very strict about what 
you receive is the raison d'être of the whole thing.

POODLE happened because SSL 3 in general and some TLS implementations in 
particular weren't strict.

Researchers look at protocol itself and only a handful of popular 
implementations, they won't be analysing if the TLS-as-implemented-by-ACME-
widget-7000 is secure even if it isn't strict.
-- 
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: "Andreas Walz" <[email-masked]>
Date: Thu, 22 Sep 2016 14:18:09 +0200

>>> Peter Gutmann <[email-masked]> 22.09.16 7.00 Uhr >>>

> Peter.

I see your point here. However, where would you draw the line between "I can't" and "I don't want to"? Think of a cipher suites list with 3 bytes in a ClientHello. You can still find one cipher suite that could be ok to work with. However, how can you trust the first two bytes if you find that third byte telling you something's abnormal?

Andi

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 22 Sep 2016 10:47:42 -0400

> On Sep 22, 2016, at 8:18 AM, Andreas Walz <[email-masked]> wrote:
> 

The server tries that first cipher, if mutually supported, and if it
works, it guessed right.  If the finished message from the server is
valid, the client's handshake as seen by the server was presumably
exactly what the client sent, so the client gets what it paid for...

Servers don't have to be that forgiving, but it is a plausible approach.

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 23 Sep 2016 14:59:12 +1000

> Servers don't have to be that forgiving, but it is a plausible approach.

Another view on this (web view):
https://annevankesteren.nl/2016/05/client-server

Why a server would tolerate rubbish and all the associated complexity,
when none of the users it cares about produce that sort of drivel is
beyond me.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 23 Sep 2016 08:14:55 +0000

Yoav Nir <[email-masked]> writes:

>But if at some point all websites use HTTP-whatever-the-current-version-is
>then maybe browsers can remove support for HTTP/1.1 and then your
>embedded/SCADA/IoT devices won’t give us that rude shock.

Since HTTP/2 pretty much guarantees that SCADA/IoT/etc will keep using HTTP
1.1 forever, browsers are going to have to keep supporting both versions
forever.  Either that or there'll be custom forks of browsers sold as "SCADA
administration clients" or something similar.

>different use cases is a bad outcome.

Neither do I.  The problem is that we're supposed to pretend that HTTP 1.1
will go away and everything will only talk HTTP/2, rather than accepting that
both will be with us for a long time, if not forever.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 23 Sep 2016 08:24:09 +0000

>That did not check for interop with any mainstream TLS library?

Mainstream TLS 1.3 libraries?  Since the spec is still subject to weekly
changes, I doubt there's anything to interop test with.  

(It's actually a bit of a rhetorical question, since I've seen little to no
evidence that embedded/SCADA/etc has any intention of throwing away their
existing investment and starting again with 1.3 or 2.0 or whatever it'll be
called, I doubt there'll be much to non-interop with.

>security protocols. 

This isn't "code to recover", it's just normal code.  If anything, it's adding
additional code to check for problems that aren't really problems that'll lead
to security issues.

>Well, the problem you encounter first with HTTP/2 is that it really dislikes
>unencrypted operation. Which impiles you pretty much need encryption. Which
>impiles you pretty much need the WebPKI certificate model... Which tends to
>be poor match for anything except named servers on the internet, which tends
>not be suitable for IoT stuff...

Yup.  The HTTP/2 folks' response to this at the time was "let them eat 1.1",
pretty much guaranteeing a fork of the HTTP protocol, with two different
versions being maintained in perpetuity.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 23 Sep 2016 08:38:44 +0000

Andreas Walz <[email-masked]> writes:

>However, where would you draw the line between "I can't" and "I don't want
>to"?

It's one of those judgement-call things, I don't know if you can strictly
define it but as a rule of thumb I'd say that if you encounter it during
normal processing it's an I-can't problem while if you have to add special-
case checks to identify it and refuse to continue it's an I-don't-want-to
problem.

Using again the example of "Couldn't connect to Amazon because no suitable
encryption was available", if the server or client accidentally memset()s the
cipher suite block to 0xDEADBEEF then you've run into an I-can't-continue
problem, while if the length fields don't quite match up (the MUST NOT that
was cited at the start of this thread), something that you wouldn't even
notice unless you added special-case code to check for it, then it's an I-
don't-want-to-continue problem.

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Fri, 23 Sep 2016 14:16:43 +0200

> case checks to identify it and refuse to continue it's an I-don't-want-to

So it comes down how the code just happens to be written? I don't think that's 
a good approach for security critical code... 

I mean if you do a

while not is_empty(buffer):
   c_id = get_two_bytes_with_overflow_check(buffer)
   list_of_cipher_ids.append(c_id)

you won't need to do additional checks to see if the length is even or not.

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 23 Sep 2016 17:51:30 -0700

> case checks to identify it and refuse to continue it's an I-don't-want-to

Yes of course, but there is another aspect to it, the general health of the
ecosystem. Postel's rule is nice, but it removes the pressure on broken
implementations to fix their code. Pushed to the extreme, the result is a
sort of protocol drift, in which buggy variants get first tolerated, and
then accepted as de-facto standards. This tends to hinder future evolutions,
not to mention adding complexity. We often hear that "the IETF has no
protocol police," but in fact it does. Each implementation that takes a
strict view of standard compliance contributes to this policing.

-- Christian Huitema

---

From: Andrei Popov <[email-masked]>
Date: Mon, 26 Sep 2016 16:56:04 +0000

> Pushed to the extreme, the result is a sort of protocol drift, in which buggy variants get first tolerated, and then accepted as de-facto standards.
Indeed, we're seeing several instances of this protocol drift in TLS 1.3 (2.0? 4.0?), e.g. the relaxed rules around the signature_algorithms extension and the version negotiation workaround that just got adopted...

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Christian Huitema
Sent: Friday, September 23, 2016 5:52 PM
To: 'Peter Gutmann' <[email-masked]>; 'Andreas Walz' <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations

On Friday, September 23, 2016 1:39 AM, Peter Gutmann wrote:
>>However, where would you draw the line between "I can't" and "I don't 
>>want to"?
> 
> It's one of those judgement-call things, I don't know if you can 
> strictly define it but as a rule of thumb I'd say that if you 
> encounter it during normal processing it's an I-can't problem while if 
> you have to add
special-
> case checks to identify it and refuse to continue it's an 
> I-don't-want-to problem.

Yes of course, but there is another aspect to it, the general health of the ecosystem. Postel's rule is nice, but it removes the pressure on broken implementations to fix their code. Pushed to the extreme, the result is a sort of protocol drift, in which buggy variants get first tolerated, and then accepted as de-facto standards. This tends to hinder future evolutions, not to mention adding complexity. We often hear that "the IETF has no protocol police," but in fact it does. Each implementation that takes a strict view of standard compliance contributes to this policing.

-- Christian Huitema