Subject: [tcpinc] Going forward without protecting TCP headers

From: Tero Kivinen <[email-masked]>
Date: Wed, 11 Mar 2015 14:24:04 +0200

In the Honolulu meeting we had long discussion about whether to
protect the TCP headers or not. There were several people who
considered the main idea of tcpinc, to be to protect against
passive attacks, and did not care that much about active attacks,
i.e. didn't care for protection of the TCP headers. There were
also few people in favor of protection of header bits, i.e.
protect against active attacks.

Everybody wanted to protect data for integrity, i.e. MAC of data
stream and protection against replay. As most people in he
meeting did not seem to want to have protection against active
attacks, it was decided that those people who do want protect TCP
header, would send email to the list and explain why they want it
and what features needs to be protected.

I sent out the request for such comments at 2014-11-15:

http://www.ietf.org/mail-archive/web/tcpinc/current/msg00393.html

In my analysis of the email thread, there were two people who
said they would like to have some TCP features to be protected:

http://www.ietf.org/mail-archive/web/tcpinc/current/msg00396.html
http://www.ietf.org/mail-archive/web/tcpinc/current/msg00403.html

There were more than dozen people discussing this in the meeting, and
while people expressed opinions supporting the two options, we believe
that there is more support for going for not protecting the header.
Moreover, we believe that at this stage it is more important to make a
decision and move forward.

Based on this the tcpinc chairs have decided that we will go with
the option of NOT protecting the TCP headers.

This means that in Dallas IETF we should work forward based on
this decision.
-- 
[email-masked]

---

From: John Border <[email-masked]>
Date: Wed, 11 Mar 2015 12:28:46 -0400

+1

-----Original Message-----
From: Tcpinc [mailto:[email-masked]] On Behalf Of Tero Kivinen
Sent: Wednesday, March 11, 2015 8:24 AM
To: [email-masked]
Subject: [tcpinc] Going forward without protecting TCP headers

In the Honolulu meeting we had long discussion about whether to protect the TCP headers or not. There were several people who considered the main idea of tcpinc, to be to protect against passive attacks, and did not care that much about active attacks, i.e. didn't care for protection of the TCP headers. There were also few people in favor of protection of header bits, i.e.
protect against active attacks.

Everybody wanted to protect data for integrity, i.e. MAC of data stream and protection against replay. As most people in he meeting did not seem to want to have protection against active attacks, it was decided that those people who do want protect TCP header, would send email to the list and explain why they want it and what features needs to be protected.

In my analysis of the email thread, there were two people who said they would like to have some TCP features to be protected:

There were more than dozen people discussing this in the meeting, and while people expressed opinions supporting the two options, we believe that there is more support for going for not protecting the header.
Moreover, we believe that at this stage it is more important to make a decision and move forward.

Based on this the tcpinc chairs have decided that we will go with the option of NOT protecting the TCP headers.

This means that in Dallas IETF we should work forward based on this decision.
--
[email-masked]

_______________________________________________
Tcpinc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 Mar 2015 10:33:09 -0700

Tero,

Although I can't disagree with your assessment of the direct discussion
on protecting TCP headers, the conclusion below seems to ignore the
discussion on "Forcing the restart of a TCPINC connection".

I wonder how people think their solution will magically protect against
forced restarts if the TCP header isn't included.

Joe

---

From: Gregory Maxwell <[email-masked]>
Date: Wed, 11 Mar 2015 17:41:33 +0000

> forced restarts if the TCP header isn't included.

I agree.

I don't think "don't protect the headers" is an accurate description
of Honolulu if it also leaves the system exposed to resets, as there
clearly was a fair amount of concern expressed about spurious resets.

I'd like to reemphasize that any passive attacker infrastructure also
trivially has the capability to inject a few packets-- just by having
access to any non RPF filtered network connection anywhere in the
world, without being a full scale man-in-the-middle.

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 Mar 2015 10:49:43 -0700

> clearly was a fair amount of concern expressed about spurious resets.

And, FWIW, I posted twice a solution that works (from TCP-AO). That
solution, again:

	1) protect the headers
		which protects against restarts
		during an active connection

		this alone leaves stale connections holding up
		ports, though - because the other end might not be
		able to send a keyed RST after a restart

	2) use keep-alive
		to force idle connections to be dropped by
		both ends without needing a key

Joe

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 12 Mar 2015 08:32:23 +0100

Gregory,
> clearly was a fair amount of concern expressed about spurious resets.

IMO, the best approach to deal with suprious resets, caused by 
middleboxes, attackers or whatever, is to use the same approach as in 
Multipath TCP by considering a TCPINC connection to be composed of 
several subflows. When one subflow dies due to a RST, another subflow 
can be restarted to continue the connection. Having multiple paths could 
also be an advantage from a security viewpoint, but that's another story.

Olivier

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 Mar 2015 11:23:11 +0200

> discussion on "Forcing the restart of a TCPINC connection".

Breaking TCP connections is active attack.

There is ways we can protect against the forcing restart of the tcpinc
connection that does not include protecting headers, but they cannot
really prevent them, they can just convert them to full scale DoS...

> forced restarts if the TCP header isn't included.

We cannot protect against forced restarts, but we can protect against
downgrade attacks. I.e. using DNS (DANE) or some other method to
signal that other end support tcpinc, and then if we actually manage
to make first tcpinc connection to the peer, but then got tcp
connection broken down and the next connection do not suddenly support
tcpinc, we know something is fishy here.

Also if the certificate / raw public key or similar changes after the
restart, we again now something is fishy there.

The question is what do we do for that?

We simply assume that as this is opportunistic we do not care, and
continue.

We might give some indication to user (warnings are usually bad, put
some people might want to configure them on).

We might stop communicating and convert that attack to DoS attack.

And I think there might be even more things...

Also some kind of protecting against TCP resets or FINs is possible
even when we do not protect tcp headers. For example if we use TLS we
might ignore FINs unless we have cleanly shut down the TLS before. For
the resets we might send keepalive for the TCP connection instead of
tearing it down immediately. We the keepalive confirms the connection
is still alive, we can ignore the reset etc.

I.e. there are ways to get some protection for those even when we do
not protect TCP header, but what of those methods can be used and will
be used, depends on the solution we are going to use, and the protocol
we define needs to explain what it tries to protect and how.

So I do not consider it impossible to provide limited support against
TCP resets or FINs, or downgrade attacks even when we do not protect
TCP header.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 Mar 2015 11:29:12 +0200

> clearly was a fair amount of concern expressed about spurious resets.

Even if we protected the headers, that would not automatically protect
against resets. Resets are hard to protect against, and for those we
most likely need something different than what can be done by the
protecting the header. 

> world, without being a full scale man-in-the-middle.

Yes. And there is also difference in blind insertion attacks and
attacks where the attacker can see all the traffic. I.e. if attacker
can see port numbers, tcp sequence numbers etc, that can allow much
more efficient attacks, even when it cannot remove any packets from
the network. On the other hand attacker with that capability can also
quite easily do limited packet deletion attacks, for example
configuring firewall filtering rules in the intermediate devices, and
with those they can do targetted active attacks.

Anyways protection against prevasive monitoring is the important thing
here, the limited protection against active attacks is secondary
objective. If you want proper protection against active attacks, use
IPsec, TCP-AO or some other method that will provide that.
-- 
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Fri, 13 Mar 2015 14:27:33 -0700

On 3/12/2015 12:32 AM, Olivier Bonaventure wrote:
> several subflows. 

TCPINC isn't limited to Multipath TCP, thus that approach is inappropriate.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 13 Mar 2015 14:34:34 -0700

> really prevent them, they can just convert them to full scale DoS...

I cannot make any sense of the following concurrent claims:
	"protect against the forcing restart"
	"cannot really prevent them,"

Either you can protect against them or you cannot.

> downgrade attacks. 

A forced restart can be used as part of a downgrade attack, but it has
other purposes, notably disrupting communications while off-path.

> I.e. using DNS (DANE) or some other method to

That presumes all TCP endpoints sharing an IP address are identical and
use identical paths.

I.e., you could have been sent to a different endpoint (load balancing
at a server farm) that doesn't support TCPINC.

Your path to that endpoint could also have changed to go over one that
no longer supports TCPINC.

All you know is that capabilities have changed, and that can happen for
benign reasons.

> restart, we again now something is fishy there.

You're again jumping to conclusions.

> The question is what do we do for that?

That's a downgrade or change of cert issue, which is independent of a
RST attack.

...
> might ignore FINs unless we have cleanly shut down the TLS before. 

In that case, you'd be protecting the TCP connection against useful
resets too.

> For

You then have to ask whether the keepalive is more important than the
reset. Wouldn't an attacker then just send a keepalive? If you don't
protect the header, you're back where you started, aren't you?

Joe

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 13 Mar 2015 22:35:06 +0100

Joe,

> TCPINC isn't limited to Multipath TCP, thus that approach is inappropriate.

I know the charter of the TCPINC working group. When I write "use the 
same approach as in Multipath TCP by considering a TCPINC connection to 
be composed of several subflows" I mean include in TCPINC a mechanism 
that contains :

  - a form of connection id as the tokens used in Multipath TCP
  - a way to enable a TCP connection to be composed of a series of TCP 
connections (i.e. the datastream that started on the previous subflow 
continues on the next one)

With this kind of mechanism, a TCP variant can have the ability to react 
to spurious resets. It is possible to use for the design of TCPINC the 
various lessons that have been learned during the design of Multipath 
TCP even if the requirements are different.

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: Joe Touch <[email-masked]>
Date: Fri, 13 Mar 2015 14:36:40 -0700

> most likely need something different than what can be done by the

That's incorrect. See TCP-AO.

> quite easily do limited packet deletion attacks, 

I think you're confusing two different levels of capability:
	- snooping and injecting traffic
	- deleting traffic

The former can be quite easy compared to the latter.

> for example

Fair enough. Good reason for me to move forward with TCP-AO-ENC in TCPM,
where I had intended it anyway...

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 13 Mar 2015 14:38:26 -0700

> continues on the next one)

TCP is intended to protect TCP, not turn all TCP users into
Multipath-lite users.

> to spurious resets. 

Only if you substantively protect those connection ID tokens. Which
means you're protecting "header" information - and you;ave' made it
worse by protecting a header that doesn't even exist yet.

It's a lot easier to protect the headers we alredy have.

Joe

---

From: Christian Huitema <[email-masked]>
Date: Fri, 13 Mar 2015 21:51:41 +0000

> TCP is intended to protect TCP, not turn all TCP users into Multipath-lite users.
> 
> > With this kind of mechanism, a TCP variant can have the ability to
> > react to spurious resets.
> 
> Only if you substantively protect those connection ID tokens. Which means
> you're protecting "header" information - and you;ave' made it worse by
> protecting a header that doesn't even exist yet.
> 

Protecting against spoofed RST would be a very good thing indeed. But we want a solution that is robust in the presence of middle-boxes, and there is a generic issue there. Today, middleboxes like NAT and Firewall inspect the TCP flags. If they see an RST or FIN flag, they "know" that the connection is being terminated, and they proceed to release the associated resource, e.g., close the open holes in the firewall or remove the mappings in the NAT. After the middle box release the connection, further packets on that path will be dropped.

What does that do to TCP-INC? Suppose we have a nice way to authenticate the headers. The attacker injects a spoofed RST message. The end points of the connection will observe that the message fails authentication, and they will drop it. But that's too late, because the middle-boxes on the path have also seen the message. They do not know the authentication key, so they have no way to know whether the RST is genuine or not. Most will continue doing what they are doing today, they will just assume that this is a bona fide RST. They will close the holes and drop the mappings. Further packets will be dropped.

Joe, do you have a design that solves that?

-- Christian Huitema

---

From: Joe Touch <[email-masked]>
Date: Fri, 13 Mar 2015 15:05:16 -0700

On 3/13/2015 2:51 PM, Christian Huitema wrote:
>> It's a lot easier to protect the headers we already have.
> 
> Protecting against spoofed RST would be a very good thing indeed. 
> But we want a solution that is robust in the presence of
> middle-boxes, and there is a generic issue there. Today, middleboxes
> like NAT and Firewall inspect the TCP flags. If they see an RST or
> FIN flag, they "know" that the connection is being terminated, and
> they proceed to release the associated resource, e.g., close the open
> holes in the firewall or remove the mappings in the NAT. After the
> middle box release the connection, further packets on that path will
> be dropped.
> 
> What does that do to TCP-INC? 

NATs that use RST or FIN to explicitly remove an entry are vulnerable to
spoofing for either kind of packet, but then they were also vulnerable
to spoofing of the SYN too (which could have flooded their tables).

> Joe, do you have a design that solves that?

Short of giving the NAT an authentication key, there's no solution to
any of these behaviors - but that's true regardless of whether the
headers are integrity protected and authenticated or not.

The only solution where endpoints track NAT behavior is one where there
is no authentication.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 13 Mar 2015 15:10:45 -0700

...
>> middle-boxes, and there is a generic issue there. 
...
>> Joe, do you have a design that solves that?

Actually, to be more direct:

Don't use a NAT.

when you're behind a NAT, you're beholden to how the NAT interacts with
the Internet, and *you* are on a private communications system that is
decidedly NOT the Internet.

Joe

---

From: Gregory Maxwell <[email-masked]>
Date: Fri, 13 Mar 2015 22:20:41 +0000

> Joe, do you have a design that solves that?

That it cannot be protected in all cases is not a reason to not
protect in the cases where it can be; just like unauthenticated
opportunistic encryption only gets you the potential for after the
fact detection when there is a MITM. Seeking a pragmatic best effort
outcome is, I think, what we want to accomplish with TCP-INC.

---

From: Olivier Bonaventure <[email-masked]>
Date: Sun, 15 Mar 2015 23:00:20 +0100

Joe,

> It's a lot easier to protect the headers we alredy have.

The key issue is when there is a middlebox on the path and that 
middlebox sees a spoofed RST (without checking any authentication in the 
RST) and reacts by removing state for the associated connection. Event 
if the the endhost ignore the RST because it does not contain any 
authentication, the connection is blocked in the middle of the network. 
At this point, there are two options :

  - TCP informs the application that the connection is gone and the 
application is assumed to be intelligent to restart a new connection 
(and resend all the data sent over the previous connection)

  - TCP restarts a new connection without informing the application and 
the bytestream continues without any interruption. This requires some 
form of connection id that is negotiated at the beginning of the 
connection and exchanged during the establishment of the second connection.

I believe that most application developpers will prefer the second 
solution to the first one.

Olivier

---

From: Olivier Bonaventure <[email-masked]>
Date: Sun, 15 Mar 2015 23:04:03 +0100

Joe,

> decidedly NOT the Internet.

I agree that the Internet would be easier without NATs, but looking at 
the TCPINC charter, the first requirement for TCPINC is :

"The high-level requirements for the protocol for providing TCP
unauthenticated encryption and integrity protection are:
- It should work over the vast majority of paths that unmodified TCP
works over, in particular it must be compatible with NATs (at the very
minimum with the NATs that comply with BEHAVE requirements as
documented in RFC4787, RFC5382 and RFC5508)."

This requirement has been met by Multipath TCP. TCPINC should also aim 
at meeting this requirement.

Olivier

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 16 Mar 2015 17:21:56 +0200

> 	"cannot really prevent them,"

In most cases if we try too hard to protect against some things, we
just makes other attacks easier. I.e if we always assume other end has
tcpinc and will never talk in clear text, and will never restart in
clear, that will protect against attackers forcing restart to lower
security, but that might cause very easy denial of service attack
against us, by just blocking tcpinc signaling, in which case we didn't
prevent the attack, we just made it different (worse or easier etc).

Another example was given by others, i.e. even if the implementation
completely had protection for RST flag, but if NATs act on them, it
would still protect us against forced restart, but on the other hand
it would again allow easy DoS. If we would actually act on the RST the
situation would be better, as then we could recover faster, i.e.
immediately when we notice that connection is gone, and we would not
need to wait for keepalive timers or similars to kick in.

> Either you can protect against them or you cannot.

"Protect against" and "prevent" do have different meanings,
preventation is not the only form of protection as Stephen Farrell put
it.

We had this dicussion earlier on this list

http://www.ietf.org/mail-archive/web/tcpinc/current/msg00445.html

> other purposes, notably disrupting communications while off-path.

Which would most likely need different approach to protect against.

> That presumes all TCP endpoints sharing an IP address are identical and

Partially yes. They do not need to be identical, but they all need to
allow passing tcpinc through.

> at a server farm) that doesn't support TCPINC.

And why would any sane people ever willingly end up configuring their
system like that. And even if they would, it still looks that
something is wrong there. Yes, the one load balancing server might be
under control of TLA and thats why it does not support TCPINC, but
that is even more the reason to try to use those which work...

> no longer supports TCPINC.

Yes, which would convert this to DoS. As I said in the beginning.
Depending how much we want to protection against some attacks, will
affect how easy it is to cause DoS against us too.

All of these are compromises...

> In that case, you'd be protecting the TCP connection against useful

No. I said we can ignore FINs, I didn't say RST. If the other end has
properly implemented TCPINC and TCPINC is using TLS and the text says
it MUST do close notify before FIN is accpeted, then we can ignore
FINs for TCPINC sessions which have not yet received close notify from
other end (note, this is again just an example of one way to solve
some parts of this problems using the information we have inside the
tcp stream, without explictly protecting TCP flags).

> > For the resets we might send keepalive for the TCP connection
> > instead of tearing it down immediately. We the keepalive confirms
> > the connection is still alive, we can ignore the reset etc.
> 

Depending what you mean by keepalive. I.e off-path attackers most
likely cannot send keepalive as they do not know sequence numbers etc,
thats why they did blind RST attack. On the other hand if that is
important thing to protect against we can make that keepalive not to
be TCP keepalive, but inner layer protocol frame, i.e. in TLS case it
could be some kind of heartbeat extension packet or similar.

I am not trying to design the protocol here in this email, I am saying
that I at least think there are solutions we can do that will solve
some (or all) of those issues, even when we do not protect TCP
headers.

Which subset the "some of those issues" is going to be and what kind
of protection we are going to provide, depends on the actual protocol
we are going to use, and what we feel is importan to provide
protection for.
-- 
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 16 Mar 2015 11:11:04 -0700

> prevent the attack, we just made it different (worse or easier etc).

If someone can block TCPINC signalling, they can create any DOS attack
they want anyway. Attacker effectiveness isn't increased, just the
number of ways an attacker can achieve the same result with the same
vulnerability.

> it would again allow easy DoS. 

Once you support NAT interaction, you are open to DOS. Again we're back
to whether the protection increases the effectiveness of the attacker
given the same vulnerability.

> If we would actually act on the RST the

You recover from the additional attacks you're vulnerable to faster.
That means your overall vulnerability increased. Don't have a party
about it, IMO.

> preventation is not the only form of protection as Stephen Farrell put

Agreed. Prevention is a-priori.

> system like that.

It happens, esp. during incremental deployment. That's part of why farms
use stateful load distribution.

> And even if they would, it still looks that

You do realize that having a mechanism that tells you when to accept or
ignore FINs *is* header protection, the very protection you just decided
you don't want or need?

You can't do that with conventional TLS - TLS is carried over TCP, and
TCP would have processed the FIN before TLS knew about it.

If this is header-based TLS, then that TLS *is* protecting the header.

So which is it?

> Depending what you mean by keepalive. 

Sorry - TCP keepalives. As per RFC1122, Sec. 4.2.3.6.

> I.e off-path attackers most
> thats why they did blind RST attack. 

Yes, for off-path attacks. Not all RST attacks are blind, though, and we
all continue to use shared nets where snooping is possible.

> On the other hand if that is

Yes, but that would be outside the scope of solutions here, no?

---

From: ianG <[email-masked]>
Date: Mon, 16 Mar 2015 22:03:44 +0000

On 12/03/2015 09:29 am, Tero Kivinen wrote:

> objective.

That is my view.  My sense is that TCPinc goes forward in v0 with only 
passive capabilities, and is easily attacked.

In v1, we might do better.  But I don't get the feeling that we/the 
group knows enough to lay down the solution without really trying it.

So better off to go for the low goal and get that right.  Is my view.

iang

---

From: Joe Touch <[email-masked]>
Date: Mon, 16 Mar 2015 16:41:29 -0700

> at meeting this requirement.

Sure, but there will never be a NAT that prevents an off-path RST attack
from DOSing a connection. Once you accept that NATs have control over
your connection but you don't have control over NATs, you're done with
claiming protection from NAT-directed attacks.

That's true for ALL TCP approaches though NATs.

Joe

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 17 Mar 2015 13:12:35 +0200

> ignore FINs *is* header protection, the very protection you just decided

As I said in my email there are some functionalities that people do
want to protect, but we do not want to protect TCP header in general.

Everybody things we need to protect against replay, reordering and
data dropping attacks. This could be interpreted to mean that we
protect sequence number.

Protecting shutdown functionality, can be done either by protecting
the TCP header bits in the TCP header, or some other method, just like
I explained above. They do provide protectiong against same
functionality, but are done on different layers.

> TCP would have processed the FIN before TLS knew about it.

Yes, which would be the benefit for tcpinc TLS compared to the plain
TLS inside TCP... In tcpinc we can do that. 

> If this is header-based TLS, then that TLS *is* protecting the header.

What do you mean by header-based TLS? 

> So which is it?

I was talking about the base version shown in
draft-rescorla-tcpinc-tls-option and explaining that if that protocol
wants to protect shutdown functionality, it can do that (currently it
does not do that, and I am not sure if it is something that needs to
be done).

Thats why I wanted people to express the list of functionalities they
wanted to protect, not actual TCP header bits. We can provide
protection to the functionalities in different layers even when we do
not care about the actual TCP header bits.

On the other hand people did not consider shutdown functionality
important enough to list is as one of those they wanted to protect, so
it can be so that we do not need / want to protect it. 

> Yes, but that would be outside the scope of solutions here, no?

Why? If we consider the protecting cleaning up state messages
important functionality enough to protect it, we can protect it. We
can do the protection on multiple different ways.
-- 
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Tue, 17 Mar 2015 09:17:11 -0700

On 3/17/2015 4:12 AM, Tero Kivinen wrote:
...
> functionality, but are done on different layers.

It MUST be in the TCP layer or above. If you put the protection in the
transport payload, you won't see that data until AFTER the TCP header
has been processed.

> TLS inside TCP... In tcpinc we can do that. 

You can decide to do that with any solution, but it is protecting the
TCP header at that point, which is exactly what you said we agreed NOT
to do (even by the subject line of this message).

> What do you mean by header-based TLS? 

The tcpinc TLS proposal.

> wanted to protect, not actual TCP header bits.

FIN and RST are TCP header bits.

> We can provide

You cannot. If you don't protect the bits of the TCP header, you're dead
before the next layer gets to react.

...
> Why?

I thought the scope here was TCP - by the name of the WG.

> If we consider the protecting cleaning up state messages

You can call it what you want, but if it blocks interpretation of TCP
header bits before confirming the message security, you ARE protecting
the TCP header, and then you are NOT "going forward without protecting
the TCP headers".

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 17 Mar 2015 10:48:45 -0700

> group knows enough to lay down the solution without really trying it.

I appreciate that viewpoint, but it's also useful to recognize that
there might not be an incremental path towards doing better in v1.

Whatever foundation you pick now will have consequences.

Joe

---

From: ianG <[email-masked]>
Date: Mon, 23 Mar 2015 19:22:03 +0000

> there might not be an incremental path towards doing better in v1.

Hmm... can you please say more about why there wouldn't be a path to 
upgrade to v1?

> Whatever foundation you pick now will have consequences.

That, granted.  1994, first month on the road, they separated the 
webpages into HTTPS and HTTP coz crypto was too slow.  We're still paying...

iang

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Mar 2015 08:34:39 -0700

> Hmm... can you please say more about why there wouldn't be a path to

Decisions you make now may limit the ability to avoid active attacks,
esp. during the SYN exchange.

> webpages into HTTPS and HTTP coz crypto was too slow.  We're still

Well, that split was arguably because of the lack of a way to negotiate
optional security; even though that was addressed with STARTTLS just 5
years later, here we are another 20 after that and just a few weeks ago,
SAAG still couldn't reach consensus on whether one port or two was
preferred from a security viewpoint.

Joe