Minutes IETF98: ipsecme
minutes-98-ipsecme-00

IPSECme meeting.
IETF98.

Tero and David as Chairs.
Room Montreux 3.  13:00, March 29, 2017.

- Slides about finished and almost finished WG drafts. -bis drafts are
  approved by IESG but have minor changes needed. TCP Encaps in IETF
  last call, pushed out by a week.

- 4307bis issues.

  - will fix ENCR_3DES will be "MAY"

  - EcDSA based auth expected downgrade, but we are still "SHOULD",
    and this will be retained: because there is no hash negotiation. 

  - If things go fine, and we move to EdDSA ("safecurves"), then we
    might get rid of EcDSA, but this is far from a foregone
    conclusion.  Much discussion about intention here, and why it is
    SHOULD, and not SHOULD-.  This document is past the IESG approval,
    so only minor inconsistency changes will be acceptable. 

  - We do not have enough implementations to move Digital Signatures
    from SHOULD to SHOULD+. (ditto ecdsa-with-sha256). 

  - ChaCha is believed to be SHOULD, not SHOULD+, but that may not be
    reflected in the draft?  (confirmed to be the case) 

  - GPP3 -13 will use Digital Signatures, and so it will be pushed
    forward. 

 - 7321bis IESG issues.

   - Manual keying issues

     - ENCR_AES_CBC will need to be fixed.

     - Clarify that some algorithms MUST NOT be used, while ones not
       mentioned MAY be used.

     - Comments that manual key seems the only way to do multicast
       IPsec.... (PAUL suggests that in a few years there will be no
       safe algorithms.)

 - EdDSA issues

   - Some kind of chicken and egg problem with openssl.

   - The algorithm we use is determined by the certificate type, and
     so far no CAs provide EdDSA certificates. 

   - Report from Tommy that he has EdDSA. We request the authors to
     ask for the codepoint, as 5. 

 - Split DNS

   - Recent changes: Removed the way to request the list of domains.
     The sender can only request a 0 size list. Removed requirement
     for Child SA to contain the DNS server IP address. 

   - IKEv2 says you can send requests optionally, so the text needs to
     be updated 

   - Open question is what to do with cache entries on disconnect.
     Paul thinks we should flush the cache whenever you change the
     resolver. Tero thinks there could be issues if the IKE SA goes
     down and comes back up and connections fail. Yoav says that if
     you don't flush, you'll have stale records. Tero says you'll try
     to access the old addresses and bring up the tunnel again.
     Michael says that if you have two answers inside and out it is
     insecure. Tommy says that sometimes deployments use different
     addresses not for security, but for keeping track of what context
     the client is from. The problem is the real world vs the ideal
     DNS world. Proposing that we soften the language to say that this
     is a client policy, and the options are to always flush the
     cache, or if you know that your domains are globably valid still,
     you can not flush the cache. Tero agrees that it is not an
     interop issue, since it's a local policy issue. The current text
     says "MUST" flush the cache, and that MUST is the problem. Paul:
     should we just change MUST to SHOULD, or do we include the
     discussion. Authors will decide. 

 - Quantum Resistant IKEv2

   - Current proposal is to stir in shared secret to derived keys. The
     entropy makes it infeasible to break. 

   - Last meeting agreed that algorithm agility is important, that ESP
     needs to be protected but IKE is not as important 

   - Open issues: how to stir in the shared secret. Draft stirs into
     each Child SA derivation. Valery suggested just using the SK_d,
     which will apply for all future derivations. It helps to not have
     to remember which key you used. Dan Harkins proposed only
     modifying KEYMAT. 

   - Darrell: We need to do something about this before NIST. Tero:
     wants to do something in IKE not just in KEYMAT so that IKE would
     fail if something goes wrong. SK_d has a good property since it
     is in IKE SA rekeys. We want PPK failures to look like auth
     failures. Michael: I agree with Tero-whatever we do, it should be
     locally loggable about which one failed. Some people may think
     "if I've gone through the trouble of sharing a PPK, why do I need
     other auth?". How easy do we want to make this, to encourage
     potentially less secure implentations from adopting. If we don't
     make it easy, why bother? We should have a way to distribute
     PPKs. Tero: It should be easy to implement regardless of how
     important implementers think it is. We don't need to specify the
     format here, will likely be binary blob. 

 - Implicit IV

   - Why? Save 8 bytes on every ESP packet. Counter-based algorithms
     are becoming more widely used. They don't need unpredictable IVs,
     so the IV can just be a counter (like the sequence number). Just
     remove the IV in the packets when negotiated. Requires new
     transform IDs. AES GCM, CCM, and ChaCha. 

   - Talked to EKR since and pointed out that it may be inefficent to
     have the new IDs, but we may not have better alternatives. There
     is a way to do with other algorithms that are AES based. 

 - Minimal ESP

   - This is draft about doing the minimal implementation of the ESP,
     i.e., still keep in line with the normal ESP, but what kind of
     tricks implementor can do to make the actual code smaller on the
     constrained devices. Similar to the minimal IKEv2 RFC but for ESP.