Subject: [tcpinc] four more months... then pixie dust?

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Jul 2015 09:34:48 +0100

Hiya,

I see a lot of folks preferring option 1 which is basically
to wait and see if some magic pixie dust appears before November
that causes the WG to achieve rough consensus for one approach
over the other.

The WG have failed to choose a *startung point* a couple of
times now and all that will happen in the next 4 months (including
holidays) is that the two proposals will be slightly harder to
separate since the authors will inevitable try adopt the strengths
of the alternative proposal where possible and mitigate whatever
has been seen as a weakness in their own proposal. I have seen
this pattern a number of times in the IETF and it has always
ended badly that I've seen. This one seems to me to be ending
similarly badly, sadly.

Can someone explain why I'm highly likely to be wrong and just
what pixie dust will magically appear here and help over the
long hot summer? (During which many sensible folk will go away
for a month.)

IMO, option 1 == more pointless prevarication. Closing the WG
now or letting Martin pick now are the only sensible choices IMO.

I think asking the AD to pick is more sensible in cases like
this since regardless of which *starting point* is adopted, the
WG will get to change that however they like before the process
is done. We are not doing an IETF LC here, we're supposed to be
deciding which *starting point* to work from, more than a year
after we should have gotten that done. I also don't see any need
for RFC3929 stuff here, nor do I think that is suited for cases
like this at all. IMO Martin can decide based on his take on
the reasonable set of technical arguments already made, none of
which are really "winning."

Frankly, I think the unwillingness to choose-and-make-progress
in this WG is demonstrating the IETF at it's near worst. (And
yes, this is written in irritated-by-that mode;-)

S.

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Jul 2015 08:01:22 -0700

On 7/17/2015 1:34 AM, Stephen Farrell wrote:
...
> is done. 
...

Anyone who has looked at buying an old home knows about "remuddling"
(remodeling gone wrong), where every individual change made sense in its
context but the result is an incomprehensible and unusable mess.

> I also don't see any need
> like this at all. 

Hmm. I'd like to understand why you think it isn't suited for EXACTLY
this case.

> IMO Martin can decide based on his take on

RFC3929 is quite illuminating in NOT offering "AD selects" as an option.

I would note that RFC3929 seems to imply that a decision must be made. I
consider this WG yet another exercise in politics over content, and the
fact that it's failing a strong signal that a decision should not be
pushed by the IESG.

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Jul 2015 17:00:50 +0100

Hiya,

> Hmm. I'd like to understand why you think it isn't suited for EXACTLY

3929 says "In most of these cases, there are two or
more competing proposals at approximately the same level of technical
maturity, deployment, and specification."

I think that doesn't match this situation well where we have one
draft that's fairly fully specified with code and some limited
deployment (but that would likely change in the WG process) and
another that is really an outline, but an outline that can clearly
form a basis for achieving the same functionality if a bunch of
relatively obvious work is done in future.

> RFC3929 is quite illuminating in NOT offering "AD selects" as an option.

3929 does however say " This is not meant to provide
   an exhaustive list" and one of the choices listed is to
select one person to just pick (in 4.3). I think Martin in this
case would be a good person given that he's afaik not stated
which he favours yet has paid attention to all the arguments.
(Well, I at least don't know which he favours and I believe
he's paid attention:-)

I will admit however, that 3929 isn't my favourite RFC - I
figure it was a reasonable attempt to codify something that may
be better off handled case-by-case. But reasonable people can
reasonably disagree about that.

S.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 17 Jul 2015 09:01:15 -0700

On Fri, Jul 17, 2015 at 1:34 AM, Stephen Farrell <[email-masked]>
wrote:

> ​I think wait and see is the wrong characterization; the proposal is to
work on both.  If one gets worked on more than the other, that is signal
that it should get more review and effort​ from the rest of the IETF.  If
that review shows flaws, we can correct them at that point (by shifting to
the other proposal if need be, or just fixing them in situ, since there's
already a lot of borrowing).

​(I would personally be okay with the option "Assume you will raise two
siblings", and require that the working group come up with an overall way
to support new methods as they arise, as a form of agility in this space.
The current situation then becomes a worked example.  I understand the
contrary vision is "single basket, watched carefully", but it's not the
only vision).

> ​

> ​If we actually do work, instead of marvel at the difficulty of picking a
pretty baby, the dust for each proposal might get ground finer, letting us
choose?​

> WG will get to change that however they like before the process

​I don't think this is within the IETF process.  The IESG could revise the
charter to name a starting point, but the revision would go through the
usual community review.   You could also use RFC 3929, since the ​community
agreed to that experiment, and after the working group consensus to use it
name the AD as the one doing qualified short-straw selection, but I think
it would be cleaner to have someone not in the appeals chain for this
decision.

> We are not doing an IETF LC here, we're supposed to be
​As the rtcweb experience shows, it can be very frustrating, but
compromises can also emerge.

Ted​

​

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Jul 2015 10:31:41 -0700

> relatively obvious work is done in future.

I see your point, but would include other context in comparing the two
approaches - e.g., based on well-established mechanisms vs. not, not
implemented but relatively clean interaction with TCP vs. not, which
puts them on a much more equal footing (which is part of why the WG has
not converged).

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Jul 2015 21:01:57 +0100

> puts them on a much more equal footing (which is part of why the WG has

Yep, that's fair, I wasn't trying to include all context and the above
points are clearly why deciding has been hard. My point though against
option 1 is that deciding won't get easier in 4 months.

S.

---

From: Andrea Bittau <[email-masked]>
Date: Fri, 17 Jul 2015 22:37:12 -0700

I think that we can make progress as long as the format of the meeting
isn't:

    "Here's TLS-option ; Here's tcpcrypt ; Which should we use?"

Even though it's been a long stalemate, tcpcrypt itself did benefit from
the WG

and some progress has been made.  For example, at IETF 91 we (the WG)
decided

not to MAC the header.  At IETF 92 we decided to use TLV.  Both resulted in
new

tcpcrypt drafts and code.  I hope that at this IETF we can continue this
design

effort, though in a more concentrated way.

It's clear that by November the WG needs to produce a substantial result
and not

just keep debating.  I suggest that we use this meeting to define this
result.

Specifically, we should:

    1) Define what we want from TLS-option (e.g., a profile?, code?, etc.).

    2) Define what we want from tcpcrypt (e.g., some handshake feature?).

    3) Discuss a generic "start encryption" TCP option that can select any

       tcpinc protocol.

    For both #1 and #2 we should spend time designing and discussing the

    protocol (as if it were the only contender) to see WG dynamics when
asked to

    work on a specific protocol.

The protocols can then be developed in the coming months and in November we
can

check to see if one result is superior.  If none is, the generic "start

encryption" option might be the best way forward, leaving it to natural

selection to decide which particular encryption option becomes most popular.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 17 Jul 2015 23:11:06 -0700

On Fri, Jul 17, 2015 at 10:37 PM, Andrea Bittau <[email-masked]> wrote:
> Even though it's been a long stalemate, tcpcrypt itself did benefit from the
> WG
>
> It's clear that by November the WG needs to produce a substantial result and
> not
>

This option has serious costs: it forces operating systems to ship
both stacks for compatibility reasons, and delays widespread adoption
and use even further. I used to think Buridan's Ass was a fable. Now I
realize it was prophecy.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.