Subject: Re: [tcpinc] Encryption of TCP Options

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 1 May 2016 21:30:56 -0700

Hi,
I am thinking about dividing encrypting a TCP segment into the two parts:
A) encrypt arbitrary part of a TCP segment and B) determine which parts of
a TCP segment should be encrypted.
Because I might want to think them separately if possible.

>From my point of view, when we encrypt TCP payload, we just mask the header
part of the TCP segment before encryption.
I am naively thinking that it's not very difficult to change masking areas.
So, I am thinking designing TCPINC to do A) might be possible.
OTOH, B) might need some more discussions and may take time as we may want
to think and analyze the behavior of middleboxes.

So, what I am wondering is if we can design A) while selecting TCP payload
as the arbitrary part for the time being and continue discussions for B)
for future extensions.
--
Yoshi

On Tue, Apr 26, 2016 at 11:50 PM, Mirja Kühlewind <
[email-masked]> wrote:

> Hi all,
>
> I briefly brought this up in the last meeting and would like to start the
> discussion on the mailing list now. The working group decided that tcpinc
> will not encrypt the TCP header for good reasons. However, it would still
> be possible to encrypt TCP options. This could help keeping confidentiality
> and would avoid that a middle could alter information in a option or strip
> it. Not sure if there is a case where some options should be encrypted and
> some not but I guess that would be possible as well. Any thoughts?
>
> Mirja
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc
>

---

From: David Mazieres <[email-masked]>
Date: Mon, 02 May 2016 14:59:00 -0700

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

> 1. Get an ExId from IANA. I think filling out
> http://www.iana.org/form/protocol-assignment can be done in 5min. This
> can be done by anybody interested in experimenting with TCP options,
> because it is clear that there is a need to experiment with TCP
> extensions prior to an official TCP option kind assignment by
> IANA. RFC 6994 was written for that.

Just to update everyone, I did actually submit an application for an
ExID, though I haven't heard back yet.  To the extent possible, I'd like
everyone to be happy with our efforts, but I also don't want to hold up
TCP-ENO because of an ID allocation catch-22.

I proposed that we keep on the current (squatting) path for now, but if
at some point we are able to secure an ExID, then we can switch over to
follow an RFC7413-like template.  Is that fair?

David

---

From: Joe Touch <[email-masked]>
Date: Mon, 2 May 2016 15:03:04 -0700

FWIW, IANA doesn't have a published expected turnaround time, but for
FCFS items like this it's not uncommon to take 1-2 weeks -- not because
of a delay in the FCFS process but because that queue has a small slice
of an overloaded server... ;-)

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 2 May 2016 22:38:34 -0700

On 5/1/2016 9:30 PM, Yoshifumi Nishida wrote:
> A) encrypt arbitrary part of a TCP segment and B) determine which
> parts of a TCP segment should be encrypted.
> From my point of view, when we encrypt TCP payload, we just mask the
> header part of the TCP segment before encryption.   

That would mean that encryption would depend on the length of the header
part. Middleboxes are known to insert, delete, fold, spindle, and
otherwise mutilate options, which means that you would be encrypting
over a different length of zero-content prefix.

At a minimum, you need to know where the TCP payload is and start there,
not merely mask out the header. That currently involves parsing only the
TCP base header, but in the future may also involve parsing one of the
TCP options (TCP-EDO) (which would further complicate the notion of
encrypting options or even a portion thereof)

> I am naively thinking that it's not very difficult to change masking

AFAICT, it would defeat encryption (or should).

Joe

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 3 May 2016 19:47:00 -0700

Hi Joe,

> encrypting options or even a portion thereof)

We'll need to know where the encryption part is. If it's payload, it will
be easy as we can get the starting point from the header.
But, I am guessing it doesn't have to be payload.
We cannot control the behavior of middleboxes. They might do some unknown
things whether the segment is encrypted or not.
All we can do is to detect if the encrypted parts are tampered (which
should be possible) and react to it (discard the segment, fallback to
normal TCP or reset the connection, etc) based on some policies.

> Hmm.. Sorry, I couldn't catch this. Could you elaborate?

Thanks,
--
Yoshi

---

From: Joe Touch <[email-masked]>
Date: Wed, 4 May 2016 12:58:56 -0700

Hi, Yoshifumi,

On 5/3/2016 7:47 PM, Yoshifumi Nishida wrote:
> Hi Joe,
>
> On Mon, May 2, 2016 at 10:38 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
> We'll need to know where the encryption part is. If it's payload, it
> will be easy as we can get the starting point from the header.
...
> Hmm.. Sorry, I couldn't catch this. Could you elaborate?

It's just a comment on using "masking" rather than an offset to start
encryption.

I.e., encrypting over "0abc" yields a different result than "abc". It's
not sufficient to just mask-out the prefix area if that area could vary
in length.

A side note: some implementations put TCP headers and payloads in
different places, so "just backing up to include the options" can
require more complicated code than it may first appear as well.

Joe

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 4 May 2016 14:07:16 -0700

can someone please give a real example how encrypting what options can
_significantly_ improve TCP, because it is clearly not a small change.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 6 May 2016 00:34:18 -0700

Hi Joe,

On Wed, May 4, 2016 at 12:58 PM, Joe Touch <[email-masked]> wrote:

> not sufficient to just mask-out the prefix area if that area could vary in
> length.
>
> different places, so "just backing up to include the options" can require
> more complicated code than it may first appear as well.
>

OK. I'm not very sure how it is complicated to take care of masking and to
follow linked lists in memory. But, anyway, I still think it's at least
worth for discussion as an optional feature.

Thanks,
--
Yoshi

---

From: David Mazieres <[email-masked]>
Date: Fri, 06 May 2016 12:46:15 -0700

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

>> But more to the point, what is your concrete proposal? 
>

Alright, everyone.  Looks like step 1 is complete and we have been
officially assigned ExID 0x454E (mnemonic: in network byte order it's
the bytes for ASCII "EN").

This will be reflected in the next draft, probably sometime later this
month.

David