Subject: [IPsec] IPsecME Status update 2016-09-02

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Sat, 3 Sep 2016 03:00:33 +0000

Charter update

  The charter is currently under review by the IESG. A new version
  was posted to address some of the IESG feedback on 2016-09-02.
  Thanks to Kathleen for her help with the edits. No objection on
  the list. Should go forward, on the 2016-09-15 IESG telechat.

  https://datatracker.ietf.org/doc/charter-ietf-ipsecme/

Document Status:

- draft-ietf-ipsecme-ddos-protection (David)

  Submitted to the IESG on 2016-08-18. Requested for publication
  as a Proposed Standard.

- draft-ietf-ipsecme-rfc4307bis (David)

  WGLC issued for -11 on 2016-09-02. The call will close on
  September 19th, 2016.

- draft-mglt-ipsecme-rfc7321bis (David)

  Call for adoption was issued on 2016-09-02. The call will close on
  September 14th, 2016 UTC 23:59.

- draft-ietf-ipsecme-safecurves (Tero)

  Submitted to the IESG on 2016-08-30. Requested for publication
  as a Proposed Standard.

- draft-nir-ipsecme-eddsa (Tero)

  I think this is still waiting for the curdle to decide for OID, but
  we could start WG adaptation call, as this is now in our charter,
  and this is good starting point.

- draft-ietf-ipsecme-tcp-encaps (Tero)

  This should also be ready for WGLC. 

New work:

- Quantum Resistance (David)

  Discussion has started on the mailing list about the requirements
  and when we have those decided on the list, we should start working
  on document.

- draft-pauly-ipsecme-split-dns (David)

  This was accepted as charter item, but need few more reviews before
  taking it as WG draft. 

- draft-mglt-ipsecme-implicit-iv (Tero)

  This was also accepted as charter item, but would like to see few
  more reviews before taking it as WG draft.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 15 Sep 2016 17:28:53 +0300

Hi,

we recently ran into one interoperability problem that is concerned
with RFC 7427.

We start testing RSASSA-PSS with another vendor product and found, 
that while it supports Digital Signature authentication method, it seems
to not support RSASSA-PSS signatures in IKE. As a result, the SA 
is failed to be created if we use RSASSA-PSS (and we do use it
because we want to be compliant with RFC-to-be draft-ietf-ipsecme-rfc4307bis,
that states that with Digital Signature RSASSA-PSS-SHA256 is MUST).

The problem is that RFC7427 doesn't provide any means to find out
what kind of signatures peer supports. If you have RSA certificate,
you need somehow to guess whether you can use newer PSS signature
format or should stick to old PKCS 1 one. The SIGNATURE_HASH_ALGORITHMS
notification doesn't provide any information of this kind. RFC7427
is silent whether support for RSASSA-PSS is required to be compliant
with it, so I think it is absolutely legal now to have support for Digital Signature
authentication method and have no support for RSASSA-PSS 
(as in the product we have tested with).
The draft draft-ietf-ipsecme-rfc4307bis does requires that if
Digital Signatures are supported, then RSASSA-PSS with SHA2-256
MUST be supported. However, even if it becomes RFC in near future,
it'll take a couple of years before it is adopted by major vendors.

I think that it is a more fundamental problem: RFC7427 allows peers
to announce what hash functions they support, but the peers 
cannot announce what kinds of signatures (or what signature formats)
they support. Few years ago life was simpler: there were a couple
of widely used signature schemes and they use different types of
public keys. So, if you had RSA certificate, you could be sure that
RSA PKCS 1 signature format would be understood by anyone.
Now we have new incompatible RSA signature format - RSASSA-PSS
and mere having RSA certificate is not enough to choose right
signature format. I envision that similar situation can repeat
in the future with Elliptic Curve certificates. Now new kind of signature
is being developed for Edwards curve public keys - EDDSA.
However, as far as I anderstand, any Edwards curve key can
be converted to short Weierstrass's form and used in ECDSA.
So we'll probably have a mess when some implementations
support EDDSA, while some use Edwards keys in ECDSA
(at least for a while), that will result in interoperability problems.

So, my question is - what to do with all this.
1. Do nothing. Coming back to the interoperability problem we have,
    it is possible to find some workarounds:
    - don't use RSASSA-PSS until it becomes ubiquitous (however if everybody
        follows this way it'll never become ubiquitous)
    - it is possible for the initiator to restart exchange if it receives
       AUTHENTICATION_FAILED while using RSASSA_PSS
        and use RSA PKCS 1 in the new run. However, this approach
        will slow down connection setup and waste resources of
        both initiator and responder.
    - it is possible for responder to look at the format of signature 
        the initiator used and act in accordance - if the initiator
        doesn't use RSASSA-PSS then don't use it.
    These are all workarounds and they complicate implementations
    and waste resources for no good reason.
2. Add some indication of signature form/format the peers support.
    I can see two possible solutions.
    - define new entries in Hash Algorithms registry
        that are not hash functions but are rather signature formats.
        For example, add RSASSA_PSS. If it is included
        in SIGNATURE_HASH_ALGORITHMS notification.
        it will mean that this format is supported with any real hash
        algorithms that are included in this notification.
        It is clearly a hack of RFC 7427.
    - define new notification SIGNATURE_FORMATS, which
        will include supported signature forms/formats.
        It seems to be a most "proper" way, however 
        it is the slowest one (new RFC is needed).

What the WG thinks of all this?

Regards,
Valery.