Scott Fluhrer (sfluhrer) writes:
> > That implementation is broken, and needs to be fixed.
>
> I can easily see a manufacturer claiming "my implementation has been
> working without a problem for 13 years; why does it need to be
> fixed?"
And the answer will be: Because it is broken, and it is
> On Nov 1, 2018, at 06:03, Tero Kivinen wrote:
>
> Scott Fluhrer (sfluhrer) writes:
>> My issue with this general idea is backwards compatibility; if we
>> issue a transform of type 5 to an old IKEv2 system, it may reject
>> the entire exchange with an "unrecognized transform type" error (and
> -Original Message-
> From: Valery Smyslov
> Sent: Thursday, November 01, 2018 7:14 AM
> To: Scott Fluhrer (sfluhrer) ; 'IPsecME WG'
>
> Cc: draft-tjhai-ipsecme-hybrid-qske-ik...@ietf.org
> Subject: RE: Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02
>
> Hi Scott,
>
> > > 1.
Hi CJ,
> > 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
Hi Scott,
> > 1. Nonces.
> >
> > The draft specifies that each additional key exchange performed
> > over IKE_AUX includes new nonces. My question - why nonces exchanged
> > during IKE_SA_INIT cannot be used instead? Is it critical for security?
>
> No, it is not. Instead, we were
On 01/11/2018, 10:00, "CJ Tjhai" 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
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
Scott Fluhrer (sfluhrer) writes:
> My issue with this general idea is backwards compatibility; if we
> issue a transform of type 5 to an old IKEv2 system, it may reject
> the entire exchange with an "unrecognized transform type" error (and
> yes, there are real systems that behave this way).
That
> -Original Message-
> From: Valery Smyslov
> Sent: Wednesday, October 31, 2018 9:55 AM
> To: IPsecME WG
> Cc: draft-tjhai-ipsecme-hybrid-qske-ik...@ietf.org
> Subject: Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02
>
> Hi,
>
> here are some comments on -02 QSKE draft to
