Subject: [tcpinc] TLV tcpcrypt code

From: Andrea Bittau <[email-masked]>
Date: Mon, 30 Mar 2015 10:10:56 -0700

All,

As per the meeting feedback, we started implementing tcpcrypt using TLV and
we no longer MAC the header.  You can download the code from our TLV branch
at:

git clone https://github.com/scslab/tcpcrypt.git
git checkout tlv

We also set up:

http://tlv.tcpcrypt.org

On that site, you'll get a session ID only when using the TLV code.  The
main site (www.tcpcrypt.org) still runs the old code.

We're updating the draft and will send a revised one soon.

thanks

---

From: Tim Shepard <[email-masked]>
Date: Mon, 30 Mar 2015 13:25:54 -0400

> we no longer MAC the header.  You can download the code from our TLV branch

It seems to me you have a choice of what sort of TLV encoding to use
at this point.   Is there any good reason not do use the same sort of
TLV scheme that TLS uses today, so that at least as far as the TLV
framing protocol the two proposals would be the same?

Yes, I know it is probably more complicated than you would like, but
it is an already well known, already existing way of framing, and
adopting it to move incrementally closer to compatibility would
probably be worth it at this point.

			-Tim Shepard
			 [email-masked]

---

From: ianG <[email-masked]>
Date: Mon, 30 Mar 2015 18:45:49 +0100

> probably be worth it at this point.

Surely the better direction would be to move towards what TCP does?  We 
are fundamentally talking about TCP, so its methods and manners should 
dominate, no?

Most discussions I have seen about the low level framing of TLS & 
friends indicate it is wildly complicated and overdone, and something to 
distance from in new designs, not emulate.

(Although to be fair, I'm not really sure what this entails beyond the 
catch-all phrases of TLV & TCP.  And, I'm not even sure I agree with 
imposing TLV over all of tcpinc.  It opens the door to "flexibility" aka 
complexity, whereas tightness and purpose is better in my mind.)

iang

---

From: Tim Shepard <[email-masked]>
Date: Mon, 30 Mar 2015 14:23:39 -0400

> complexity, whereas tightness and purpose is better in my mind.)

Where you in the WG meeting (or listening in remotely)?  My
understanding of the consensus in the room was that using TCP's
framing for tcpinc would make tcpinc too brittle in the face of
middleboxen which resegment the TCP connection (despite having let
the initial options through where we negotiated tcpinc on).  Yes, we
all agree they those middleboxes shouldn't be doing that, but the
desire to make tcpinc continue to work through those sorts of boxes
mandates that we not use TCP's framing but do our own framing in-band
(within the bytestream carried by TCP).    And the tcpcrypt folks
agreed to respin their proposal with in-band TLV-like framing.

			-Tim Shepard
			 [email-masked]

---

From: ianG <[email-masked]>
Date: Mon, 30 Mar 2015 20:07:09 +0100

On 30/03/2015 19:23 pm, Tim Shepard wrote:
> Where you in the WG meeting (or listening in remotely)?

No, 'fraid not.

> My
> the initial options through where we negotiated tcpinc on).

Hmmm ok - thanks for that, so at least there is a positive reason.

> Yes, we
> (within the bytestream carried by TCP).

I see that there might be an issue here, although I do not see why the 
muddleboxen would breaking the framing, no matter which method is used.

> And the tcpcrypt folks

Yes, saw that, in the minutes.  Just didn't understand why.

I guess the tcpfolk have seen the evidence of this and have the handle 
on it and how this new framing solves the problem.  If it is just a 
matter of handling framing that trips up middle boxes, then fine.

If however it is a matter of "becoming more compatible with TLS" this is 
an oddity that is beyond my comprehension...

thanks again.

iang

---

From: David Mazieres <[email-masked]>
Date: Mon, 30 Mar 2015 17:55:50 -0700

> framing protocol the two proposals would be the same?

As far as I understand, TLS MACs then encrypts the data.  (Apologies if
I've misread RFC5246.)  The best current practice is to encrypt then MAC
the ciphertext.  Since there's no need to be compatible, we might as
well use the best practices as of 2015.  See, e.g.:
http://cseweb.ucsd.edu/~mihir/papers/oem.pdf

David

---

From: Tim Shepard <[email-masked]>
Date: Mon, 30 Mar 2015 22:38:30 -0400

> http://cseweb.ucsd.edu/~mihir/papers/oem.pdf

Well, ekr did say that TLS would be profiled for use in tcpinc.  So
presumably rfc7366 would be in the profile of TLS for tcpinc.

			-Tim Shepard
			 [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 31 Mar 2015 07:01:31 -0700

> presumably rfc7366 would be in the profile of TLS for tcpinc.

Either that or (my preference) specify an AEAD (combined encryption
and integrity) algorithm such as AES-GCM or ChaCha/Poly1305.
It's always hard to read community consensus, but my sense is that
AEAD represents the current best practice.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 31 Mar 2015 07:02:38 -0700

> AEAD represents the current best practice.

I should have mentioned, TLS 1.2 already supports AEAD algorithms and
they're the only constructions which will be allowed in TLS 1.3.

-Ekr

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 31 Mar 2015 11:44:11 -0400

>> AEAD represents the current best practice.

I think this fairly states the TLS WG's consensus.

> they're the only constructions which will be allowed in TLS 1.3.

This is true, but the framing mechanism (after the first handshake) is
potentially up for a transition in 1.3 as well.

I think it would be a mistake for tcpcrypt to duplicate the TLS framing
mechanism byte-for-byte.  TLS carries with it a complicated and
difficult legacy, and its framing is a part of that.  tcpcrypt has an
opportunity to not deal with that legacy, and can be cleaner.  let's be
cleaner where we can be :)

        --dkg

---

From: Brian Trammell <[email-masked]>
Date: Tue, 31 Mar 2015 17:51:08 +0200

Greetings, all,

> On 31 Mar 2015, at 17:44, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

+1 to learning from the past, yes.

Learning from my own past, corner cases in framing are an excellent place to make design mistakes that you won't find for a while because, hey, it's only framing and framing's easy, right?

Not saying we shouldn't do it, but while "let's invent a new framing" doesn't raise as many flags as "hey look at my shiny new cipher!", it still makes me nervous.

Cheers,

Brian

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 31 Mar 2015 09:52:41 -0700

> cleaner where we can be :)

I'm not arguing that tcpcrypt (if adopted) should use the TLS framing
(though of course if we were to adopt the TCP-use-TLS proposal
then of course we should use the TLS framing).

-Ekr

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 31 Mar 2015 22:47:34 +0300

> > Where you in the WG meeting (or listening in remotely)?

Note, that you can watch the recorded show at meetecho... Some people
did say that tcpinc was one of the most entertaining sessions, so it
might be worth of it (or not :-)

http://ietf92.conf.meetecho.com/index.php/Recorded_Sessions

http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF92_TCPINC&chapter=chapter_0
-- 
[email-masked]