Here are the preliminary minutes of the IPsecME meeting in Chicago.
Send corrections, and additions etc to me.
Thanks to Michael and Tommy for taking the minutes.
----------------------------------------------------------------------
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.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
