Re: [IPsec] RFC4307 update

Hi. I’ll reply to Daniel’s and Paul’s comments. Note that this draft is a starting point to feed into discussion. Just like this kind of discussion. Re: ENCR_AES_CBC. If someone wanted to build an IKEv2 implementation with only one algorithm, the choice for maximum interoperability would be

Re: [TLS] TLS 1.3 - Support for compression to be removed

> On Oct 4, 2015, at 1:44 AM, takamichi saito wrote: > > > On 2015/10/03, at 0:24, Salz, Rich wrote: > >> >>> 1) We know CRIME threat, but it can not be risk for everyone. >>> e.g., CVSS v2 Base Score: 2.6 (LOW) >> >> CVSS isn't always appropriate; CVSS2 called

Re: [IPsec] RFC4307 update

> On Sep 28, 2015, at 6:57 PM, Michael Richardson wrote: > > > Tero Kivinen wrote: >> We did update cryptographic algorithms for ESP and AH >> (RFC4305->4835->7321), but we have never updated the RFC4307. > >> I think there should be update for that

Re: [TLS] TLS 1.3 - Support for compression to be removed

> On Sep 24, 2015, at 7:40 AM, Jeffrey Walton wrote: > >> I have to wonder if it’s worth it. In the last decade bandwidth has >> increased and prices for networking have gone down much faster than CPU >> speeds. 10 years ago having 1 Mbps at home was the highest-end

Re: [IPsec] WG Interest in TCP Encapsulation

> On Sep 16, 2015, at 5:01 AM, Tero Kivinen wrote: > > Tommy Pauly writes: >> I wanted to get a sense of WG interest in working on a standard for running >> IKEv2/IPSec over a TCP (or TLS/TCP) connection to traverse networks that >> currently block UDP traffic. > > Before we

Re: [IPsec] My review of draft-nir-ipsecme-curve25519

On Aug 26, 2015, at 9:33 AM, Yaron Sheffer yaronf.i...@gmail.com wrote: In the section 3.2 recipient tests there is discussion about checking that the public key 32-octet string will have last byte in such way that high-order bit of it is not set. If this is property of the func(d, G)

Re: [IPsec] My review of draft-nir-ipsecme-curve25519

On Aug 25, 2015, at 3:19 PM, Tero Kivinen kivi...@iki.fi wrote: Firstly the name of the draft is bit misleading, as this defines both curve25519 and Curve448 keys not only curve25519. Agree. Version -00 had only Curve25519 and the name remained. For the WG draft we can pick a different

Re: [TLS] padding

On Aug 25, 2015, at 2:22 AM, Tom Ritter t...@ritter.vg wrote: On 22 August 2015 at 19:28, Dave Garrett davemgarr...@gmail.com wrote: Toggling solves the undesired bandwidth use concern stated by Tom by making it fully optional on both sides. The even simpler route of just having to check

Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

On Aug 24, 2015, at 5:31 PM, Watson Ladd watsonbl...@gmail.com wrote: On Mon, Aug 24, 2015 at 7:29 AM, Ilari Liusvaara ilari.liusva...@elisanet.fi wrote: On Mon, Aug 24, 2015 at 07:22:23AM -0700, Watson Ladd wrote: On Mon, Aug 24, 2015 at 6:33 AM, David Mazieres This is a misreading:

Re: [websec] [Editorial Errata Reported] RFC6797 (4449)

Granted, this is only my opinion, but I don’t think that Mr Luyimbaazi’s failure to access his Facebook wall using Firefox is indicative of an error in RFC 6797. Yoav On Aug 18, 2015, at 5:34 PM, RFC Errata System rfc-edi...@rfc-editor.org wrote: The following errata report has been

Re: [IPsec] DDoS draft next steps - CAPTCHA

On Aug 14, 2015, at 7:08 PM, Valery Smyslov sva...@gmail.com wrote: With no hat on, I hate captchas. I sometimes don't see it well enough depending on the images selected and have not used applications as a result. It is a clever way to tackle the problem, so it would be up to the

Re: [TLS] Commentary on the client authentication presentation slides

On Aug 10, 2015, at 8:10 PM, Andrei Popov andrei.po...@microsoft.com wrote: Hi Ilari, What sort of usecase you have in mind for this? This is to support a fairly common website design where the landing page does not require client auth, but subsequent request to a protected resource

Re: [TLS] Commentary on the client authentication presentation slides

On Aug 10, 2015, at 10:04 PM, Andrei Popov andrei.po...@microsoft.com wrote: Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2. Correct, anything less than this will create deployment problems. I’d

Re: [IPsec] P-256 speed

Is this code available anywhere? If not, it makes it hard to reproduce their results. It’s too bad they don’t submit this to bench.cr.yp.to so we could have an apples-to-apples comparison with other implementations. Yoav On Jul 21, 2015, at 11:57 AM, Stephen Kent k...@bbn.com wrote: I

Re: [TLS] sect571r1

On Jul 15, 2015, at 9:19 PM, Benjamin Beurdouche benjamin.beurdou...@inria.fr wrote: Hey, Except if someone has a real need for it, I would favour removing p571 and keep secp521r1 as the maximum … +1 It should be noted that I have removed it from RFC4492bis. In terms of real-world

Re: [Captive-portals] Feedback requested: Charter text.

On Jul 9, 2015, at 5:16 PM, Warren Kumari war...@kumari.net wrote: snip / The CAPPORT Working Group will define mechanisms and protocols to: - allow endpoints to discover that they are in such a limited environment - allow endpoints to learn about the parameters of their confinement -

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-chacha20-poly1305-11: (with COMMENT)

So, how about replacing the first two paragraphs? OLD: The Advanced Encryption Standard (AES - [FIPS-197]) has become the gold standard in encryption. Its efficient design, wide implementation, and hardware support allow for high performance in many areas, including IPsec VPNs. On

Re: [IPsec] draft-ietf-ipsecme-chacha20-poly1305

On Jul 1, 2015, at 10:31 AM, Martin Willi mar...@strongswan.org wrote: Kathleen, I am getting the ballot ready for the next telechat (next week on Thursday). Are there any implementations? For the strongSwan open source project [1] I've implemented this draft, supporting

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ipsecme-chacha20-poly1305-10

Hi Sorry about that. I have looked over the draft looking for acronyms that were not spelled out before use, and I could find only three: AEAD, which is used unexpanded in the Abstract, but expanded before the next use in the Introduction. I thought it was acceptable to avoid expansions in the

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-chacha20-poly1305-11: (with COMMENT)

Hi, Stephen. See below. On Jul 8, 2015, at 2:15 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: -- COMMENT: -- intro: gold standard is being a

Re: [IPsec] Ben Campbell's No Objection on draft-ietf-ipsecme-chacha20-poly1305-11: (with COMMENT)

Hi, Ben. See below On Jul 8, 2015, at 5:51 AM, Ben Campbell b...@nostrum.com wrote: -- COMMENT: -- This is easier than usual to read for this sort of

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

: Yoav Nir Valery Smyslov Filename: draft-ietf-ipsecme-ddos-protection-02.txt Pages : 25 Date: 2015-07-04 Abstract: This document recommends implementation and configuration best practices for Internet-connected

[dane] DANE and IPsec

Hi I see that our milestones still contain a DANE with IPsec document, although the WG has not yet discussed or adopted such a document. There is one proposed document (draft-osterweil-dane-ipsec). That one ties DANE to opportunistic encryption. While interesting, I think we need a far more

Re: [dane] DANE and IPsec

On Jul 2, 2015, at 6:03 PM, Viktor Dukhovni ietf-d...@dukhovni.org wrote: On Thu, Jul 02, 2015 at 05:13:01PM +0300, Yoav Nir wrote: The IPsec entity will resolve this FQDN with DNSSEC, yielding both an IP address and a DANE record. The DANE record can be used to identify the certificate

Re: [dane] DANE and IPsec

On Jul 2, 2015, at 6:48 PM, Viktor Dukhovni ietf-d...@dukhovni.org wrote: On Thu, Jul 02, 2015 at 06:40:45PM +0300, Yoav Nir wrote: What prevents IP address hijacking (mallory.example publishes alice.example's IP address and now mallory's IPSEC keys are used to encrypt traffic to alice

Re: [dane] DANE and IPsec

On Jul 2, 2015, at 8:08 PM, Viktor Dukhovni ietf-d...@dukhovni.org wrote: On Thu, Jul 02, 2015 at 08:04:37PM +0300, Yoav Nir wrote: Not sure I follow. Mallory publishes - mallory.example.com IN A 192.0.2.5 - mallory.example.com IN TLSA Mallory publishes her own TLSA record

Re: [dane] DANE and IPsec

On Jul 3, 2015, at 12:28 AM, Viktor Dukhovni ietf-d...@dukhovni.org wrote: On Thu, Jul 02, 2015 at 11:29:45PM +0300, Yoav Nir wrote: The hard part is the transport-mode use-case. If the SPD entries are specific and pre-configured, the same reasoning as for VPNs applies. Things change

Re: [Captive-portals] Feedback requested: Charter text.

On Jul 1, 2015, at 1:55 AM, Dan Wing dw...@cisco.com wrote: On 30-Jun-2015 02:50 pm, Dave Dolson ddol...@sandvine.com wrote: Hyperbole aside, ‎the techniques in use today can be deployed in any network gear along the path, even theoretically in a core router, and also to present any

Re: [IPsec] draft-ietf-ipsecme-chacha20-poly1305

Hi, Kathleen. The sentences in question are the ones that get modified after IANA assignment. We’ve asked for early assignment. If we get it (hint, hint, Tero) I’ll update these sentences (“… MUST use 31, the identifier assigned by IANA to …”). If not, then the RFC editor makes these edits

Re: [IPsec] nat traversal and transport mode

Hi. Transport mode works fine behind NAT devices. For example, L2TP clients connect to VPN gateways using transport mode and they work behind NAT devices. It is AH that cannot work behind NAT. HTH Yoav On Jun 16, 2015, at 2:34 PM, Michał Zegan webczat_...@poczta.onet.pl wrote:

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-09.txt

and Extensions Working Group of the IETF. Title : ChaCha20, Poly1305 and their use in IKE IPsec Author : Yoav Nir Filename: draft-ietf-ipsecme-chacha20-poly1305-09.txt Pages : 12 Date: 2015-06-13 Abstract

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-09.txt

Done. On Jun 14, 2015, at 8:57 PM, Yaron Sheffer yaronf.i...@gmail.com wrote: Sure. On 06/14/2015 02:11 PM, Yoav Nir wrote: How about: OLD: The Pad Length field need not exceed 4 octets. However, RFC 4303 and this specification do not prohibit using greater pad lengths

Re: [openssl-dev] OpenSSL offers reviewers for draft-saarinen-blake2

On Jun 13, 2015, at 4:12 PM, Salz, Rich rs...@akamai.com wrote: Recently the OpenSSL development community has expressed renewed interest in having the document finalized as an RFC and they seem to consider this to be a prerequisite of BLAKE2's adoption into the main branch of OpenSSL

Re: [IPsec] AD review of draft-ietf-ipsecme-chacha20-poly1305-08

On Jun 12, 2015, at 10:08 PM, Kathleen Moriarty kathleen.moriarty.i...@gmail.com wrote: Hi Yoav, Once again, sorry for the delay! My schedule should start to get better in a couple of weeks. On Sat, Jun 6, 2015 at 6:03 PM, Yoav Nir ynir.i...@gmail.com mailto:ynir.i...@gmail.com

Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

. A BLAKE2 MAC can be customized wrt key or tag size, and can provide the highest security level for a give key/tag size combination. On Thu, Jun 11, 2015 at 10:15 AM Yoav Nir ynir.i...@gmail.com mailto:ynir.i...@gmail.com wrote: On Jun 11, 2015, at 2:36 AM, Bill Cox waywardg

Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

On Jun 11, 2015, at 2:36 AM, Bill Cox waywardg...@google.com wrote: BLAKE2 rocks. I'm looking forward to using it in many applications. Sure. I would be glad to see that used as a hash in signatures and in TLS, as a PRF in TLS and IKE, etc. Does anyone know what the status of

[IPsec] Fwd: New Version Notification for draft-nir-ipsecme-curve25519-00.txt

.txt Date: June 11, 2015 at 11:01:26 AM GMT+3 To: Yoav Nir ynir.i...@gmail.com, Simon Josefsson si...@josefsson.org, Yoav Nir ynir.i...@gmail.com, Simon Josefsson si...@josefsson.org A new version of I-D, draft-nir-ipsecme-curve25519-00.txt has been successfully submitted by Yoav Nir

Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

On Jun 9, 2015, at 4:07 AM, Zooko Wilcox-OHearn zo...@leastauthority.com wrote: On Tue, Jun 9, 2015 at 12:57 AM, Salz, Rich rs...@akamai.com wrote: So if you're going to replace md5sum... which one should you use? Which ONE HASH should replace MD5? I'd suggest blake2sp. It's

Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

On Jun 8, 2015, at 1:37 PM, Hubert Kario via RT r...@openssl.org wrote: On Friday 05 June 2015 16:39:36 Zooko Wilcox-OHearn via RT wrote: Dear OpenSSL folks: I'm one of the authors of the BLAKE2 hash function (https://blake2.net). I've been working with the maintainers of GNU coreutils

Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

On Jun 8, 2015, at 1:37 PM, Hubert Kario via RT r...@openssl.org wrote: On Friday 05 June 2015 16:39:36 Zooko Wilcox-OHearn via RT wrote: Dear OpenSSL folks: I'm one of the authors of the BLAKE2 hash function (https://blake2.net). I've been working with the maintainers of GNU coreutils

Re: [IPsec] AD review of draft-ietf-ipsecme-chacha20-poly1305-08

Hi, Kathleen. Please see below On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty kathleen.moriarty.i...@gmail.com wrote: Hi, Sorry this took me a bit of time to get to, I wanted to read through some of the background materials first and have been a bit swamped lately (should clear up

[IPsec] Question about PFS in IKEv2

Hi This may have been discussed before, but I haven’t found such discussion. Apologies in advance if this is a stupid question. Suppose we have to VPN peers configured to set up a tunnel between them. Suppose further that the IKE SAs are significantly longer-lived than the IPsec SAs. PFS is

Re: [IPsec] Question about PFS in IKEv2

Hi, Vijay. Thanks for the response. On May 28, 2015, at 12:38 PM, vijay kn vijay...@huawei.com wrote: The only problem I see is if the Gw-1 rekeyed with group19 but GW2 does not support Group19 then it can result in traffic loss. For this, the administrators of the two devices must

Re: [IPsec] Question about PFS in IKEv2

On May 28, 2015, at 1:40 PM, Tero Kivinen kivi...@iki.fi wrote: Yoav Nir writes: When the tunnel is first set up, it is negotiated in the IKE_AUTH exchange. Diffie-Hellman is not performed, so the mismatched configuration is not detected - traffic flows through the tunnel. If your setup

Re: [IPsec] How to negotiate a new capability with parameters

Hi, Frederic That sounds mostly correct. In IKEv1 capabilities were usually declared in VendorIDs. In IKEv2 they are mostly declared in notifications within IKE_SA_INIT. Why the difference? No idea. It’s just the way other extensions were done, but with a private extension you can do

Re: [IPsec] New Version Notification - draft-ietf-ipsecme-chacha20-poly1305-08.txt

Hi I have just uploaded version -08. The only difference from version -07 is changing the reference for the algorithm document from draft-irtf- to RFC 7539. Yoav On May 14, 2015, at 12:24 AM, internet-dra...@ietf.org wrote: A new version (-08) has been submitted for

Re: [IPsec] Restarting the discussion about the puzzle

On May 9, 2015, at 7:32 PM, Yaron Sheffer yaronf.i...@gmail.com wrote: Hi Yoav, First, I raised a third concern, which is that allowing the client to decide on the difficulty of the puzzle it is willing to solve adds unneeded complexity. Basically the client doesn't have enough

Re: [IPsec] My comments to draft-ietf-ipsecme-chacha20-poly1305-06

Thanks, Tero. Fixed in -07 Yoav On May 4, 2015, at 6:19 PM, Tero Kivinen kivi...@iki.fi wrote: I have now read the latest draft-ietf-ipsecme-chacha20-poly1305-06 and it seems to be ok. I have few nits that could be fixed, and and one real mistake:

[IPsec] Restarting the discussion about the puzzle

Hi. As a reminder, there were two concerns about the difficulty of puzzles: • That some clients are weaker than others and therefore are able to try less keys in a unit of time • That individual puzzles might prove more difficult than other puzzles, so some “unlucky” initiators

Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305

On Apr 28, 2015, at 4:09 PM, Michael Richardson mcr+i...@sandelman.ca wrote: Yoav Nir ynir.i...@gmail.com wrote: Is this diagram correct: some comment on the accuracy of my diagram would be appreciated :-) I’ll get to that later. I think that the IANA considerations of ipsecme

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

item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : ChaCha20, Poly1305 and their use in IKE IPsec Author : Yoav Nir Filename: draft-ietf-ipsecme-chacha20-poly1305-06.txt Pages : 11 Date

Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11

Thanks. I’ve fixed this in my working draft of -06, which should be published soon. Yoav On Apr 27, 2015, at 1:05 PM, Doyle, Stephen stephen.do...@intel.com wrote: In the ESP Example in Appendix A, the 'Next Header' field is missing from the ESP Trailer portion of the plaintext.

Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11

not mention KEYMAT, which is unrelated, and maybe should mention SK_ei/er. Thanks, Yaron On 04/27/2015 11:38 AM, Yoav Nir wrote: On Apr 27, 2015, at 10:46 AM, Yaron Sheffer yaronf.i...@gmail.com wrote: I am still a bit confused about Sec. 3 (use in IKEv2): - Where does it say

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

Hi, Martin. See inline. On Apr 27, 2015, at 2:02 PM, Martin Willi mar...@strongswan.org wrote: Yoav, Oh, and one more thing: I’d really appreciate it if somebody checked my examples. All I can be sure of is that they work in my code. I've hit two issues when verifying the IKEv2

Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11

On Apr 27, 2015, at 10:46 AM, Yaron Sheffer yaronf.i...@gmail.com wrote: I am still a bit confused about Sec. 3 (use in IKEv2): - Where does it say (in this draft or in Sec. 2.7 of the CFRG draft) that the IV is included explicitly, and where exactly it should go? It says that the IV is

Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305

On Apr 27, 2015, at 6:25 PM, Michael Richardson mcr+i...@sandelman.ca wrote: I read draft-ietf-ipsecme-chacha20-poly1305 on Friday last, and then found that I needed to further review draft-nir-cfrg-chacha20-poly1305-06 to better understand the questions in para 2 of the security

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

On Apr 28, 2015, at 2:49 AM, Paul Wouters p...@nohats.ca wrote: On Tue, 28 Apr 2015, Yoav Nir wrote: This is actually quite unfortunate text. Fields must be aligned to block size only for CBC. Aligning AES-GCM to 16 bytes and ChaCha20-Poly1305 to 64 bytes would be totally arbitrary

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

Oh, and one more thing: I’d really appreciate it if somebody checked my examples. All I can be sure of is that they work in my code. Yoav On Apr 26, 2015, at 11:50 PM, Yoav Nir ynir.i...@gmail.com wrote: Hi. At Paul’s request I have added examples in appendix A and appendix B

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

the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : ChaCha20, Poly1305 and their use in IKE IPsec Author : Yoav Nir Filename: draft-ietf-ipsecme

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-03.txt

Will do, although 4106 doesn’t have any either. Yoav On Apr 25, 2015, at 5:54 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Apr 25, 2015, at 2:27 AM, Yoav Nir ynir.i...@gmail.com wrote: With this I believe the document is ready for WGLC. I might want to add an appendix with an example

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-03.txt

of the IP Security Maintenance and Extensions Working Group of the IETF. Title : ChaCha20, Poly1305 and their use in IKE IPsec Author : Yoav Nir Filename: draft-ietf-ipsecme-chacha20-poly1305-03.txt Pages : 7 Date

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-03.txt

Replying to myself to prevent others from sending messages to the internet-drafts and i-d-announce. On Apr 25, 2015, at 12:25 PM, Yoav Nir ynir.i...@gmail.com wrote: Hi This new version closes (I think) all the open issues. I have removed all references to GDOI as it has been pointed out

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-03.txt

And adding the [1]… On Apr 25, 2015, at 12:27 PM, Yoav Nir ynir.i...@gmail.com wrote: Replying to myself to prevent others from sending messages to the internet-drafts and i-d-announce. On Apr 25, 2015, at 12:25 PM, Yoav Nir ynir.i...@gmail.com wrote: Hi This new version closes (I think) all

Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305

Hi, Valery. Thanks for the review. See my reply inline. On Apr 21, 2015, at 7:19 PM, Valery Smyslov sva...@gmail.com wrote: Hi, this is my review of draft-ietf-ipsecme-chacha20-poly1305-02. I think that the draft is in a good shape. A few issues need to be resolved. Technical

Re: [IPsec] mot sure if this posted before, so resending

On Apr 6, 2015, at 10:07 PM, Stephen Kent k...@bbn.com wrote: Yoav, Hi, There is two questions I would like guidance from the group about. First is the nonce/IV question: In the current draft, there is a 64-bit IV with guidance not to repeat them (so use a counter or LFSR). The

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-02.txt

directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : ChaCha20, Poly1305 and their use in IKE IPsec Author : Yoav Nir Filename: draft-ietf-ipsecme-chacha20-poly1305-02.txt

Re: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00

On Mar 31, 2015, at 1:49 PM, Tero Kivinen kivi...@iki.fi wrote: Yoav Nir writes: First is the nonce/IV question: In the current draft, there is a 64-bit IV with guidance not to repeat them (so use a counter or LFSR). The function itself accepts a 96-bit input nonce, so the nonce

Re: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00

On Mar 30, 2015, at 8:42 PM, Scott Fluhrer (sfluhrer) sfluh...@cisco.com wrote: -Original Message- From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir Sent: Monday, March 30, 2015 10:40 AM To: internet-dra...@ietf.org Cc: ipsec@ietf.org; i-d-annou...@ietf.org

Re: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt)

OK, so this thread kind of got side-tracked about the name of the algorithm. I think ENCR_CHACHA20_POLY1305 works for everybody. What about early code point assignment? Thanks Yoav On Mar 31, 2015, at 12:15 PM, Yoav Nir ynir.i...@gmail.com wrote: One more thing. I would like

Re: [IPsec] ChaCha20/Poly1305 padding (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-01.txt)

On Apr 1, 2015, at 3:37 PM, Martin Willi mar...@strongswan.org wrote: Hi, In Section 2, draft-ietf-ipsecme-chacha20-poly1305-01 has the following text: o Finally, the Poly1305 function is run on the data to be authenticated, which is, as specified in section 2.7 of

Re: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt)

Seeing as none of the transform names begins with “ESP_” and that we’re specifying the algorithm for IKE as well as ESP, I’ve changed the identifier to ENCR_ChaCha20_Poly1305. Yoav On Mar 31, 2015, at 12:15 PM, Yoav Nir ynir.i...@gmail.com wrote: One more thing. I would like to request

[IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt)

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : ChaCha20, Poly1305 and their use in IPsec Author : Yoav Nir

[IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00

Hi, There is two questions I would like guidance from the group about. First is the nonce/IV question: In the current draft, there is a 64-bit IV with guidance not to repeat them (so use a counter or LFSR). The function itself accepts a 96-bit input nonce, so the nonce is constructed from the

Re: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00

Arrgh. Please don’t reply-all to my previous message, because it was mistakenly directed to I-D announce… On Mar 30, 2015, at 5:39 PM, Yoav Nir ynir.i...@gmail.com wrote: Hi, There is two questions I would like guidance from the group about. First is the nonce/IV question

[IPsec] Review for ChaCha20 draft (was: Re: IETF092 draft minutes)

On Mar 27, 2015, at 9:20 PM, p...@nohats.ca wrote: - chacha20poly1305 http://www.ietf.org/proceedings/92/slides/slides-92-ipsecme-2.pdf Yoav presenting Yaron: does arm have aes acceleration? Yoav: no. it has something called neon - not in phones but in tablets. has some advantages

[tcpinc] Minutes for tcpinc @ IETF 92

TCPINC minutes == Agenda bashing Tero: two drafts, trying to select between them: tcpcrypt and TLS-based. Lots of ADs in the room. Andrea about tcpcrypt Encrypt payload, MAC some of the options. The MAC is in a TCP option Brian Trammell: tcpcrypt MAC'd the header. Do you have

Re: [IPsec] Vendor Identifiers

On Mar 11, 2015, at 8:54 PM, Russ Housley hous...@vigilsec.com wrote: About two years ago, I was at a workshop where someone claimed that the Vendor Identifiers that are exchanged in IKE are very useful for dealing with bugs. The claim was that following the report of a bug, others could

Re: [IPsec] Vendor Identifiers

On Mar 12, 2015, at 1:38 AM, paul_kon...@dell.com wrote: On Mar 11, 2015, at 5:23 PM, Yoav Nir ynir.i...@gmail.com wrote: On Mar 11, 2015, at 8:54 PM, Russ Housley hous...@vigilsec.com wrote: About two years ago, I was at a workshop where someone claimed that the Vendor

Re: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305

On Mar 6, 2015, at 6:01 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Feb 26, 2015, at 2:11 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: Greetings again. A few people have expressed interest in having https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305 as a WG item for

Re: [IPsec] ChaCha20 + Poly1305 for IKE and IPsec

On Feb 26, 2015, at 4:48 PM, Paul Wouters p...@nohats.ca wrote: On Tue, 24 Feb 2015, Yoav Nir wrote: In the meantime, I have updated my draft to only define the AEAD. Since we not have CFRG’s “stamp of approval” if not yet an RFC number, I would like to renew my request to have

Re: [IPsec] ChaCha20 + Poly1305 for IKE and IPsec

On Feb 24, 2015, at 1:21 PM, Yoav Nir ynir.i...@gmail.com wrote: In the meantime, I have updated my draft to only define the AEAD. Since we not have CFRG’s “stamp of approval” … * Since we **now** have... ___ IPsec mailing list IPsec@ietf.org

Re: [IPsec] ChaCha20 + Poly1305 for IKE and IPsec

On Feb 24, 2015, at 4:24 PM, Michael Richardson mcr+i...@sandelman.ca wrote: Yoav Nir ynir.i...@gmail.com wrote: On Feb 24, 2015, at 1:21 PM, Yoav Nir ynir.i...@gmail.com wrote: In the meantime, I have updated my draft to only define the AEAD. Since we now have CFRG’s “stamp

Re: [IPsec] DDoS puzzle: PRF vs Hash

On Feb 9, 2015, at 4:03 AM, Paul Wouters p...@nohats.ca wrote: On Sun, 8 Feb 2015, Yaron Sheffer wrote: I think we've come a full circle. We now have a proposal that makes proof-of-work more deterministic for each type of client (which I find very useful). But the weaker clients will

Re: [IPsec] DDoS puzzle: PRF vs Hash

Before I respond, here’s one more data point: I’ve compiled OpenSSL 1.0.2 for ARM and got ~60,500 SHA-256 hashes (it’s close enough to not matter to the result for HMAC-SHA-256) per second. That says that assuming 1 second as the “reasonable” time to solve a puzzle, we can expect to do about

Re: [IPsec] DDoS puzzle: PRF vs Hash

-language implementation. As it is, it’s about 4 bits behind the Intel i5. Yoav data64.xlsx Description: MS-Excel 2007 spreadsheet On Feb 2, 2015, at 8:31 AM, Yoav Nir ynir.i...@gmail.com wrote: The three-sigma rule applies even with a non-normal distribution. Anyway, I tried the 64-key

Re: [IPsec] DDoS puzzle: PRF vs Hash

On Jan 31, 2015, at 12:35 AM, Yoav Nir ynir.i...@gmail.com wrote: On Jan 30, 2015, at 3:37 PM, Yaron Sheffer yaronf.i...@gmail.com wrote: What I would suggest is: we give the client a single puzzle, and ask it to return 16 different solutions. Indeed each puzzle then should be 16X

Re: [IPsec] DDoS puzzle: PRF vs Hash

And now it’s really attached. data.xlsx Description: MS-Excel 2007 spreadsheet On Feb 1, 2015, at 11:45 AM, Yoav Nir ynir.i...@gmail.com wrote: On Jan 31, 2015, at 12:35 AM, Yoav Nir ynir.i...@gmail.com wrote: On Jan 30, 2015, at 3:37 PM, Yaron Sheffer yaronf.i...@gmail.com wrote

Re: [IPsec] DDoS puzzle: PRF vs Hash

. For comparison, could you try again with 64 replacing the 16 tries, and with lower bit lengths? Thanks, Yaron On 02/01/2015 11:46 AM, Yoav Nir wrote: And now it’s really attached. On Feb 1, 2015, at 11:45 AM, Yoav Nir ynir.i...@gmail.com wrote: On Jan 31, 2015, at 12:35 AM

Re: [IPsec] DDoS puzzle: PRF vs Hash

On Jan 30, 2015, at 3:37 PM, Yaron Sheffer yaronf.i...@gmail.com wrote: What I would suggest is: we give the client a single puzzle, and ask it to return 16 different solutions. Indeed each puzzle then should be 16X easier. The nice thing is, the server should only check *one* of them, at

Re: [IPsec] DDoS puzzle: PRF vs Hash

of times for each level, not only average). Regards, Valery. - Original Message - From: Yoav Nir mailto:ynir.i...@gmail.com To: Yaron Sheffer mailto:yaronf.i...@gmail.com Cc: IPsecME WG mailto:ipsec@ietf.org Sent: Friday, January 30, 2015 2:41 AM Subject: Re: [IPsec] DDoS

[IPsec] DDoS puzzle: PRF vs Hash

Hi all. Following Valery’s suggestion, I’ve created a pull request for replacing the puzzle mechanism: OLD: appending a string to the cookie so that the hash of the extended string has enough zero bits at the end. NEW: finding a PRF key such that PRF(k, cookie) has enough zero bits at the end.

Re: [IPsec] DDoS puzzle: PRF vs Hash

puzzles of the given strength? Of course, the responder would request 2-3 bits of strength less. The net effect should be a lower variance in run times, i.e. more deterministic run time for any particular type of client. Thanks, Yaron On 01/29/2015 11:27 PM, Yoav Nir wrote: Hi all

Re: [IPsec] Puzzle algorithm negotiation

On Jan 25, 2015, at 8:58 PM, Yaron Sheffer yaronf.i...@gmail.com wrote: Hi Yoav, Valery, I agree with Valery's proposed redefinition of the proof-work-work, based on the PRF. I am currently off-line so my question may have been answered in the pull request, but: can we make it very

[IPsec] Status of IKE DDoS

Hi all A few updates about the IKE DDoS draft: 1. Valery Smyslov has agreed to join as co-author. Thanks, Valery 2. We have moved the source onto github [1], so now anyone can easily create pull requests. 3. I’ve been asked by the chairs to emphasize that despite (2), the discussion is to

Re: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes

On Dec 16, 2014, at 7:28 PM, Hanno Böck ha...@hboeck.de wrote: On Tue, 16 Dec 2014 17:17:01 + Viktor Dukhovni openssl-us...@dukhovni.org wrote: However, where do we fit ChaCha20/Poly-1305? Again, not hand-placement, but some extensible algorithm. How about this simpler criterion:

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

On Dec 9, 2014, at 1:24 PM, Steffen Nurpmeso via RT r...@openssl.org wrote: Salz, Rich rs...@akamai.com wrote: |I think magic names -- shorthands -- are a very bad idea. \ I _completely_ disagree. | They are point-in-time statements whose meaning evolves, \ |if not erodes, over time.

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

On Dec 9, 2014, at 1:24 PM, Steffen Nurpmeso via RT r...@openssl.org wrote: Salz, Rich rs...@akamai.com wrote: |I think magic names -- shorthands -- are a very bad idea. \ I _completely_ disagree. | They are point-in-time statements whose meaning evolves, \ |if not erodes, over time.

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

On Dec 10, 2014, at 9:31 PM, Daniel Kahn Gillmor via RT r...@openssl.org wrote: I'd love to see a version of bettercrypto.org that only has to say to configure OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE” I’d be much happier if that string was called

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

On Dec 10, 2014, at 9:31 PM, Daniel Kahn Gillmor via RT r...@openssl.org wrote: I'd love to see a version of bettercrypto.org that only has to say to configure OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE” I’d be much happier if that string was called

Re: [IPsec] Some speculations about puzzles

allows 16 levels of puzzles.. (just a thought as if the difficulty level disappears you loose the ability to set a the hardness of the puzzle) On 03/12/2014 16:01, Yoav Nir ynir.i...@gmail.com wrote: On Dec 3, 2014, at 5:44 PM, Valery Smyslov sva...@gmail.com wrote: Hi Scott

<    1   2   3   4   5   6   7   8   9   10   >