[TLS] Fwd: New Version Notification for draft-ietf-tls-rfc4492bis-04.txt

[Yoav Nir]

Hi

I’ve submitted version -04 of this draft, incorporating the new curves 
Curve25519 and Curve448.

I’m sorry to say that I have made the merge far too quickly and the result is 
quite sketchy, but I did beat the deadline.

So I’m hoping to complete the merge soon.

Yoav


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Date: 19 October 2015 at 6:56:17 PM GMT+3
> To: "Yoav Nir" <ynir.i...@gmail.com>, "Manuel Pegourie-Gonnard" 
> <m...@elzevir.fr>, "Simon Josefsson" <si...@josefsson.org>, "Simon Josefsson" 
> <si...@josefsson.org>, "Yoav Nir" <ynir.i...@gmail.com>, "Manuel 
> Pegourie-Gonnard" <m...@elzevir.fr>
> Subject: New Version Notification for draft-ietf-tls-rfc4492bis-04.txt
> 
> 
> A new version of I-D, draft-ietf-tls-rfc4492bis-04.txt
> has been successfully submitted by Yoav Nir and posted to the
> IETF repository.
> 
> Name: draft-ietf-tls-rfc4492bis
> Revision: 04
> Title:Elliptic Curve Cryptography (ECC) Cipher Suites for 
> Transport Layer Security (TLS) Versions 1.2 and Earlier
> Document date:2015-10-19
> Group:tls
> Pages:30
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4492bis-04.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-04
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-04
> 
> Abstract:
>   This document describes key exchange algorithms based on Elliptic
>   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
>   protocol.  In particular, it specifies the use of Ephemeral Elliptic
>   Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
>   use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
>   authentication mechanism.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [tcpinc] A few nits about draft-rescorla-tcpinc-tls-option-04

[Yoav Nir]

> On 19 Oct 2015, at 6:24 AM, Martin Thomson  wrote:
> 
> On 18 October 2015 at 16:59, Eric Rescorla  wrote:
>> Yeah, I am starting to think I was getting too clever here and it would be
>> better
>> to just say "tear down the connection"
> 
> 
> I can't think of any situation in which a compliant, valid ServerHello
> would induce that behaviour.  It would have to be busted somehow, I
> guess.

I was thinking some extension missing from the ServerHello that the client 
isn’t willing to do without, but I can’t think of any that makes sense. A 
ServerKeyExchange might have a key or a signature that fails some standard. I 
guess the “western” client with the GOST server is solved by the server 
returning an alert instead of a ServerHello.  In this case they could continue 
with the connection but it’s still a matter of classifying all the fatal vs 
non-fatal conditions. That and coming up with an alternate term that does not 
confuse with the fatal and non-fatal alerts of TLS.

Yoav


___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

[tcpinc] A few nits about draft-rescorla-tcpinc-tls-option-04

[Yoav Nir]

Hi

Two things that bothered me that I think have not been mentioned by either 
Mirja or David:

Section 2 says: "If the TLS handshake fails for non-cryptographic reasons … 
endpoints SHOULD behave as if the the TCP-TLS option was not present.”
I’m missing what counts as “cryptographic” vs not. So there is one example: no 
matching ciphers, but we need a bit more: What about an unsupported public key 
on the server? What about an invalid signature? What about a bad Finished 
message? What about an unrecognized record type? An unrecognized handshake 
message?

Second thing I’m missing is about how we get from the state of negotiating TLS 
to the state of behaving as if the TCP-TLS option was not present. Obviously 
with a fatal error (or “cryptographic reason”) the side that detected the 
failure closes the TCP connection. That’s the easy part. But what if we have a 
non-fatal (in the sense of tcpinc) issue? Does the detecting side send an 
alert? Does the other side begin transmitting plaintext immediately following 
the alert? 

Suppose the Client processes the Server’s ServerHello and is not happy (maybe 
there’s a missing extension). It sends an Alert, but the server is still 
sending the other messages (key share, How do we know at which point the server 
can abort sending records and start sending plaintext? I think the 
synchronization mechanism should be explained.

HTH

Yoav


___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Re: [IPsec] RFC4307 update

[Yoav Nir]

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 AES-CBC. This 
is the same as 3DES-CBC when RFC 4307 was published. I didn’t make it a MUST- 
because I don’t know what the next MUST is going to be.

AES-GCM: “8 octet ICV” vs “16 octet ICV” - that was a mistake. Of course I 
meant 16, and I will fix it in -01. As for requirement level, as far as I know, 
AES-GCM got a lot of adoption for IPsec, but not so much for IKE. Why? Because 
it is only defined since RFC 5282, and also because it cannot be used in IKEv1, 
and also because its speed advantage doesn’t matter much in IKE. My 
implementation does not have it for IKE (just an example)

AES-CCM: Why a MUST?  I don’t have any interest in implementing it. 

So with no clear direction on what the next “go to” algorithm is going to be, I 
don’t think it’s time yet to hint at AES-CBC’s deprecation.

SHA-512: I assume you mean HMAC-SHA-512 as PRF and integrity algorithm. Do we 
need it? The future seems to be AEAD algorithms, so do we really need 
PRF_HMAC_SHA2_512 ? Perhaps something SHA-3 based is going to be the future?

"Can we add a recommendation to use integ == prf for non-AEAD algorithms?” - I 
don’t thin we can in this document. That would be changing IKE, no?

Group 18 (8192 bits) - IMO this is so slow that I don’t like making it a SHOULD.

"Can we recommend that the initial exchanges and create child sa use
the same MODP group? and that we recommend PFS for create_child_sa.”

The former is a sensible recommendation, but it belongs in 7296, not here. 
As for recommending PFS, I’m not sure. This is not the same as TLS. PFS in TLS 
prevents exposing encryption keys with the future exposure of a long-term 
secret - the private key.
In IKE the IPsec encryption key depends not on the long term secret, but on 
another ephemeral value - the SK_d. This is far less problematic, so I’m not 
sure such a recommendation is worth the cost.

"Can we recommend that a default proposal set should have at least one
MUST algorithm for each type?”

I didn’t understand this. What is a default proposal set?

"Can we recommend not to apply these recommendations for IKEv1 because
that will cause more interop problems (see my draft for text)”

I think we should just ignore IKEv1 at this point. You definitely should not 
use AES-GCM with IKEv1.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

> 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 Heartbleed a 5; CVS v3 called it 
>> 7.5
>> 
> 
> We know it, but one of indicators.
> How can you say the dangerous or risk instead of it? 
> My point is, CRIME is risk for every case?  

I don’t know. Probably not. 

But consider that we had been using HTTP with TLS for over 15 years before we 
found out about CRIME. It’s a subtle attack that relies on specific structures 
in HTTP and the peculiar way that browsers allow a script from one site to 
issue requests on behalf of another site. But still, it took researches all 
these years to find it. 

There are many lessons to be learned from this: that a bearer token that is 
repeated many times is not a good idea; that the trust model in the web is not 
great; but also that blindly compressing content with no regard to its 
structure and sources is dangerous and reveals information about the cleartext. 
 A security protocol should not do that. 

An even more executive-level lesson might be that security layers should not 
provide non-security services, but that is not really convincing because if 
there was a separate compression layer that you could compose with the security 
layer in TLS, CRIME would still be possible. To compress HTTP without the 
danger of CRIME you need to either not compress header fields with sensitive 
information, not compress header fields that might be controlled by an 
attacker, or at least delegate those to a separate compression state. That is 
not something that any transport layer shim can provide.

Yoav

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [IPsec] RFC4307 update

[Yoav Nir]

> 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 document too, as it now defines
>> following madantory to implement algorithms:
> 
>> 1024 MODP Group, ENCR_3DES, PRF_HMAC_SHA1, AUTH_HMAC_SHA1_96.
> 
>> And I think at least the 1024-bit MODP groupp, and perhaps the 3DES
>> also should be changed to something more suitable. For exmple 2048-bit
>> MODP group and ENCR_AES_CBC...
> 
> I guess the can-o-worms called ECDSA will show up too as a SHOULD+.

Does it have to? 4307 does not mention any signature algorithms. ECDH with NIST 
curves and/or the new curves might should make an appearance.

> Does 3DES go to MAY?

I think so.

> Does SHA1 go to MUST-?
> 
> We hadn't listed SHA2 at all before.
> We also have no GCM/CCM things specified.
> 
> Are we obligted to list them as SHOULD+ for awhile?

I think we should reflect what is common/best practice now. AES-GCM is now 
widely implemented and faster than the combination of AES-CBC and 
HMAC-SHA-something. I think it’s a prime candidate for MUST. CTR was always 
uncommon. ChaCha20+Poly1305 is so new that it can't be MUST this iteration. 
Maybe next time.

> I think that the updates will otherwise be non-controversial.

Maybe.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

> 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 broadband 
>> you could get. Now you routinely get 100x that. CPU has increased, but 
>> nowhere near that. This makes compression less desirable, to the point that 
>> people did not complain much when browser vendors removed compression 
>> following the CRIME attacks. True, the rise of mobile brought back limited 
>> bandwidth, but is this really an issue?
>> 
> I don't think using bandwidth as a factor is a good idea.
> 
> On other lists I still see the occasional quip about suffering a low
> bandwidth connection. It used to be folks in some European countries,
> but most recently I seem to recall South American. (I think we're
> seeing the shift because South American countries are going places
> American and Europeans have already been with respect to
> infrastructure).

At some point the countries with the least developed infrastructure eventually 
go through some government-led project to improve infrastructure, and that 
makes them leapfrog most other countries just because all their infrastructure 
is suddenly new. It happened in South Korea 15 years ago, and it’s happening in 
many African countries now. I don’t think we should burden a security protocol 
with a problematic mode based on a perceived need that might evaporate in a 
couple of years. Deploying high bandwidth is even faster now that you can make 
the last mile wireless rather than running copper or fiber to individual homes.

> In the rural US, I understand low bandwidth is the norm. Those folks
> can't get companies like Verizon or Comcast to service them due to
> population density. Its just not profitable for the providers to
> update the infrastructure. Also see
> https://www.google.com/search?q=rural+us+high+speed+internet.

That supports my point.  To quote one of the top results from that search (the 
first one that was not an ad):

"53 percent of rural Americans have no access to high-speed Internet, 
which he defined as capable of downloading content at 25 megabits per second.”

15 years ago, having “no access to high-speed Internet” meant having just 
56Kbps dial-up modem. 10 years ago it meant not having access to 0.5 Mbps 
broadband. The bar is now significantly higher. And you don’t usually need 25 
Mbps for NNTP, although the last time I actually used NNTP was over a 56Kbps 
modem. 

Yoav
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [IPsec] WG Interest in TCP Encapsulation

[Yoav Nir]

> 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 made the UDP framentation document, our original plan was to
> run IKEv2 over TCP, just because that would solve this problem.
> 
> During this process we then found out that WG wanted to standardize
> UDP fragmentation instead of IKEv2 over TCP.
> 
> Is there really happend something that changes that?
> 
> The old informal poll can be found from 
> 
> http://marc.info/?t=13632609353=1=1
> 
> So how does your draft relate to the earlier ike over tcp draft? 
> 
> http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ike-tcp/

Hi, Tero

At the time that we (at my suggestion) dropped the work on IKE over TCP it was 
because of a conclusion we had reached:

In all the cases where IKE over TCP solves your connectivity issues but IKE 
fragmentation doesn’t, the IPsec would fail.

At the time, the WG was not in favor of running the IPsec over that TCP 
connection, so there seemed to be little point.

This draft is proposing both IKE and ESP over the TCP connection, so the 
protocol will work in situations where UDP (even with fragmentation at the IKE 
rather than IP layer) fails.

We’ve had something like this working with IKEv1 for over 10 years. Many 
vendors have “SSL VPN” solutions that have pretty much the same performance, 
scalability, and connectivity characteristics. There’s ample evidence that this 
kind of solution works. And although the need is slowly diminishing (more and 
more public networks allow IKE and IPsec to work), there are still many places 
where we still need to tunnel everything over TCP.

It it hasn’t been clear, I am in favor of adopting this draft.

Yoav


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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) for curve25519, and curve448,
 how can we ever get public values having that bit set? So why it is
 only SHOULD to reject that public key? I mean if we receive such
 public key, that clearly means that other end is either attacker, or
 working incorrectly, and we MUST always reject it.
 
 Or if there is no security issues accepting such public keys, then why
 not just say that no checks needs to be done. If we reject such public
 key, what behavior should happen in IKE level? Error message, drop
 silently? Same as RFC6989?
 
 Tough one. The draft says something about implementation fingerprinting, but 
 if some implementations drop this at the IKE level and some don’t that’s is 
 a new avenue for fingerprinting. I don’t know which one is right. In any 
 case, *if* you make the check *and* it fails *then* it’s appropriate to send 
 an INVALID_SYNTAX (although I don’t understand why RFC 6989 recommends that 
 over INVALID_KE_PAYLOAD) notification.
 
 
 RFC 6989 recommends INVALID_SYNTAX because per RFC 7296, INVALID_KE_PAYLOAD 
 is used for cases where the initiator is expected to retry the exchange. 
 Incorrect DH values are at best a bug and at worst an attack, and should not 
 result in an automatic retry.

Ah. Makes sense. Section 2.5 has the string “invalid KE payload” several times, 
so it looked strange.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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 file name. 

The title is New Safe Curves for IKEv2 Key Agreement”, which I think is 
slightly better than the CFRG draft (Elliptic Curves for Security”), but 
perhaps too generic. Maybe we should follow the example of the TLS draft 
(“Curve25519 and Curve448 for Transport Layer Security (TLS)”) and title it 
“Curve25519 and Curve448 for IKEv2 Key Agreement”.

 This document is bit confusing as some of the values are defined as
 strings of 32 octets, some are defined as 255/448-bit numbers having
 certain properties (high bit set, n lowest bits unset), but then later
 it mixes these.
 
 For example the public key is defined of string of 32 octets, but
 then section 3.1 says that it is 32 octets encoded as an array of
 bytes in little-endian order As we are talking about the string
 of 32 octets, talking about it being litt-endian is confusing.
 
 I would assume that section 8 of [CFRG-Curves] would define how to
 convert the internal number to 32-octet string, so leaving out the
 little-endian order from this draft would be clearer.

I tried to follow the example of the TLS draft where the public keys are 
strings of octets while the private (or “secret”) keys are numbers. I see that 
I missed that in section 3.1. How about:

OLD:
   o  The Key Exchange Data is 32 octets encoded as an array of bytes in
  little-endian order as described in section 8 of [CFRG-Curves]
NEW:
   o  The Key Exchange Data is a 32-octet public key as described in 
  section 8 of [CFRG-Curves]
...or even...
NEW2:
   o  The Key Exchange Data is a 32-octet public key.


 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) for curve25519, and curve448,
 how can we ever get public values having that bit set? So why it is
 only SHOULD to reject that public key? I mean if we receive such
 public key, that clearly means that other end is either attacker, or
 working incorrectly, and we MUST always reject it.
 
 Or if there is no security issues accepting such public keys, then why
 not just say that no checks needs to be done. If we reject such public
 key, what behavior should happen in IKE level? Error message, drop
 silently? Same as RFC6989?

Tough one. The draft says something about implementation fingerprinting, but if 
some implementations drop this at the IKE level and some don’t that’s is a new 
avenue for fingerprinting. I don’t know which one is right. In any case, *if* 
you make the check *and* it fails *then* it’s appropriate to send an 
INVALID_SYNTAX (although I don’t understand why RFC 6989 recommends that over 
INVALID_KE_PAYLOAD) notification.

 In the security considerations section the 2nd last paragraph only
 mentions that Curve25519 explictly, but does not mention curve448. Is
 there difference between them, or should the text say This is widely
 seen as a security advantage for these curves, since….

Nope. Just missed that when extending the document to cover Curve448.

 Typos: In section A.1.1 s/mutliplying/multiplying/
 
 The test vectors should most likely also include Curve448 test
 vectors, and perhaps even full IKEv2 KE payloads…

Yes. These were copied from the earlier TLS draft. They need some work.

Yoav


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [TLS] padding

[Yoav Nir]

 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 if there's bytes in the encrypted fragment other than the payload 
 would avoid a little bit of complexity, but with no way for an endpoint to 
 say no to increased bandwidth usage that it doesn't want to or can't handle. 
 Given this constraint, I'd favor either easily toggleable or always-on, 
 rather than a middle-ground where implementations won't know what they're 
 going to get and can't do anything about it.
 
 A footnote: Negotiating via an extension is probably not a good idea because 
 client extensions will generally be in the clear. That's why I suggest a 
 simple message instead. (there's no need to pad the cleartext hello, so it's 
 fine to wait until record protection is available) Note that I don't think 
 allowing this to be decided after the handshake is a good idea.
 
 A more generalized way to handle throttling padding would be to set a low 
 default and require each endpoint to send a message with a different value, 
 in max bytes per record (or second, or both) of padding permitted, in order 
 to use a different amount. Each endpoint could easily arbitrarily throttle 
 its downstream padding bandwidth independently, if need be.
 
 
 I have a not-very-hidden motive in not having it be negotiable: I want
 to enable clients to want to send padding be able to do so to any
 server, even if that server does not want to pad.  (They can just
 discard.)  If it's negotiated, the server may say I don't support
 padding and clients who want to use it out out of luck.

I’m not sure having one side send a continuous stream of large record buys you 
much if the other side doesn’t. Suppose an HTTPS server has 100 resources, each 
with a different size, it won’t help if the client obscures the identity of the 
resource it’s asking for if the resource can be identified by its size. Same 
goes for the existence of traffic. If the server stays quiet until there’s an 
actual request, the client’s continuous stream of padding-only records is just 
wasted effort.

IMO this is an argument for negotiation, although even with negotiation we can 
never be assured that the other side is doing TFC well. 

Yoav

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

 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: I'm proposing that at any time there is only one
 suite that everyone uses, and versioning is just for transitions.
 
 This becomes highly problematic when one needs to:
 - Support multiple security levels.
 - There isn't one technically (meaning, ignore legal constraints)
  superrior algorithm.
 
 In case of point 2, why is there a need to use multiple algorithms?

Because I believe algorithm A is superior, you believe algorithm B is superior, 
but neither of us thinks the other algorithm is so bad that we might as well 
use cleartext.

So both of our implementations (or configurations) support both algorithms, but 
whichever one gets to choose chooses according to our preference.

AES-GCM vs ChaCha20/Poly1305. Which is superior?

Yoav

___
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

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

[Yoav Nir]

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 submitted for RFC6797,
 HTTP Strict Transport Security (HSTS).
 
 --
 You may review the report below and at:
 http://www.rfc-editor.org/errata_search.php?rfc=6797eid=4449
 
 --
 Type: Editorial
 Reported by: deo luyimbaazi luyimbaaz...@gmail.com
 
 Section: facebook
 
 Original Text
 -
 i cant access Facebook wall through Mozilla Firefox, thank
 
 
 Corrected Text
 --
 i cant access Facebook wall through Mozilla Firefox, thank
 
 Notes
 -
 
 
 Instructions:
 -
 This erratum is currently posted as Reported. If necessary, please
 use Reply All to discuss whether it should be verified or
 rejected. When a decision is reached, the verifying party (IESG)
 can log in to change the status and edit the report, if necessary. 
 
 --
 RFC6797 (draft-ietf-websec-strict-transport-sec-14)
 --
 Title   : HTTP Strict Transport Security (HSTS)
 Publication Date: November 2012
 Author(s)   : J. Hodges, C. Jackson, A. Barth
 Category: PROPOSED STANDARD
 Source  : Web Security
 Area: Applications
 Stream  : IETF
 Verifying Party : IESG
 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [IPsec] DDoS draft next steps - CAPTCHA

[Yoav Nir]

 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 deployer to make sure their captcha images didn't prevent
 expected and authorized users from connecting.
 
 To be frank I hate them also as a user in real life.
 But any kind of puzzle solution (be it captca or
 cryptographic puzzle) would annoy users (additional delays, battery power 
 consumption etc.).
 captcha's also assume there is a user to talk to, which might not always
 (or even mostly) be the case.
 
 Yes, I wrote in my original e-mail that this is not appropriate
 for unattended devices. For those cryptographic puzzles are left.
 This is appropriate mostly for smartphones.

And IoT devices are left out in the cole by both approaches. They can’t do 
millions of SHA-2 fast enough, and they don’t have a user or a user interface 
capable of displaying the captcha.

I’m trying to imagine this as a conversation between the user and their phone:

  User: Connect
  Phone: VPN gateway is overloaded. Wait 48 seconds while I solve the puzzle or 
type in the numbers from this picture
  User: I guess I didn’t really want to read my work email this badly

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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 
 triggers client authentication within an existing TLS connection.
 In TLS=1.2, this was accomplished via renegotiation. In TLS1.3, there is no 
 renegotiation, so we need an alternative solution if we want to support these 
 existing sites over TLS1.3.

I’d like to point out that I am very interested in this use case, but I’m not 
sure that this is the solution.

Such sites were first broken by HTTP/2 which forbade renegotiation. Then they 
were broken again by TLS 1.3 that does not include renegotiation.

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. 

Assuming that HTTP/2 is the HTTP of the future (meaning that relegating these 
sites to HTTP/1 is a temporary thing), I don’t think that this new mechanism 
fixes the issue with renegotiation that caused httpbis to reject its usage. We 
still get a race condition where several requests might be answered before, 
after or during authentication depending on the timing of the TLS handshake 
message vs the HTTP messages.

It would be useless IMO to create an alternate renegotiation in TLS only for it 
to not be used in HTTP/2.

Yoav

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

 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 like to point out that I am very interested in this use case, but I’m 
 not sure that this is the solution.
 I'm open to alternatives that fix the broken use case. 

One solution would be to move the authentication for this use case (and perhaps 
for HTTPS in general) from the transport layer to either HTTP as an 
authentication method or to the application (through some standardized exchange 
of JSON objects).

Another option is to allow renegotiation and your mechanism in HTTP/2 with some 
change of behavior that eliminates the race condition. For example:
 1. The server receives a request for a resource that requires a client 
certificate
 2. The server sends a new HTTP message (or code) that says that client 
certificate authentication is required.
 3. The client sends a new HTTP control frame with the highest number of 
resource that it has requested.
 4. The server finishes serving all resources that don’t need authentication 
with a number below what the client sent
 5. The client does not initiate any new requests.
 6. When the server is done, it initiates renegotiation or the new mechanism
 7. After renegotiation, the client can resume sending requests, all of which 
are authenticated.

The details may be different, but something like this can bring determinism to 
the process.

 We still get a race condition where several requests might be answered 
 before, after or during authentication depending on the timing of the TLS 
 handshake message vs the HTTP messages.
 The idea is that before answering a request that requires client auth, the 
 server checks if a client cred is available. If there is no suitable client 
 cred available, the request is blocked until the client authenticates. This 
 does not necessarily have to block other requests that do not require client 
 auth.

This is a somewhat contrived example, but consider an object in the web page 
that says “Hello, guest” when no credential is available, and “Hello, Andrei” 
when a credential is available.  If the page has optional authentication and 
you have presented the certificate, then depending on timing you might still 
see “Hello, guest” on the page.

Yoav

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [IPsec] P-256 speed

[Yoav Nir]

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 checked with the NIST folks and their contractor. The answer is that their 
 sign
 operations are constant time. The attached paper describes their work in the
 context of BGPsec, because that was the motivation at NIST for exploring 
 performance
 improvements for P-256. There is one table (3) that also compares P-256 code 
 to 25591 
 in terms of signature performance. I realize that we were discussing ECDH, 
 not ECDSA,
 for IKE(v2) but I believe the performance numbers cited in this paper are 
 indicative 
 of what one would see in that context as well.
 
 Steve
 Efficient and Secure ECC Implementation of Curve  P-256  
 vf.pdf___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [TLS] sect571r1

[Yoav Nir]

 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 use secp256r1secp384r1secp521r1 and everything else is lost in 
the noise. 

At any rate, if the group decides to keep it, I might as well bring it back to 
4492bis as well.

Yoav

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

 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
 - provide a URL to interact with the Captive Portal and satisfy the
 requirements
 - interact with the Captive Portal to obtain information
 such as status, remaining access time, etc.
 - (optionally) advertise a service whereby devices can enable or
 disable unrestricted access without human interaction

This may be covered by the third bullet (sort of...) but I would like the 
endpoint to be able to authenticate the captive portal (captor? MitM?). This 
could be done by requiring that the URL be https and that the certificate 
identify the portal.  For example, I’m typing this while riding a train on my 
way home. If the captive portal here had a CN or alternate name such as 
“www.rail.co.il” or “captive-portal.rail.co.il” that would be fine. If it said 
“CN=acme-initial-certificate,OU=replace-before-deploying,O=do-not-use-in-production”
 I would be more worried about using it.

I think publicly trusted certificates are now cheap enough that we can require 
them in (new) captive portals. This is especially important in places like some 
airports where the portals ask for your credit card number.

I realize this has its limitations. If I go to Frankfurt airport and the 
certificate says “CN=captive.frankfurtflughafen.de” I don’t know if this is the 
real domain of the airport or a convincing domain name somebody registered in 
order to obtain the certificate. But methods to get the right identity can be 
layered on top of authentication.

Yoav

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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

[Yoav Nir]

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 most modern platforms, AES is
   anywhere from 4x to 10x as fast as the previous most-used cipher,
   3-key Data Encryption Standard (3DES - [SP800-67]). 3DES also has a
   64-bit block, which means that the amount of data that can be
   encrypted before rekeying is required is not great.  These reasons
   make AES not only the best choice, but the only choice.

   The problem is that if future advances in cryptanalysis reveal a
   weakness in AES, VPN users will be in an unenviable position.  With
   the only other widely supported cipher being the much slower 3DES, it
   is not feasible to re-configure IPsec installations away from AES.
   [standby-cipher] describes this issue and the need for a standby
   cipher in greater detail.

NEW:
   The Advanced Encryption Standard (AES - [FIPS-197]) has become the
   go-to algorithm for encryption.  It is now the most commonly used 
   algorithm in many areas, including IPsec virtual private networks
   (VPN).  On most modern platforms AES is anywhere from 4x to 10x as 
   fast as the previous popular cipher, 3-key Data Encryption Standard 
   (3DES - [SP800-67]). 3DES also uses a 64-bit block, which means that 
   the amount of data that can be encrypted before rekeying is required 
   is limited. These reasons make AES not only the best choice, but the 
   only viable choice for IPsec.
   
   The problem is that if future advances in cryptanalysis reveal a
   weakness in AES, VPN users will be in an unenviable position.  With
   the only other widely supported cipher for IPsec implementations 
   being the much slower 3DES, it is not feasible to re-configure IPsec 
   installations away from AES. [standby-cipher] describes this issue 
   and the need for a standby cipher in greater detail.


Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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 ChaCha20/Poly1305 both in IKEv2 and in our userland ESP
 backend (see [2] for details). It is not mainline/released yet, but gets
 merged as soon as we have the final IANA identifier.

Hi.

The latest two revisions have the final IANA number. It is 28.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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 abstract 
(although I did expand IKE. The others are “IPsec”, which I think it’s fine to 
not expand, and “VPN”, which I agree should have been expanded.

Were there any others?

Yoav

 On Jul 9, 2015, at 1:10 AM, Jari Arkko jari.ar...@piuha.net wrote:
 
 Thanks for the review, Meral!
 
 (Authors, I assume you have seen the editorial comment below on acronyms; I 
 don’t see any e-mail related to it.)
 
 Jari
 
 On 30 Jun 2015, at 07:10, Meral Shirazipour meral.shirazip...@ericsson.com 
 wrote:
 
 I am the assigned Gen-ART reviewer for this draft. For background on 
 Gen-ART, please see the FAQ at 
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
 
 Please resolve these comments along with any other Last Call comments you 
 may receive.
 
 
 Document: draft-ietf-ipsecme-chacha20-poly1305-10
 Reviewer: Meral Shirazipour
 Review Date: 2015-06-29
 IETF LC End Date: 2015-06-29
 IESG Telechat date: NA
 
 
 Summary:
 This draft is ready to be published as Standards Track RFC.
 
 
 
 Major issues:
 
 Minor issues:
 
 Nits/editorial comments:
 -Please consider spelling out acronyms at first use.
 
 
 
 Best Regards,
 Meral
 ---
 Meral Shirazipour
 Ericsson
 Research
 www.ericsson.com
 ___
 Gen-art mailing list
 Gen-art@ietf.org
 https://www.ietf.org/mailman/listinfo/gen-art
 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Yoav Nir]

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 bit too keen IMO, I'd say
 toning the language down a bit would be better.

AES is what I get when I’m using IPsec, TLS (at least in browsers and SMTP) and 
SSH with normal tools. It’s what disk encryption schemes use and what S/Mime 
uses. Even the DICE profile names AES as the MTI algorithm. Same for the 
current TLS 1.3 draft and HTTP/2 RFC. When Intel was looking to add a 
cryptographic algorithm to the general-purpose CPUs, they chose AES. IBM did 
the same with mainframe CPUs. Any paper describing a new algorithm compares the 
new algorithms to AES. Even here at the IETF we tend to call anything else 
“vanity crypto”. I think “gold standard” is appropriate. I guess I could 
rephrase it as “has become the go-to algorithm for encryption”, although that 
might be too American an idiom.

 intro: 3DES may be the only other widely supported cipher
 for IPsec, but that's not true more generally.

Well, this is a document about IPsec. It’s also true for TLS and SSH. There’s 
also the occasional Blowfish and Camelia, but 3DES is more common than any of 
them. There is RC4 and it’s fast, but (1) you can’t use that in IPsec, and (2) 
you don’t want to use that in TLS and SSH anyway.

 section 2 says: As the ChaCha20 block function is not applied
 directly to the plaintext, no padding should be necessary.
 That should could be confusing as written if a reader thinks
 it means their code doesn't have to do padding. It might be
 better to e.g. say something like In theory no padding is
 needed for this cipher, however, in keeping with… 

I take the point, but I don’t like using “in theory”. How about:
   As the ChaCha20 block function is not applied directly to the
   plaintext, the algorithm does not require any padding. However,

 section 3: Is SHOULD inlude no padding really right?  I'd
 have thought a MAY was better there.  MUST accept any length
 is also a bit odd - what if I (try:-) add loads of padding?

This pretty much follows the text in RFC 7296:
   o  Pad Length is the length of the Padding field.  The sender SHOULD
  set the Pad Length to the minimum value that makes the combination
  of the payloads, the Padding, and the Pad Length a multiple of the
  block size, but the recipient MUST accept any length that results
  in proper alignment.  This field is encrypted with the negotiated
  cipher.
Since there is no proper alignment requirements for this algorithm, I take that 
to mean “no padding” but “MUST accept any length”. It’s true that with a 
single-octet byte length you can’t insert more than 255 octets of padding, but 
I don’t thin this has to be spelled out.

 Appendices: thanks for those - I assume someone checked them
 for you? (I didn't:-)

Martin Willi (implementer of StrongSwan) did, and pointed out a mistake in a 
previous version.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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 draft :-) 
 
 -- Section 1, 1st paragraph:
 I concur with Stephen's comment. Furthermore, this entire paragraph
 pretty much reads like advertising copy. Can it be toned down a bit?

As I replied to Stephen, I think the text is factual. Perhaps a more toned-down 
version could be something like this:

   The Advanced Encryption Standard (AES - [FIPS-197]) has become the
   go-to algorithm for encryption.  It is not the most commonly used 
   algorithm in many areas, including IPsec VPNs.  On most modern 
   platforms AES is anywhere from 4x to 10x as fast as the previous 
   popular cipher, 3-key Data Encryption Standard (3DES - [SP800-67]). 
   3DES also has a 64-bit block, which means that the amount of data 
   that can be encrypted before rekeying is required is not great.  
   These reasons make AES not only the best choice, but the only choice.


 -- 8.1 (Normative References)
 
 The reference to [RFC7539]  is a normative downref. I don't see it on the
 downref registry, nor was it mentioned in the last call notice. (For the
 record, I think it's a reasonable downref.)

Yes, it should have been pointed out. RFC 7539 was written specifically to 
serve as a reference for this and the TLS document (and any future documents 
anyone might want to write about SSH, S/Mime, etc.)

Yoav
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

Hi,

Nothing earth-shattering here. Only a few editorial fixes.

A friendly reminder of Yaron’s message from two weeks ago:
http://www.ietf.org/mail-archive/web/ipsec/current/msg09910.html

Yoav

 On Jul 5, 2015, at 8:49 AM, internet-dra...@ietf.org wrote:
 
 
 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   : Protecting Internet Key Exchange (IKE) 
 Implementations from Distributed 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 implementation and configuration best
   practices for Internet-connected IPsec Responders, to allow them to
   resist Denial of Service and Distributed Denial of Service attacks.
   Additionally, the document introduces a new mechanism called Client
   Puzzles that help accomplish this task.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/
 
 There's also a htmlized version available at:
 https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-02
 
 A diff from the previous version is available at:
 https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-02
 
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[dane] DANE and IPsec

[Yoav Nir]

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 
basic document. This is what I would like to propose.

IPsec as defined in RFC 4301 has a static configuration. Specifically, there is 
a data structure called PAD (peer authorization database). This structure 
contains a list of peers authorized to communicate with this IPsec entity, and 
for each such peer the following:
 - protocol and method for authentication
 - authentication data
 - constraints on the types and values of IKE IDs sent.
 - location, such as IP address (or DNS name).

For example, we might have a peer that will use IKE with certificates to 
authenticate, its certificate will have an alternate name that says “vpngw”, It 
will send an ID payload that says “VPN Gateway” and it’s located at 192.0.2.5.

What I can see DANE doing is reducing many of those fields in the PAD to a 
single field: and FQDN.  So a PAD record for a peer when DANE is used will have:
 - protocol and method (IKE with DANE)
 - FQDN: as in vpngw.example.com http://vpngw.example.com/

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 or raw public key used in IKE. And the document can specify what 
the ID payload looks like: in all likelihood the FQDN itself is a good idea. 
Similar to the way a TLS client gives the TLS server a hint of identity using 
SNI, IKE has an IDr payload in the IKE_AUTH request which should perform a 
similar function. 

What do people think?  

Yoav

___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

Re: [dane] DANE and IPsec

[Yoav Nir]

 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 or raw public key used in IKE.
 
 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)?

Not sure I follow. Mallory publishes
 - mallory.example.com  IN  A 192.0.2.5
 - mallory.example.com  IN TLSA 

But there’s also 
 - alice.example.com IN A 192.0.2.5
 - alice.example.com IN TLSA 

So Mallory can push people looking for his IPsec entity to go to Alice’s IPsec 
entity. Once there they might accept the public key they’re presented with (if 
he has copied the contents of the TLSA record) or not. Assuming Mallory cannot 
publish alice.example.com records, where is the attack?

 I thought that Paul Wouters is working on a more comprehensive
 specification, IIRC in an IPSEC working group where it can get
 better informed review.  This is much more of an IPSEC design
 problem, than a DANE design problem.

Paul is working on host to host IPsec for opportunistic encryption. The problem 
I would like to solve is that configuring the PAD is (1) hard, and (2) 
unwieldy, because any changes to your certificate requires updating the static 
configuration on all your peers.

Yoav

___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

Re: [dane] DANE and IPsec

[Yoav Nir]

 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)?
 
 Not sure I follow. Mallory publishes
 - mallory.example.com  IN  A 192.0.2.5
 - mallory.example.com  IN TLSA 
 
 But there's also 
 - alice.example.com IN A 192.0.2.5
 - alice.example.com IN TLSA 
 
 So Mallory can push people looking for his IPsec entity to go to Alice's
 IPsec entity.
 
 No, Mallory might be able to hijack the traffic keys to 192.0.2.5
 (Alice's IP address), and then MiTM the traffic in question (BGP
 attack or equivalent).  If there's no risk of MiTM, just do anon-DH
 and you're done, no need for a PKI.
 

It’s the Internet. MitM is always a risk. But I’m still not getting it. IPsec 
traffic keys are negotiated with the IKE protocol, which provides both 
authentication and key exchange with D-H. How could mallory hijack traffic 
keys?  If Mallory doesn’t have the private key that matches the public key in 
Alice’s TLSA record ([1]) then IKE will fail.

Yoav

[1] I’m assuming here use of the same TLSA record as in TLS, but it could be 
another type of record

___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

Re: [dane] DANE and IPsec

[Yoav Nir]

 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 for keys she possesses.
 
 But there's also 
 - alice.example.com IN A 192.0.2.5
 - alice.example.com IN TLSA 
 
 Alice's keys are ignored once Mallory's PAD entry for 192.0.2.5
 supercedes or displaces Alices.

Ah, I see the source of my confusion.  

I never think of a PAD as a table indexed by IP address. The “key” for the PAD 
is a peer, so in practice it might be indexed by an internal name (such as the 
“conn” labels in the ipsec.conf file in all *swan implementation) or it might 
be indexed by the content of the ID payload that we expect that peer to present 
in IKE.

There is no entry for 192.0.2.5.  I’m suggesting that there should be a static 
entry in the PAD for “alice.example.com”. DNS is used to resolve this to an IP 
address and to a public key. Unless mallory can affect “alice.example.com” 
entries, the victim never gets to see his records, because she never looks for 
them.

Yoav

___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

Re: [dane] DANE and IPsec

[Yoav Nir]

 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 if you want the SPD and PAD to be dynamic,
 such as reading them from DNS.
 
 Dynamic.
 
 There is RFC 4025 with the IPSECKEY record. So when the application performs
 a DNS lookup for www.example.com, the OS could also ask for an IPSECKEY
 record and get both public key and a gateway address. If we set the gateway
 address to be equal to the server address, this is the transport-mode
 use-case. Again, this all begins with the DNS name, so mallory cannot do
 anything.
 
 Mallory can often trigger DNS lookups for her own domain, which
 can return IP addresses that collide with Alice's domain.  How
 is that handled?

RFC 4025 and Wikipedia suggest mapping the IPSECKEY record to the address 
through reverse DNS. I don’t know in what percentage of the Internet that would 
work.

Yoav
___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

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

[Yoav Nir]

 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 kind of alert. Yet the internet has not degraded into chaos.
 
 I know that some captive portal enforcement points reside at locations other 
 than ‎WiFi access points. Sometimes the networks aren't even WiFi networks. 
 So failing to provide for those would mean mobile devices would need to 
 continue with proprietary methods and new methods as well.
 
 So I think this group could try to solve the general problem, or just 
 address the WiFi at hotels and airports problem.‎ The former is what I'd 
 expect from IETF.
 
 Joining a network (the captive portal problem) is different from injecting 
 content hours or days after an endpoint has joined a network.

I agree and I think the latter should be out of scope. 

But we may need a loose definition of “joining a network”. Many airports allow 
you to join the network and browse some internal sites (departures, arrivals, 
airport map, stores in the airport), but you get the captive portal as soon as 
you try to browse to something else.

Yoav

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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

[Yoav Nir]

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 anyway.

Although I have asked (and got) the assignment for AEAD_CHACHA20_POLY1305, I’m 
still not clear on what it is for. The numbers in that registry aren’t every 
transmitted on the wire in any protocol.

Yoav

 On Jun 30, 2015, at 4:05 PM, Kathleen Moriarty 
 kathleen.moriarty.i...@gmail.com wrote:
 
 Hello,
 
 I am getting the ballot ready for the next telechat (next week on Thursday).  
 Are there any implementations?
 
 My other question is to see if some more text is going to be added to 
 distinguish AEAD_CHACHA20_POLY1305 from ENCR_CHACHA20_POLY1305.  I ask 
 because this came up in 2 reviews.  While the definitions for both are in the 
 draft and this should be clear enough, an added sentence could do some good 
 to explain that they are different.
 
 Thanks.
 
 -- 
 
 Best regards,
 Kathleen
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] nat traversal and transport mode

[Yoav Nir]

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:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hello.
 
 I have heard that transport mode should not be used if the initiator
 is behind a NAT, even with nat traversal protocols, because this does
 have some issues.
 However, I am not quite sure if I understand what issues are that?
 Also, does it mean that l2tp over ipsec suffers the same issues but
 you have no choice in this case?
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2
 
 iQIcBAEBAgAGBQJVgAnHAAoJEHb1CzgxXKwYEmkP+gOyeNY+JjLJW78mIUb6WPaW
 DKQ8TyrnWsB3rTjWeNlO0eADKlj5XfpXRhf257XDkZgDxlNNhcJxol23nx7tRRqB
 8kZimQqgpSA+WE4vQ6odZeSEIzfXElv4viPeIZgOcftDMhsgfqhpkqn7gfH+Kg8J
 SRy9JWxdPQ2oJHiurjRIjZ4/KoLqGgU+ncl9wj68FJrKjs2uM2NIncHQAlW9AEUD
 KFy/+QbIo5/UFkHzwXKzw/I5Z4Fic2YfELW6H5JmQEl77zQywKknM+OgDL58VpXW
 cQTPKvJaQLlJ7PbJi7N3t/SupQsUmQBQsPfit/q0+H3il+i+Yijkz8d/Ofy0lssB
 DUnIxr+o6R3qGx5XHNtA1F2fJ3gGFCLd5mQHOs40+Bl3Xlhyx0PcGChHGrne7INl
 vIqnLOQWyJxEUzIdTkzUbFo7UlYYJh6wUq2MViMDGrV6TbaPuhj+FewQvylpeyqH
 Bjfumhj5ShhMNeXqv0isEQz/V7KWWO47GvL8jveUcaOK7udzSwjHETK9H+Rp8S29
 BZTCFXs2TMMPEppJoSljVz/xue22aV6eCB0cT1VOtZUn3+2pZybq2Qlkzu7mAFtl
 LYYMdV/XS9ZEyYUf5KDQWIiK5+Q3dK5gFUSb6eiiWb5COToY247DsPR9yrHDDCpT
 1SfJd/Dcg4mg6i1aKB75
 =14QR
 -END PGP SIGNATURE-
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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.

NEW:
   The length of the Padding field need not exceed 4 octets. However, neither 
RFC 4303 nor this 
   specification require using the minimal padding length.

Yoav

 On Jun 14, 2015, at 10:37 AM, Yaron Sheffer yaronf.i...@gmail.com wrote:
 
 Quick nit: the sentence The Pad Length field need not exceed 4 octets is a 
 bit confusing, because the Pad Length field is obviously a constant 2 octets. 
 I would suggest The Padding field's length (and the value of the Pad Length 
 field) need not exceed 4 octets.
 
 Thanks,
   Yaron
 
 On 06/14/2015 09:46 AM, internet-dra...@ietf.org wrote:
 
 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 IKE  IPsec
 Author  : Yoav Nir
  Filename: draft-ietf-ipsecme-chacha20-poly1305-09.txt
  Pages   : 12
  Date: 2015-06-13
 
 Abstract:
This document describes the use of the ChaCha20 stream cipher along
with the Poly1305 authenticator, combined into an AEAD algorithm for
the Internet Key Exchange protocol (IKEv2) and for IPsec.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/
 
 There's also a htmlized version available at:
 https://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-09
 
 A diff from the previous version is available at:
 https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-09
 
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec
 
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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.
 
 NEW:
The length of the Padding field need not exceed 4 octets. However, 
 neither RFC 4303 nor this
specification require using the minimal padding length.
 
 Yoav
 
 On Jun 14, 2015, at 10:37 AM, Yaron Sheffer yaronf.i...@gmail.com wrote:
 
 Quick nit: the sentence The Pad Length field need not exceed 4 octets is 
 a bit confusing, because the Pad Length field is obviously a constant 2 
 octets. I would suggest The Padding field's length (and the value of the 
 Pad Length field) need not exceed 4 octets.
 
 Thanks,
 Yaron
 
 On 06/14/2015 09:46 AM, internet-dra...@ietf.org wrote:
 
 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 IKE  IPsec
 Author  : Yoav Nir
Filename: draft-ietf-ipsecme-chacha20-poly1305-09.txt
Pages   : 12
Date: 2015-06-13
 
 Abstract:
This document describes the use of the ChaCha20 stream cipher along
with the Poly1305 authenticator, combined into an AEAD algorithm for
the Internet Key Exchange protocol (IKEv2) and for IPsec.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/
 
 There's also a htmlized version available at:
 https://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-09
 
 A diff from the previous version is available at:
 https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-09
 
 
 Please note that it may take a couple of minutes from the time of 
 submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec
 
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec
 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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
 
 This is not true.  The topic of RFC-or-not has never come up in any OpenSSL 
 discussions that I have seen.

Except the previous thread.

An RFC is not needed to get an algorithm into OpenSSL. It *is* necessary if we 
want ciphersuites for TLS, signature hashes for certificates PRFs and MACs for 
IKE/IPsec etc.

None of the bodies standardizing those will go with an algorithms whose sole 
specifications are a website maintained by the people who invented the 
algorithm and a wikipedia article. That’s where an RFC can help, just like RFC 
7539 was needed to get ChaCha20-Poly1305 into TLS and IPsecME drafts. With a 
good RFC we can push TLS, IPsecME, and PKIX drafts, perhaps even get some 
interest from CAs in the CA/BF.

With Blake2 getting no use at all in browsers, web servers, VPN gateways and 
certificates, I don’t even know what BLAKE2 is a de facto industry standard 
hash function” means.

Yoav
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Yoav Nir]

 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 wrote:
 Hi, Kathleen.
 
 Please see below
 
 On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty 
 kathleen.moriarty.i...@gmail.com mailto: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 soon).  Anyway, I have a few comments from my review and also some 
 from a developer.  Please don't feel the need to respond over the weekend as 
 I am sending this late on a Friday.
 
 First, thank you very much for your work on this draft.  Having a standby 
 cipher n hand is a good thing for algorithm agility.  Hopefully we don't 
 need it for some time.
 
 
 Section 2 talks about AEAD_CHACHA20_POLY1305 and makes the statement that 
 the initialization vector (part of the nonce) does not have to be 
 unpredictable.  That might be okay for chacha20 as long as you have 
 uniqueness, but I thought POLY1305 required an unpredictable nonce (section 
 2.5 of rfc7539).  It is not entirely clear to me where that value comes from 
 in this description.  Please let me know if I am missing something in 
 section 2. 
 
 The Poly1305 function does require a unique key. The way that we generate 
 this unique and unpredictable key is by running the ChaCha20 block function 
 with the same key and nonce, but with the block counter set to zero and using 
 the top 256 bits of the result as the one time key. If ChaCha20 is a valid 
 encryption function that has output indistinguishable from random data, this 
 makes the one-time Poly1305 key unpredictable, even though the nonce is not 
 unpredictable.  The text for that is at the bottom of page 3:
 
The same key and nonce, along with a block counter of zero are passed
to the ChaCha20 block function, and the top 256 bits of the result
are used as the Poly1305 key.
 
 Right, but the RFC7539 for POLY1305, the nonce must be unpredictable.  If you 
 are feeding in the same nonce used for chacha, then it should also be 
 unpredictable. 

Ah, I see the source of the confusion. Poly1305 does not get a nonce at all. It 
gets a one-time key. You could generate this one-time (unpredictable) key in 
many ways, but the way we do it here is by encrypting the (predictable) nonce 
using ChaCha20. This is similar to the practice of generating a random 128-bit 
value, and using that as an AES key, and encrypting a counter to generate 
unpredictable values (such as initialization vectors).

So it’s fine for the nonce to be predictable as long as the encrypted nonce is 
not.

I’ll make the rest of the changes soon.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

That shouldn’t be too difficult (finding reviewers, I mean).

Is the ISE asking for volunteers to review? What kind of volunteers?  IMO what 
a reviewer needs to be able to say is:
 - The document is clear (you can implement based on this)
 - The algorithm might be useful in the IETF
 - The security claims are sufficient to what IETF protocols need
 - The security claims are backed up by either peer-reviewed academic papers or 
equivalent

So there’s a lot of people who can do all that. You don’t even need real 
cryptographers, although having at least one would be good. What is holding 
things up?

Yoav

 On Jun 11, 2015, at 11:50 AM, Jean-Philippe Aumasson 
 jeanphilippe.aumas...@gmail.com wrote:
 
 The status of the draft is unchanged (Finding Reviewers). Perhaps OpenSSL 
 can speed up the review process.
 
 BLAKE2 has a keyed (aka MAC/PRF) mode, so it may also replace Poly1305. 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...@google.com 
  mailto: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 draft-saarinen-blake2 is?  If that 
 progresses we can propose things like 
 TLS_ECDHE_EdDSA_WITH_CHACHA20_POLY1305_BLAKE2[*] or PRF_BLAKE2.
 
 Yoav
 
 [*] I think we should call that ciphersuite “Suite-C” with ‘C’ standing for 
 civilian, because this is a whole bunch of algorithms, none of which came 
 from the government of the (pseudo-)military.
 
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev 
 https://mta.openssl.org/mailman/listinfo/openssl-dev
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Yoav Nir]

 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 draft-saarinen-blake2 is?  If that 
progresses we can propose things like 
TLS_ECDHE_EdDSA_WITH_CHACHA20_POLY1305_BLAKE2[*] or PRF_BLAKE2.

Yoav

[*] I think we should call that ciphersuite “Suite-C” with ‘C’ standing for 
civilian, because this is a whole bunch of algorithms, none of which came from 
the government of the (pseudo-)military.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Yoav Nir]

Hi

I’ve submitted this draft, mostly based on Simon’s TLS draft.

CFRG is considering new curves for key agreement. So far, they’ve selected 
Curve25519 and they might add another one. This draft requests an identifier 
for this curve and standardizes payload format for IKE.

Compared to NIST curves such as P-256, Curve25519 is faster and easier to 
implement securely. It is now being used in SSH and TLS (experimentally). I 
believe the security requirements of IKE and those other protocols are very 
similar, so it makes sense to standardize this here as well.

My future plans for this draft:
 - Solicit feedback (that is this message)
 - Request adoption
 - Add examples
 - Request publication (only when CFRG is done, probably in parallel with TLS)

Yoav

 Begin forwarded message:
 
 From: internet-dra...@ietf.org
 Subject: New Version Notification for draft-nir-ipsecme-curve25519-00.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 and posted to the
 IETF repository.
 
 Name: draft-nir-ipsecme-curve25519
 Revision: 00
 Title:Using Curve25519 for IKEv2 Key Agreement
 Document date:2015-06-11
 Group:Individual Submission
 Pages:11
 URL:
 https://www.ietf.org/internet-drafts/draft-nir-ipsecme-curve25519-00.txt
 Status: https://datatracker.ietf.org/doc/draft-nir-ipsecme-curve25519/
 Htmlized:   https://tools.ietf.org/html/draft-nir-ipsecme-curve25519-00
 
 
 Abstract:
   This document describes the use of Curve25519 for ephemeral key
   exchange in the Internet Key Exchange (IKEv2) protocol.
 
 
 
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 The IETF Secretariat
 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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 currently the fastest on my machine, and I
 guess that there will often be multiple cores in systems where hash
 performance matters (i.e. hashing large files or many files).

As a replacement for md5sum (like it says in the title) - I agree.

If we also want blake for protocols (like TLS_RSA_WITH_AES_128_GCM_BLAKE or 
something), the non-parallel versions would be more suitable.

Yoav

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Yoav Nir via RT]

 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 to make a tool named b2sum, which I hope will eventually
 replace md5sum.
 
 md5sum is the most widely-used tool in the world for data integrity
 but, as you know, MD5 is weak in ways that could endanger the users of
 md5sum, depending on how they use it. I want to see md5sum phased out
 entirely in our lifetimes!
 
 BLAKE2 is a secure hash function, while being faster than MD5 (at
 least on 64-bit CPUs). BLAKE2 is being used in new software projects
 (https://blake2.net/#us) and there is recently an Internet Draft to
 specify it
 (https://datatracker.ietf.org/doc/draft-saarinen-blake2/?include_text=1).
 
 One of the coreutils maintainers suggested that we should ask OpenSSL
 to add BLAKE2, because coreutils itself will probably just use a
 portable C implementation, but it would use an optimized
 implementation if openssl provided it. Here's that thread:
 http://lists.gnu.org/archive/html/coreutils/2015-06/msg00011.html
 
 We, the BLAKE2 maintainers, offer both reference C code and optimized
 implementations: https://blake2.net/#dl . There are also other
 implementations with various virtues available: https://blake2.net/#sw
 
 Here's my blog post extolling the virtues of BLAKE2 as a
 high-performance hash function:
 
 https://leastauthority.com/blog/BLAKE2-harder-better-faster-stronger-than-MD
 5.html
 
 
 how resistant is it against side channel attacks?

Since it’s based on ChaCha, it’s very resistant to timing (and power) based 
side channel leakage.

Yoav


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Yoav Nir]

 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 to make a tool named b2sum, which I hope will eventually
 replace md5sum.
 
 md5sum is the most widely-used tool in the world for data integrity
 but, as you know, MD5 is weak in ways that could endanger the users of
 md5sum, depending on how they use it. I want to see md5sum phased out
 entirely in our lifetimes!
 
 BLAKE2 is a secure hash function, while being faster than MD5 (at
 least on 64-bit CPUs). BLAKE2 is being used in new software projects
 (https://blake2.net/#us) and there is recently an Internet Draft to
 specify it
 (https://datatracker.ietf.org/doc/draft-saarinen-blake2/?include_text=1).
 
 One of the coreutils maintainers suggested that we should ask OpenSSL
 to add BLAKE2, because coreutils itself will probably just use a
 portable C implementation, but it would use an optimized
 implementation if openssl provided it. Here's that thread:
 http://lists.gnu.org/archive/html/coreutils/2015-06/msg00011.html
 
 We, the BLAKE2 maintainers, offer both reference C code and optimized
 implementations: https://blake2.net/#dl . There are also other
 implementations with various virtues available: https://blake2.net/#sw
 
 Here's my blog post extolling the virtues of BLAKE2 as a
 high-performance hash function:
 
 https://leastauthority.com/blog/BLAKE2-harder-better-faster-stronger-than-MD
 5.html
 
 
 how resistant is it against side channel attacks?

Since it’s based on ChaCha, it’s very resistant to timing (and power) based 
side channel leakage.

Yoav

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Yoav Nir]

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 soon).  Anyway, I have a few comments from my review and also some 
 from a developer.  Please don't feel the need to respond over the weekend as 
 I am sending this late on a Friday.
 
 First, thank you very much for your work on this draft.  Having a standby 
 cipher n hand is a good thing for algorithm agility.  Hopefully we don't need 
 it for some time.
 
 
 Section 2 talks about AEAD_CHACHA20_POLY1305 and makes the statement that the 
 initialization vector (part of the nonce) does not have to be unpredictable.  
 That might be okay for chacha20 as long as you have uniqueness, but I thought 
 POLY1305 required an unpredictable nonce (section 2.5 of rfc7539).  It is not 
 entirely clear to me where that value comes from in this description.  Please 
 let me know if I am missing something in section 2. 

The Poly1305 function does require a unique key. The way that we generate this 
unique and unpredictable key is by running the ChaCha20 block function with the 
same key and nonce, but with the block counter set to zero and using the top 
256 bits of the result as the one time key. If ChaCha20 is a valid encryption 
function that has output indistinguishable from random data, this makes the 
one-time Poly1305 key unpredictable, even though the nonce is not 
unpredictable.  The text for that is at the bottom of page 3:

   The same key and nonce, along with a block counter of zero are passed
   to the ChaCha20 block function, and the top 256 bits of the result
   are used as the Poly1305 key.


   o  The Initialization Vector (IV) is 64-bit, and is used as part of
   the nonce.  The IV MUST be unique for each invocation for a
   particular SA but does not need to be unpredictable.  The use of a
   counter or a linear feedback shift register (LFSR) is RECOMMENDED.
 
 The IANA considerations list ENCR_CHACHA20_POLY1305 as the name of the 
 algorithm without explanation in the draft.  It appears that this was a WG 
 decision:
 https://www.ietf.org/mail-archive/web/ipsec/current/msg09772.html 
 https://www.ietf.org/mail-archive/web/ipsec/current/msg09772.html
 An explanation might be helpful.  Elsewhere in the draft, you just have 
 AEAD_CHACHA20_POLY1305.

Well AEAD_CHACHA20_POLY1305 is the code point already assigned to RFC 7539 for 
the algorithm.
http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml#aead-parameters-2
 
http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml#aead-parameters-2
As a side note, I have no idea what that registry is for. It assigns numeric 
IDs to algorithms but those numeric IDs are never stored or transmitted in any 
protocol.

ENCR_CHACHA20_POLY1305 is the identifier we are requesting for use within IKE. 
Perhaps I should change the last paragraph of section 2 as follows:
OLD:
   The encryption algorithm transform ID for negotiating this algorithm
   in IKE is TBA by IANA.

NEW:
   The encryption algorithm transform ID for negotiating this algorithm
   in IKE is ENCR_CHACHA20_POLY1305 (number is TBA by IANA).

 
 I had another implementer of AEAD_CHACHA20_POLY1305 (but not for IPsec) read 
 the draft and he commented that he didn't understand the term 'Standby 
 cipher'.  This was clear to me, but I read a lot of drafts.  It might be 
 helpful to expand on that a bit more since this came from a developer.

This is strange to me, because the second paragraph of the introduction both 
discusses the need for a standby cipher and links to draft-mcgrew-standby- 
https://tools.ietf.org/html/draft-mcgrew-standby-ciphercipher.  I don’t know 
how to clarify this further.

 He also requested that it would be helpful if the packet could be laid out to 
 explain where the IV, ciphertext and tag go.  This seems like a reasonable 
 request and is from a developer.

I guess this can be done. I wanted to keep the draft short by minimizing 
copying and pasting diagrams from 4303 and 7296, but it’s no great effort.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Question about PFS in IKEv2

[Yoav Nir]

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 configured on both sides, but there are no matching groups (perhaps GW-1 
is configured with only group 19, while GW-2 is configured only with group 20).

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.

After a while, one of the gateways attempts to rekey the tunnel, or else create 
a new tunnel with the same peer. This time the tunnel is set up using the 
CREATE_CHILD_SA exchange. The SA payload will contain the wrong DH group and 
the exchange will fail, resulting in traffic flow stopping.

As far as I can tell, this behavior is consistent with the RFC, but the user 
experience is very strange. Traffic should either flow or not flow - it should 
not stop at rekeying.

Am I missing something?

Thanks

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Question about PFS in IKEv2

[Yoav Nir]

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 ensure that the other end supports 
 this algorithm before using the same in pfs configuration.
 

This is the issue for me. Of course the root cause is the configuration 
mismatch (that they have no common group for PFS). We usually expect 
configuration mismatches to show up immediately rather than hours down the 
line. 

Ideally, the original tunnel setup would have failed. In fact, with IKEv1 where 
keying IPsec SAs is always done in Quick Mode you get the failure immediately.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Question about PFS in IKEv2

[Yoav Nir]

 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 is set to that you configure only one Diffie-Hellman for
 the IKEv2, which is then used for both IKE SA and Child SAs, then you
 would notice this misconfiguration immediately. 

My product has a separate configuration for phase 1 Diffie-Hellman group and 
phase 2 Diffie-Hellman group. Thinking it over, I cannot explain why this is 
needed, but at least StrongSwan also specifies ESP groups separately from IKE 
groups.

 After a while, one of the gateways attempts to rekey the tunnel, or
 else create a new tunnel with the same peer. This time the tunnel is
 set up using the CREATE_CHILD_SA exchange. The SA payload will
 contain the wrong DH group and the exchange will fail, resulting in
 traffic flow stopping. 
 
 When the last Child SA gets deleted from the IKE SA, you should most
 likely shut down the IKE SA, or at least if all the rekeys fails, you
 should start from the beginning. 
 
 As far as I can tell, this behavior is consistent with the RFC, but
 the user experience is very strange. Traffic should either flow or
 not flow - it should not stop at rekeying. 
 
 IKEv2 tries to notice some misconfigurations, but it cannot catch them
 all. 

IKEv1 caught that particular one.

 Am I missing something?
 
 Do not misconfigure your systems…

I’ll tell the users…

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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.

Whether the parameters are passed in new payloads, notify payloads or Config 
attributes is a matter of taste. Generally, Config attributes are mostly for 
remote access and have request-response semantics, so they’re somewhat 
negotiable. Notifications are for something one side declares which is not 
negotiable, and new payloads are hardly ever used.

Note though, that in the IKE_AUTH exchange, the peer is not yet authenticated. 
So depending on how sensitive the content of the parameters is, you might not 
want to send it at that point. The IKE SA at that point protects against 
passive eavesdropping and message modification only.

Yoav

 On May 20, 2015, at 3:13 PM, Frederic Detienne (fdetienn) 
 fdeti...@cisco.com wrote:
 
 Hello,
 
 we would like to implement new vendor specific capabilities under IKEv2. This 
 capability requires argument passing. These arguments should be protected 
 (encrypted and signed).
 
 We were wondering what was the cleanest way to do this.
 
 What seemed the most logical is
 
 1- negotiating capability in message 1/2 via a Vendor-ID payload
 2- if both peers support capability, exchange parameters via Notify Payloads 
 in message 3/4 or later
 
 We were considering using configuration attributes instead of Notify Payload 
 but we are not sure this is an adequate message type.
 
 Can someone give us an advice ?
 
 thanks,
 
   Frederic Detienne
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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-ipsecme-chacha20-poly1305:
 https://www.ietf.org/internet-drafts/draft-ietf-ipsecme-chacha20-poly1305-08.txt
 
 
 The IETF datatracker page for this Internet-Draft is:
 https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/
 
 Diff from previous version:
 https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-08
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 IETF Secretariat.
 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Restarting the discussion about the puzzle

[Yoav Nir]

 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 information to make a 
 good decision.
 
 To answer your question, I think we've already been down this path and 
 reducing the variance is certainly a good thing.
 

I’m sure that less variance is better than more variance, but that comes at the 
expense of more work for the responder. So do we set the number of returned 
results to 1, with minimal work for the responder and maximum variance?  Do we 
set it to 8, with a nice balance between fairness and responder work?  Do we 
set it to 64, with a huge packet, a lot of responder work and maximum fairness? 
 Or do we let the responder decide and communicate through the challenge, which 
has some complexity cost?

Yoav


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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:
 
 --
 In appendix B you say:
 
 The ciphertext is also 16 octets long, so the construction
   has no padding at all.
 
 This is not true. The ciphertext was 13 bytes long (as can be seen
 from the length), and there was 3 bytes of padding.
 --
 Nits:
 
 In section 2:
 
   The same key and nonce, along with a block counter of zero are passed
   to the ChaCha20 block function, and the top 256 bits of the result
   are used as the Poly1305 key.  The nonce passed to the block function
   here is the same nonce that is used in ChaCha20, including the 32-bit
   Salt, and the key passed is the same as the encryption key.
 
 I think it is bit useless to first say that The same key and nonce,
 ... and then define that by the way the nonce is same and the key is
 same ...
 
 I would remove the second sentence, I think it is enough to say that
 the same key and nonce are passed to block function.
 
 --
 
 In the draft you use little-endian integer and network order
 integer. I do not know what the order of the network is (most likely
 it is messed up), but I assume you mean integer in network byte
 order or something like that. You might want to talk about byte
 orders in both cases.
 
 Btw, I really hate to have system where we need to mix network byte
 order and little-endia byte order stuff, but I think that is what cfrg
 decided so better stick with that.
 
 --
 
 In section 2.1 you should expand ESN.
 
 -- 
 kivi...@iki.fi
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Restarting the discussion about the puzzle

[Yoav Nir]

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 might take too long to solve the puzzle.

This is about the second issue. I’d be glad if someone could make a measurement 
of solving the proposed puzzle on an ARM processor so that we can know how much 
of an issue #1 is.

As Tero has mentioned, there are no easy or hard puzzles. Depending on how you 
order your guesses you might stumble upon the solution very quickly, or you 
might be trying millions of keys before hitting the answer. Choose a different 
ordering of your guesses for the same puzzle, and you might get very different 
results.  Still, we don’t like that luck plays such a role. 

One way to reduce the variance is to increase the sample size: instead of 
looking for one key for a hard puzzle, we can require the initiator to return 
several correct solutions for an easier puzzle.  The advantage is that it 
indeed reduces the variance. The disadvantage is that the responder’s job 
becomes more difficult, as it has to verify not one but several correct 
solutions.

I’ve run a test of 20 randomly-generated cookies, and set the puzzle difficulty 
to 20 bits when requiring 1 solutions, 19 bits when requiring 2 solutions, 18 
bits when requiring 4 solutions, etc. The full results are in the attached 
Excel file (all results in seconds), but here’s a summary:

Bits | keys | median | % over twice median
-+--++
| 20 |   1  |  0.947 |  30.0%
| 19 |   2  |  1.309 |  15.0%
| 18 |   4  |  1.464 |   5.0%
| 17 |   8  |  1.516 |   1.5%
| 16 |  16  |  1.499 |   0.5%
| 15 |  32  |  1.507 |   0.0%
| 14 |  64  |  1.499 |   0.0%
-+--++——

I could increase the sample to get more accurate results, or look for results 
that are 3 times the median or 3 times the average etc. But just looking at 
this it seems to me that either 8 or 16 keys is the sweet spot, where an 
initiator is not likely to get stuck, a packet is not too big, and the load on 
the responder is not too great.

Comments?

Yoav



data_20.xlsx
Description: MS-Excel 2007 spreadsheet
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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-chacha20-poly1305
 should say
 something like,
 According to cfrg-chacha20, Poly-1305 is not suitable for
 use as a PRF for IKEv2, and this specification explicitely
 does not allocate a code point for that.”
 
 That’s kind of a weird thing to write. We don’t allocate an ICMPv6 type
 number either. It’s kind of sad because while Poly1305 is not a good
 PRF, ChaCha20 is. But unfortunately it’s not a good PRF for IKEv2 as it
 requires a constant-size key, and RFC 7296 requires that all PRFs
 support any size key. Of course we could add the blake2 hash function
 to convert any non-256-bit key to a 256-bit key, and blake2 is based on
 the ChaCha20 block function.  But we chose not to do this. At least not
 yet.
 
 I predict that in two years, there will be a stream of queries from
 @gmail/@hotmail accounts asking in broken english why there isn't a PRF
 number.  I'll bet we even get an Errata filed :-)

But we’re not even creating an AUTH entry…

 The bit about ChaCha also being wrong would be useful to write down
 somewhere.

https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-10#section-2.7

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

Hi

Changes include:
 - Clarified keying material derivation for IKE
 - Calrified that IV is included in the Encrypted payload
 - Fixed the requirements for padding in the Encrypted payload so as not to 
require padding bytes.
 - Added a paragraph on the (non-)secrecy of the Salt based on discussion in 
the TLS mailing list
 - Fixed some errors in the examples (thanks to Steve Doyle and Martin Willi)

Those examples are all synthetic, generated by calling the same ChaCha20 / 
Poly1305 implementation that I made for creating the examples in the CFRG 
draft. They were not created with an IKE daemon or a IPsec driver, so they are 
prone to such errors.

I did *not* include the suggestion by Paul Wouters to tighten up the 
requirements for generating and parsing padding in the IKEv2 encrypted payload, 
as this changes the SHOULD in RFC 7296 to a MUST for the sender, and a “MUST 
accept any” to “MUST NOT accept any except” for the receiver. I don’t want to 
make such a change without the WG telling me to.

Yoav

 On Apr 28, 2015, at 10:03 AM, internet-dra...@ietf.org wrote:
 
 
 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 IKE  IPsec
Author  : Yoav Nir
   Filename: draft-ietf-ipsecme-chacha20-poly1305-06.txt
   Pages   : 11
   Date: 2015-04-28
 
 Abstract:
   This document describes the use of the ChaCha20 stream cipher along
   with the Poly1305 authenticator, combined into an AEAD algorithm for
   the Internet Key Exchange protocol (IKEv2) and for IPsec.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/
 
 There's also a htmlized version available at:
 https://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-06
 
 A diff from the previous version is available at:
 https:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-06
 
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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.
 
 Regards,
 Steve
 --
 Intel Shannon Limited
 Registered in Ireland
 Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
 Registered Number: 308263
 Business address: Dromore House, East Park, Shannon, Co. Clare
 
 This e-mail and any attachments may contain confidential material for the 
 sole use of the intended recipient(s). Any review or distribution by others 
 is strictly prohibited. If you are not the intended recipient, please contact 
 the sender and delete all copies.
 
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

OK. Make those changes. I’ll post a new version tomorrow.

Yoav

 On Apr 27, 2015, at 12:38 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
 
 Clearly we need to mention that the IV is included, despite the text of RFC 
 7296.
 
 You are right about SK_ei/er. The second bullet in Sec. 3 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 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 64-bit, same as in section 2, and RFC 7296 section 
 3.14 says that the IV is explicit. Although in honesty, it also says that 
 the size of the IV is equal to block length, which would make it 512 bits 
 here?  Anyway, RFC 7296 does say that this is true only for CBC.
 
 - In the bullet that describes the IV, I would add text that the IKE 
 Message ID is not an option, and why.
 
 The whole idea of using sequence number as IV is now gone from the draft. If 
 we want to add some path-not-taken text, it should probably go in the 
 Security Considerations or maybe another appendix. I don’t really think it 
 is relevant.
 
 - How do we make sure that the key/IV combination is unique between 
 Initiator and Responder?
 
 PRF+ generates a bitstring with separate SK_ei and SK_er for the initiator 
 and responder respectively. Each is 36 octets (288 bits). While we don’t 
 explicitly prevent PRF+ from generating the same 36 bytes twice, good PRFs 
 hardly ever will. The same is not true for IKEv1 (RFC 2409) where the same 
 SKEYID_e is used by both.
 
 Thanks,
 Yaron
 
 On 04/27/2015 01:44 AM, Paul Hoffman wrote:
 Greetings again. This begins the two-week WG Last Call on 
 draft-ietf-ipsecme-chacha20-poly1305, which ends Monday May 11. We would 
 love to hear from people in either of two groups:
 
 - Those who have already reviewed an earlier version of this draft. Please 
 re-read the draft now, and let us know if it is perfect, or if there 
 anything else you want added or changed. This includes Yaron, PaulW, Tero, 
 ScottF, and Valery.
 
 - Those who have *not* yet reviewed this draft, but want to help the IETF 
 create good standards in this area. If you are an IPsec implementer, or 
 know one at your organization, reviewing this draft and sending any 
 comments to the list (even just seems fine or I liked it except this 
 one thing) is useful to all of us.
 
 It seems very likely that this new algorithm combination will appear in 
 IKEv2 and ESP soon, and having folks give a bit more review will help 
 prevent whoopsies in the future.
 
 --Paul Hoffman
 
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec
 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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 example in our code:
 
 
 From appendix B:
 
 Padding as required by RFC 7296 is 4 bytes long.
 
 Do we have such a padding requirement for IKEv2? For ChaCha20 we have no
 requirement for input lengths, so no padding is needed. While we have 4
 byte padding in ESP, I don't think this is true for IKEv2 Encrypted
 Payloads, is it?
 
 From RFC 7296 3.14:
 
   o  Padding MAY contain any value chosen by the sender, and MUST have
  a length that makes the combination of the payloads, the Padding,
  and the Pad Length to be a multiple of the encryption block size.
  This field is encrypted with the negotiated cipher.
 
   o  Pad Length is the length of the Padding field.  The sender SHOULD
  set the Pad Length to the minimum value that makes the combination
  of the payloads, the Padding, and the Pad Length a multiple of the
  block size, but the recipient MUST accept any length that results
  in proper alignment.  This field is encrypted with the negotiated
  cipher.
 
 So while the used padding is not invalid, it is not what we SHOULD use,
 and if so probably not a good example. Maybe we should also add a note
 about IKEv2 padding to section 3?

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, yet that is what the MUST requirement in the first 
bullet seems to be saying. I don’t even know what “proper alignment” means for 
a cipher such as this. If anything is proper alignment, then the value that 
fulfills the SHOULD requirement is zero (with no padding bytes). For section 3, 
I could add a text that echoes the second bullet:

   The sender SHOULD include no padding and set the Pad Length field to zero. 
The receiver MUST accept any length of padding.

Sounds good?

 
 
 
 The other issue I've seen is about the Next Payload:
 
  Encrypted Payload:
  000  00 00 00 2c 10 11 12 13 14 15 16 17 61 03 94 70  ...,a..p
 
 The Next Payload field in the Encrypted Payload is 0. However, RFC 7296
 defines:
 
 Next Payload - The payload type of the first embedded payload.
 
 So I think Next Payload should be Notify (0x29).

Yes, you’re right. I’ve fixed this in my working draft. I should publish again 
in a day or two.

Thanks.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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 64-bit, same as in section 2, and RFC 7296 section 3.14 
says that the IV is explicit. Although in honesty, it also says that the size 
of the IV is equal to block length, which would make it 512 bits here?  Anyway, 
RFC 7296 does say that this is true only for CBC.

 - In the bullet that describes the IV, I would add text that the IKE Message 
 ID is not an option, and why.

The whole idea of using sequence number as IV is now gone from the draft. If we 
want to add some path-not-taken text, it should probably go in the Security 
Considerations or maybe another appendix. I don’t really think it is relevant.

 - How do we make sure that the key/IV combination is unique between Initiator 
 and Responder?

PRF+ generates a bitstring with separate SK_ei and SK_er for the initiator and 
responder respectively. Each is 36 octets (288 bits). While we don’t explicitly 
prevent PRF+ from generating the same 36 bytes twice, good PRFs hardly ever 
will. The same is not true for IKEv1 (RFC 2409) where the same SKEYID_e is used 
by both.

 Thanks,
   Yaron
 
 On 04/27/2015 01:44 AM, Paul Hoffman wrote:
 Greetings again. This begins the two-week WG Last Call on 
 draft-ietf-ipsecme-chacha20-poly1305, which ends Monday May 11. We would 
 love to hear from people in either of two groups:
 
 - Those who have already reviewed an earlier version of this draft. Please 
 re-read the draft now, and let us know if it is perfect, or if there 
 anything else you want added or changed. This includes Yaron, PaulW, Tero, 
 ScottF, and Valery.
 
 - Those who have *not* yet reviewed this draft, but want to help the IETF 
 create good standards in this area. If you are an IPsec implementer, or know 
 one at your organization, reviewing this draft and sending any comments to 
 the list (even just seems fine or I liked it except this one thing) is 
 useful to all of us.
 
 It seems very likely that this new algorithm combination will appear in 
 IKEv2 and ESP soon, and having folks give a bit more review will help 
 prevent whoopsies in the future.
 
 --Paul Hoffman
 
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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 considerations, the
 question about the uniqueness the nonce, so my initial reading, being
 mostly ignorant about ChaCha and Poly1305 was very confusing.
 
 (In preparing this email, I was also using the -05 document, which I see is
 new. I think that I read -03 on Friday. -04 seems to have been skipped?)
 
 I had not yet read any of the discussion on the list (intentionally) so as
 to judge whether I understood the document on it's own.
 
 {in preparing this email, I read the thread afterwards, and I now see that
 some discussion was previously about IV being derived from replay counter, a
 notion which I think has been removed from the ID. I don't think that I have
 any new questions;  I think that after having read the document well, that
 I can implement from the documents as they are}
 
 I don't understand:
 As the ChaCha20 block function is not applied directly to the
 plaintext, no padding should be necessary.  However, in keeping with
 
 could this be a typo ChaCha20 vs Poly1305?
 If the encryption algorithm is now applied directly, then what is?
 Or is meant that the block function for ChaCha20 used only to generate
 bits for a stream cipher, and the XOR is what is applied directly”?

Yeah, perhaps I didn’t phrase it the best way. If you’re using AES and you have 
a 19-byte plaintext and you’re using ECB (or CBC) you can encrypt the first 
16-byte block of the plaintext, but for the second block you only have 3 bytes, 
whereas AES requires 16. So you need to pad. With CTR, CCM, GCM you encrypt a 
counter, which is always 16 bytes, Since you’re not applying AES to the 
plaintext (but to a counter) you don’t need to pad the plaintext - you just 
throw away the extra bytes of XOR mask that you created.
ChaCha20 is the same: you generate a 64-byte block from a key, a nonce and a 
counter, and you XOR as much of it as you need with the plaintext - so no pad 
is needed.

  The same key and nonce, along with a block counter of zero are passed
  to the ChaCha20 block function, and the top 256 bits of the result
  are used as the Poly1305 key.  The nonce passed to the block
  function here is the same nonce that is used in ChaCha20, including the 
 32-bit
  Salt, and the key passed is the same as the encryption key.
 
 I think that if I have a block encryption function, that I need to encrypt
 something to get an output.  I don't know what that is here
 Later I understood from reading cfrg-chacha20 that the ChaCha20 block
 function acts as a prng, and that's why this is a stream ciper, not a block
 cipher.  The use of the term block function here was confusing to me.

It’s not that different from AES-GCM. With AES-GCM (or just CTR) you have a 
128-bit counter (actually it’s just a 32-bit counter as 96-bits are the 
per-packet nonce). You encrypt the counter and get a 16-byte block that you XOR 
with the plaintext.
With ChaCha20-Poly1305 you also have a 128-bit counter with 96 fixed bits. You 
run the ChaCha20 block function to generate a 64-byte block that you XOR with 
the plaintext.
The only difference is that the size of the counter is not the same as the size 
of the output block.
This is different from a real stream cipher where a single key with no nonce 
can generate an arbitrary length byte stream. ChaCha20 can only produce 64 
bytes from a single value of the nonce.

 At first, I understand the nonce, was going to be the IV. Was there some
 discussion/options in a previous version of the draft?
 I initially understood that the the 32-bit block counter would be taken from
 the replay counter, but now I see that this is incorrect, that it's unrelated
 to the replay counter, and that I misunderstood at first.
 
 So the Salt is really part of the key material.  We have a 36-byte key.  It
 matters to people debugging things with a tool like TCPDUMP, that they know 
 they
 should expect 36-bytes.
 
 Is this diagram correct:
 
 keymat:iv:   ctr:
  +---++ ++  ++
  |01234567890123456789012|0123| |abcdefgh|  |0001|
  +---++ ++  ++
|   |   |  |
|   |   |  |
|   |   |  |
 key:Vnonce: V  block   V
  +---+   ++ ctr:++
  |01234567890123456789012|   |0123abcdefgh| |00xx|
  +---+   ++ ++
words: 4-11words: 13-15  word 12
 
  \-\  /\/-/
 \/  \  /
  

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

[Yoav Nir]

 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, yet that is what the MUST requirement in 
 the first bullet seems to be saying. I don’t even know what “proper 
 alignment” means for a cipher such as this. If anything is proper alignment, 
 then the value that fulfills the SHOULD requirement is zero (with no padding 
 bytes). For section 3, I could add a text that echoes the second bullet:
 
  The sender SHOULD include no padding and set the Pad Length field to zero. 
 The receiver MUST accept any length of padding.
 
 Sounds good?
 
 Not really?
 
 Choices like that make me nervous that an attacker can tweak the padding
 option. Who knows what oracle that can become in the future. There MUST
 only be one way to do things. So I would rather see:
 
   The sender MUST NOT include padding and set the Pad Length field to
   zero. The receiver MUST reject a non-zero Pad Length field.

I’m OK with that as well, (though I would phrase it in the positive “The sender 
MUST include no padding and set …”), but that goes against RFC 7296. 
Specifically your second sentence turns a “MUST accept” into a “MUST reject”.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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.
 
 At Yaron’s request I have added some text about the key and salt derivation 
 in IKE (as opposed to IPsec)
 
 Yoav
 
 On Apr 26, 2015, at 11:48 PM, internet-dra...@ietf.org wrote:
 
 
 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 IKE  IPsec
   Author  : Yoav Nir
  Filename: draft-ietf-ipsecme-chacha20-poly1305-04.txt
  Pages   : 11
  Date: 2015-04-26
 
 Abstract:
  This document describes the use of the ChaCha20 stream cipher along
  with the Poly1305 authenticator, combined into an AEAD algorithm for
  the Internet Key Exchange protocol (IKEv2) and for IPsec.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-04
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-04
 
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec
 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

Hi.

At Paul’s request I have added examples in appendix A and appendix B.

At Yaron’s request I have added some text about the key and salt derivation in 
IKE (as opposed to IPsec)

Yoav

 On Apr 26, 2015, at 11:48 PM, internet-dra...@ietf.org wrote:
 
 
 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 IKE  IPsec
Author  : Yoav Nir
   Filename: draft-ietf-ipsecme-chacha20-poly1305-04.txt
   Pages   : 11
   Date: 2015-04-26
 
 Abstract:
   This document describes the use of the ChaCha20 stream cipher along
   with the Poly1305 authenticator, combined into an AEAD algorithm for
   the Internet Key Exchange protocol (IKEv2) and for IPsec.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-04
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-04
 
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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.
 
 As chair and shepherd: we can't start the WG Last Call on this until we have 
 examples*s*, given the changes in the -03 to add IKEv2. Please issue a -04 
 soon that has an appendix with one example of use in IKEv2, and another in 
 IPsec.
 
 --Paul Hoffman

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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 sender-ID 
bits from the visible IV, not the invisible salt. I have replaced all places 
where it said “sender ID” with “Salt”. I have made the salt generated from the 
keymat just as it is for AES-GCM. The TLS working group has moved in a whole 
other direction ([1]) where they will generate a 96-bit value and XOR that with 
the record counter to produce the nonce. We can’t do that without revising ESP, 
so for this document I’ll just leave it at that.

With this I believe the document is ready for WGLC. I might want to add an 
appendix with an example.

Yoav

 On Apr 25, 2015, at 12:10 PM, internet-dra...@ietf.org wrote:
 
 
 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 IKE  IPsec
Author  : Yoav Nir
   Filename: draft-ietf-ipsecme-chacha20-poly1305-03.txt
   Pages   : 7
   Date: 2015-04-25
 
 Abstract:
   This document describes the use of the ChaCha20 stream cipher along
   with the Poly1305 authenticator, combined into an AEAD algorithm for
   the Internet Key Exchange protocol (IKEv2) and for IPsec.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-03
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-03
 
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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 that GDOI allocated sender-ID 
bits from the visible IV, not the invisible salt. I have replaced all places 
where it said “sender ID” with “Salt”. I have made the salt generated from the 
keymat just as it is for AES-GCM. The TLS working group has moved in a whole 
other direction ([1]) where they will generate a 96-bit value and XOR that with 
the record counter to produce the nonce. We can’t do that without revising ESP, 
so for this document I’ll just leave it at that.

With this I believe the document is ready for WGLC. I might want to add an 
appendix with an example.

Yoav

 On Apr 25, 2015, at 12:10 PM, internet-dra...@ietf.org wrote:
 
 
 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 IKE  IPsec
   Author  : Yoav Nir
   Filename: draft-ietf-ipsecme-chacha20-poly1305-03.txt
   Pages   : 7
   Date: 2015-04-25
 
 Abstract:
  This document describes the use of the ChaCha20 stream cipher along
  with the Poly1305 authenticator, combined into an AEAD algorithm for
  the Internet Key Exchange protocol (IKEv2) and for IPsec.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-03
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-03
 
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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 the open issues. I have removed all 
references to GDOI as it has been pointed out that GDOI allocated sender-ID 
bits from the visible IV, not the invisible salt. I have replaced all places 
where it said “sender ID” with “Salt”. I have made the salt generated from the 
keymat just as it is for AES-GCM. The TLS working group has moved in a whole 
other direction ([1]) where they will generate a 96-bit value and XOR that with 
the record counter to produce the nonce. We can’t do that without revising ESP, 
so for this document I’ll just leave it at that.

With this I believe the document is ready for WGLC. I might want to add an 
appendix with an example.

Yoav

[1] http://www.ietf.org/mail-archive/web/tls/current/msg16122.html

 On Apr 25, 2015, at 12:10 PM, internet-dra...@ietf.org wrote:
 
 
 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 IKE  IPsec
  Author  : Yoav Nir
   Filename: draft-ietf-ipsecme-chacha20-poly1305-03.txt
   Pages   : 7
   Date: 2015-04-25
 
 Abstract:
 This document describes the use of the ChaCha20 stream cipher along
 with the Poly1305 authenticator, combined into an AEAD algorithm for
 the Internet Key Exchange protocol (IKEv2) and for IPsec.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-03
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-03
 
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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 issues.
 
 1. For the question raised in the draft:
 
   TBD: do we want an extra 32 bits as salt for the nonce like
   in GCM, or keep the salt (=SenderID) at zero?
 
 I prefer to follow GCM-like approach, i.e. to take these 32 bits
 from the KEYMAT. It is cryptographically sound and is good
 from evaluation point of view - you know where these bits come from.

I thought so as well. In the meantime, the TLS working group is discussing the 
same thing for TLS 1.3, and they are proposing to get rid of the salt (or IV) 
for AES-GCM as well as ChaCha20. 

http://www.ietf.org/mail-archive/web/tls/current/msg15884.html

The TLS working group is not making decisions for us, but I think it would be a 
shame to arrive at different conclusions where the cases are very similar. More 
technically, I use a single crypto library for both TLS and IPsec, and having a 
“salt parameter that is always set to zero for TLS makes me sad.

 I understand that it would require some adaptation
 for multi-sender case, like in RFC6054, but AFAIK currently
 Many-to-Many IPsec SAs are rare and look exotic.
 And as RFC6054 states, the nonce is not transferred in packet,
 so it is not the best place for SenderID (unlike explicit IV).

As RFC 6045 says in section 3, the sender ID is carved out of the explicit IV, 
not out of the invisible salt. So that part of my question made no sense 
anyway. We either want the salt to protect against something, or we don’t. It’s 
not reserved for sender ID.

 2. Section 4.
 
  When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or
  IPsec, the value xxx (TBA by IANA) should be used in the transform
  substructure of the SA payload as the ENCR (type 1) transform ID.  As
  with other AEAD algorithms, INTEG (type 3) transform substructures
  SHOULD NOT be specified unless at least one of the ENCR transforms is
  non-AEAD.
 
 The last sentence is wrong. Section 3.3 of RFC7296 states:
 
  Combined-mode ciphers include
  both integrity and encryption in a single encryption algorithm, and
  MUST either offer no integrity algorithm or a single integrity
  algorithm of NONE, with no integrity algorithm being the
  RECOMMENDED method.
 
 So INTEG either MUST NOT be present in the proposal substructure
 containing ChaCha20-Poly1305 or MUST be NONE. And RFC7296
 requires not to mix AEAD and non-AEAD algorithms in the same proposal:
 
  If an initiator wants to propose both combined-
  mode ciphers and normal ciphers, it must include two proposals: one
  will have all the combined-mode ciphers, and the other will have all
  the normal ciphers with the integrity algorithms.

Thanks. I forgot about this restriction. Will fix in the next draft.


 
 Editorial issues.
 
 1. Section 2, first bullet.
 
  o  The Initialization Vector (IV) is 64-bit, and is used as part of
 the nonce.  The IV MUST be unique for each SA but does not need to
 be unpredictable.  The use of a counter or an LFSR is RECOMMENDED.
 
 The IV MUST be unique for each invocation (ESP packet or IKEv2 message),
 not for each SA.

Unique for each invocation *with the same key, no?  And keys are different from 
one SA to another.


 2. Section 2, last but one bullet:
 
 *  The length of the additional data in octets (as a 64-bit
little-endian integer).
 
 additional data is a bit vague, please use Authenticated Additional Data
 (or AAD) for clarity.

OK.

 3. Informative References
 
  [FIPS-46]  National Institute of Standards and Technology, Data
 Encryption Standard, FIPS PUB 46-2, December 1993,
 http://www.itl.nist.gov/fipspubs/fip46-2.htm.
 
 The url is incorrect, it leads to the NIST home page.
 I believe the correct url is
 http://csrc.nist.gov/publications/fips/archive/fips46-3/fips46-3.pdf
 (and it is FIPS 46-3, that superceeded FIPS 46-2).

It worked when I first wrote the draft. Will fix.

 
 Minor nits (subjective).
 
 1. Section 1.
 
 I think the main problem with 3DES is not that it is significantly slower
 than AES, but that it has blocksize of 64 bits, that is considered
 loo small for high-speed networks, when the possibility of birthday attack
 leads to necessity to frequently rekey.

It’s hard to make that case. The blocksize is 64 bits. So it’s prudent to not 
use more than, say, a billion blocks. A billion blocks is 64 Gb. There are very 
few real tunnels that run that kind of throughput in under a minute. OTOH it’s 
no problem at all to run a CreateChildSA every minute, or even every five 
seconds. So I think there are very few cases that *can’t* use 3DES.


 2. Section 2.
 
 From the description of how ESP packet is constructed it is not
 absolutely clear what parts of the nonce are 

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

[Yoav Nir]

 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 function 
 itself accepts a 96-bit input nonce, so the nonce is constructed from the 
 64-bit IV and 32 zero bits. The reason for doing this is so the algorithm 
 could be used in a multi-sender case such as GDOI, where the 32-bit zero can 
 be replaced by a sender ID. Alternatively, we could generate a 32-bit salt 
 value from the key material, but I don’t see a reason why we’d want that. 
 Another thing we could do is what some people are advocating for TLS: Since 
 a counter is a fine IV (no need for secrecy), we don’t need a 64-bit IV that 
 has the exact same value as the replay counter. We might as well save 8 
 bytes per packet and just feed the replay counter to the function.  The 
 argument against this is that some crypto modules may have the API set up in 
 such a way that the IVs are generated within the module and could be 
 something other than a counter (like an LFSR). The proposal will break such 
 APIs.
 agreed. The other, related issue, is that if one wants to achieve FIPS 
 certification
 for an alg like this, the nonce/IV needs to be within the eval boundary for 
 the
 alg certification. I realize that ChaCha is not a FIPS alg, but I recall 
 someone
 asking NIST if it might be willing to evaluate ChaCha. If the goal is 
 (eventual)
 FIPS evaluation, then it makes sense to consider the implications of trying 
 to reuse the
 ESP sequence counter as an input to the IV/nonce in this context.
 

I think it’s risky to base decisions on our attempts to divine future NIST 
decisions, but I agree that out best option now is to leave the 64-bit IV (or 
nonce) explicit for now and perhaps later add an IKE extension that allows you 
to “compress” the IV as long as it’s equal to the packet counter. That allows 
the ESP implementation to compress the ESP packet as long as the encryption 
module keeps generating payloads that have an IV exactly the same as the packet 
counter.

I’ve recently had the dubious pleasure of going over some NIST document ([1]). 
Appendix A.5 is about Key/IV pair uniqueness in AES-GCM, but I guess (divining 
again…) that if they ever accept ChaCha20, they might ask for similar things. 
So what does it say about IV generation? 

There are several ways to generate the IV. One is to generate the IV in 
compliance with the TLS 1.2 GCM
Cipher Suites for TLS, as described in the corresponding IETF RFC 5116 
and 5288. Alternatively, the IV may 
be generated randomly or set deterministically, possibly by being 
incremented by 1 every time a new value 
is needed.

That sounds good, because “deterministically… by being incremented by 1 every 
time” is exactly what we’re looking for, right?  The document goes on to say 
that the method in RFC 5288 is allowed only for TLS 1.2, and “in all other 
cases the following requirements shall be satisfied”

If the GCM Key is generated either internally or externally and the IV 
is generated internally 
deterministically then the requirement of SP 800-38D quoted in the 
Background section above will be 
modified. Instead of requiring that the probability of any (key, IV) 
collision anywhere in the 
Universe at all times did not exceed 2^-32, it will only be required 
that for a given key distributed to 
one or more cryptographic modules, the (key, IV) collision probability 
would not exceed 2^-32. This 
is equivalent to the requirement that for any key distributed to one or 
more modules the probability of 
a collision between the deterministically-generated IVs is no greater 
than 2^-32.

That is still fine, because a 64-bit counter has a zero chance of repeating, 
and 0  2^-32. But then the document goes on to “specify what the module has to 
do to meet this requirement”.

Each deterministically established IV shall include an encoding of the 
module’s name and the 
name shall be long enough to allow for at least 2^32 different names. 
For example, if the module’s 
name is such that it consists of at least 8 hexadecimal characters then 
this condition is satisfied, 
since 16^8 is no smaller than (indeed, equal to) 2^32 . Alternatively, 
if the name consists of at least 
6 alphanumerical characters, each having at least 62 values, then this 
is also sufficient. Even 
though not all possible names are equally likely to be used, just the 
fact that the modules can 
possibly have at least 232 different names will be sufficient to meet 
this requirement.

So now we’re supposed to dedicate 32 bits of the available 64 to encoding the 
module name??? That leaves 32 bits per key for packet counter. That also means 
that 

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

[Yoav Nir]

Hi

Updated the draft. Changes:
 * Aligned the description of the AEAD construction with the one in the latest 
CFRG draft and fixed the references (thanks, Martin Willi)
 * Added a section about negotiating it in IKE
 * Renamed the constant to uppercase: ENCR_CHACHA20_POLY1305

Since I only got an opinion from Yaron, and the explanation from Scott, for now 
I’ve left the SenderID as zero rather than convert it to a 
derived-from-the-key-block salt.

Yoav

 On Apr 5, 2015, at 8:34 AM, internet-dra...@ietf.org wrote:
 
 
 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 IKE  IPsec
Author  : Yoav Nir
   Filename: draft-ietf-ipsecme-chacha20-poly1305-02.txt
   Pages   : 7
   Date: 2015-04-04
 
 Abstract:
   This document describes the use of the ChaCha20 stream cipher along
   with the Poly1305 authenticator, combined into an AEAD algorithm for
   IPsec.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-02
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-02
 
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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 is constructed from the 64-bit IV and 32 zero bits. The reason
 for doing this is so the algorithm could be used in a multi-sender
 case such as GDOI, where the 32-bit zero can be replaced by a sender
 ID. Alternatively, we could generate a 32-bit salt value from the
 key material, but I don’t see a reason why we’d want that.
 
 Reserving that 32-bits as sender-ID is fine...
 
 Another thing we could do is what some people are advocating for
 TLS: Since a counter is a fine IV (no need for secrecy), we don’t
 need a 64-bit IV that has the exact same value as the replay
 counter. We might as well save 8 bytes per packet and just feed the
 replay counter to the function. The argument against this is that
 some crypto modules may have the API set up in such a way that the
 IVs are generated within the module and could be something other
 than a counter (like an LFSR). The proposal will break such APIs.
 
 As Kent explained in the meeting, if you move the IV generation out
 from the crypto operation, then that also moves the FIPS boundary,
 i.e. if the uniqueness of the IV generation (counter) is inside the
 IPsec module, not in the ChaCha20 module, then you need to FIPS
 certify whole thing.
 
 On the other hand with IPsec I think you mostly need to FIPS certify
 quite a lot of stuff anyways...
 
 On the other hand, I think it would be possible to do things other way
 around, i.e. make cipher to internally generate IV, but define that IV
 MUST be running counter starting from 0, and use that counter as
 sequence number in the ESP and compress sequence number out from the
 packet. I.e. we would still have IV (coming form inside the crypto
 boundary), but we compress the sequence number away, as it would
 always be the same as IV...
 
 Currently we cannot do that, as we do not define how the IVs are
 generated, thus the IPsec part cannot know for sure that IVs are
 generated in such way.
 
 On the other hand if we define this cipher in such way that IV MUST be
 generated such way, then we could make sequence number compression
 option in the future, which would compress sequence number away from
 the actual packet... I.e. gain the same effect, but not compressing
 the IV, but compressing the sequence number...
 
 This would save 32-bits from the packet, as only 32-bits of the
 sequence number is transmitted, not the full 64-bits, but that would
 still be something, and if even more IV compression is needed, there
 would be ways to only transmit smaller part of the IV and then
 reconstruct it before decryption and verification.
 
 These compression extensions could happen after ESP encryption and
 before ESP decryption, so the actual ESP packets seen by the engine
 would be exactly same, only difference would be that they would need
 to maintain strict requirement that SEQ matches IV…

Such a compression extension would work fine for both ChaCha20-Poly1305 and 
AES-GCM at least. Probably the other currently-defined AEAD mode. OK, for now 
I’ll leave the TBD in, but I won’t change the text.

 Second issue is about UI advice. Some implementations (yes, mine is
 included) allow the user to configure encryption algorithm, MAC
 algorithm, and D-H group. There is no setting for PRF since such UIs
 date back to IKEv1. The PRF is usually just taken from the setting
 for MAC algorithm. This works fine as long as all supported MAC
 algorithms are HMAC, XCBC, and CMAC. AES-GCM would have the same
 issue, but RFC 5282 makes no mention of this issue. I’m wondering if
 we should recommend to pair this algorithm in IKE with
 PRF_HMAC_SHA2_256. 
 
 There is no need in IKEv2 to tie the PRF to other algorithms, so I see
 no reason to do so in this draft.
 
 On the other hand the other draft making the UI suite for this will of
 course need to select suitable PRF, but that draft might want to wait
 for new EC curves, so we could have complete DJB suite...
 
 Btw, in the draft introduction you have text which says:
 
   weakness in AES, VPN users will be in an unenviable position.  With
   the only other widely supported cipher being the much slower 3DES, it
   is not feasible to re-configure IPsec installations to use 3DES.
   [standby-cipher] describes this issue and the need for a standby
   cipher in greater detail.
 
 I do not think the problem with 3DES is the speed, I think the bigger
 problem is the way too short block length of it. As RFC7321 says:
 
   The Triple Data Encryption Standard (TDES) is obsolete because of its
   small block size; as with all 64-bit block ciphers, it SHOULD NOT be
   used to encrypt more than one gigabyte of data with a single key
   [M13].  Its key size is smaller than that of the Advanced Encryption

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

[Yoav Nir]

 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
 Subject: [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 
 64-bit IV and 32 zero bits. The reason for doing this is so the algorithm 
 could be used in a multi-sender case such as GDOI, where the 32-bit zero can 
 be replaced by a sender ID. 
 
 This idea about the multi-sender case works only if the there's a sender id 
 somewhere in the encrypted packet.

You’re right. For some reason I thought that the SID in GDOI was implied rather 
than transmitted on the wire. Oh, well…

 Alternatively, we could generate a 32-bit salt value from the key material, 
 but I don’t see a reason why we’d want that.
 
 Here's the reason that we do use the 32-bit salt value for GCM - to prevent 
 batching attacks.
 
 Consider the case that an attacker is able to collect packets from a billion 
 (2^30) sessions; each such session contains a packet with the same IV (say, 
 IV=0), and contains a packet with the same known plaintext (or, at least, 
 plaintext that satisfies the same known linear equations).  Then, what an 
 attacker can do is check a key to see if any of the IV=0 packets used that 
 key, in constant time.  The reduces the effort for an attacker to find the n 
 bit key for some session from 2^n to 2^{n-30}.  What the salt does is 
 multiply the effort involved in this specific attack by a factor of 2^32 
 (because the attacker needs to guess the key and the salt); that way, the 
 attacker needs to collect 4 billion sessions before this attack starts to 
 have any advantage over a simpler attack that just attacks a single packet 
 (which the salt doesn’t protect against).
 
 Now, of course, chacha20 has 256 bit keys; hence even if we decided not to 
 apply the same protection, someone with a collection of a billion sessions 
 might be able to use this to reduce the effort to 2^226.
 
 I'll let you decide whether this is a compelling argument or not…

I think that for 256-bit keys it’s not that compelling. So the question is 
which is simpler: to do as AES-GCM does, or to set the salt to zero?

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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 to request early code point assignment for ESP_ChaCha20-Poly1305.
 
 I know that it is the goal of the chairs to bring this to LC sooner rather 
 than later, but I would like to get started on implementation sooner rather 
 than later, and the IETF process takes three months at best, and six months 
 in the more common case.
 
 Thanks
 
 Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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
  [chacha_poly] a concatenation of the following in the below order:
 
  *  The Authenticated Additional Data (AAD) - see Section 2.1.
  *  The AAD length in bytes as a 32-bit network order quantity.
  *  The ciphertext
  *  The length of the ciphertext as a 32-bit network order
 quantity.
 
 First, I assume [chacha_poly] should be updated to
 draft-irtf-cfrg-chacha20-poly1305, where section 2.7 is now 2.8?

Right you are. Thanks. I’ve fixed it in my local storage. 
draft-irtf-cfrg-chacha20-poly1305 is now in the RFC editor’s queue. In a few 
weeks it will be published as an RFC, and then I will update the reference.

 draft-irtf-cfrg-chacha20-poly1305-10 2.8 defines AEAD construction for
 Poly1305 with padding and a final block with two 64-bit little endian
 length fields; in contrary to what is defined here.

Oh, right. That justifies a new revision immediately. The question is whether I 
should just delete the bullet points, leaving only the reference to the CFRG 
document, or fix it here.

 The GCM-like padding is certainly preferable, as it allows
 implementations to run four Poly1305 iterations on each ChaCha20 block.
 This is not only simpler, but allows parallel ChaCha20/Poly1305
 processing without operating on partial blocks.

I doubt it would produce a measurable difference in performance, but I agree.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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 early code point assignment for ESP_ChaCha20-Poly1305.
 
 I know that it is the goal of the chairs to bring this to LC sooner rather 
 than later, but I would like to get started on implementation sooner rather 
 than later, and the IETF process takes three months at best, and six months 
 in the more common case.
 
 Thanks
 
 Yoav
 
 Begin forwarded message:
 
 From: internet-dra...@ietf.org mailto:internet-dra...@ietf.org
 To: i-d-annou...@ietf.org mailto:i-d-annou...@ietf.org
 Date: March 30, 2015 at 4:32:37 PM GMT+3
 Cc: ipsec@ietf.org mailto:ipsec@ietf.org
 Subject: [IPsec] 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
  Filename: draft-ietf-ipsecme-chacha20-poly1305-00.txt
  Pages   : 6
  Date: 2015-03-29
 
 Abstract:
   This document describes the use of the ChaCha20 stream cipher along
   with the Poly1305 authenticator, combined into an AEAD algorithm for
   IPsec.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ 
 https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-00
 
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

One more thing.

I would like to request early code point assignment for ESP_ChaCha20-Poly1305.

I know that it is the goal of the chairs to bring this to LC sooner rather than 
later, but I would like to get started on implementation sooner rather than 
later, and the IETF process takes three months at best, and six months in the 
more common case.

Thanks

Yoav

 Begin forwarded message:
 
 From: internet-dra...@ietf.org
 To: i-d-annou...@ietf.org
 Date: March 30, 2015 at 4:32:37 PM GMT+3
 Cc: ipsec@ietf.org
 Subject: [IPsec] 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
   Filename: draft-ietf-ipsecme-chacha20-poly1305-00.txt
   Pages   : 6
   Date: 2015-03-29
 
 Abstract:
   This document describes the use of the ChaCha20 stream cipher along
   with the Poly1305 authenticator, combined into an AEAD algorithm for
   IPsec.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-00
 
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 ___
 IPsec mailing list
 IPsec@ietf.org
 https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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 64-bit IV 
and 32 zero bits. The reason for doing this is so the algorithm could be used 
in a multi-sender case such as GDOI, where the 32-bit zero can be replaced by a 
sender ID. Alternatively, we could generate a 32-bit salt value from the key 
material, but I don’t see a reason why we’d want that. Another thing we could 
do is what some people are advocating for TLS: Since a counter is a fine IV (no 
need for secrecy), we don’t need a 64-bit IV that has the exact same value as 
the replay counter. We might as well save 8 bytes per packet and just feed the 
replay counter to the function.  The argument against this is that some crypto 
modules may have the API set up in such a way that the IVs are generated within 
the module and could be something other than a counter (like an LFSR). The 
proposal will break such APIs.


Second issue is about UI advice. Some implementations (yes, mine is included) 
allow the user to configure encryption algorithm, MAC algorithm, and D-H group. 
There is no setting for PRF since such UIs date back to IKEv1. The PRF is 
usually just taken from the setting for MAC algorithm. This works fine as long 
as all supported MAC algorithms are HMAC, XCBC, and CMAC. AES-GCM would have 
the same issue, but RFC 5282 makes no mention of this issue. I’m wondering if 
we should recommend to pair this algorithm in IKE with PRF_HMAC_SHA2_256.

Thanks

Yoav
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

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: 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 
 64-bit IV and 32 zero bits. The reason for doing this is so the algorithm 
 could be used in a multi-sender case such as GDOI, where the 32-bit zero can 
 be replaced by a sender ID. Alternatively, we could generate a 32-bit salt 
 value from the key material, but I don’t see a reason why we’d want that. 
 Another thing we could do is what some people are advocating for TLS: Since a 
 counter is a fine IV (no need for secrecy), we don’t need a 64-bit IV that 
 has the exact same value as the replay counter. We might as well save 8 bytes 
 per packet and just feed the replay counter to the function.  The argument 
 against this is that some crypto modules may have the API set up in such a 
 way that the IVs are generated within the module and could be something other 
 than a counter (like an LFSR). The proposal will break such APIs.
 
 
 Second issue is about UI advice. Some implementations (yes, mine is included) 
 allow the user to configure encryption algorithm, MAC algorithm, and D-H 
 group. There is no setting for PRF since such UIs date back to IKEv1. The PRF 
 is usually just taken from the setting for MAC algorithm. This works fine as 
 long as all supported MAC algorithms are HMAC, XCBC, and CMAC. AES-GCM would 
 have the same issue, but RFC 5282 makes no mention of this issue. I’m 
 wondering if we should recommend to pair this algorithm in IKE with 
 PRF_HMAC_SHA2_256.
 
 Thanks
 
 Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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
 Steve Kent: the civilian part keep in mind several industry sectors make 
 use of FIPS approved algos for liability
 purpose. If the motivation is performance, that is not a good argument 
 anymore. Russ Housley chatted with NIST people
 and made optimized miplementation og P-256 so the performance of Curve25519 
 is not different enough. Performance is not
 a good reason.
 Tero: you cannor use curve25519  same for blake ?
 Tero: I hate the names A B and C. C for civilian is not a good name. Move UI 
 out and do UI in separate document
 Yoav: I thought we'd have the answer of CRFG by now
 ??? from NIST:  We received documents and proposal claiming they have to 
 implement P-256 faster than Curve25519. Has not
been verified. It is just a claim.
 PaulH: who will support with review or code: Tero,PaulW, Michael and Valery

Hi

In the meeting Kathleen asked how long the draft was. With all the algorithm 
details moved to the CFRG draft, the entire document is six pages, including 
introduction, IANA and security considerations, references, and the UI suite 
stuff (that I agree with Tero that should be moved out).

The real “meat” of the document is section 2, which spans a little over one 
page.

HTH

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[tcpinc] Minutes for tcpinc @ IETF 92

[Yoav Nir]

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 data as to how often you 
run into trouble?
Andrea: some data. No exact number.
BT: This discussion should be informed by data. 
Andrea: I have 1000 points of data. Wish I was Google. Question is: does it 
work? We don't have a clear answer.

Open question: store the MAC in TCP header or use TLV?

MAC in TCP option is simple, easy to implement. Does not change TCP semantics. 
Does not mess with buffering.
TLV advantages: robust to middleboxes. Easier to make work with TSO.

 ekr for TLS over TCP
Bob: EDO is not on the SYN, only SYN-ACK
ekr: there were some discussions. Fix that
Stuart Cheshire: If we're doing it this implies the application is plaintext. 
So the application receives a bunch of TLS stuff it doesn't understand
ekr: If it's EDO it's ignored.
Others: that's the needed magic.

Bob Briscoe: the ability to build authentication on top of the encryption
EKR: channel bindings is a standard feature of TLS
Andrea: tcpcrypto session-id is super simple. Don't know about TLS channel 
binding.
David Mazieres: The issue of segmentation and choosing MTU helps in the center, 
but pushes complexity to the receiver. There are advantages to TLV, but it's 
nice that TCP options keep semantics.
EKR: yes, but TLS does this all the time.
Jana Iyengar: MACS by segment is not just a strength. A TCP-level proxy might 
muck with segment size
Jana: if we decide we need a TLV-style transport, we end up with two proposals 
that have a lot of common features. Even a TLS handshake could export keying 
material for tcpcrypt style data layer. Both can be upgraded to MAC headers 
like TCP-AO. After those were addressed, it comes down to which crypto you 
want. We can do both.
chair: no.
Bob: in both cases we're talking about things you COULD do, but it's not 
written down, and you can't just hand-waive.
chair: we don't want to progress with two proposals. Too much effort. We want 
to pick one, assume that it's very initial and work on that.
Bob: not disagree, but neither protocol is specified enough.
chair: both can be made to work. People will be able to modify the proposal. We 
don't want to make the authors invest a lot of work in modifying only to then 
throw away their work by picking the other.
Bob: These are important details.
David: we are not proposing to change them. Only change the framing of the 
application data.
AD: no space for two documents. Need to go with one single document. Need not 
be perfect.
Steve Kent: If we're going to make a decision, it should be based on 
properly-specified proposals. Let the proponents make a best and final proposal.
Ted Hardie: I disagree with SK. I want this to deploy. The faster we have *one* 
thing, the faster we'll get something that is deployed.
EKR: If people don't want to select between non-fleshed-out proposals, there's 
always something else that can be fleshed out. If we want something, get 
requirements.
Stephen Farrell: Don't want to spend time writing requiremetns.
Christian: Both are good. tcpcrypt doesn't require a server credential. TLS as 
deployed does.
EKR: There are two options without good certs: self-signed, oob keys.
???: Is there an implementation?
EKR: not yet.
David: concern about moving to TLV for tcpcrypt: it changes a lot of things 
(socket buffer size...) 

 Tero on framing options
Paul Wouters: please don't do with library pre-loading
Tero: I said you *can* do, not that you should. We want it to be in kernel.
David: people don't want to change the kernel. need usermode. Our 
implementation of tcpcrypt is not pre-loading.
Jana: is there an equivalent for Mac and Windows?
David: yes.

Keith Moore: you need to have the same effect of urgent data. They are rare, 
but important to some people. This is going to be imposed on applications, and 
you don't want random breakage.
Tero: Right, and we don't know that urgent data is going to come. Urgent 
pointer cleared by middlebox causes breakage
Richard: obsolete. don't have to worry about it
Keith: yes, you do.
David: only FTP and telent use urgent data.
Richard: but it's broken in a lot of operating systems.
Bob Briscoe: Richard is saying that given that it's broken, might as well break 
it more.
???: It has not changed on the wire.
Christian: no discussion of MTU changes.
Tero: users don't know MTU
Christian: if you add a MAC, your MTU reduces.
Tero: As long as it's fixed, it just goes down and the kernel knows the 
overhead.
Christian: If you sent a 2K packet with MAC and it is dropped, how do you 
retransmit? The already calculated MAC is wrong for the smaller packet.
David: The attempt to be friendly to middleboxes. relatively straight-forward. 
Optimized the MAC
Bob: Do you think you've presented 

Re: [IPsec] Vendor Identifiers

[Yoav Nir]

 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 adjust 
 their behaviors to avoid the circumstances that enable the bug.  In the worst 
 case, they could refuse to talk to the badly broken version, but accept 
 connections to later versions where the bug has been repaired.
 
 Does anyone have operation experience doing this kind of thing?  I want to 
 know if is real experience or speculation about what could be done.

I haven’t encountered this kind of use of a VendorID. Years ago there was a 
push by auditors for vendors to stop revealing their versions in protocols. As 
a result, our VendorID has not changed in ten years. I suspect the same is true 
for other vendors. So if a bug is fixed, the VendorID is not changed. I don’t 
believe the VendorID is a good way to identify buggy implementations.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Vendor Identifiers

[Yoav Nir]

 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 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 behaviors to avoid the circumstances that enable the bug.  In 
 the worst case, they could refuse to talk to the badly broken version, but 
 accept connections to later versions where the bug has been repaired.
 
 Does anyone have operation experience doing this kind of thing?  I want to 
 know if is real experience or speculation about what could be done.
 
 I haven’t encountered this kind of use of a VendorID. Years ago there was a 
 push by auditors for vendors to stop revealing their versions in protocols. 
 As a result, our VendorID has not changed in ten years. I suspect the same 
 is true for other vendors. So if a bug is fixed, the VendorID is not 
 changed. I don’t believe the VendorID is a good way to identify buggy 
 implementations.
 
 As for buggy implementations, I think that it isn’t needed for that.  If 
 someone has a bug that breaks interoperability, we would in general take the 
 view of “if they fix it, it will work” — in other words, vendors normally 
 don’t take on the job of working around someone else’s mistakes.
 
 Interesting story about auditors.  I haven’t run into any such thing.  I 
 would hope that most auditors have more sense than that.

Unfortunately, it’s far easier to stop sending the version than to argue 
against this.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2679

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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 IPsecME. If you want this as a WG document, and you are willing to 
 review drafts as they move through, please say so on this thread. If you are 
 opposed to this being a WG document, please say so (and say why). Thanks in 
 advance.
 
 This got very little interest, which surprised me. Without a few more people 
 who will commit to review the document and offer comments, we can't really 
 call it a WG work item. Is there really so little interest in new algorithms 
 that are being adopted in other protocols?
 
 If you are an IPsec implementer, it would be very useful to know whether or 
 not you would support adding this algorithm to your implementation, and why.
 

Obviously I’m in favor of adoption, as I’m the author.

[vendor hat on]
If (when?) this becomes an RFC, Check Point will implement this, in all 
likelihood this year or early next year.

I of course can’t promise dates or versions when this is delivered as a feature 
in our product - that is more of a UI decision, and out of my hands.

Yoav


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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 the ChaCha20+Poly1305 for IKE and 
 IPsec document [2] accepted by this working group with the
 intent of having it published as a standard-track document.
 
 I am in favour of adopting this document for the WG.
 
 [2] https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305-05
 
 Can we rename ESP_ChaCha20-Poly1305 to ESP_ChaCha20_Poly1305 ? That
 allows implementors to match the literal IANA string into C-code, which
 does not allow a - symbol.

Hmm, it’s like version -10 all over again:
http://www.ietf.org/rfcdiff?url1=draft-irtf-cfrg-chacha20-poly1305-09url2=draft-irtf-cfrg-chacha20-poly1305-10


   The problem is that if future advances in cryptanalysis reveal a
   weakness in AES, VPN users will be in an unenviable position.  With
   the only other widely supported cipher being the much slower 3DES,
 
 I'm not sure if that is completely true. We do have Camellia, although
 I'm not a cryptographer and it might be too similar to AES. So I still
 agree with the sentiment of the text.

There are several algorithms that exist, and even quite a few that are defined 
for IPsec. But none are as universally implemented as 3DES and AES. So as a 
developer I can implement Camellia (and I have no idea about its speed relative 
to AES), but as a user with an existing version of some software that has to 
interoperate with some other user of some other version of some other software, 
only with AES and 3DES it’s safe to assume that we can achieve interoperability.

   The length of the ciphertext as a 32-bit network order quantity.
 
 Can we clarify the number of octets used here without needing to go into
 another reference document?

Mmm, 4?   Network order is the controversial part, because everything else in 
ChaCha20 is little-endian.

 I kind of dislike using HMAC-SHA-256 but I understand we don't have much
 choice right now:

For PRF? What’s wrong with HMAC-SHA-256?  I would have preferred to use these 
algorithms for the PRF. Poly1305 is not suitable as a PRF. ChaCha20 is a block 
cipher in counter mode and is very suitable as a PRF, but it doesn’t fit the 
definition of a PRF in section 2.13 of RFC 7296.

 https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-10#section-2.7
 
 Although perhaps we can go back to CRFG and ask if they can give us
 something that is not based on the SHA2 family?

Why don’t you like SHA2?  Is it about the performance or just a general dislike 
of NIST algorithms?
Anyway, perhaps you’d like blake2 better:
http://tools.ietf.org/html/draft-saarinen-blake2-01

Still seems like a shame to brink that in just for the PRF.

 I have no strong opinions about Diffie-Hellman groups.

Perhaps Curve25519 after CFRG finish recommending it.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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 of approval” …
 
 I needed to read up on these things, and I read:
  ChaCha20+Poly1305 can be as much as 300% faster than AES-256-GCM with SHA-1
  authentication.

I’m guessing you mean AES-256-CBC, because if you use GCM, you don’t need 
SHA-1. Either way, these values are right for older Intel chips as well as ARM 
and whatever is it that runs in the IoT space. Newer Intel chips with the 
AESENC opcode have faster AES-GCM than ChaCha20+Poly1305.

 and claims that Poly1305 is faster than SHA1/2/3.
 This is certainly interesting to me.
 
 {I'm very concerned in the IoT space (not really IPsec related at all), that
 we are cooking too much AES-GCM in as the one and only choice, and may lose
 algorithm agility in protocols.}

Interesting. I thought they were baking AES-CCM into IoT standards. 
ChaCha20+Poly1305 are attractive options because of a very small code base, and 
a 64-byte workspace for ChaCha (16 x 32-bit ints). Can’t get below ~500 bytes 
for AES.

 I am supportive of defining code points for these.
 
 --
 Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works
 -= IPv6 IoT consulting =-

Thanks

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Yoav Nir]

 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 always lose, no matter what POW 
 solution we choose. This has been a problem with this proposal from day one 
 and it's a limitation that we as a group need to decide whether to accept or 
 not.
 
 I'm not yet convinced this proposal will provide a working solution to
 the DDOS problem.

Hi, Paul

“solution” is hard. Whatever we do, an attacker with unlimited resources can 
throw more at us. 

We could block all regular initiations under load, allowing only RFC 5723 
resumptions. But this allows an attacker to force us into this mode and 
effectively deny service to all initiators that don’t have a saved session. 

So instead we can allow resumptions and also make it more costly for the 
attacker to mount the attack on regular initiations. Even an easy puzzle, one 
that my 1.2 GHz single-core ARMv5 with C code can solve in a second is much 
harder than just the return routability that COOKIE provides. The draft has 
text about how to make these puzzles a weapon of last resort, so legitimate 
users hardly ever need to solve them, but even setting the puzzle difficulty to 
something a strong desktop can do 20 times a second, it’s still better than the 
two other alternatives: allow the strong desktop to create 1000 half-open SAs 
in a second, or entirely block the subnet from which the desktop seems to come.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Yoav Nir]

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-17 bits for one solution, 12 for 16 solutions or 10 
for 64. That’s pretty much in line with what I got with “my” code. According to 
messages on openssl’s dev list, the assembly-language version of SHA-256 is 
about twice as fast, so respectively that’s 18, 13 or 11 bit puzzles, Still 3 
bits behind Intel. This does not take into considerations 2- or 4-core laptops 
or octo-core Samsung Galaxies.

 On Feb 5, 2015, at 8:52 AM, Valery Smyslov sva...@gmail.com wrote:
 
 I think this data proves the idea that the difference between
 computation power of different clients is significant and
 no single puzzle difficulty level would be reasonable for all.
 I think we should proceed with the proposal that
 client is allowed to return less zero bits than requested.

It’s simpler and safer code to get a request from the initiator, mark it as 
solved/not-solved, and process if solved or discard if not. Then you don’t have 
to do any queueing beyond what the UDP stack is doing anyway.

 And in this case we may go further.
 The server may even not indicate to the client
 how many zero bits it wants to get. The server
 could just give the puzzle to the client and
 the client would return the best solution that it can
 get for a reasonable (from client's point of view) time.
 Some clients would be able to get more zero bits, some less.
 Then the server would sort all the requests, as described
 in Tero's e-mail and serve them accordingly.


This would allow a sufficiently powerful botnet to flood the queues and deny 
service to phones. Suppose it turns out that phones like to work for 0.5 
seconds and usually come up with 15-, 16-, or 17- bit solutions, it should be 
easy for a botnet to work far less time on each puzzle and solve hundreds of 
puzzles at these bit lengths. That would effectively block the phones that take 
a whole half second to calculate just one such solution.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Yoav Nir]

OK, now I’ve got a chance to test on an ARM appliance (similar in power to a 
2-3 year old phone, I think.

Again these are single-core results, but there’s an extra bit of badness here 
in that this is a C implementation of SHA256. We could probably gain around 2 
extra bits with an assembly-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 sample. Results are slightly better.
 
 Yoav
 data64.xlsx
 On Feb 1, 2015, at 7:36 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
 
 Hi Yoav,
 
 This is good, but I'm not sure if it's good enough. The ratio between min 
 and max (which I trust more than the mean +/- 3s rule, because this is not 
 a normal distribution) is consistently around 4. So if you have to design 
 your timeouts on a particular machine, you would still 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.
 
 
 
 
 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:
 
 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 random. The client would still need to solve all of them because it 
 doesn't want to risk the exchange being rejected because some solutions 
 are invalid (the game theory is probably more complex than that, but I 
 think what I'm saying is still close to the truth).
 
 So: the client does the same amount of work, the server does the same 
 amount of work, but the client run-time is still much more deterministic.
 
 snip /
 
 Note that these are still single core results, and most laptops can do 
 twice or four times as much. Now, I know that what I SHOULD be doing is 
 to randomly generate 100 “cookies” and then calculate the times for 
 different bit lengths for each of them, and then calculate mean and 
 standard deviation. But just by looking, it looks like it’s much closer 
 to what we want. 16 bits would be a fine puzzle level for my laptop. No 
 idea about a phone, although I could try to compile this and run it on an 
 ARM-based appliance, which should match phones.
 
 OK. Now I have done it right. See attached. The data suggests that 15 or 
 16 bits is the level of puzzle that for this kind of hardware is 
 challenging but not too onerous. Add another bit if we assume (probably 
 correctly) that the vast majority of laptops have dual cores at least.
 
 I would like to run a similar test on an ARM processor, though. The 
 capabilities of phones and tablets are all over the place, what with 
 different versions of ARM processors and devices having anything from dual 
 to octo-core, but it would be nice to get ballpark figures.
 
 Yoav
 
 
 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Yoav Nir]

 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 easier. 
 The nice thing is, the server should only check *one* of them, at random. 
 The client would still need to solve all of them because it doesn't want to 
 risk the exchange being rejected because some solutions are invalid (the 
 game theory is probably more complex than that, but I think what I'm saying 
 is still close to the truth).
 
 So: the client does the same amount of work, the server does the same amount 
 of work, but the client run-time is still much more deterministic.

snip /

 Note that these are still single core results, and most laptops can do twice 
 or four times as much. Now, I know that what I SHOULD be doing is to randomly 
 generate 100 “cookies” and then calculate the times for different bit lengths 
 for each of them, and then calculate mean and standard deviation. But just by 
 looking, it looks like it’s much closer to what we want. 16 bits would be a 
 fine puzzle level for my laptop. No idea about a phone, although I could try 
 to compile this and run it on an ARM-based appliance, which should match 
 phones.

OK. Now I have done it right. See attached. The data suggests that 15 or 16 
bits is the level of puzzle that for this kind of hardware is challenging but 
not too onerous. Add another bit if we assume (probably correctly) that the 
vast majority of laptops have dual cores at least.

I would like to run a similar test on an ARM processor, though. The 
capabilities of phones and tablets are all over the place, what with different 
versions of ARM processors and devices having anything from dual to octo-core, 
but it would be nice to get ballpark figures.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Yoav Nir]

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:
 
 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 
 random. The client would still need to solve all of them because it doesn't 
 want to risk the exchange being rejected because some solutions are invalid 
 (the game theory is probably more complex than that, but I think what I'm 
 saying is still close to the truth).
 
 So: the client does the same amount of work, the server does the same 
 amount of work, but the client run-time is still much more deterministic.
 
 snip /
 
 Note that these are still single core results, and most laptops can do twice 
 or four times as much. Now, I know that what I SHOULD be doing is to 
 randomly generate 100 “cookies” and then calculate the times for different 
 bit lengths for each of them, and then calculate mean and standard 
 deviation. But just by looking, it looks like it’s much closer to what we 
 want. 16 bits would be a fine puzzle level for my laptop. No idea about a 
 phone, although I could try to compile this and run it on an ARM-based 
 appliance, which should match phones.
 
 OK. Now I have done it right. See attached. The data suggests that 15 or 16 
 bits is the level of puzzle that for this kind of hardware is challenging but 
 not too onerous. Add another bit if we assume (probably correctly) that the 
 vast majority of laptops have dual cores at least.
 
 I would like to run a similar test on an ARM processor, though. The 
 capabilities of phones and tablets are all over the place, what with 
 different versions of ARM processors and devices having anything from dual to 
 octo-core, but it would be nice to get ballpark figures.
 
 Yoav
 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Yoav Nir]

The three-sigma rule applies even with a non-normal distribution.

Anyway, I tried the 64-key sample. Results are slightly better.

Yoav


data64.xlsx
Description: MS-Excel 2007 spreadsheet

 On Feb 1, 2015, at 7:36 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
 
 Hi Yoav,
 
 This is good, but I'm not sure if it's good enough. The ratio between min and 
 max (which I trust more than the mean +/- 3s rule, because this is not a 
 normal distribution) is consistently around 4. So if you have to design your 
 timeouts on a particular machine, you would still 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.
 
 
 
 
 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:
 
 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 
 random. The client would still need to solve all of them because it 
 doesn't want to risk the exchange being rejected because some solutions 
 are invalid (the game theory is probably more complex than that, but I 
 think what I'm saying is still close to the truth).
 
 So: the client does the same amount of work, the server does the same 
 amount of work, but the client run-time is still much more deterministic.
 
 snip /
 
 Note that these are still single core results, and most laptops can do 
 twice or four times as much. Now, I know that what I SHOULD be doing is to 
 randomly generate 100 “cookies” and then calculate the times for different 
 bit lengths for each of them, and then calculate mean and standard 
 deviation. But just by looking, it looks like it’s much closer to what we 
 want. 16 bits would be a fine puzzle level for my laptop. No idea about a 
 phone, although I could try to compile this and run it on an ARM-based 
 appliance, which should match phones.
 
 OK. Now I have done it right. See attached. The data suggests that 15 or 16 
 bits is the level of puzzle that for this kind of hardware is challenging 
 but not too onerous. Add another bit if we assume (probably correctly) that 
 the vast majority of laptops have dual cores at least.
 
 I would like to run a similar test on an ARM processor, though. The 
 capabilities of phones and tablets are all over the place, what with 
 different versions of ARM processors and devices having anything from dual 
 to octo-core, but it would be nice to get ballpark figures.
 
 Yoav
 
 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Yoav Nir]

 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 random. The 
 client would still need to solve all of them because it doesn't want to risk 
 the exchange being rejected because some solutions are invalid (the game 
 theory is probably more complex than that, but I think what I'm saying is 
 still close to the truth).
 
 So: the client does the same amount of work, the server does the same amount 
 of work, but the client run-time is still much more deterministic.

OK, I’ve tried that. 

But first, I found an inefficiency in my code, so I’ve fixed it and ran the 
tests again. Here are the results:

 cookie set
#bits 1  2  3  
= =  =  =
 15 0.016
 16 0.031  0.065  0.057
 17 0.087  0.820  0.250
 18   0.289
 19 0.420
 20 5.965 0.401
 2114.055  0.916
 2219.065  2.074
 2323.753  3.067  6.688
 245.414 48.045
 2529.924
 2660.088130.753
 27
 28  87.437
 29   111.921

So still pretty much all over the place.  So I tried Yaron’s suggestion of 
calculating until I find 16 keys that produce at least so many zero bits. Here 
are the results for 16 keys each time:

 cookie set
#bits 1  2  3  4  
= =  =  =  =
 15  0.780  0.954  0.678  0.778
 16  1.734  2.056  1.575  1.162
 17  3.090  4.161  2.932  2.832
 18  4.981  7.463  4.766  4.380
 19 11.612 10.069 14.525  8.486
 20 22.789 21.111 30.961 24.146 
 21 40.066 39.875 57.930 53.785
 22 92.264116.453123.352139.584

Note that these are still single core results, and most laptops can do twice or 
four times as much. Now, I know that what I SHOULD be doing is to randomly 
generate 100 “cookies” and then calculate the times for different bit lengths 
for each of them, and then calculate mean and standard deviation. But just by 
looking, it looks like it’s much closer to what we want. 16 bits would be a 
fine puzzle level for my laptop. No idea about a phone, although I could try to 
compile this and run it on an ARM-based appliance, which should match phones.

Yoav
 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Yoav Nir]

I’ll try that later, but suppose we give the client 16 puzzles to solve, then 
we expect solving all of them to take 16 times as long, so they can be 16 times 
easier. So instead of 22 bits, they can be 18 bits. I’m not sure if that 
increased the chance of getting “stung” by a bad outlier or that it averages 
better.

But one effect is obvious. If we require the client to solve all puzzles, the 
server has to check all 16 parts of the solution, and that makes it 16x harder 
for the server.

OTOH if we required to solve just one of the 16, the client could try all 16 at 
the same time, and have a better chance of finding a “good” outlier. Again, I’m 
not sure which is the dominant effect.

Yoav

 On Jan 30, 2015, at 1:27 PM, Valery Smyslov sva...@gmail.com wrote:
 
 Hi,
  
 I also had some concerns on the variance of the times. But then
 another thought came to me. Let's look on this issue from the other side.
 The responder will use puzzles only when it feels that it is under attack.
 It means, that there are a lot of (thouthands, tens of thouthands)
 half-open connections. If responder requests that number of puzzles,
 then some of them will appear to be easier to solve than the others.
 Every initiator is different from another in terms of computing power and
 each of them may receive more or less hard puzzle. 
 It's like an exam - some tasks are more easy to solve, some are harder.
 Some clients will be more lucky, some less. That's a lottery.
 But all those differences will be averaged for the responder, so why bother?
  
 Also if we require initiator to solve several puzzles, than it will need
 to send back all the solutions, that will noticeably increase
 IKE message size.
  
 So, while the idea is interesting, I think that the problem it solves
 is not important, so why should we bother?
  
 But it would be nice, if Yoav (as a person who already has
 test bed) could check, that if we solve puzzle for 100
 (or better 1000) different cookies, and average the times,
 that the results will be less erratic (it would also be great
 to measure the deviation 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 puzzle: PRF vs Hash
 
 Interesting. I’ve tried with a few different “cookies”.
 
 Cookie: 4f331b879f6d02322aa894942f66473d8a1949625c488aa0f4f943b441cfd6f4
 Key=…3db1  PRF=…4c82f8b8  #zeros=19  time=0.025
 Key=…0002ea6c  PRF=…5faafb80  #zeros=23  time=0.250
 Key=…0124159c  PRF=…9136e500  #zeros=24  time=26.013
 
 Cookie: 6756a2fee7047eb87030b5cd7eb97ee24579371f54fecd3bc71f8b028f8c18b1
 #zeros=14   time=0.016
 #zeros=15   time=0.035
 #zeros=19   time=0.134
 #zeros=20   time=0.837
 #zeros=21   time=1.932
 #zeros=22   time=5.646
 #zeros=24   time=16.790
 #zeros=27   time=17.477
 
 Cookie: 61a3a14b02580773234b8a773305aefed61c067775cea9c4797a406cd30fb14f
 #zeros=15   time=0.016
 #zeros=17   time=0.434
 #zeros=21   time=1.034
 #zeros=22   time=1.230
 #zeros=23   time=16.213
 #zeros=24   time=25.554
 #zeros=
 
 Seems like the big issue here is inconsistency. Set the puzzle level to 22 
 bits, and it could be solved in a quarter second or in 5.6 seconds or in 
 1.230. And these are not just outliers - they’re the first three values I 
 picked at this length.
 
 20 bits seems an acceptable difficulty level, but beyond that it becomes too 
 erratic.
 
 Yoav
 
 On Jan 29, 2015, at 11:57 PM, Yaron Sheffer yaronf.i...@gmail.com 
 mailto:yaronf.i...@gmail.com wrote:
 
 Looking at the timing table, there is obviously significant variance in the 
 time to solve each puzzle, compared to the ideal exponential curve. For 
 example, for 28 bits we have 250s, whereas for 29 bits it's 1240s.
 
 Would it make sense to require the initiator to return 4 or 8 solved 
 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.
 
 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.
 
 The source files and change are available at
 https://github.com/ietf-ipsecme/drafts/pull/3 
 https://github.com/ietf-ipsecme/drafts/pull/3
 
 The relevant section is appended below
 
 Please let us know what you think. Also about Valery’s pull request
 about negotiation.
 
 Yoav
 
 3.  Puzzles
 
The puzzle introduced here extends the cookie mechanism from RFC
7296.  It is loosely based on the proof-of-work

[IPsec] DDoS puzzle: PRF vs Hash

[Yoav Nir]

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.

The source files and change are available at 
https://github.com/ietf-ipsecme/drafts/pull/3 
https://github.com/ietf-ipsecme/drafts/pull/3

The relevant section is appended below

Please let us know what you think. Also about Valery’s pull request about 
negotiation.

Yoav

3.  Puzzles

   The puzzle introduced here extends the cookie mechanism from RFC
   7296.  It is loosely based on the proof-of-work technique used in
   BitCoins ([bitcoins]).  Future versions of this document will have
   the exact bit structure of the notification payloads, but for now, I
   will only describe the semantics of the content.

   A puzzle is sent to the Initiator in two cases:

   o  The Responder is so overloaded, than no half-open SAs are allowed
  to be created without the puzzle, or
   o  The Responder is not too loaded, but the rate-limiting in
  Section 5 prevents half-open SAs from being created with this
  particular peer address or prefix without first solving a puzzle.

   When the Responder decides to send the challenge notification in
   response to a IKE_SA_INIT request, the notification includes three
   fields:

   1.  Cookie - this is calculated the same as in RFC 7296.  As in RFC
   7296, the process of generating the cookie is not specified.
   2.  Algorithm, this is the identifier of a PRF algorithm, one of
   those proposed by the Initiator in the SA payload.
   3.  Zero Bit Count.  This is a number between 8 and 255 that
   represents the length of the zero-bit run at the end of the
   output of the PRF function calculated over the Keyed-Cookie
   payload that the Initiator is to send.  Since the mechanism is
   supposed to be stateless for the Responder, the same value is
   sent to all Initiators who are receiving this challenge.  The
   values 0 and 1-8 are explicitly excluded, because the value zero
   is meaningless, and the values 1-8 create a puzzle that is too
   easy to solve for it to make any difference in mitigating DDoS
   attacks.

   Upon receiving this challenge payload, the Initiator attempts to
   calculate the PRF using different keys.  When a key is found such
   that the resulting PRF output has a sufficient number of trailing
   zero bits, that result is sent to the Responder in a Keyed-Cookie
   notification, as described in Section 3.1.

   When receiving a request with a Keyed-Cookie, the Responder verifies
   two things:

   o  That the cookie part is indeed valid.
   o  That the PRF of the transmitted cookie calculated with the
  transmitted key has a sufficient number of trailing zero bits.

   Example 1: Suppose the calculated cookie is
   fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets), the algorithm
   is HMAC-SHA256, and the required number of zero bits is 18.  After
   successively trying a bunch of keys, the Initiator finds that the key
   that is all-zero except for the last three bytes which are 02fc95
   yields HMAC_SHA256(k, cookie) =
   843ab73f35c5b431b1d8f80bedcd1cb9ef46832f799c1d4250a49f683c58,
   which has 19 trailing zero bits, so it is an acceptable solution.

   Example 2: Same cookie, but this time the required number of zero
   bits is 22.  The first key to satisfy that requirement ends in
   960cbb, which yields a hash with 23 trailing zero bits.  Finding this
   requires 9,833,659 invocations of the PRF.___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Yoav Nir]

Interesting. I’ve tried with a few different “cookies”.

Cookie: 4f331b879f6d02322aa894942f66473d8a1949625c488aa0f4f943b441cfd6f4
Key=…3db1  PRF=…4c82f8b8  #zeros=19  time=0.025
Key=…0002ea6c  PRF=…5faafb80  #zeros=23  time=0.250
Key=…0124159c  PRF=…9136e500  #zeros=24  time=26.013

Cookie: 6756a2fee7047eb87030b5cd7eb97ee24579371f54fecd3bc71f8b028f8c18b1
#zeros=14   time=0.016
#zeros=15   time=0.035
#zeros=19   time=0.134
#zeros=20   time=0.837
#zeros=21   time=1.932
#zeros=22   time=5.646
#zeros=24   time=16.790
#zeros=27   time=17.477

Cookie: 61a3a14b02580773234b8a773305aefed61c067775cea9c4797a406cd30fb14f
#zeros=15   time=0.016
#zeros=17   time=0.434
#zeros=21   time=1.034
#zeros=22   time=1.230
#zeros=23   time=16.213
#zeros=24   time=25.554
#zeros=

Seems like the big issue here is inconsistency. Set the puzzle level to 22 
bits, and it could be solved in a quarter second or in 5.6 seconds or in 1.230. 
And these are not just outliers - they’re the first three values I picked at 
this length.

20 bits seems an acceptable difficulty level, but beyond that it becomes too 
erratic.

Yoav

 On Jan 29, 2015, at 11:57 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
 
 Looking at the timing table, there is obviously significant variance in the 
 time to solve each puzzle, compared to the ideal exponential curve. For 
 example, for 28 bits we have 250s, whereas for 29 bits it's 1240s.
 
 Would it make sense to require the initiator to return 4 or 8 solved 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.
 
 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.
 
 The source files and change are available at
 https://github.com/ietf-ipsecme/drafts/pull/3
 
 The relevant section is appended below
 
 Please let us know what you think. Also about Valery’s pull request
 about negotiation.
 
 Yoav
 
 3.  Puzzles
 
The puzzle introduced here extends the cookie mechanism from RFC
7296.  It is loosely based on the proof-of-work technique used in
BitCoins ([bitcoins]).  Future versions of this document will have
the exact bit structure of the notification payloads, but for now, I
will only describe the semantics of the content.
 
A puzzle is sent to the Initiator in two cases:
 
o  The Responder is so overloaded, than no half-open SAs are allowed
   to be created without the puzzle, or
o  The Responder is not too loaded, but the rate-limiting in
   Section 5 prevents half-open SAs from being created with this
   particular peer address or prefix without first solving a puzzle.
 
When the Responder decides to send the challenge notification in
response to a IKE_SA_INIT request, the notification includes three
fields:
 
1.  Cookie - this is calculated the same as in RFC 7296.  As in RFC
7296, the process of generating the cookie is not specified.
2.  Algorithm, this is the identifier of a PRF algorithm, one of
those proposed by the Initiator in the SA payload.
3.  Zero Bit Count.  This is a number between 8 and 255 that
represents the length of the zero-bit run at the end of the
output of the PRF function calculated over the Keyed-Cookie
payload that the Initiator is to send.  Since the mechanism is
supposed to be stateless for the Responder, the same value is
sent to all Initiators who are receiving this challenge.  The
values 0 and 1-8 are explicitly excluded, because the value zero
is meaningless, and the values 1-8 create a puzzle that is too
easy to solve for it to make any difference in mitigating DDoS
attacks.
 
Upon receiving this challenge payload, the Initiator attempts to
calculate the PRF using different keys.  When a key is found such
that the resulting PRF output has a sufficient number of trailing
zero bits, that result is sent to the Responder in a Keyed-Cookie
notification, as described in Section 3.1.
 
When receiving a request with a Keyed-Cookie, the Responder verifies
two things:
 
o  That the cookie part is indeed valid.
o  That the PRF of the transmitted cookie calculated with the
   transmitted key has a sufficient number of trailing zero bits.
 
Example 1: Suppose the calculated cookie is
fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets), the algorithm
is HMAC-SHA256, and the required number of zero bits is 18.  After
successively trying a bunch of keys, the Initiator finds

Re: [IPsec] Puzzle algorithm negotiation

[Yoav Nir]

 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 clear that the PRF used for the POW must be 
 the very same as the one selected by the responder for the IKE SA?

It is possible, but I don’t see why it’s a good thing. Suppose the conversation 
goes like this:

Initiator: I want (AES-CBC-128 or AES-CBC-256) with (AUTH_HMAC-SHA1 or 
AUTH_HMAC-SHA256) and (PRF_ HMAC-SHA1 or PRF_HMAC-SHA256) and (Group 2 or Group 
14)

Responder: First do proof-of-work with PRF_HMAC-SHA256

Initiator: Here’s the proof-of-work, now I want (AES-CBC-128 or AES-CBC-256) 
with (AUTH_HMAC-SHA1 or AUTH_HMAC-SHA256) and (PRF_ HMAC-SHA1 or 
PRF_HMAC-SHA256) and (Group 2 or Group 14).

Responder: Fine, I choose AES-CBC-128 with HMAC-SHA1 and PRF_HMAC-SHA1 and 
Group 2.

What is the benefit of forcing the responder to choose the same PRF algorithm 
twice? What is wrong with having it choose PRF_HMAC-SHA1?  Sure, we *can* do 
this, but why?

 People may not like it (I don't) but a major reason for including agility 
 today is FIPS silliness. One day people will be forced to rip out any mention 
 of SHA-256 from their code, and we don't want to need to reopen the RFC.

Some algorithms are also more fashionable than others.

Yoav

 
 Thanks,
   Yaron
 
 On 01/19/2015 12:02 AM, Valery Smyslov wrote:
 Hi Yoav,
 
Pull Request: https://github.com/ietf-ipsecme/drafts/pull/2
 
Hi,
 
Valery has created this pull request. During the meeting in Honolulu
and subsequent discussion on the list, several people requested that
there be a negotiation of the algorithm used in the puzzle rather
than fixing it to SHA-256.
 
The pull request suggests figuring out which algorithms the
Initiator supports by examining the SA payload in the IKE_SA_INIT
request, and using the PRF algorithms.
 
I’m posting this to the list, even thought we’re not sure about
this. Specifically, PRF_AES128_XCBC and (I think) PRF_AES128_CMAC
won’t work with the bitcoin-like puzzle that is currently in the draft.
 
Why?
 
For convenience assume a 16-byte cookie, a fixed zero IV (as always
in AES-XCBC) and fixed zero key.
 
So let Y = AESENC(key, IV XOR COOKIE) = AESENC(zero, COOKIE)
Let Z = AESDEC(key, zero) = AESDEC(zero, zero)
Extend the cookie by Y XOR Z.
The result will give you a 128-bit tag of all zeros. Way too easy.
 
 You forgot about the mandatory 10* padding in AES-XCBC.
 So, the result of AESDEC(zero, zero) should not be a random
 string, but should look like properly padded one.
 But anyway, I think that if we use PRF for puzzles, then the puzzle
 definition should be changed.
 Let R=PRF(K,S). Then the puzzle should be: using supplied cookie as
 message S,
 find a key K so, that result R contains the requested number of trailing
 zero bits.
 I'm not a cryptographer, but I think this variant of puzzle should be secure
 for all PRFs, defined in IPsec. Why? First, every secure PRF is a secure
 MAC
 (not visa versa). This is pointed out by several sources. Then, secure MAC
 should not allow attacker to recover a key given the message and
 the authentication tag. In our case the authentication tag is not fully
 given,
 but it must have some properties (desired number of trailing zero bits),
 so it is not arbitrary.
 
Another way to do this is to add a notification in the Initiator’s
request listing the hash algorithms that it supports. We could reuse
the RFC 7427 registry of hash algorithms.
 
 I don't think this is a good idea. First, it will require initiator to
 include
 a list of supported hash algorithms into request message. This will
 unnecessary increase its size in all cases: at this point initiator
 has no idea whether responder will ever use puzzles or even
 whether it supports them. I think this is a waste of resources,
 especially taking into consideration that we may reuse
 information, that is always present in the request message.
 
Personally, I really don’t like this algorithm agility, because we
don’t want to give the Initiator the options of a hard vs easy
puzzle. So suppose the Responder supports two algorithms, SHA-256
and SHA-512, and that the latter is half as fast as the former, then
a SHA-512 puzzle would have to have 1 bit less than the SHA-256
puzzle. But in fact, we know that SHA-512 is faster on 64-bit
platforms, while SHA-256 is faster on 32-bit platforms. Add some
GOST-certified hash to the mix, and the administrator’s task becomes
that much harder.
 
 If the difference in algorithms speeds is significant, then some weights
 could be
 added to algorithm definitions to make the required time to solve puzzle
 roughly the same
 on the same platform.
 
OTOH often when a 

[IPsec] Status of IKE DDoS

[Yoav Nir]

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 take place on this list, not on github.
 4. Valery has created the first pull request [2], about puzzle algorithm 
negotiation (new thread soon)

Yoav

[1] 
https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-ddos-protection.xml
 
https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-ddos-protection.xml
[2] https://github.com/ietf-ipsecme/drafts/pull/2 
https://github.com/ietf-ipsecme/drafts/pull/2

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

 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:
 AEAD always beats non-AEAD. GCM and poly1305 are both AEAD. Done with
 it.
 
 (this doesn't answer whether chacha20-poly1305 or aes-gcm should be
 considered better, but I don't know if there is a clear consensus on
 that)

Agree about AEAD before non-AEAD. As for ChaCha20 vs AES-GCM, as long as we 
don’t have evidence that on is significantly weaker than the other, I don’t 
think preferences should depend on security arguments, but on performance. 
Unfortunately , this is difficult to determine, because AES-GCM is faster on 
modern Intel processors, but slower on older processors and on ARM. It really 
depends on the application which is preferable. 

If we don’t want preference to be user-determined, I guess AES-GCM is more 
likely to be the preferred cipher for most servers.

Yoav

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

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

[Yoav Nir via RT]

 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.
 
 Because i don't think that a normal user, or even normal
 administrators and programmers is and are willing or even capable
 to understand what they are doing.

You are almost certainly far better qualified to make this decision than most 
administrators. Nevertheless, if upgrading OpenSSL from version X to version Y 
causes a ciphersuite (or TLS version) to be dropped into VULNERABLE, there are 
going to be angry phone calls from users whose browser or application has 
stopped working. It is the administrator who is going to get those phone calls, 
not you, and the decision of whether to enable an obsolete ciphersuite or to 
force the user/programmer to update is a political decision that you can’t make 
on their behalf. 

So there’s bettercrypto.org and there’s Qualys and there’s this BCP document 
that the UTA working group at the IETF is writing, but ultimately we can’t 
shove security down people’s throat - just make good tools for them and provide 
(hopefully) good advice.

Yoav


___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

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

[Yoav Nir]

 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.
 
 Because i don't think that a normal user, or even normal
 administrators and programmers is and are willing or even capable
 to understand what they are doing.

You are almost certainly far better qualified to make this decision than most 
administrators. Nevertheless, if upgrading OpenSSL from version X to version Y 
causes a ciphersuite (or TLS version) to be dropped into VULNERABLE, there are 
going to be angry phone calls from users whose browser or application has 
stopped working. It is the administrator who is going to get those phone calls, 
not you, and the decision of whether to enable an obsolete ciphersuite or to 
force the user/programmer to update is a political decision that you can’t make 
on their behalf. 

So there’s bettercrypto.org and there’s Qualys and there’s this BCP document 
that the UTA working group at the IETF is writing, but ultimately we can’t 
shove security down people’s throat - just make good tools for them and provide 
(hopefully) good advice.

Yoav

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev