Subject: [tcpinc] The way forward

From: Tero Kivinen <[email-masked]>
Date: Tue, 21 Jul 2015 10:23:38 +0300

During the meeting yesterday we made plan how to go forward. The plan
is summarized below:

----------------------------------------------------------------------
- Confirm during the list that we do not have consensus now for week,
   after that continue this process if so
   
- Timeline
   - Aug: Working group to review current drafts and send comments
   - Sep: A full but not final specification
     - For tcpcrypt: means including all the changes resulting from WG input
     - For TLS means a complete profile for TCPINC
   - Oct: Provide comparison of the proposals
   - Nov: An implementation that matches the specification that the
     implementers claims that matches the above specification

- If both fail to deliver: we close the WG

- If one fails, we choose the other one as starting point

- If both deliver,
   - We do a consensus call, for 2 weeks
   - If no consensus : we do a coin toss (something else?)

- If the room consensus on this way forward is not confirmed in the
   list, we close the WG.
----------------------------------------------------------------------

So that will mean that during this week we (chairs) will make straw
poll on the list to confirm that we do not have consensus about which
draft to pick as starting point for the tcpinc.

Then during the August work group members should read the current
drafts, and send comments, so draft authors can update their draft as
needed. For TLS based draft it would actually be more useful to get
one update as soon as possible to include proper profile to be used in
the tcpinc, so WG have some time to comment on that.

Before the end of September, the draft authors will submit the "full
but not final specifications". For the tcpcrypt, that will mostly mean
addressing comments raised by the WG, for the TLS it would mean proper
profile (hopefully we will get that earlier, but this is the latest
time for it).

Then during October, we and draft authors can compare the proposals,
and try to summarize what is the main differences between them and
what are pros and cons for each version compared to each other.

Finally before the November meeting, we would like to see some kind of
implementation that matches the specification. This does not mean
production quality code, but more or less proof-of-concept type of
implementation. Mostly just to show that the specifications are in
such shape that they can be implemented based on the text provided.
These will most likely come from the draft author teams, but if
someone is willing to make independent implementations that would be
best...

Then in the November meeting we will try to see if we have consensus
on which draft to pick as starting point, and we will not have
consensus, then we will pick one by coin toss (or some other suitable
method).

This email is just to confirm in the working group that we do have
consensus about this way forward.... 
-- 
[email-masked]

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 21 Jul 2015 07:39:44 +0000

>     - For TLS means a complete profile for TCPINC

I thought we agreed on a complete, *self-contained* profile for TLS. Self-contained meaning one doc that someone can hand to their dev team which they can read without the need to consult (too many) other documents to understand what an implementation would entail.

(In other words, not a document that says "read and understand all of TLS, and then ignore pieces X, Y and Z.)

Lars

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jul 2015 09:50:18 +0200

On Tue, Jul 21, 2015 at 9:39 AM, Eggert, Lars <[email-masked]> wrote:

> I thought we agreed on a complete, *self-contained* profile for TLS.
> Self-contained meaning one doc that someone can hand to their dev team
> which they can read without the need to consult (too many) other documents
> to understand what an implementation would entail.
>

I don't recall that agreement. I know that some people were in favor of it,
but I think it's
a bad idea, and I don't think there was anything like consensus to do it.

-Ekr

(In other words, not a document that says "read and understand all of TLS,
> and then ignore pieces X, Y and Z.)
>
> Lars
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Jul 2015 08:59:07 +0100

> a bad idea, and I don't think there was anything like consensus to do it.

+1 to ekr on that - I think an informed opinion on this topic does
require IETFers to understand the work-in-progress that is TLS1.3.

Whether an eventual RFC ought or ought not be self-contained is a
question the WG can consider if the TLS approach is adopted.

So I'd characterise the requirement for the TLS draft for this
milestone as being that the draft needs to specify a complete
profile, but need not necessarily be self-contained.

S.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 21 Jul 2015 11:22:03 +0300

Eggert, Lars writes:
> Self-contained meaning one doc that someone can hand to their dev
> team which they can read without the need to consult (too many)
> other documents to understand what an implementation would entail. 

Yes, that something that I would like to see. I am not competely sure
whether it needs to be completely self-contained.

I mean in my ikev2 minimal draft, I had 6 pages of actual description
of the protocol, and that is the important part to understand how
IKEv2 works, and what needs to be done. Then at the end of that
document there is about 20 pages of payload formats for payloads used
in the protocol. In my case I cut & pasted the actual payload formats
from the IKEv2 RFC, but I could have just provided references, i.e.
for "Key Exchange Payload" look at section 3.4 of RFC 7296.

> (In other words, not a document that says "read and understand all
> of TLS, and then ignore pieces X, Y and Z.)

Yes, I would not consider that as complete profile. I think this is
what the current draft is now, but not even fully mentioning which
pieces to ignore... 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 21 Jul 2015 11:40:53 +0300

Eric Rescorla writes:
> I don't recall that agreement. I know that some people were in favor
> of it, but I think it's a bad idea, and I don't think there was
> anything like consensus to do it.

During the meeting people did say that would favor for that, and I do
not remember anybody really saying otherwise either... 

We did not really ask for consensus for that, but at least I got
impression that this is what working group would like to get (i.e.
people seemed to nod their heads when this was discussed). I.e. such
document would be preferred by the WG.

I do understand that this is more work for you, but after making ikev2
minimal draft myself, I actually say it is useful document to have
anyways, as it condenses the essence of protocol to core components,
and that makes it much easier to understand (even for someone who is
quite familiar with the protocol). I think it too me few hours to make
the initial version of the minimal draft.
-- 
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jul 2015 10:48:05 +0200

> not remember anybody really saying otherwise either...

I though I said I was against it.

> the initial version of the minimal draft
>

I'm not concerned about the level of effort; I'm concerned about having
multiple normative references for the same protocol.

-Ekr

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 21 Jul 2015 12:18:13 +0300

> multiple normative references for the same protocol.

My minimal draft says in abstract:

   This document does not update or modify RFC 7296, but provides more
   compact description of the minimal version of the protocol.  If this
   document and RFC 7296 conflicts then RFC 7296 is the authoritative
   description.

And actually my minimal draft has not been published as RFC, but it
has already been useful to make people to understand how IKEv2 can be
used on the IoT devices or other cases where minimal implementation is
needed.

http://datatracker.ietf.org/doc/draft-ietf-lwig-ikev2-minimal/
-- 
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Jul 2015 10:33:19 +0100

> multiple normative references for the same protocol.

Right. I don't want to risk complicating the TLS1.3 effort, esp for a
draft we don't even know will be adopted.

S.

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Jul 2015 09:36:59 -0700

+1

Cite, don't replicate.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 22 Jul 2015 10:35:48 +0200

On Tue, Jul 21, 2015 at 11:33 AM, Stephen Farrell <[email-masked]
> wrote:

> draft we don't even know will be adopted.
​This set of messages reinforces the concern raised in a set of exchanges
that was in the room:  will a tcpinc based on TLS be able to make progress
at a reasonable rate with tcpinc's concerns being only a part of a much
larger effort?    It's obvious that creating a profile of TLS 1.3
appropriate for tcpinc is a significant amount of work, whether we are in
cite-and-explain or copy-and-keep-current mode.

To re-iterate my own view:  either of these approaches seems capable of
meeting the needs set out in the charter.  Continuing to delay the choice
will leave flows unencrypted for longer and longer.   The delay is also
harmful, though, if it is derived from the need to harmonize instead of the
need to make a tough choice. Put another way, if the AD for TLS 1.3 is not
willing to complicate the TLS 1.3 effort with this work, perhaps it should
be withdrawn from consideration.

regards,

Ted Hardie
/no hats

---

From: David Mazieres <[email-masked]>
Date: Wed, 22 Jul 2015 13:08:10 -0700

> draft we don't even know will be adopted.

But supposing the self-contained profile description is not normative?

I'll grant you that two normative descriptions of TLS are a bad idea.
At the same time, if it's impossible to produce a concise non-normative
description of what TCP-use-TLS looks like on the wire, then some of us
believe that's a disadvantage for TCP-use-TLS, or at least evidence that
the "minimal profile" is not sufficiently minimal.

Additionally, should the wire description of TCP-use-TLS reveal any
vulnerabilities, that will complicate the TLS1.3 effort, but the
complication would consist of necessary bug fixes.

David

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 24 Jul 2015 03:29:25 -0500

Dear all,

This point got lost on the mailing list, but it has been decided in the 
WG session here at IETF-93 that there will be a Last Call for consensus 
about which document of the below ones to take as starting point for the 
WG.

Here are the two drafts:
a) draft-rescorla-tcpinc-tls-option-03
b) draft-bittau-tcpinc-tcpcrypt-03

Please respond to the tcpinc wg mailing list until

    July 31st, 2015
    1pm CEST

on wether you prefer
- either draft a) or b)
- or none

to be accepted as WG item.

Please write also your brief reasoning on why you made your choice.

Please note that accepting a draft is not the end of working on the 
technical content of the draft, but it is actually the starting point 
when the WG has full change control about the content of the draft!

Regards,

   Martin Stiemerling
   Transport Area Director

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 24 Jul 2015 17:43:35 +0000

Hi,

I tend to go with option b) to be adopted as a WG document; Which, in my mind, does NOT imply that it's technically cemented at that point, but rather becomes a proper IETF document, with the WG having change control over it. And implementer experience DOES matter (as does time, IMHO).

I would further like to point out to like the idea that was voiced by Tim Shephard at the last IETF, that perhaps the current running code, and some of the ideas of the other draft can eventually be reconciled; But I do not like the logjam that has been evident over the last couple months.

Best regards,
 Richard

> -----Original Message-----
> From: Tcpinc [mailto:[email-masked]] On Behalf Of Martin
> Stiemerling
> Sent: Freitag, 24. Juli 2015 10:29
> To: [email-masked]
> Subject: [tcpinc] Reminder: Ongoing Working Group Last Call about drafts
> to choose as WG item
> 
> Dear all,
> 
> This point got lost on the mailing list, but it has been decided in the WG
> session here at IETF-93 that there will be a Last Call for consensus about
> which document of the below ones to take as starting point for the WG.
> 
> 
> Here are the two drafts:
> technical content of the draft, but it is actually the starting point when
> the WG has full change control about the content of the draft!
> 
> 
> Regards,
> 
>    Martin Stiemerling
>    Transport Area Director
>

---

From: ianG <[email-masked]>
Date: Fri, 24 Jul 2015 18:57:52 +0100

Proceed with b) draft-bittau-tcpinc-tcpcrypt-03.

I am opposed to putting TLS into TCP.  I think that approach as a 
project will put too much weight above the waterline and capsize is the 
likely option as soon as we hit heavy seas.

It could be any flavour of protocol inside TLS.  But it should be lean, 
tight, simple.  And modern.  And working code and experience speaks 
volumes.  b) has got all that, afaics.

While TLS has working code outside TCP, and substantial experience, it's 
also got huge technical debt and is very slow to update at the 
institutional level.

It's also philosophically troubling.  TLS is for the people who need 
security.  TcpInc is for everyone else.  Putting them together confuses 
the discussion which leads to mission madness.

iang

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Fri, 24 Jul 2015 18:18:11 +0000

Hi,

I'd support the adoption of (a) as a starting point. It serves the purpose of opportunistic encryption and allows applications to seek full TLS if available and upgrade to it.

Be goode,

On 24 Jul 2015, at 10:29 , Martin Stiemerling <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

This point got lost on the mailing list, but it has been decided in the WG session here at IETF-93 that there will be a Last Call for consensus about which document of the below ones to take as starting point for the WG.

Here are the two drafts:

  July 31st, 2015
  1pm CEST

on wether you prefer
- either draft a) or b)
- or none

Please note that accepting a draft is not the end of working on the technical content of the draft, but it is actually the starting point when the WG has full change control about the content of the draft!

Regards,

 Martin Stiemerling
 Transport Area Director

_______________________________________________
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: Joe Touch <[email-masked]>
Date: Fri, 24 Jul 2015 13:22:41 -0700

+1

On 7/24/2015 11:18 AM, DIEGO LOPEZ GARCIA wrote:
> Hi,
> 
> I'd support the adoption of (a) as a starting point. It serves the
> purpose of opportunistic encryption and allows applications to seek full
> TLS if available and upgrade to it.
> 
> Be goode,
> 
>> This point got lost on the mailing list, but it has been decided in
>> the WG session here at IETF-93 that there will be a Last Call for
>> consensus about which document of the below ones to take as starting
>> point for the WG.
>>
>>
>> Here are the two drafts:
>> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
> 
> 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
> 
>