Re: [IPsec] meeting at IETF-95 ?

Count me too. Regards, Valery. +1 to having a meeting at IETF 95. Thanks, Tommy On Jan 12, 2016, at 6:56 AM, Paul Wouters wrote: I hope we are scheduling a meeting for IETF-95. Last time we did not meet and ended up meeting in the hallway. This time there are more drafts

Re: [IPsec] NIST question concerning IKEv2 and quantum resistance

Hi Scott, Scott Fluhrer (sfluhrer) wrote: > - It defines the transform of the nonce from the on-the-wire version into the > one presented to the IKEv2 KDF (mixing in the PPK). > - The initiator gives an indication of which PPK to use (without leaking any >

Re: [IPsec] SLOTH & IKEv2

I think that responder must verify the cookie if it is present, regardless on whether it is expected to be present or not. And it must request another cookie if the verification failed. That would allow an initiator to trigger the cookie generating mechanism on the responder on demand. I don't

Re: [IPsec] SLOTH & IKEv2

[HJ]So to summary what has been discussed previous in this thread: On Initiator side: - This attack is impractical if the initiator's SPIi is unpredictable, since it is infeasible for attacker to compute C1/C2 offline for all possible SPIi. And it is impossible to compute C1/C2 online before

Re: [IPsec] SLOTH & IKEv2

OK, but if those extra payloads are disguised as some notification (there is no payload actually called “info”), then responders do tend to ignore notifications they don’t recognize. True, but in this case the inputs to the hash function will be different (you need to insert Notification

Re: [IPsec] SLOTH & IKEv2

[HJ] according to this figure(https://securityblog.redhat.com/wp-content/uploads/2016/01/sloth-ike-2.png): The IKE_INIT request(m1') send to real responder contain infoi' at the end, which equals=SAi|g^x|Ni|infoi, so the actual m1'=HDR|C2|SAi'|g^x'|ni|SAi|g^x|ni|infoi; thus two SA, tw KE, two

Re: [IPsec] SLOTH & IKEv2

I must correct myself - if attacker takes care and puts the Notify payload header at the end of ck it sends to initiator (and he must correctly guess the length of info`), then it will work - all the original payloads from the initiator will appear inside Notification payload and will be ignored

[IPsec] SLOTH & IKEv2

implementations? Regards, Valery Smyslov. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06

HI Paul, I'd rather change it a bit: When the Responder is under attack, it SHOULD prefer previously authenticated peers who present a Session Resumption ticket [RFC5723]. However, the Responder SHOULD NOT swich to resumed clients completely (and thus refuse every IKE_SA_INIT

Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecMEWG document

Hi, I support adopting this document. I think we need to have a PQ-secure solution in IPsec. I'd like to see it generic enough and not limiting to QKD technology only. I'd also like to have IKE SA to be protected, as well as Child SAs, so that this solution can be used in cases when sensitive

Re: [IPsec] draft-fluhrer-qr-ikev2-01

Hi Tero, I think you are doing this wrong. There is no need to change the SKEYSEED calculation. That only prototects the IKE SA encryption, authentication keys. It would be much better to change the KEYMAT calculation only, and keep the SKEYSEED calculation as it is now. SKEYSEED is used to

Re: [IPsec] Textual changes to the DDoS draft

That was also my impression. And the draft is already being edited to include multiple puzzles. Valery. - Original Message - From: Yoav Nir To: Waltermire, David A. Cc: ipsec@ietf.org WG Sent: Friday, February 26, 2016 8:43 AM Subject: Re: [IPsec] Textual changes to the

Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK

Hi, I as an IANA expert got request from 3gpp to allocate new configuration attribute called TIMEOUT_PERIOD_FOR_LIVENESS_CHECK for IKEv2. This is used to set the timeout after which the UE will do liveness check with other end if no cryptographically protected IKEv2 or IPSec messages are not

Re: [IPsec] draft-fluhrer-qr-ikev2-01

Hi Michael, > I think that the protection of IKE SA is important. This would preserve > IKEv2 security properties (like protecting identities against passive > attacker) and would allow to re-use the solution in G-IKEv2 and other > IKEv2 derivations that do transfer sensitive

Re: [IPsec] draft-fluhrer-qr-ikev2-01

That would certainly be a more implementable suggestion, if the WG is OK with the idea that the IKE SAs not being protected. It would make like living with an HSM easier to deal with, while making the process of deciding which PPK to use simpler. We may end up including a simple notification

Re: [IPsec] SLOTH & IKEv2

Hi Tero, The attack can be easily modified so that the message sent from the attacker to the responder looks unsuspicious. All that attacker need to do is to find C1 and C2 so, that the COOKIE notification type in C1 is changed to any unused status notification type in C2. It is just a little

Re: [IPsec] NIST question concerning IKEv2 and quantum resistance

Hi Scott, I see the point, thank you. However AES support in hardware is not always available, so I still think that having a single crypto primitive is better in this situation. But your explanations brings me to a conclusion, that the protocol could me modified. Please see my logical chain.

Re: [IPsec] SLOTH & IKEv2

You should have read the rest of that paragraph: For MD5, the most efficient collision attacks do not have a compatible message difference, but it seems possible to build a dedicated attack with complexity below 2^39. However, for SHA-1, all known collision attacks use differences in every

Re: [IPsec] DDoS Protection - single vs multiple solutions

Hi, As we’re nearing WGLC for the DDoS protection draft, there is a question we’ve left open in the past that should be resolved. The issue is with the variability of the time it takes to solve a puzzle. To demonstrate it, I ran a simulation of trying to solve a 20-bit puzzle 1000 times on

Re: [IPsec] DDoS Protection - single vs multiple solutions

I tend to support this idea, but I think in this case the sub-puzzles must be chained to deal with parallel solving. Something like the following: Puzzle_data[0] = cookie Puzzle_data[1] = Puzzle_solution[0] | cookie Puzzle_data[2] = Puzzle_solution[1] | cookie ... Puzzle_data[n] =

Re: [IPsec] DDoS Protection - single vs multiple solutions

With a chain such as you’re suggesting, I could still parallelize. For each step I could still partition the key space and search in parallel until one solution was found before proceeding to the next step. Yes. So it seems that the chaining is useless. Yoav Regards, Valery.

Re: [IPsec] draft-fluhrer-qr-ikev2-01

an additional secret that is shared between the initiator and the responder; this secret is in addition to the authentication method that is already provided within IKEv2.] s/in addition/an addition ? 3. IANA Considerations section is missing. Regards, Valery Smyslov. Last year, NSA made a

Re: [IPsec] draft-fluhrer-qr-ikev2-01

in using AES. What about the registries - I just follow Occam's razor principle. Regards, Valery. -Original Message- From: Paul Hoffman Date: 20 февраля 2016 г. 18:12 To: Valery Smyslov Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 Your proposal of using heuristics

Re: [IPsec] Textual changes to the DDoS draft

Hi Yaron, I also think that it's more safe to verify all 4 results (that's why it's SHOULD). If nobody objects we can make it MUST for the sake of security and simplicity. Regards, Valery. - Original Message - From: Yaron Sheffer To: Valery Smyslov ; Yoav Nir ; Waltermire

Re: [IPsec] IKEv1 retransmits - was Re: WGLC on draft-ietf-ipsecme-ddos-protection-04

Hi Paul, On Wed, 16 Mar 2016, Michael Richardson wrote: Tero Kivinen wrote: > What we could say in the DDoS draft is to add saying that IKEv1 > protocol is obsoleted, and will be common avenue for the DDoS attacks, > and because of that it MUST be disabled. > Or

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

prescribed in Section 2.1 of RFC7296. Regards, Valery. - Original Message - From: "Graham Bartlett (grbartle)" <grbar...@cisco.com> To: "Yoav Nir" <ynir.i...@gmail.com> Cc: "Valery Smyslov" <sva...@gmail.com>; "Paul Wouters" <p..

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

Hi Graham, a few comments on your text. A number of attacks can occur if implementations use the HASH and URL, malicious parties can send a URL to redirect a VPN gateway to a server which does not contain the HASH of the certificate, but The server never contains hash, it contains the

Re: [IPsec] IKEv1 retransmits - was Re: WGLC on draft-ietf-ipsecme-ddos-protection-04

at this point initiator completed the exchange and has working IKE SA. However, since AggOutI2 is lost, then responder doesn't have IKE SA yet. Since initiator has ready IKE SA it has no reasons to retransmit AggOutI2. The only way responder can force initiator to retransmit AggOutI2 is to

Re: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires

Hi Paul, I'd like to make a short presentation (~10 min) about using compression in IKEv2 (draft-smyslov-ipsecme-ikev2-compression). I'm also a bit puzzled that there is nothing in the agenda concerning the yang data model for IPsec. I remember in Prague authors promised to merge their drafts

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt

Hi, my comments mostly are addressed, thanks. The one still unaddressed is a strange comment "?SHOULD" in the last table (Section 4.2). What does it mean? Regards, Valery. -Original Message- From: Tero Kivinen Sent: Wednesday, April 6, 2016 3:06 PM To: internet-dra...@ietf.org Cc:

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt

After re-reading the draft I think that I'm also a bit unhappy with the way the last table (Section 4.2) is introduced. The draft says that this table is: Recommendation of Authentication Method described in [RFC7427] notation. However, the values from this table are just examples in

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt

, Valery. -Original Message- From: Tero Kivinen Sent: Wednesday, April 6, 2016 7:17 PM To: Valery Smyslov Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt Valery Smyslov writes: my comments mostly are addressed, thanks. The one still unaddressed

Re: [IPsec] IKEv1 retransmits - was Re: WGLC on draft-ietf-ipsecme-ddos-protection-04

I still do not see that: AggrOutI1 ---> < AggrOutR1 [ rest of exchange ] If AggrOutI1 is dropped: AggrOutI1 ---> X AggrOutI1 ---> < AggrOutR1 [ rest of exchange ] If AggrOutR1 is dropped: AggrOutI1 ---> X <

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

Hi Graham, thank you for the updated text. I¹ve made some amendments to the proposed text based on Valerys comments. I¹ve also added text around the correct sending of INFORMATIONAL messages due to a Responder receiving an SA_INIT, this is a known problem today with a number of

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt

Hi Paul, thank you for the detailed review. I would remove most of the speculative text in: In IPv4 it makes sense to limit the number of half-open SAs based on IP address. Most IPv4 nodes are either directly attached to the Internet using a routable address or are hidden behind a NAT

Re: [IPsec] New version of IKEv2 TCP Encapsulation draft

nt about ESP Sequence Numbers. I think a few words could be added that while the ESP SN are unnecessary with TCP encapsulation, the sender still must increnet it in every sent packet. Regards, Valery Smyslov. - Original Message - From: Tommy Pauly To: ipsec@ietf.org

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

Hi Graham, GB> Thanks Valery - this is now clear. However not only was I confused, as Paul confirms there’s other implementations that are also confused. Seeing as there’s confusion with regards to this wording and it can lead to an amplification attack I personally feel we should include

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-04.txt

hat RSASSA-PSS MUST be implemented, however a few lines below in a table I read: RSASSA-PSS with SHA-256 - SHOULD. I think more explanation text should be added. Regards, Valery Smyslov. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] IKEv1 retransmits - was Re: WGLC on draft-ietf-ipsecme-ddos-protection-04

The problem is that the last message comes from the initiator, and if this message got lost, the initiator never knew about it it unless the responder retransmits the response to the very first message from the initiator. It's an immanent feature of IKEv1 caused by odd number of messages in

Re: [IPsec] draft-fluhrer-qr-ikev2-01

d an additional secret that is shared between the initiator and the responder; this secret is in addition to the authentication method that is already provided within IKEv2.] s/in addition/an addition ? 3. IANA Considerations section is missing. Regards, Valery Smyslov.

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

Hi Paul, thank you for your comments. I think the document is well written with respect to DDOS. I like everything except the puzzles. It seems a lot of complexity for no gain, especially with the problem being that botnets are better at puzzle solving then mobile phones who want to not drain

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

Hi Tommy, thank you for your comments. I tend to agree with Paul that I find it unlikely, from an implementor’s standpoint, that many Initiators will choose to implement the puzzle logic, especially ones that are running on mobile devices. It is unlikely that the phones will be able to solve

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

If there is no consensus about puzzles, perhaps we should leave that part out of the document? I had an impression that threre was a consensus when the document was adopted by WG. In any case, I think that it is better to have an interoperable specification than to leave puzzles at all (and

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt

Hi Paul, Do I get you right that you want to remove the following text? IPv6 networks are currently a rarity, so we can only speculate on what their wide deployment will be like, but the current thinking is that ISP customers will be

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt

The text is not exactly about this. Once the responder sent IKE_SA_INIT response it is able to calculate SKEYSEED and SK_* keys. However, it is a good idea not to do it immeditely, but instead wait for the IKE_AUTH request to come. The reason is that in case IKE_AUTH request never came (attack,

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-04.txt

HI Tero, Valery Smyslov writes: 7. Descriptions for AES-GCM and ENCR_AES_CCM_8 demonstrate some inconsistency. While the former claims that the advantage of using shorter than 16 bytes ICV are minimal, the latter claims that 8 bytes ICV is enough for IKE SA. Sure, the latter

Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

Hi Paul, thank you for clarifications. One more point. The draft is silent about what the responder is supposed to do with the stream prefix. Should it check it? In this case what should it do if the prefix is different from "IKEv2"? Discard the TCP session? Or should it ignore the prefix

Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

the prefix completely? In this case how many bytes should it skip from the beginning of the stream - exactly 5? Regards, Valery. - Original Message - From: "Tommy Pauly" <tpa...@apple.com> To: "Valery Smyslov" <sva...@gmail.com>; "Yoav Nir" <

Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

Hi Tommy, sorry for late reply. I'm mostly OK with the last version of the draft. Few comments. It is a bit unclear how Stream Prefix is intended to be used with TLS. Is it insterted at the beginning of the TLS data stream? Then, I think some text should be added describing a situation when

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-06.txt

: Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks Authors : Yoav Nir Valery Smyslov Filename: draft-ietf-ipsecme-ddos-protection-06.txt Pages : 29 Date

Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis

If RSASSA-PSSv2 is done because RSASSA-PSS is found broken, then we just mark RSASSA-PSS as MUST NOT, and move to the new version. And this will cause interoperability problems since there is no way for the peers to indicate each other that they support particular signature encoding. "MUST

Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis

Hi, Thanks for your response, I am fine with your comments but I have a question: in Sec. 4.2, we have: "With the use of Digital Signature, RSASSA-PKCS1-v1.5 MAY be implemented. RSASSA-PSS MUST be implemented." And then the table has SHOULD for RSA (as well as ECDSA). How come? RSASSA-PSS

Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis

Hi, Yes, I think we discussed it, but I think we should really see at least one implementation before we pick it as SHOULD+ level... Has anybody implemented this yet? Yes. Also as we do say that RSASSA-PSS MUST be implemented, that means that every implementation which sends out the

Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis

> RSASSA-PSS is MUST when implementing Digital Signature. All these thing are not clear from the current text of the draft. I was also confused as well as Yaron. Why the following text is not clear enough: With the use of Digital Signature, RSASSA-PKCS1-v1.5 MAY be implemented.

Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis

Hi, > Has anybody implemented this yet? Yes. Good to know. Do you know if there has been any interoperability tests with it? We are interoperable with ourselves (not a surprise) and with strongSwan (no RSASSA-PSS was tested yet though). I think it is a deficiency of RFC7427 that it only

Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document

Hi, just to reiterate my position in light of this questionnaire: This has been a good discussion so far. There is work to be done to address the issues raised. Getting back to the call for adoption, I'd like to see feedback on the following questions to better understand where consensus is

Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document

Hi Tero, I think it is a bit early to discuss particular approaches, before the WG makes a decision to adopt the document. However, just for the record (see below). Earlier I have proposed very simple method where the IKE_SA_INIT contains just some kind of notification messages identifying

Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document

Hi, Not necessary. In particular, the current draft allows to detect OOB key mismatch and to act gracefully in this situation. And I don't think it is far too complicated. Current draft does, but there has been other proposals which did not. The current draft is also very costly and allows

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

The draft provides postquantum protection to any SA, regardless of the authentication methods used. In other words, PPKs (as specified in the draft) don't replace preshred keys authentication in IKEv2, they augment any authentication method to provide postquantum security. The original title

Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection

Hi Dave, thank you for your review. I just completed a review of the DDoS draft. I fixed a number of grammar and wording issues. I would like to issue a pull request, but I don't have access to the site yet. I hope to get that resolved ASAP and then submit the pull request. While I was

Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06

Hi Paul, thank you for part two of your review. This is part two of my review. I do think the document needs some work moving text to better locations and I have some questions I would like to see resolved. I wrote down some nits but stopped doing that in the end because I think chunks of text

Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06

Hi Tero, To be clear - I'm not against updating RFC 7296, I just think it is not needed. I think the rules are All documents which do change IKEv2 core behavior are marked as updates 4306/5996/7296. Currently those are: ... If there is negotiation of this feature before the IKEv2 behavior

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-07.txt

Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks Authors : Yoav Nir Valery Smyslov Filename: draft-ietf-ipsecme-ddos-protection-07.txt Pages : 29 Date: 2016-07-01 Abs

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

Hi Paul, Isn't this kinda off-topic for the thread? I though we were first considering "create an IKEv2 extension that mixes in the PSK" as the simplest way to get around the "go back to IKEv1" guidance. So that was not entire clear to me from the title, but it seems you are right. Perhaps

Re: [IPsec] Call for adoption of draft-pauly-ipsecme-split-dns as an IPSecME WG document

Hi, I support adoption this document. I think it presents a useful functionality. Regards, Valery. > This is the call for adoption of > https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/ as an > IPSecME working group (WG) document. > > By adopting this draft, the WG is agreeing

Re: [IPsec] Review of draft-ietf-ipsecme-tcp-encaps-05

> Hi Valery, > > Thanks so much for your comments! I have posted a new version of the draft > here: > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-06 > > Responses inline. > > Best, > Tommy > > > On Feb 2, 2017, at 4:13 AM, Valery Smyslov

[IPsec] Review of draft-ietf-ipsecme-tcp-encaps-05

Hi, here is my review of draft-ietf-ipsecme-tcp-encaps-05. The draft is in a good shape, but a bit of final polishing is required. 1. The terms "tunnel", "tunneled" are used throughout the document when referring to ESP SA. I think it is technically incorrect, since ESP supports both

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

Hi Tommy, > >> Actually Valery did raise good point, that for IKE this might cause > >> issues. > >> > >> Now when I am thinking about this, I think that for IKE packets the > >> response to the IKE request should go to the same TCP session where > >> the request came in. This would be aligned

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

HI Tero, > Actually Valery did raise good point, that for IKE this might cause > issues. > > Now when I am thinking about this, I think that for IKE packets the > response to the IKE request should go to the same TCP session where > the request came in. This would be aligned with the RFC7296

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

Hi Tero, > > If attacker intercepts TCP session carrying ESP packet with sequence > > 0x1000 and manages to get the packet and drop the TCP session before > > responder gets it, then it can create a new TCP session > > sending this packet. The responder will switch to the attacker's > > TCP

Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03

Yaron, I don't think these attacks are relevant to ESP compression. As far as I understand, they rely on statistical analysis of the frame lengthes when phonems are encoded with a lossy compression algorithm. I don't see how it affects losless compression used in ESP. Regards, Valery.

Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03

Hi Valery, Yes, these are lossy algorithms, but the TLS/HTTP attacks are all with lossless algorithms. And as far as I know, they are applicable to any situation where here is an attacker that can force traffic on the wire, mixed with other, non-attacker controlled traffic. So IMO they are

Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03

And ESP compression could help applying TFC padding without consuming considerable anount of additional bandwidth. You mean TFC pad to something that's not the MTU ? Probably, but not necessary. Not sure I see how compression + TFC makes smaller packets, unless your TFC padding is very

Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03

Hi Yaron, Can we make all the compression algorithms SHOULD NOT instead of MAY? TLS got rid of compression altogether, there are numerous attacks on compressed traffic, and even the document states that these algorithms are not widely implemented. What attacks do you mean? Those that I'm

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-09.txt

IETF. Title : Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks Authors : Yoav Nir Valery Smyslov Filename: draft-ietf-ipsecme-ddos-protection-09.txt Pages : 29

Re: [IPsec] Call for adoption of draft-mglt-ipsecme-rfc7321bis as an IPSecME WG document

Hi, I support adoption of this document. Regards, Valery. This is a quick reminder that the call for WG adoption on draft-mglt-ipsecme-rfc7321bis ends on Wednesday, September 14th, 2016 at UTC 23:59. I have not seen any support or concerns posted in response to my initial email. While this

Re: [IPsec] WGLC on draft-ietf-ipsecme-rfc4307bis-11

Hi Paul, We have kept key lengths out of the tables on purpose. It matches the tables at IANA that also do not list separate items for different key lengths. Would "This requirement" instead of "This requirement level" make that more clear? If you don't want to add key length column to the

Re: [IPsec] WGLC on draft-ietf-ipsecme-rfc4307bis-11

Hi, here is my review of draft-ietf-ipsecme-rfc4307bis-13. I didn't participate in the recent discussions, so I'm acting here more or less like "fresh" reader. Overall, I think that the document is in a good shape, however some additional polishing is required to improve its clarity and

[IPsec] Interoperability problem concerning RFC 7427

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

Re: [IPsec] AD review of draft-ietf-ipsecme-ddos-protection

Hi Kathleen, thank you for the review. I'll try to answer. Hello, Thank you for you work on draft-ietf-ipsecme-ddos-protection. This is a good read that lays out the problem well and describes the solution well. Thanks for that! I have some nits and questions before we put this into IETF

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-14.txt

Hi, > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-14 These are the changes based on Valery's feedback. my concerns are resolved. Thank you, Valery. Paul ps. I hope Valery will assist me when testsuites or testlabs ask

Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

Hi Mirja, Yoav, I agree with Yoav's answers, just want to clarify a few things. See below (I removed the comments where I have nothing to add to Yoav's answers). > -- > COMMENT: >

Re: [IPsec] Interoperability problem concerning RFC 7427

Hi Paul, I don't think negotiation is needed. It's enough if each side announces its capabilities, the same way it is done in RFC7427 with hash functions. And the easiest way to do it is to add pseudo-hash value "RSASSA-PSS supported" into the hash algorithms registry. In this case each side

Re: [IPsec] Interoperability problem concerning RFC 7427

Sure. I can prepare the slides (if the WG chairs don't mind). Regards, Valery. Perhaps we (as in the working group) should schedule some time (15-20 minutes?) to discuss the options in Seoul. Understanding both RFC 7427 and PSS signatures when they are in certificates, but not PSS

Re: [IPsec] Interoperability problem concerning RFC 7427

Do you really think we will see this more in ECC? How will that happen more in the ECC? If I have Ed25519 key, why would someone go against the "SHOULD NOT" in draft-nir-ipsecme-eddsa draft and use something else than Ed25519, i.e., why would someone use Ed25519ph, or why would someone use ECDSA

Re: [IPsec] Interoperability problem concerning RFC 7427

The reasons can be various. For example, after wide adoption of EdDSA some vulnerability is found in the scheme and some modifications are introduced to eliminate it (analogously to If there would be vulnerability in the signature scheme, I think we would say you MUST NOT use the old format

Re: [IPsec] Interoperability problem concerning RFC 7427

Hi Yoav, No this was different issue. I remember that discussion very well (since I initiated it) and I wouldn't start it over again. The issue we came across is not about different algorithms (say indicating whether we need to use RSA or ECDSA if we have both certificates). The algorithm is

[IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-compact-00.txt

are very welcome. Regards, Valery. A new version of I-D, draft-smyslov-ipsecme-ikev2-compact-00.txt has been successfully submitted by Valery Smyslov and posted to the IETF repository. Name: draft-smyslov-ipsecme-ikev2-compact Revision: 00 Title: Compact Format of IKEv2 Payloads Document date

[IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-compact-00.txt

are very welcome. Regards, Valery. - Original Message - From: <internet-dra...@ietf.org> To: "Valery Smyslov" <s...@elvis.ru> Sent: Friday, October 07, 2016 6:18 PM Subject: New Version Notification for draft-smyslov-ipsecme-ikev2-compact-00.txt A new version

Re: [IPsec] WGLC on draft-ietf-ipsecme-rfc4307bis-11

Hi Tero, > | RSASSA-PSS with Empty Parameters | MUST NOT | | > | RSASSA-PSS with Default Parameters | MUST NOT | | > > Well, I'm a confused with these requirements. As far as I > understand the RSASSA-PSS parameters default to using a SHA1 for > both

Re: [IPsec] Quantum Resistance Requirements

Hi Scott, thank you for the list of requirements. My answers are inline. In Berlin, we decided to take up Quantum Resistance as a work item, and that we should start talking about requirements. I'm starting this thread in a hope of kicking off the discussion. First of all, a solution

Re: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

s the type of the following payload, not the type of payload the diagram depicts. There is also an IANA Considerations Section which also specifies the payload type for the Puzzle Solution payload. Thank you, Valery Smyslov. Alexey Melnikov has entered the following ballot position for draft-ietf-ip

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

): The responder should change the value of frequently, especially if under attack. I think we can add some words to the draft that will recommend to generate cookie in such a manner, that the cookie is not repeated even if the same IP, SPI and nonce are used by Initiator. Thank you, Va

Re: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

core" Is this supposed to say 2014? Struck me as a little weird. The -00 version of the document was written in 2014, so the estimates came from Yoav's experiments, that he conducted at that time, I think. Regards, Valery Smyslov. ___ IPsec mailing

Re: [IPsec] FW: New Version Notification fordraft-mglt-ipsecme-implicit-iv-01.txt

t; -Ursprüngliche Nachricht- > Von: IPsec [mailto:ipsec-boun...@ietf.org] Im Auftrag von Valery Smyslov > Gesendet: Montag, 10. Oktober 2016 09:06 > An: Daniel Migault <daniel.miga...@ericsson.com>; IPsecME WG <ipsec@ietf.org> > Betreff: Re: [IPsec] FW: New Version Notif

Re: [IPsec] FW: Quantum Resistance Requirements

a single point (SK_d’ derivation) where modifications to keys derivation algorithm take place, instead of two points. It will make implementations modification easier, I think. So, did you consider such variant? Are there any security disadvantages? Regards, Valery Smyslov. From: Scott Fluhrer

Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

What’s wrong with that? As far as I understand the draft, the mapping between IKE/IPsec and TCP is loose, so it seems that such a scenario is OK (Tommy corrects me if I’m wrong). Do you have any problems with it? From: Hu, Jun (Nokia - US) Sent: 15 ноября 2016 г. 10:48 To: Valery Smyslov

Re: [IPsec] Take a stand for key hygine

Hi Watson, the problem is not that the host cannot deduce from received AUTH payload what kind of signature was used – the AUTH payload includes AlgorithmIdentifier, so these signatures are treated differently. The problem is that host cannot guess what kind of signatures the peer supports, that

Re: [IPsec] Take a stand for key hygine

Hi Yoav, or the servers must be provided with two certificates – one for TLS 1.2 and the other for TLS 1.3, that won’t make server owners happy. I think it is a good idea to raise this issue in TLS WG. Regards, Valery. From: Yoav Nir Sent: 19 ноября 2016 г. 7:21 To: Tero Kivinen Cc:

Re: [IPsec] Take a stand for key hygine

. Regards, Valery Smyslov. From: Yoav Nir Sent: 18 ноября 2016 г. 11:31 To: Watson Ladd Cc: ipsec@ietf.org WG Subject: Re: [IPsec] Take a stand for key hygine Hi, Watson On 18 Nov 2016, at 9:18, Watson Ladd <watsonbl...@gmail.com> wrote: > Dear all, > > In reviewing the

<    1   2   3   4   5   6   7   8   9   >