Minutes IETF97: tcpinc
minutes-97-tcpinc-00

Notes taken by Aaron Falk (aaron.falk@gmail.com)
If you add notes in this Etherpad please put your name below to enable
color-match.
--------------------------

AGENDA
        TCP Increased Security (tcpinc) Agenda at IETF-97 (Seoul)

        Friday, November 18, 2016, 9:30-11:30
        Room Name: Studio 4

        WG Status Update
        Chair(s)
        10 minutes

        TCP-ENO: Encryption Negotiation Option
        draft-ietf-tcpinc-tcpeno-06
        Dave Mazi�res
        40 minutes (including discussion)

        tcpcrypt: Cryptographic protection of TCP Streams
        draft-ietf-tcpinc-tcpcrypt-03
        Andrea Bittau
        40 minutes (including discussion)

        <bash: inssert discussion of API doc>

        TCPINC Queries to CFRG
        Kyle Rose
        20 minutes (including discussion)

        Open Mic
        10 minutes

NOTES

Agenda bash
    * Adding discussion of API doc after tcpcrypt

Chairs update
    *
    https://www.ietf.org/proceedings/97/slides/slides-97-tcpinc-tcpinc-wg-chair-slides-ietf-97-00.pdf
    * Long email discussion on URG/FIN bits on list * documents tweaked
    accordingly * believe docs are ready for last call * Unlikely to meet Jan
    date for API, will discuss later today * Need to figure out what to do
    about middlebox probing * CALL FOR IMPLEMENTORS: TCP-ENO and tcpcrypt need
    independent
      implementations

TCP-ENO: Encryption Negotiation Option - Dave Mazires
    *
    https://www.ietf.org/proceedings/97/slides/slides-97-tcpinc-tcp-eno-encryption-negotiation-option-00.pdf
    * Goal of TCP-ENO: faciliate adoptions of future TCP encryption protocols
      (TEPS) by abstracting details
        * Q: is data in SYN for session resumption?  A: no, for future TEP
          implementations & applications that want SYN-only data (e.g., key
          exchange data)
    * Improving wording for TEP requirements to avoid reopening RFC793
    * David B commments
        * application independent authentication would be a fine followon but
          should be specific
        * Do you use A-bit in your prototype?  yes, we have a binary
          replacmemetn for libssl.  if A bit isn't supported, use vanilla SSL.
        * Dedicated TCP option: game plan: get through wg last call first, then
          ask for 69.  Joe Touch's experience and input will be helpful.  Rough
          consensus of the wg is to use 69.
        * (as an individual) suggest don't 'create an optional way to signal
          ENO implemented but disabled' - already pretty complicated, sounds
          like gratuitous functionality.
            * Kyle: disagree it is gratutious.  doesn't complicate protocol.
              helpful to alert other side that ENO is supported.
            * Mirja: don't see big benefit, you'll need to do renegotiation
              next time anyway
            * David: might be useful to detect whether middleboxes are passing
              ENO, for measureing deployment success.
            * Tero Kivnen: other end needs to be able ignore it, so doesnt add
              any complexity.  Would be beneficial compared to what was
              avaialble iwth IPsec.  THinks it would be OK.
            * Kyle: 2 cases it helps: 1. probing and 2. preventing spurious
              resets -- need to discuss and get consensus call xon the mail
              list.
            * Dave will propose a diff to the list.  Should be very short ~ 2
              sentences
            * Martin Duke: not opposed if IANA, complexity, and doc costs are
              negligable
            * Mirja: might want to make it legal to send an empty ENO option
              but not require it; will allow measurement

tcpcrypt: Cryptographic protection of TCP Streams - Andrea Bittau
draft-ietf-tcpinc-tcpcrypt-03
    *
    https://www.ietf.org/proceedings/97/slides/slides-97-tcpinc-tcpcrypt-00.pdf
    * Review mechanism * Discussion
        * Tero: look to Chicago hackathon for implementors, attract students
        * Andrea: we might be able to contribute some framework code
        * Mirja: there's a website where you can call for implememtation help,
          will send link
        * Dave M: Stanford would love to hire someone to do this, just need
          money

API discussion
    * Assume it is functionally complete and ready for last call with the other
      two drafts
    * missing a few things as identified in Dave's talk, very close
    * proposal: sequence the last calls, don't include API doc in 1st last call
      to avoid them getting out of sync,
    * Run WGLC on both tcpcrypt & TCPENO proposals at the same time

TCPINC Queries to CFRG - Kyle Rose
    *
    https://www.ietf.org/proceedings/97/slides/slides-97-tcpinc-tcpinc-queries-to-cfrg-00.pdf
    * Asked CFRG to review some TCPCRYPT topics
        * TCPCRYPT offers session ID as primitive to bootstrap endpoint
          authentication
        * ENO can be used to negotiate different encryption protocols
        * Worried about requirements on security properties of session IDs
            * Dave M: experince shows over-specfiying is preferred; eg.,
              session id should be indistinguishable from random
            * David B: maybe that is sufficient to solve the problem
            * DKG: 2 kinds of unlinkability: to the peer & to the network.
              need to state which is the requirement.
            * David B: need some precise terms, prefereably written in the
              security area.  where?  Shouldn't block the work, though.
            * DKG: might look in the HRPC group as they are interested in
              unlinkability
            * Mirja will bring this topic to IESG / IAB wrapup for potential
              IAB recommendation development