Subject: [tcpinc] Expressing draft support

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 16 Mar 2015 16:43:58 +0100

We would like to ask the WG to express their support to adopt one (or 
none) of the following documents as WG document that will serve as a 
basis for the protocol specification. Of course, the draft, if adopted, 
will need to updated according to the WG input. In particular, they need 
to be updated to not protect the TCP header.

The candidate drafts are:

https://datatracker.ietf.org/doc/draft-bittau-tcpinc-tcpcrypt/
https://datatracker.ietf.org/doc/draft-rescorla-tcpinc-tls-option/

We plan to discuss this on the meeting but it would be useful to start 
the discussion before the meeting, so if you can express your opinions 
before the meeting, it would be helpful.

Regards, marcelo (on behalf of the co chairs)

---

From: David Mazieres <[email-masked]>
Date: Mon, 16 Mar 2015 12:29:35 -0700

> before the meeting, it would be helpful.

I obviously support tcpcrypt.  To meet the new requirements, we would
make several modifications to the tcpcrypt draft.  The most obvious is
that authenticating the TCP header would become optional, and the draft
would state that, barring a setsockopt or sysctl to the contrary,
implementations SHOULD make unauthenticated TCP headers the default.  To
prevent FIN injection attacks from altering the TCP stream, we would add
a payload-level EOF marker that MUST accompany any FIN segment.  Likely
this indicator would be a MAC of the FIN's 64-bit extended sequence
number position, and would not be covered by the payload MAC so as to
prevent it from being interpreted as data should the FIN bit be cleared.
Other functions such as flow control would not be protected.

In addition, we would modify some of the structures used in tcpcrypt
negotiation to make it impossible for there to be downgrade attacks,
where an attacker removes header authentication from a connection that
actually wants it.  We will also generalize this to make tcpcrypt's
forward compatibility story more obvious.  (Though we believe tcpcrypt
in its current form is amenable to newer versions of the protocol, the
existing draft does not give a good sense as to how the protocol should
be evolved to avoid downgrade attacks.)

David

---

From: ianG <[email-masked]>
Date: Mon, 16 Mar 2015 21:50:35 +0000

> https://datatracker.ietf.org/doc/draft-bittau-tcpinc-tcpcrypt/

Tcpcrypt for me.  It's up, working, got the experience.

> https://datatracker.ietf.org/doc/draft-rescorla-tcpinc-tls-option/

I just can't see grafting a heavyweight protocol into TCP as being a 
sensible path.  Maybe I'm wrong, but I just don't see it.

iang

---

From: "Everhart, Craig" <[email-masked]>
Date: Mon, 16 Mar 2015 21:55:04 +0000

+1.

		Craig Everhart

On 3/16/15 5:50 PM, "ianG" <[email-masked]> wrote:

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Mar 2015 22:01:02 +0000

With no hats and repeating something I've said before. I'm sure
either can work, and am confident that the WG will make whichever
it chooses work. (And speedily I hope:-)

But I do have a concern that we're maybe putting too maybe eggs in
the one TLS basket. If the WG picked tcpcrypt here then I think that
might be right from the point of view of providing better genetic
diversity and slightly better defense in depth.

I do recognise that the argument that TLS has been better analysed
is quite a good counter though, even if the particular pared down
profile of TLS that'd be needed in the end hasn't been so analysed.

S.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Mar 2015 17:07:40 -0700

> https://datatracker.ietf.org/doc/draft-rescorla-tcpinc-tls-option/

I'd prefer doing less work overall.  Due diligence on the tcpcrypt
security analysis can't be cheap.

"Put all your eggs in one basket and then watch that basket."

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 16 Mar 2015 19:01:12 -0700

Hi,

I'm personally curious about the roadmap of the technology before thinking
about this question. (The charter page seems to be a bit ambiguous on this
point.)
We can start from protecting data, but I think security stuff is moving
target. Things might be changed in the future.
Or, data protection is the only target anyway?

Thanks,
--
Yoshi

On Mon, Mar 16, 2015 at 8:43 AM, marcelo bagnulo braun <[email-masked]>
wrote:

> none) of the following documents as WG document that will serve as a basis
> for the protocol specification. Of course, the draft, if adopted, will need
> to updated according to the WG input. In particular, they need to be
> updated to not protect the TCP header.
>
>
> We plan to discuss this on the meeting but it would be useful to start the
> discussion before the meeting, so if you can express your opinions before
> the meeting, it would be helpful.
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 17 Mar 2015 09:55:06 +0100

Just to add, it would ne nice if people expressing support for one draft
or the other also state whether you are willing to:
- review the different versions of the draft
- contribute with text to the draft
- produce code/implement the protocol

Thanks, marcelo

El 16/03/15 a las 16:43, marcelo bagnulo braun escribió:
> basis for the protocol specification. Of course, the draft, if
> adopted, will need to updated according to the WG input. In
> particular, they need to be updated to not protect the TCP header.
>
>

---

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

[Without any hats]

> https://datatracker.ietf.org/doc/draft-rescorla-tcpinc-tls-option/

I personally would prefer TLS option, mostly because:

- Doing full security analysis for completely new key exchange
  protocol (tcpcrypt) will take time and effort, and we seem to be
  missing people having enough time in WG. Using existing already
  analysed protocol (tls) would make us able to go forward faster.
  Designing key exchange protocol is not that hard, but desining it so
  that it does not have any security issues is extremely hard as we
  have seen from our previous examples... 

- Using as little of TCP options, as possible, will provide us best
  possible way of getting through almost all possible middleboxes.
  Using separate framing (in TLS case the TLS record layer) inside the
  TCP stream and moving protection there, makes things to work through
  middleboxes. I.e. if we go with tcpcrypt, I would think that it
  would also benefit from this architectural change.

- Regardless which solution we pick, implementing it in kernel will
  mean that new code needs to be written, I do not expect that people
  will be trying to run OpenSSL inside the kernel and be done with
  that. In that case I do not see that big difference whether we
  implement tcpinc tcpcrypt or whether we implement tcpinc TLS. We can
  limit features away which we do not need to make it small (for
  example if we start with one anonymous Diffie-Hellman ciphersuite,
  we do not need PKIX certificates etc). On the other hand the TLS
  already have existing code which can be used for testing (i.e. we
  can test our kernel space tcpinc TLS implementation against TLS test
  suites or implementations we already have), and also TLS do have
  lots of stuff already specified, which means that if we want to
  expand it to do some feature (for example raw key based
  authentication), we already have specifications for that, we just
  need to lift the restriction set in tcpinc specification and allow
  that to be used.
-- 
[email-masked]

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 17 Mar 2015 17:17:48 +0200

> Tcpcrypt for me.  It's up, working, got the experience.

Agreed. 

Needs adjusting, but I think it is a reasonable starting point. 
 
> sensible path.  Maybe I'm wrong, but I just don't see it.

Agreed. This thing might end up being implemented in supervisor mode,
where complexity is really expensive and consequences of mistakes are
really severe.

What it would take to simplify TLS down to acceptable complexity (and
fix the security flaws!) would yield protocol that looks pretty much
nothing like TLS. And it is questionable if security analyses would
still hold.

Heck, there's an RFC about attacks against TLS. Less than half year
since last update, but:

- Contains an attack that is only fixed in TLS 1.3 draft (not even
  draft extension to fix it in TLS 1.2).
- Contains an attack that has no standardized fix yet (and hits anondh
  practicularly bad).
- Already missing at least 3 attacks, 2 of those apply to reasonably
  modern stuff (not "you should already have deimplemented this a
  LONG time ago!") and the other of those 2 is unfixed even in TLS 1.3
  draft.

-Ilari

---

From: Andrea Bittau <[email-masked]>
Date: Tue, 17 Mar 2015 09:11:31 -0700

I obviously support tcpcrypt too and want to add based on Marcelo's note
that I'm available to promptly make any changes to the current
implementation and work toward upstreaming kernel patches based on the
working group's outcome.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Mar 2015 09:20:39 -0700

>   LONG time ago!") and the other of those 2 is unfixed even in TLS 1.3

This is not really the place to raise these issues.  TLS 1.3 is a work
in progress, if you have specific concerns, I know that you know where
to raise them.  I'd also encourage you to be more specific.

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 17 Mar 2015 16:29:49 +0000

> https://datatracker.ietf.org/doc/draft-rescorla-tcpinc-tls-option/

tcpcrypt

Lars

---

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

> to be updated to not protect the TCP header.

First, as discussed on the list, this is inaccurate; at best, you'll be
updating them to not protect SOME of the TCP header. Any information
that is processed before the TCP header AND makes interpretation of that
header conditional on success, by definition *protects* at least some of
the header.

Given that provision, I propose that draft-touch-tcp-ao-enc is also a
viable candidate, given the following changes:

	- configuration-based use of a connection identifier,
	used instead of the address/port pair to associate the
	connection messages with the security context

	- when that identifier is used, it protects the SYN/FIN/RST
	and some other similar fields of the header (TBD)

For the record, *of the selections below*, I would have to see the
changes required to support the changes indicated above before being
able to indicate a preference. At this point, my initial preference is
for the TLS approach because it appears to interact more simply with TCP.

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 17 Mar 2015 19:16:05 +0000

> https://datatracker.ietf.org/doc/draft-bittau-tcpinc-tcpcrypt/

My view is that this document has to change significantly before we can discuss adoption. Since this proposal significantly modifies the TCP protocol and the TCP state engine, I'd really prefer to *first* have a consistent document and *then* discuss a potential adoption. If the consensus in TCPINC is not to use header protection, I think header protection has to be removed entirely from the protocol specification - it could go to a separate document.

I've stated already multiple times that I am really concerned about the definition of an own option payload encoding for INIT1 and INIT2 [1]. TCPM has a chartered milestone for EDO to provide long options. To me, EDO provides what is needed for INIT1/INIT2. If I miss something here, I am really willing to learn more. I do not think that the TCPINC working group should define a second and incompatible TCP long option format. This will very likely result in incompatibility issues once EDO, TCPINC, and/or other TCP extensions evolve in the future, or if they will be used in combination. The last thing we need in the IETF is standardizing multiple incompatible TCP variants each defining their own encoding of the data stream. This will end up in a mess. I believe updating draft-bittau-tcpinc-tcpcrypt to use EDO would only be a small change of the protocol.

If EDO as currently defined was not sufficient for TCPINC, the TCPM working group would be really open to feedback [2]. Supporting combinations of TCP-AO, MPTCP, TCPINC, etc. was the main reason why TCPM decided to start the design of a long option solution.

I also expect that a TCPINC protocol will (hopefully) evolve in future, and the TCPINC community should therefore develop a future-proof design. I imagine that future TCPINC enhancements could need the exchange of additional data, possibly exceeding the 40B option limit like INIT1/INIT2. In this case, a TCPINC protocol using the current tcpcrypt payload encoding could easily require further, very complex long option encoding hacks to be able to transport the data needed by such TCPINC extensions. As a result, I believe that the current INIT1/INIT2 encoding is not future-proof and may prevent an evolution of the TCPINC protocol itself. Again, if I should miss something here, I am willing to learn more.

I am not a crypto algorithm expert. But without the need to offer TCP header protection, I assume that the unauthenticated encryption features of tcpcrypt can also be provided by a TLV encoding (or something equivalent) inside the TCP data stream. I'd assume that the actual protocol inside the TCP byte stream could be different to TLS if diversity was an important design objective - this part of the design has to be sorted out by security experts. In addition to a much cleaner protocol architecture not interfering with other TCP extensions, such a TCPINC design would also waste less scarce TCP option space and seems clearly superior to the current design in draft-bittau-tcpinc-tcpcrypt.

To make the long story short: Do *not* adopt draft-bittau-tcpinc-tcpcrypt until a new version of the draft either uses EDO or until the specification defines a future-proof encoding. I am willing to review whether future updates of draft-bittau-tcpinc-tcpcrypt incorporate these changes prior to a potential adoption (if the TCPINC community decides to use this design as a basis).

Thanks

Michael

[1] http://www.ietf.org/mail-archive/web/tcpinc/current/msg00370.html

[2] http://www.ietf.org/mail-archive/web/tcpinc/current/msg00447.html

---

From: David Mazieres <[email-masked]>
Date: Wed, 18 Mar 2015 01:18:03 -0700

"Scharf, Michael (Michael)" <[email-masked]> writes:

> My view is that this document has to change significantly before we
> can discuss adoption. Since this proposal significantly modifies the
> TCP protocol and the TCP state engine, I'd really prefer to *first*
> have a consistent document and *then* discuss a potential adoption. If
> the consensus in TCPINC is not to use header protection, I think
> header protection has to be removed entirely from the protocol
> specification - it could go to a separate document.

Hi, Michael.  I'd like to address some of your points, and attempt to
provide and request clarification on others.  So long as tcpcrypt is a
viable contender, we will of course produce an updated draft to disable
default header protection.

> I've stated already multiple times that I am really concerned about
> the definition of an own option payload encoding for INIT1 and INIT2
> [1]. TCPM has a chartered milestone for EDO to provide long
> options. To me, EDO provides what is needed for INIT1/INIT2. If I miss
> something here, I am really willing to learn more. I do not think that
> the TCPINC working group should define a second and incompatible TCP
> long option format. This will very likely result in incompatibility
> issues once EDO, TCPINC, and/or other TCP extensions evolve in the
> future, or if they will be used in combination. The last thing we need
> in the IETF is standardizing multiple incompatible TCP variants each
> defining their own encoding of the data stream. This will end up in a
> mess. I believe updating draft-bittau-tcpinc-tcpcrypt to use EDO would
> only be a small change of the protocol.

It seems that you are asking us to move the body of the INIT1 and INIT2
messages into option space using EDO.  But TCP-use-TLS does not put the
key exchange into option space, either.  So on this point are you
equally opposed to the TCP-use-TLS proposal?  INIT1 and INIT2 are part
of the session.  For example, it could be necessary for INIT1 to exceed
the size of a single TCP segment.  Why re-invent TCP to stitch together
options over various segments when TCP already has a nice mechanism for
reliable in-order data delivery?

> If EDO as currently defined was not sufficient for TCPINC, the TCPM
> working group would be really open to feedback [2]. Supporting
> combinations of TCP-AO, MPTCP, TCPINC, etc. was the main reason why
> TCPM decided to start the design of a long option solution.

Speaking as a tcpcrypt author, I strongly support the adoption of an EDO
option, and believe tcpcrypt would benefit through more graceful
coexistence with other options (particularly large SACK blocks).

> I also expect that a TCPINC protocol will (hopefully) evolve in
> future, and the TCPINC community should therefore develop a
> future-proof design. I imagine that future TCPINC enhancements could
> need the exchange of additional data, possibly exceeding the 40B
> option limit like INIT1/INIT2. In this case, a TCPINC protocol using
> the current tcpcrypt payload encoding could easily require further,
> very complex long option encoding hacks to be able to transport the
> data needed by such TCPINC extensions. As a result, I believe that the
> current INIT1/INIT2 encoding is not future-proof and may prevent an
> evolution of the TCPINC protocol itself. Again, if I should miss
> something here, I am willing to learn more.

Can you give an example of why you think this is not future proof?  Our
INIT messages have a 4-byte magic number and 4-byte length.  I can't see
any scenario in which we would need more than 4GiB of key exchange data,
but if the need really does arise we can just specify new magic numbers
with an 8-byte length field.

> I am not a crypto algorithm expert. But without the need to offer TCP
> header protection, I assume that the unauthenticated encryption
> features of tcpcrypt can also be provided by a TLV encoding (or
> something equivalent) inside the TCP data stream. I'd assume that the
> actual protocol inside the TCP byte stream could be different to TLS
> if diversity was an important design objective - this part of the
> design has to be sorted out by security experts. In addition to a much
> cleaner protocol architecture not interfering with other TCP
> extensions, such a TCPINC design would also waste less scarce TCP
> option space and seems clearly superior to the current design in
> draft-bittau-tcpinc-tcpcrypt.

So the way I see the two options we were asked to chose between,
TCP-use-TLS uses TLV for both key exchange and data, while tcpcrypt uses
TLV for key exchange only (namely INIT1 and INIT2).  I think Joe Touch
would prefer TLV for neither.  You now seem to be advocating a fourth
design point which uses TLV for data only.  Maybe I misunderstand you,
since we've had a number of drafts and no one has yet advocated that
design point.

I think TLV has disadvantages for data.  For example, it may increase
latency if authentication doesn't fall on segment boundaries.  But
non-TLV also has disadvantages, such as consuming options space that
could otherwise be used for larger SACK blocks (though EDO could really
help here).  This is something I would expect the working group to
debate.  But I don't see any disadvantage to TLV for key exchange.
(Possibly you could argue it undermines the "TCPness" of the protocol,
but not if you are anyway using TLV for session data.)

David

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 18 Mar 2015 09:49:29 +0000

David,

> default header protection.

I digreee that disabling is the right approach. My suggestion is to entirely remove all discussion of header protection from draft-bittau-tcpinc-tcpcrypt, so that it is clear how a TCPINC protocol looks like without header protection (if draft-bittau-tcpinc-tcpcrypt was used as a base protocol for TCPINC). Header protection can go do a separate document.

> equally opposed to the TCP-use-TLS proposal?

No, I just strongly oppose to an adoption of draft-bittau-tcpinc-tcpcrypt in its current form.

As far as I understand, TCP-use-TLS has its own framing in the TCP payload, and it is thus inherently robust to all middleboxes messing up TCP options. This seems a clean approach and looks future-proof to me. Regarding interaction with other TCP features, there is no reason to oppose to the TCP-use-TLS approach.

However, I do not understand why TCPINC should need a TCP option outside the SYN. This would probably needed for header protection only. To me, payload protection does not need TCP options after initial negotiation.

I do not care whether the actual protocol running in the TCP payload is TLS, or whether it is a protocol using the crypto principles of tcpcrypt, or whether it is some third protocol still-to-be designed. This has to be sorted out by the crypto experts. I can even imagine that the IETF specifies several different TCPINC protocols in the TCP payload.

>From a TCP perspective, all these designs running in the TCP payload are equal. Once the upgrade to encryption is negotiated in the SYN, the TCP protocol engine (including segmentation offloading etc.) does not have to care about the crypto features.

> INIT1 and INIT2 are part

Indeed, use of options for something that can be done in the payload is not the right approach. TCP is pretty efficient in doing reliable in order delivery.

My suggestion is just leverage that TCP transport for all control information needed by TCPINC. Just put INIT1/INIT2, the MACs, etc. in the payload and use a clear framing method to distinguish the messages (typically this would be TLV). KISS design principle. Unless there are excellent reasons not to go down that road, which I do not see so far.

> coexistence with other options (particularly large SACK blocks).

If you decide not to change to TLV, you should at least use EDO in the next version of draft-bittau-tcpinc-tcpcrypt.
 
I actually believe that when entirely removing the header protection from draft-bittau-tcpinc-tcpcrypt, a lot of the protocol features of tcpcrypt can significantly be simplified, which results in a better and more robust protocol design.

But since this is speculation only at this stage, my key message is that I'd first like to have a look how the protocol specification without header protection and without a proprietary option encoding format looks like, before discussion any WG adoption.

> with an 8-byte length field.

My point is not the INIT1/INIT2 encoding. My concern is that somebody will in future come up with a new feature of TCPINC, e.g. a better way to protect against certain new attacks currently not known. Imagine that this extension will need more than 40B of control data. This will in particular be challenging if that information should be required mid-stream, in combination with resegmenting middleboxex etc. In that case, without either using EDO or a clean payload framing like TLV, the TCPINC community may easily have to use very complex tricks to reliably exchange said control information. Basically, TCPINC will have to solve all problems again that TCPM discusses for EDO right now. I consider it rather likely that extensions of TCPINC will be suggested in the years to come - there is usually lots of innovation in transport protocol design. I think TCPINC should define a base protocol that allows such extensions. In particular if the ambition is to become the default transport in the Internet.

So, either use EDO or just pick a payload encoding such as TLV that does not have all those problems. The latter would be strongly preferred.

> since we've had a number of drafts and no one has yet advocated that

I advocate not to mix payload and option encoding. This is a hack. Either use EDO and put everything into options, or use TLV in the payload for everything. The latter approach is much simpler and has much less interoperability issues with other TCP extensions. Therefore, I think TCPINC would need strong arguments not to TLV. But this is up to the community to decide.

Maybe this community should try to summarize if there are any reasons not to use TLV.
 
> latency if authentication doesn't fall on segment boundaries.  But

That additional latency is the time between two consecutive segments, right? On a 100 Mbps link with 1500 byte MTU, this corresponds to 0.1ms. Is this really a significant effect? Also, a sender can try to avoid this additional latency by an intelligent segmentation strategy.

I'd actually assume that segmentation offloading is much more relevant for throughput and latency. I assume segmentation offloading inherently works for any TLV design (including TLS). Has tcpcrypt been tested with hardware segmentation offloading?

> but not if you are anyway using TLV for session data.)

I really think the TCPINC working group should debate whether there is *any* reason not to use TLV in the TCP payload, given that header protection is out of scope.

This question seems entirely independent of the question whether the protocol using the TLV data structure is TLS or something else.

Michael

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Mar 2015 10:00:11 -0400

+1

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Mar 2015 10:03:53 -0400

I prefer a TLS-based solution, principally because of the
extensive experience understanding the security aspects of
TLS, and because of the code reuse opportunity.

I am willing to review and comment on future versions of docs
addressing the tcpinc requirements as now stated.

Steve

---

From: Brandon Williams <[email-masked]>
Date: Wed, 18 Mar 2015 10:28:24 -0400

As has been stated by others, I think either can work and so would not 
oppose adoption of either draft.

That wasn't really the question though. The draft I would most support 
adopting is draft-rescorla-tcpinc-tls-option because I think there are 
benefits to relying on TLS.

*  I think it simplifies ongoing threat monitoring and response to use a 
protocol that is already in broad use. Of course, when a flaw is 
discovered in that one protocol, relying exclusively on the one protocol 
can mean that we're too much at risk during the response period. That 
said, I think the benefit of simplified threat monitoring outweighs that 
risk.

* I think the fact that TLS is already in broad use would help to speed 
adoption of the tcpinc output. I recognize that tcpcrypt is also already 
implemented and deployed, but it doesn't have nearly the footprint of 
TLS and therefore doesn't have the same pre-existing base of trust that 
would encourage adoption.

--Brandon

On 03/16/2015 11:43 AM, marcelo bagnulo braun wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbittau-2Dtcpinc-2Dtcpcrypt_&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=SDQLCYrWjnC-wdDPA6CZzABU8Gj2zGGnUJea3FbkD9s&s=rUnvYbV71wh0kga8hI50zyN0FXtY1yzX64JRUYmZ9Ks&e=
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Drescorla-2Dtcpinc-2Dtls-2Doption_&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=SDQLCYrWjnC-wdDPA6CZzABU8Gj2zGGnUJea3FbkD9s&s=zVlUP7rkVUm2AHEqSfhk5p1ah6-6Q7oyYudC-YKOEbw&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tcpinc&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=SDQLCYrWjnC-wdDPA6CZzABU8Gj2zGGnUJea3FbkD9s&s=lBhIRnmELyJ_Hj09XDdr11OtjC44-DFSLzuydccO2Ds&e=
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Paul Lambert <[email-masked]>
Date: Wed, 18 Mar 2015 09:00:57 -0700

>TLS, and because of the code reuse opportunity.

TLS is poorly documented and implemented:
	https://www.smacktls.com/smack.pdf

Whatever new mechanisms are created, the more
they stand on their own the better.

Paul

---

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

On Mon, Mar 16, 2015 at 3:43 PM, marcelo bagnulo braun
<[email-masked]> wrote:
> We would like to ask the WG to express their support to adopt one (or none)
> of the following documents as WG document that will serve as a basis for the
> protocol specification. Of course, the draft, if adopted, will need to
> updated according to the WG input. In particular, they need to be updated to
> not protect the TCP header.
>
>

I strongly support draft-bittau-tcpcrypt, having read the drafts and
experimented with the prior tcpcrypt implementation.
Draft-bittau-tcpcrypt is generally well written and clear and squarely
addresses the requirements of the application space.

I do not support draft-rescorla-tcpinc-tls.

The argument to drive more towards a TLS monoculture on the internet
is not completely without merit but the complexity of the complete TLS
solution (including the rather enormous TLS protocol stack) weighed
heavily against the security and maintainability of that solution
path. This is materially attested to the much higher
running-code-factor that we've seen with TCPCRYPT than alternatives.

The track-record of actual TLS implementations in practice should also
not be disregarded; the reality seems to be that very general high
security cryptographic protocols may be at the edge of or beyond the
internet communities current collective engineering ability; The
narrower scope and purpose of tcpcrypt vastly simplifies both protocol
and implementation review, even though it may somewhat increases the
total number of security critical lines of code to be reviewed (though
even that isn't clear.).

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 20 Mar 2015 09:10:22 +0000

> total number of security critical lines of code to be reviewed (though

Code audit seems a really valid argument. Yet, from a TCP perspective, I'd come to a quite different conclusion regarding what this implies to the TCPINC design.

Unless I miss something, the difference between tcpcrypt and a solution running in the TCP payload (again, to me a TLV design does not have to be TLS) is that the tcpcrypt code audit has to analyze the complete TCP stack, whereas in case of a TLV protocol in the payload the code review just comes down to reviewing a narrow-scoped (kernel-internal or kernel-external) library handling the encryption on top of the existing, security-hardened TCP byte stream transport.
 
Production TCP stacks are very complex. As a result, my impression is that only a rather small number of developers and IETF contributors completely understand a state-of-the-art TCP implementation, in particular in corner cases that attackers would probably try to leverage. Adding a significant number of new, non-trivial features in the core of the TCP stack could have side effects that are extremely hard to detect even by TCP experts. The more features we add inside TCP, the higher the risk that we actually add *new* security bugs to all TCP-based communication, even for connections not using TCPINC.

I have no own expertise with security reviews of code. But I imagine that reviewing a library that is separated from the complex TCP protocol engine (e.g., its SACK implementation) should be simpler to many people familiar with security reviews. In particular, a reviewer would probably not have to be an expert for all segment handling aspects inside TCP, including the many non-trivial corner cases. 

In summary, I believe that for security reviews a TCPINC design running on top of the TCP byte stream should be much simpler than the current typcrypt design. What do I miss?

Thanks

Michael

---

From: David Mazieres <[email-masked]>
Date: Fri, 20 Mar 2015 10:37:33 -0700

"Scharf, Michael (Michael)" <[email-masked]> writes:

> Unless I miss something, the difference between tcpcrypt and a
> solution running in the TCP payload (again, to me a TLV design does
> not have to be TLS) is that the tcpcrypt code audit has to analyze the
> complete TCP stack, whereas in case of a TLV protocol in the payload
> the code review just comes down to reviewing a narrow-scoped
> (kernel-internal or kernel-external) library handling the encryption
> on top of the existing, security-hardened TCP byte stream transport.

One nice thing about tcpcrypt's design is that it layers very nicely
below TCP.  So if you start from the premise that your TCP
implementation is okay between two honest implementations, tcpcrypt can
be implemented without touching existing TCP code.  Indeed, the
user-level implementation does not require any changes to kernel TCP
stacks.  It's basically just a 1:1 packet rewriter.  (The only exception
is a timer for lost INIT2 segments.)  We plan to start work with Kestrel
on a verified linux tcpcrypt implementation soon, and our hope is to do
this without having to verify the whole TCP stack.

We understand that header protection is no longer in the cards.
Depending on the sentiment at the meeting next Thursday, we may
therefore change tcpcrypt to a TLV protocol.  There are certainly valid
arguments for TLV, but I suspect it will add implementation complexity
by increasing the cross-product of tcpcrypt and TCP states.  For
example, on the inbound path, you must now buffer both unverified
segments and unconsumed but verified+decrypted data, where this new
unconsumed data buffer increases code size and attack surface.  The TLV
question basically comes down to whether we want TCPINC to be layered
underneath TCP (like tcpcrypt, mostly doing packet rewriting) or on top
of it (like TLS-use-TCP, relying on TCP's reliable stream).

As a programming abstraction, TLV will look a lot more like today's TLS
than TCP.  At a high level, maybe that's okay, since TLS already works
over TCP and both provide a reliable bytestream abstraction.  But there
is more to TCP than just read and write.  So that forces a whole bunch
of subjective design decisions about how much of TCP's semantics we want
TCPINC to preserve.  E.g., what happens when the length of a TLV message
exceeds the advertised window?  Should there be any attempt to preserve
a connection with a single corrupted packet?  Should SO_LINGER wait for
secure EOF acknowledgment?

If we had a working TCP-use-TLS implementation to kick the tires on, we
could get a better sense of how people like one particular set of
answers to these questions.  If they do, then just as TCP-use-TLS
borrowed a lot of ideas from tcpcrypt, I'd feel more comfortable moving
towards their semantics for a TLV version of tcpcrypt.  But I see
TCPINC's purpose as specifically catering to applications that, for one
reason or another, have not yet adopted TLS; otherwise, today's TLS
would be the solution.  For that reason, in the absence of more data, my
inclination is to favor traditional TCP semantics over TLS ones.

David

---

From: Allison Mankin <[email-masked]>
Date: Fri, 20 Mar 2015 16:54:38 -0400

Though I've not posted to the list to date, I've been have been around the
topic for a long time, and I have read through the drafts and the
discussion.  My support goes to tcpcrypt.

Allison

---

From: marcelo bagnulo <[email-masked]>
Date: Mon, 16 Mar 2015 16:34:29 +0100

We would like to ask the WG to express their support to adopt one
(or none) of the following documents as WG document that will serve
as a basis for the protocol specification. Of course, the draft,
if adopted, will need to updated according to the WG input. In
particular, they need to be updated to not protect the TCP header.

---

From: marcelo bagnulo <[email-masked]>
Date: Tue, 17 Mar 2015 09:54:34 +0100

Thanks, marcelo

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 23 Mar 2015 14:27:46 -0500

> To make the long story short: Do *not* adopt draft-bittau-tcpinc-tcpcrypt until a new version of the draft either uses EDO or until the specification defines a future-proof encoding. I am willing t…

I second Michael's proposal to defer the adoption until a better tcpcrypt draft.

I trust the authors on getting security aspects of tcpcrypt right,
however I found the draft hard to read for a TCP implementor. For
example: the term C-MODE first appears in protocol states
enumerations. Then it was tabulated with TCP states. Then there is
special handling of FIN and C-MODE. After the main protocol section
(4), I still don't know what exactly C-MODE is.

Some questions I couldn't find definitive answers in reading the draft.
1. Does it cover sequence numbers in SACK options
2. Do pure ACK requires MAC options (I guess yes but not sure)
3. It mentions "Minimize computational cost, particularly on servers."
as a goal. Minimal compares to what?

Some 2c suggestions:
* move the examples (sec5) up front after intro
* dedicated a section to summarize the changes needed in TCP proper
* use implementation throughout the doc instead of operating systems,
end points, hosts interchangeability. esp we know tcpcrypt has
user-level impl.
* from what I can tell, the tcpcrypt has a crypto-core (sec 3) that
interfaces to the TCP (sec4). But right now the two are kinda weaved
together. The other proposal tcpinc-tls-option the interface is much
more clearer. Can we improve that in tcpcrypt?
* it'd be nice to have a section on usage scenarios of tcpcrypt and
SSL, if the app has both choices.

Thanks.

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 23 Mar 2015 21:14:29 +0000

Hi,

I support draft-rescorla-tcpinc-tls-option (for the same reasons I've expressed before) and I am in the position of reviewing the coming versions.

Be goode,

On 17 Mar 2015, at 03:54 , marcelo bagnulo <[email-masked]<mailto:[email-masked]>> wrote:

Just to add, it would ne nice if people expressing support for one draft or the other also state whether you are willing to:
- review the different versions of the draft
- contribute with text to the draft
- produce code/implement the protocol

Thanks, marcelo

El 16/03/15 a las 16:43, marcelo bagnulo braun escribió:
We would like to ask the WG to express their support to adopt one (or none) of the following documents as WG document that will serve as a basis for the protocol specification. Of course, the draft, if adopted, will need to updated according to the WG input. In particular, they need to be updated to not protect the TCP header.

We plan to discuss this on the meeting but it would be useful to start the discussion before the meeting, so if you can express your opinions before the meeting, it would be helpful.

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 24 Mar 2015 00:11:07 +0100

Marcelo,

> before the meeting, it would be helpful.

I don't think that this is the right question to ask. Tcpcrypt is a 
mature proposal while tcpinc-tls is a first idea that could lead to a 
more detailed draft later.

There are two high level questions that are hidden behind the draft 
adoption question that you asked :

1. Key exchange : do the working group members want to define a new key 
exchange scheme (see tcpcrypt) or reuse (some of) the existing TLS key 
exchange mechanisms

2. Encoding of protocol information : do the working group members 
prefer to encode information related to the operation of tcpinc mainly 
in the TCP payload by using a TLV format or mainly in TCP options

Currently, tcpcrypt relies mainly on TCP options and defines a new key 
exchange mechanims, while tcpinc-tls does not rely on TCP options and 
reuse the TLS key exchange schemes. These are two possible designs once 
we have answered these two questions, but not the only ones. Other 
combinations are possible. For example, tcpinc could design a new key 
exchange mechanism and encode the tcpinc information by using a TLV 
format in the payload.

I think that we should first discuss these two high level design 
questions before looking at the details of these two drafts.

Olivier