On 01/11/2018, 10:00, "CJ Tjhai" <c...@post-quantum.com> wrote:

    Hi all,

    >
    > That implementation is broken, and needs to be fixed.

    What's the procedure on this? Is there a need to publish a document or
    some test vectors that all implementations can validate against?

    Personally, it is more logical to introduce new transform types for
    QSKEs, but one of my concerns is how can we guarantee that all broken
    implementations are fixed?

>> I would also not know how to guarantee that all deployed broken 
>> implementations can be fixed.

    Consider the following simplified proposal:

    SA Payload
          |
          +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 0,
          |      |            6 transforms)
                +-- Transform ENCR ( Name = ENCR_AES_CBC )
                |     +-- Attribute ( Key Length = 256 )
                +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 )
                +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 )
                +-- Transform D-H ( Name = Curve25519 )
                +-- Transform QSKE1 ( Name = Foobar )
                +-- Transform QSKE2 ( Name = Zappa )

    At the moment, some broken implementations may abort the exchange
    entirely and in some way, this helps as we may want to establish a
    connection with a broken implementation. On the other hand, there
    could be other implementations that ignore both QSKE1 and QSKE2 and
    return a response as if there is an implicit second proposal:
         |
          +--- Proposal #2 ( Proto ID = IKE(1), SPI size = 0,
                |            4 transforms)
                |
                +-- Transform ENCR ( Name = ENCR_AES_CBC )
                |     +-- Attribute ( Key Length = 256 )
                +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 )
                +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 )
                +-- Transform D-H ( Name = Curve25519 )

    So more complex checks will be required to cater for all broken cases.
    I have no idea what response we will get from other broken
    implementations.

    Or alternatively, do we have to rely on another Notification payload
    to check for potential backward compatibility issues?

    I think it would be great to also get some thoughts from VPN
    manufacturers on this point.

    > That is not true. Section 3.3.3 lists mandatory types, and those
    > optional types, which are included in that RFC. It does NOT list any
    > of the future optional types.
    >
    > In section 3.3.6 this is explained very clearly:
    >
    >    If the responder receives a proposal that contains a Transform Type
    >    it does not understand, or a proposal that is missing a mandatory
    >    Transform Type, it MUST consider this proposal unacceptable; however,
    >    other proposals in the same SA payload are processed as usual.
    >    Similarly, if the responder receives a transform that it does not
    >    understand, or one that contains a Transform Attribute it does not
    >    understand, it MUST consider this transform unacceptable; other
    >    transforms with the same Transform Type are processed as usual.  This
    >    allows new Transform Types and Transform Attributes to be defined in
    >    the future.
    >
    > I.e., the intention is that if there is transform type you do not
    > understand you skip whole proposal, but STILL PROCESS rest of the
    > proposals normally, i.e., this allows backward compatiblity.
    >

    Yes, this is how it should behave.

    Cheers,
    CJ



________________________________
The information contained in this message may be confidential and legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified 
that any use, forwarding, dissemination, or reproduction of this message is 
strictly prohibited and may be unlawful. If you are not the intended recipient, 
please contact the sender by return e-mail and destroy all copies of the 
original message.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to