> On Aug 25, 2015, at 3:19 PM, Tero Kivinen 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 file name.
T
> On Aug 25, 2015, at 2:22 AM, Tom Ritter wrote:
>
> On 22 August 2015 at 19:28, Dave Garrett 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 if there's bytes in the enc
> On Aug 24, 2015, at 5:31 PM, Watson Ladd wrote:
>
> On Mon, Aug 24, 2015 at 7:29 AM, Ilari Liusvaara
> 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: I'm proposing that at any time there
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
> wrote:
>
> The following errata report has been submitted for RFC6797,
> "
> On Aug 14, 2015, at 7:08 PM, Valery Smyslov 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 deplo
> On Aug 10, 2015, at 10:04 PM, Andrei Popov 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 like to point out
> On Aug 10, 2015, at 8:10 PM, Andrei Popov 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
> triggers client aut
> On Aug 3, 2015, at 8:39 PM, David Mazieres
> wrote:
>
> Eric Rescorla writes:
>
>> - ECDH_anon with P256 and Curve25519
>> - AES_128_GCM; AES_256_GCM; ChaCha/Poly1305
>
> This is a naive question, but could we get some guidance from the powers
> that be on what ciphers are and are not appr
> On Jul 31, 2015, at 5:54 PM, Richard Barnes wrote:
>
> I have a pretty strong preference for (a), the Rescorla draft. New code is
> undesirable in security systems -- better to rely on a known, battle-tested
> code base.
The codebase is going to be new anyway. We’re not likely to be abl
> On Jul 31, 2015, at 3:58 AM, Cullen Jennings wrote:
>
>
> I prefer for the WG to select draft a) draft-rescorla-tcpinc-tls-option-03 as
> the starting point.
>
> The track record of security bugs in developing a new security protocol
> result in me having a strong preference for using some
> On Jul 27, 2015, at 8:23 PM, Tommy Pauly wrote:
>
> Start with (b) tcpcrypt, and either adopt (a) once it is more specified or
> try to converge.
>
> Part of this is pragmatic. If we end up with a protocol based on tcpcrypt,
> then we will probably want to have started working earlier since
> On Jul 22, 2015, at 2:36 PM, Martin Thomson wrote:
>
> On 22 July 2015 at 02:29, Yoav Nir wrote:
>> PR at
>> https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.xml
>> ?
>
> https://github.com/tlswg/rfc4492bis/pull/6
So the chang
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 wrote:
>
> I checked with
I’d like to hear from the chairs if it’s OK to rename stuff in the IANA
registry.
That has some implications for implementations that use these names.
Not to mention that the same issue applies to DH(E)_anon
> On Jul 22, 2015, at 7:09 PM, Martin Thomson wrote:
>
> On 22 July 2015 at 19:07, Da
PR at
https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.xml ?
> On Jul 22, 2015, at 11:23 AM, Martin Thomson wrote:
>
> On 22 July 2015 at 02:20, Yoav Nir wrote:
>> They both provide forward secrecy.
>
> The draft specifically excludes ECDH_an
On Jul 22, 2015, at 10:44 AM, Martin Thomson wrote:
> I have never understood why 4492 doesn't claim forward secrecy for
> ECDH_anon suites. Can someone explain why this doesn't have an 'E’?
I wasn’t there for the original 4492, but I think it’s because the old
anonymous ciphersuites were cal
On Jul 16, 2015, at 6:50 AM, Viktor Dukhovni wrote:
> An auditor who believes that we can rigourously quantify the security
> of these curves precisely enough to say which is stronger or more
> closely "matches" AES-256, should be laughed out of the room and fired.
Same kind of auditor who tell
> On Jul 15, 2015, at 9:19 PM, Benjamin Beurdouche
> 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 use secp256r1>>secp384r1
> On Jul 1, 2015, at 10:31 AM, Martin Willi 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 ChaCha20/Poly1305 both
> On Jul 9, 2015, at 5:16 PM, Warren Kumari wrote:
> 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
> - provide a URL to intera
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 mo
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
Hi, Ben.
See below
> On Jul 8, 2015, at 5:51 AM, Ben Campbell wrote:
>
> --
> COMMENT:
> --
>
> This is easier than usual to read for this sort of draft :-)
Hi, Stephen.
See below.
> On Jul 8, 2015, at 2:15 AM, Stephen Farrell wrote:
>
>
> --
> COMMENT:
> --
>
>
> intro: "gold standard" is being a bit too keen I
uted Denial of Service Attacks
> Authors : Yoav Nir
> Valery Smyslov
> Filename: draft-ietf-ipsecme-ddos-protection-02.txt
> Pages : 25
> Date: 2015-07-04
>
> Abstract:
> This document recommends i
> On Jul 3, 2015, at 5:07 PM, Paul Wouters wrote:
>
> The problem is two different keys in two different domains in combination
> with traffic hijacking.
>
> If I steal your 8.8.8.8 route, and trick you into looking up and doing IKE to
> my domain google.nohats.ca with A record 8.8.8.8, you s
> On Jul 3, 2015, at 12:28 AM, Viktor Dukhovni 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
>>
> On Jul 2, 2015, at 10:40 PM, Viktor Dukhovni wrote:
>
> On Thu, Jul 02, 2015 at 10:09:46PM +0300, Yoav Nir wrote:
>
>>> At the end of the day though, IPSEC needs to apply policy to
>>> application traffic presented to the kernel (almost universally)
>>&
> On Jul 2, 2015, at 9:22 PM, Viktor Dukhovni wrote:
>
> On Thu, Jul 02, 2015 at 09:02:03PM +0300, Yoav Nir wrote:
>
>>> Alice's keys are ignored once Mallory's PAD entry for 192.0.2.5
>>> supercedes or displaces Alices.
>>
>> Ah, I see the
> On Jul 2, 2015, at 8:08 PM, Viktor Dukhovni 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 ...
> On Jul 2, 2015, at 6:48 PM, Viktor Dukhovni 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
> On Jul 2, 2015, at 6:03 PM, Viktor Dukhovni 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 t
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
ba
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 anyw
> On Jul 1, 2015, at 1:55 AM, 🔓Dan Wing wrote:
>
>
> On 30-Jun-2015 02:50 pm, Dave Dolson 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 kind of alert. Yet the
> On Jun 16, 2015, at 4:44 PM, Paul Wouters wrote:
>
> On Tue, 16 Jun 2015, Yoav Nir wrote:
>
>> Transport mode works fine behind NAT devices. For example, L2TP clients
>> connect to VPN gateways using transport mode and they work behind NAT
>> devices.
&g
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 wrote:
>
> -BEGIN PGP SIGNED MESSAGE---
Done.
> On Jun 14, 2015, at 8:57 PM, Yaron Sheffer 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
afts
>> 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
> On Jun 13, 2015, at 4:12 PM, Salz, Rich 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
>
> Thi
> On Jun 12, 2015, at 10:08 PM, Kathleen Moriarty
> 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 <mailto:ynir.i...@gmail.com>> wr
e-curve25519-00.txt
> Date: June 11, 2015 at 11:01:26 AM GMT+3
> To: "Yoav Nir" , "Simon Josefsson"
> , "Yoav Nir" , "Simon Josefsson"
>
>
>
> A new version of I-D, draft-nir-ipsecme-curve25519-00.txt
> has been successfully submitt
oly1305. 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 <mailto:ynir.i...@gmail.com>> wrote:
>
> > On Jun 11, 2
> On Jun 11, 2015, at 2:36 AM, Bill Cox 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 draft-saarinen-blake2 is? If
> On Jun 9, 2015, at 4:07 AM, Zooko Wilcox-OHearn
> wrote:
>
> On Tue, Jun 9, 2015 at 12:57 AM, Salz, Rich 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 currently the fastest on my machine, an
> On Jun 8, 2015, at 1:37 PM, Hubert Kario via RT 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 to m
> On Jun 8, 2015, at 1:37 PM, Hubert Kario via RT 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 to m
Hi, Kathleen.
Please see below
> On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty
> 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 soon). Anyway, I have a fe
> On May 28, 2015, at 1:40 PM, Tero Kivinen 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 tu
Hi, Vijay.
Thanks for the response.
> On May 28, 2015, at 12:38 PM, vijay kn 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 ensure that the othe
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 c
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 either.
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
> draft-ietf-ipse
> On May 9, 2015, at 7:32 PM, Yaron Sheffer 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 information to make a
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 m
Thanks, Tero.
Fixed in -07
Yoav
> On May 4, 2015, at 6:19 PM, Tero Kivinen 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:
>
> -
> On Apr 28, 2015, at 4:09 PM, Michael Richardson wrote:
>
>
> Yoav Nir 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
t; 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-poly130
> On Apr 28, 2015, at 2:49 AM, Paul Wouters 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 w
> On Apr 27, 2015, at 6:25 PM, Michael Richardson 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 considerations, the
> qu
should 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 wrote:
>>>
>>> I am still a bit confused abo
Hi, Martin. See inline.
> On Apr 27, 2015, at 2:02 PM, Martin Willi 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 example in our cod
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 wrote:
>
> In the ESP Example in Appendix A, the 'Next Header' field is missing from the
> ESP Trailer portion of the plaintext.
>
> Regards,
> Steve
>
> On Apr 27, 2015, at 10:46 AM, Yaron Sheffer 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 64-bit, same as
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 wrote:
>
> Hi.
>
> At Paul’s request I have added examples in appendix A and appendix B.
>
&g
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 IKE & IPsec
>Author : Yoav Nir
&g
Will do, although 4106 doesn’t have any either.
Yoav
> On Apr 25, 2015, at 5:54 PM, Paul Hoffman wrote:
>
> On Apr 25, 2015, at 2:27 AM, Yoav Nir wrote:
>> With this I believe the document is ready for WGLC. I might want to add an
>> appendix with an example.
>
>
And adding the [1]…
On Apr 25, 2015, at 12:27 PM, Yoav Nir 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 wrote:
Hi
This new version closes (I think) all the open issues. I have removed all
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 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 that GDOI allocated
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-03.txt
>
Hi, Valery.
Thanks for the review. See my reply inline.
> On Apr 21, 2015, at 7:19 PM, Valery Smyslov 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 issues.
> On Apr 6, 2015, at 10:07 PM, Stephen Kent 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
ernet-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: dr
> On Mar 30, 2015, at 8:42 PM, Scott Fluhrer (sfluhrer)
> 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-
> On Mar 31, 2015, at 1:49 PM, Tero Kivinen 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 inpu
> On Apr 1, 2015, at 3:37 PM, Martin Willi 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
>> [chacha_poly]
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 wrote:
>
> One more thing.
>
> I would like to req
> On Mar 31, 2015, at 5:03 PM, Paul Wouters wrote:
>
> On Tue, 31 Mar 2015, Yoav Nir wrote:
>
>> 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 E
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 wrote:
>
> One more thing.
>
> I would like to req
gt;
>
> 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
>
> On Mar 30, 2015, at 10:07 PM, Warren Kumari wrote:
>
> On Mon, Mar 30, 2015 at 7:41 AM, Patrick McManus wrote:
>> I really appreciate the draft.
>>
>> There is one thing I really like about the draft, as it operates at a dhcp
>> level the first hint I'm in a CP happens strictly before any co
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 wrote:
>
> Hi,
>
> There is two questions I would like guidance from the group about.
>
> First is the nonce/IV question:
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 6
> 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 advan
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 d
Hi, Mike
> Please discuss on the saag mail list. I will schedule a
> meeting time at a local drinking establishment for either Monday or Wednesday
> at 7:30 PM (local Dallas time). I’d appreciate feedback on the meeting times
> (if you expect to attend) as well as any comment o
> On Mar 6, 2015, at 6:01 PM, Paul Hoffman wrote:
>
> On Feb 26, 2015, at 2:11 PM, Paul Hoffman 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 IPsecME. If you want this as a WG do
> On Mar 12, 2015, at 1:38 AM, paul_kon...@dell.com wrote:
>
>>
>> On Mar 11, 2015, at 5:23 PM, Yoav Nir wrote:
>>
>>
>>> On Mar 11, 2015, at 8:54 PM, Russ Housley wrote:
>>>
>>> About two years ago, I was at a workshop where
> On Mar 11, 2015, at 8:54 PM, Russ Housley 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 adjust
> their
> On Mar 6, 2015, at 6:01 PM, Paul Hoffman wrote:
>
> On Feb 26, 2015, at 2:11 PM, Paul Hoffman 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 IPsecME. If you want this as a WG do
> On Feb 26, 2015, at 4:48 PM, Paul Wouters 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 m
> On Feb 24, 2015, at 4:24 PM, Michael Richardson wrote:
>
>
> Yoav Nir wrote:
>>> On Feb 24, 2015, at 1:21 PM, Yoav Nir wrote:
>>>
>>> In the meantime, I have updated my draft to only define the
>>> AEAD. Since we now have CFRG’s “stamp
> On Feb 24, 2015, at 1:21 PM, 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” …
* Since we **now** have...
___
IPsec mailing list
IPsec@ie
> On Feb 9, 2015, at 4:03 AM, Paul Wouters 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 always
Thinking it over, you don’t really need AES at all, and in any case it doesn’t
matter. The initiator doesn’t know the key and doesn’t know the algorithm, so
it’s entirely a local matter.
For example, the responder could pick HMAC-SHA256 with a fixed key, and
calculate HMAC-SHA256(K,cookie). An
> On Feb 1, 2015, at 8:38 PM, Scott Fluhrer (sfluhrer)
> wrote:
>
> If you want to tighten up the time between worse case and average case time
> taken by the problem solver, might I suggest this:
>
> - When the verifier is asked to generate a problem, it pick a nonce N, and
> use it to comp
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 16
-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 wrote:
>
> The three-sigma rule applies even with a non-normal distribution.
>
> Anyway, I tried the 64-key samp
have a lot of uncertainty.
> 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.
>>
>>
>>
>>
And now it’s really attached.
data.xlsx
Description: MS-Excel 2007 spreadsheet
> On Feb 1, 2015, at 11:45 AM, Yoav Nir wrote:
>
>
>> On Jan 31, 2015, at 12:35 AM, Yoav Nir wrote:
>>
>>
>>> On Jan 30, 2015, at 3:37 PM, Yaron Sheffer wrote:
>>&
601 - 700 of 1764 matches
Mail list logo
