Subject: [Taps] Stephen Farrell's No Objection on charter-ietf-taps-00-00: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 26 Jun 2014 05:13:54 -0700

Stephen Farrell has entered the following ballot position for
charter-ietf-taps-00-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/charter-ietf-taps/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Also along the lines of Alissa's comment, I'd be interested in 
whether and how the security properties of transports are to
be handled here. I hope they are, but it'd be good for a final
charter to mention that. One specific instance of that that'd 
be useful to consider could be tcpinc. That might lead to 
tricky timing, but OTOH, it'd be a pain if tcpinc were ignored 
here.

Many applications actually fall back to (or just stick with) HTTP
for the reasons stated here, I don't know if it makes sense
to de-scope those applications here or not, but hope that 
that's discussed during chartering (maybe it has been already?).

Stupidly, I find paragraphs and sentences that start with 
an adverb, comma are harder to read. Annoyingly, for me, 
this charter does that. Politely, I'd ask you to consider fixing 
that:-)

---

From: <[email-masked]>
Date: Thu, 26 Jun 2014 22:44:09 +0000

Security is out of scope for this charter - just as QoS is. 

A working group focused on future new security-focused
encapsulations would also be out of scope.

I have seen emphasis on security above all else derail work on transports elsewhere,
to the detriment to getting any decent transport work done. While there's always a
security context to protocol work, explicitly putting security in the charter moves
this group to yet another security group, and derails the stated purpose of the
workgroup.

I have no objection to the charter - as it stands.

Sincerely,

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Taps <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Sent: Thursday, 26 June 2014 10:13 PM
To: The IESG
Cc: [email-masked]
Subject: [Taps] Stephen Farrell's No Objection on charter-ietf-taps-00-00: (with COMMENT)

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

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 26 Jun 2014 18:26:02 -0500

> Security is out of scope for this charter - just as QoS is.

So, just to try to keep things straight ... the theory is that no matter 
how one Lego-assembles one's transport, one could use TLS or DTLS above 
that transport, if one is relying on the aspects of security those 
mechanisms provide? Does TAPS need to go beyond that?

I take Stephen's point about TCPINC happening in parallel with TAPS.

I'm wondering if relying on something like TCPINC-ng that would provide 
TCPINC-style unauthenticated encryption and integrity protection for 
non-TCP transports would make sense, if that turned out to be feasible, 
rather than trying to fly in formation with TCPINC, which was approved 
on the formal telechat earlier today, so it already has a head start ...

Spencer

---

From: Barry Leiba <[email-masked]>
Date: Thu, 26 Jun 2014 19:37:06 -0400

> So, just to try to keep things straight ... the theory is that no matter how
> one Lego-assembles one's transport, one could use TLS or DTLS above that
> transport, if one is relying on the aspects of security those mechanisms
> provide? Does TAPS need to go beyond that?

I think it should.  I think that encryption, TLS-style server
authentication, and the like are just as much transport services as
are congestion control and in-order delivery.  The whole point here is
to remove the specification of what services are needed from the
specifics of the transport protocols that provide them.

And TLS as we know it today requires TCP.  In a TAPS world, it would,
itself (if it were not part of the transport layer), have to specify
what transport services it requires.

I would like to see "transport layer security" become a true part of
the transport layer, not in name only.

Barry

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 26 Jun 2014 20:52:11 -0500

> specifics of the transport protocols that provide them.

I get that. What I'm wondering might break into two questions:

- How much awareness of security do we expect (and let's say "new") 
applications to have? and

- Is the security part of "transport services" factorable, or do we have 
to do it in TAPS?

I should emphasize that I don't have opinions about the right answer to 
either of these questions.

I'm just holding the pen, and trying to get a charter written that's 
worth carrying out.

Spencer

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Fri, 27 Jun 2014 06:48:57 +0000

With this proposed charter, I thought TAPS wasn't going to be building
protocols itself, other than the experimental protocol to choose among
different transports (what we've been calling "angry eyeballs" because of
the number of different combinations you would have to check if you just
extend happy eyeballs naively).

Some of the transport characteristics will be more security-relevant than
others, and should likely have a note to that effect in their description.
 Once we have a close-to-exhaustive list of characteristics with their use
cases, it will be much easier to do architecture on how to compose those
characteristics into a transport in a secure manner.  It's *way* too early
to do that now by deciding which characteristics are required.

If we need to modify the text in the group's third action item ("Specify
experimental mechanisms...") to make it more clear that there won't be any
actual transport protocol development, but only the angry-eyeballs bit, it
might make the IESG more comfortable.

-- 
Joe Hildebrand

---

From: Barry Leiba <[email-masked]>
Date: Fri, 27 Jun 2014 03:55:52 -0400

> might make the IESG more comfortable.

That would certainly do it for me -- though I was comfortable before, as well.

Barry

---

From: Michael Welzl <[email-masked]>
Date: Fri, 27 Jun 2014 10:14:16 +0200

> That would certainly do it for me -- though I was comfortable before, as well.

And myself, I'm more comfortable with leaving that item as it is  :-)

Cheers,
Michael