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

["Black, David" <[e-mail]>]

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
> > alternate, more direct approach along those lines by Eric R ?? was
> > rejected, FWIW).

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

> > 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".

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.

> > 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.
> 
> ENO explicitly was designed 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).

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.

> > 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.
> 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 :-)

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

Thanks, --David

> -----Original Message-----
> From: Tsv-art [mailto:[e-mail]] On Behalf Of Mirja
> Kühlewind
> Sent: Thursday, October 12, 2017 9:42 AM
> To: Joe Touch <[e-mail]>; Martin Stiemerling
> <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of
> 10/11
> 
> Hi Joe,
> 
> On 12.10.2017 15:25, Joe Touch wrote:
> >
> >
> > 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.Sorry I
> missed that request.
> 
> >
> >> 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.
> 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.
> 
> >
> >> 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".
> 
> 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.
> 
> >
> >> 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.
> 
> QUIC as standardized in the IETF currently is using TLS1.1 (as explicitly
> stated in the charter I believe).
> >
> > 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.
> 
> 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).
> 
> >
> >> 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.
> 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
> 
> 
> >
> > 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
> >>
> >>
> >>
> >> On 12.10.2017 06:21, Joe Touch wrote:
> >>> 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 <[e-mail]>
> >>>> 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.
> >>>>
> >>>> 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
> >>>>
> >>>> _______________________________________________
> >>>> Tsv-art mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/tsv-art
> >>>
> >>> _______________________________________________
> >>> Tsv-art mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/tsv-art
> >>>
> >
> > _______________________________________________
> > Tsv-art mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tsv-art
> >
> 
> _______________________________________________
> Tsv-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tsv-art