Subject: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 10/11

From: Martin Stiemerling <[email-masked]>
Date: Wed, 11 Oct 2017 10:07:25 +0200

Dear TSVers,

I did work through all documents that are in IETF LC, IESG processing or 
being requested for publication as of 10/11, 10:00 am CEST.

Please find below all documents checked and what to do with these
documents.

There are a two documents out of TCPINC that are important and probably 
should be reviewed by the TSVART, if not somebody has already reviewed 
those as part of the regular TCPINC WG review:
draft-ietf-tcpinc-tcpeno-10
draft-ietf-tcpinc-tcpcrypt-07

Any volunteers or did someone out of the TSVART (David probably?) any 
read it?

Documents that require TSV attention:
draft-ietf-i2nsf-framework-08 -- Martin
draft-ietf-dhc-relay-port-06 -- Jörg (changed, was assigned to Colin)
draft-ietf-sunset4-ipv6-ietf-01 -- Michael Tuexen
draft-ietf-nvo3-mcast-framework-10 -- Colin, as he did review -09
draft-ietf-mboned-interdomain-peering-bcp-11 -- Yoshifum (AD request by 
Mirja)

Documents that do not require TSV attention:
draft-ietf-netconf-rfc6536bis-06
draft-ietf-lime-yang-connectionless-oam-methods-09
draft-ietf-lime-yang-connectionless-oam-11
draft-ietf-acme-acme-07
draft-schaad-curdle-oid-registry-02
draft-ietf-rmcat-scream-cc-11 -- TSV owned
draft-ietf-sidrops-bgpsec-rollover-02
draft-ietf-uta-email-deep-09
draft-ietf-ospf-segment-routing-extensions-19
draft-ietf-dnssd-hybrid-07
draft-ietf-anima-voucher-05
draft-ietf-anima-prefix-management-05

Thanks,

   Martin

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 Oct 2017 21:21:41 -0700

Hi Martin (et al.),

I’ve (unfortunately) tracked TCPCRYPT and ENO since their introduction to the IETF. I remain unclear on what problem they’re trying to solve, other than to integrate TLS into the TCP 3WHS (an alternate, more direct approach along those lines by Eric R ?? was rejected, FWIW). It doesn’t protect the TCP layer at all.

IMO, both would benefit from at least a cursory pass by fresh eyes, though. Besides, at this point I doubt anything I have to say hasn’t been said (and largely ignored) before.

Joe

> On Oct 11, 2017, at 1:07 AM, Martin Stiemerling <[email-masked]> wrote:
> 
> Dear TSVers,
> 
> I did work through all documents that are in IETF LC, IESG processing or being requested for publication as of 10/11, 10:00 am CEST.
> 
> There are a two documents out of TCPINC that are important and probably should be reviewed by the TSVART, if not somebody has already reviewed those as part of the regular TCPINC WG review:
> Any volunteers or did someone out of the TSVART (David probably?) any read it?
> 
> 
> draft-ietf-mboned-interdomain-peering-bcp-11 -- Yoshifum (AD request by Mirja)
> 
> 
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 12 Oct 2017 10:34:41 +0200

Hi Joe,

not sure, what your actual request is to the triage team but they usually 
don't assign tsv document for tsv-art review. Also your concern seems to be 
quite fundamentally about the approach taken by the working group and it 
seems simply too late to change anything about this now as the document(s) 
are in IETF last call.

However, let me provide you some more input as responsible AD and previous 
chair. The TLS-based proposal was not rejected at all. There was, however, 
not enough energy in the group to follow on with that approach now, so the 
only option to finish up any time soon was to go with tcpcrypt. However, the 
reason why there is tcpeno, is that this mechanism can still be used to 
negotiate the use of TLS and the hope it that this proposal will still be 
finished at some point of time. I personally think that just having a 
negotiation mechanism in TCP for TLS could provide a stronger incentive for 
adoption but as far as I can tell there is currently anyway not a huge 
interest in deploying tcpinc (probably also because QUIC could provide a 
alternative if you want an encrypted transport).

I hope that addresses your concerns at least a bit. Thanks for your feedback 
though! I really appreciate your (and some others) efforts to have an eye on 
what's going on! Honestly thanks!

Mirja

---

From: Joe Touch <[email-masked]>
Date: Thu, 12 Oct 2017 06:25:33 -0700

On 10/12/2017 1:34 AM, Mirja Kühlewind wrote:
> Hi Joe,
>
> not sure, what your actual request is to the triage team but they
> usually don't assign tsv document for tsv-art review.
I was responding to Martin's request, not making one of my own.

> Also your concern seems to be quite fundamentally about the approach
> taken by the working group and it seems simply too late to change
> anything about this now as the document(s) are in IETF last call.
Any review - at any stage, for any reason - can bring up issues with the
need for an approach and the utility of the approach provided.

> However, let me provide you some more input as responsible AD and
> previous chair. The TLS-based proposal was not rejected at all. There
> was, however, not enough energy in the group to follow on with that
> approach now, 
I disagree; what I saw were "votes" to pick *a* solution, not multiple
ones. In particular, working on multiple solutions was deemed to
undermine the goal of "we have one that everyone will use".

> so the only option to finish up any time soon was to go with tcpcrypt.
> However, the reason why there is tcpeno, is that this mechanism can
> still be used to negotiate the use of TLS and the hope it that this
> proposal will still be finished at some point of time. I personally
> think that just having a negotiation mechanism in TCP for TLS could
> provide a stronger incentive for adoption but as far as I can tell
> there is currently anyway not a huge interest in deploying tcpinc
> (probably also because QUIC could provide a alternative if you want an
> encrypted transport).
QUIC is basically TLS for UDP: https://www.chromium.org/quic
In fact, the project claims to want to adopt TLS 1.3 in place of its
interim approach.

I don't know if ENO will support anything other than TCPCRYPT; it may be
intended that way, but the jury is out exactly because nobody else is
using it.

> I hope that addresses your concerns at least a bit.
It doesn't.

I was giving my impression as context, but basically encouraging someone
else from TRIAGE to volunteer to give these docs a pass. If that's not
useful, perhaps you should let Martin know he didn't need to ask for that.

Joe

> Thanks for your feedback though! I really appreciate your (and some
> others) efforts to have an eye on what's going on! Honestly thanks!
>
> Mirja
>
>
>
>> I’ve (unfortunately) tracked TCPCRYPT and ENO since their
>> introduction to the IETF. I remain unclear on what problem they’re
>> trying to solve, other than to integrate TLS into the TCP 3WHS (an
>> alternate, more direct approach along those lines by Eric R ?? was
>> rejected, FWIW). It doesn’t protect the TCP layer at all.
>>
>> IMO, both would benefit from at least a cursory pass by fresh eyes,
>> though. Besides, at this point I doubt anything I have to say hasn’t
>> been said (and largely ignored) before.
>>
>> Joe
>>
>>> I did work through all documents that are in IETF LC, IESG
>>> processing or being requested for publication as of 10/11, 10:00 am
>>> CEST.
>>>
>>> There are a two documents out of TCPINC that are important and
>>> probably should be reviewed by the TSVART, if not somebody has
>>> already reviewed those as part of the regular TCPINC WG review:

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 12 Oct 2017 15:41:56 +0200

Hi Joe,

On 12.10.2017 15:25, Joe Touch wrote:
> I was responding to Martin's request, not making one of my own.Sorry I missed that request.

> need for an approach and the utility of the approach provided.
Sure, you can bring up new issues but issues regarding the selection of this 
approach have been discussed before and I don't think it will be use useful 
to revisit that argument at this stage.

> undermine the goal of "we have one that everyone will use".

This was before I took over the group as chair. These (kind of weird) votes 
didn't lead to any conclusion. When I took over the group we adopted both 
proposals but the author of the TLS one later explained that he would not 
have the time commitment to follow on, so the group concentrated on 
finalizing the tcpcrypt approach.

> In fact, the project claims to want to adopt TLS 1.3 in place of its

QUIC as standardized in the IETF currently is using TLS1.1 (as explicitly 
stated in the charter I believe).
> intended that way, but the jury is out exactly because nobody else is

ENO explicitly was designed to to support other approaches, especially TLS. 
There was even a registration for the TLS in the ENO draft. I told the 
authors to remove that because that registration should be done by the TLS 
draft itself (if it every gets finished).

> useful, perhaps you should let Martin know he didn't need to ask for that.
Sorry again, I missed that. I personally think we don't need further tsv 
reviews at this stage. But of course any additional review can help.

@Martin: David is the chair of the tcpinc group and shepherd of one of the 
drafts, so he has certainly reviewed it already :-)

Mirja

---

From: "Black, David" <[email-masked]>
Date: Thu, 12 Oct 2017 14:20:09 +0000

Writing as a TCPINC WG chair ...

> > I remain unclear on what problem they’re
> > trying to solve, other than to integrate TLS into the TCP 3WHS 

First sentence of charter:

	The TCPINC WG will develop the TCP extensions to provide unauthenticated encryption and integrity protection of TCP streams.

The key word here is "unauthenticated" - in practice TLS needs to be authenticated, usually with a certificate.  A second important distinguishing aspect is that this is layered functionality that is intended to provide communication security to applications that don't have TLS or similar security functionality.

> > (an
> > rejected, FWIW).

the "was rejected" statement is not correct ...

> > undermine the goal of "we have one that everyone will use".

As Mirja explained, the ADs noticed that unproductive activity and made some changes because the "beauty contest" to choose one crypto approach a priori was consuming time without making any forward progress.  The result in the latter part of 2015 was WG adoption of drafts for a common negotiation option and both crypto approaches.   Based on the level of WG participant interest and ability to work on the drafts, the tcpcrypt crypto work has been completed, and work on the TLS-based crypto work could be resumed if there is sufficient interest in doing so.

> > It doesn’t protect the TCP layer at all.

That's mostly correct, but not 100%.   The underlying situation is that the WG decided not to do anything that would break middlebox resegmentation (send gag reflex responses to /dev/null, please), which makes it impossible to do much in the way of protecting TCP headers.  OTOH, there is some modest TCP protection provided, e.g., this blocks injected FINs.

> ENO explicitly was designed to support other approaches, especially TLS.

While both Joe and Mirja are correct, I concur with Joe's view of the likely future - the TLS-based crypto approach seems unlikely to be completed.

> drafts, so he has certainly reviewed it already :-)

Indeed I have reviewed, but more reviewer eyes never hurt ...

Thanks, --David

> -----Original Message-----
> From: Tsv-art [mailto:[email-masked]] On Behalf Of Mirja
> Kühlewind
> Sent: Thursday, October 12, 2017 9:42 AM
> To: Joe Touch <[email-masked]>; Martin Stiemerling
> <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of
> 10/11
> 
> Hi Joe,
> 
> >>>> draft-ietf-mboned-interdomain-peering-bcp-11 -- Yoshifum (AD
> request
> >>>> by Mirja)
> >>>>
> >>>>

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 26 Oct 2017 09:59:10 +0200

Hi Mirja, and Joe,

Am 12.10.17 um 10:34 schrieb Mirja Kühlewind:
> usually don't assign tsv document for tsv-art review. Also your concern 
> seems to be quite fundamentally about the approach taken by the working 
> group and it seems simply too late to change anything about this now as 
> the document(s) are in IETF last call.

I did put the ENO and TCPCRYPT docs on the list, as I did wonder if 
there is a need for more review.

However, this was purely a question, as I wasn't sure how the review 
quality was (not blaming anybody, but I haven't followed the review 
process thoroughly).

Cheers,

   Martin