Re: [IPsec] WG Adoption call for draft-mglt-ipsecme-ikev2-diet-esp-extension

2023-12-08 Thread David Schinazi
As with the other document, I also support adoption. (Still unsurprisingly since I'm a co-author :-P ) David On Fri, Dec 8, 2023 at 9:28 AM William Atwood wrote: > I support adoption of this draft. It will be useful for the secure > exchanges in ANIMA environments (i.e., everything!),

Re: [IPsec] WG Adoption call for draft-mglt-ipsecme-diet-esp

2023-12-08 Thread David Schinazi
I also support adoption. (Unsurprisingly since I'm a co-author :-) ) David On Fri, Dec 8, 2023 at 9:27 AM William Atwood wrote: > I support adoption of this draft. It will be useful for the secure > exchanges in ANIMA environments (i.e., everything!), especially in > constrained environments.

Re: [IPsec] TCP and MOBIKE

2018-11-07 Thread David Schinazi
I'm having a hard time imagining why anyone would want to use NO_NATS_ALLOWED with TCP encapsulation. If you're encapsulating in TCP it means that there is something on path even worse than a NAT, right? Perhaps we could simply say you MUST NOT use NO_NATS_ALLOWED with TCP encaps? David On Thu,

Re: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04

2018-06-18 Thread David Schinazi
Hi, I have read and reviewed the last few revisions of the draft and I believe it is ready for publication. I also implemented Implicit IV for ChaCha20-Poly1305 and it was pretty straightforward. Thanks, David Schinazi > On Jun 18, 2018, at 09:17, Daniel Migault wrote: > > as a

Re: [IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-03.txt

2018-05-09 Thread David Schinazi
Thanks for the update, authors! I've reviewed -03 and it looks great to me. David > On May 9, 2018, at 13:09, 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

Re: [IPsec] Summary of charter discussion

2018-03-05 Thread David Schinazi
roblem statement and potential solution in London. I would personally recommend not deciding on its addition to the charter until this has been discussed. Thanks, David Schinazi > On Mar 4, 2018, at 12:18, Tero Kivinen <kivi...@iki.fi> wrote: > > There was very little discus

Re: [IPsec] Additional charter items 4/4: Mitigating privacy concerns

2018-02-16 Thread David Schinazi
Hi Yoav, responses inline. > On Feb 16, 2018, at 10:25, Yoav Nir wrote: > >> On 16 Feb 2018, at 20:13, Tero Kivinen wrote: >> >> 1) It's not possible to run a server that obfuscates IKEv2/IPsec using >> TLS. >> >> Today thanks to RFC 8229 it is

Re: [IPsec] Key rollover and IDr payload(s)

2017-11-30 Thread David Schinazi
Hi Paul, Regarding the original email, I'm not a fan of (1) as then implementations have to handle receiving two different FQDN IDr's for example. Having something like (2) where the new notify can only appear once and it explicitly is there to select the key sounds best IMHO. Regarding the

Re: [IPsec] Candidate charter text is now in wiki

2017-11-28 Thread David Schinazi
mechanism to IKEv2 that allows the initiator to only send IDi/IDr to known entities (e.g. that possess a shared secret). Thanks, David Schinazi > On Nov 16, 2017, at 22:35, mohamed.boucad...@orange.com wrote: > > Dear Tero, > > It seems that you missed this text for the addr

Re: [IPsec] Proposal for using Implicit IV for IKE

2017-11-12 Thread David Schinazi
I suspect that there was a typo and Yoav meant to include the flags for proposal 2: | Next Payload (8 bits) | Flags (8 bits) | Fragment Counter (16 bits) | Message ID (32 bits) | In that case I do prefer option 2 as it doesn't add much complexity and allows fragmentation. David > On Nov

[IPsec] Proposed new privacy items to the ipsecme charter

2017-11-12 Thread David Schinazi
. I had written up a proposed solution here: https://www.ietf.org/mail-archive/web/ipsec/current/msg11575.html <https://www.ietf.org/mail-archive/web/ipsec/current/msg11575.html> Regardless of the solution, I think there is value in adding these items to the charter. Thanks, David Sc

Re: [IPsec] Privacy attack vectors against IKEv2 and Postquantum

2017-08-16 Thread David Schinazi
anything. > On Aug 16, 2017, at 09:50, Christopher Wood <christopherwoo...@gmail.com> > wrote: > > On Wed, Aug 16, 2017 at 9:34 AM, Paul Wouters <p...@nohats.ca> wrote: >> On Mon, 14 Aug 2017, David Schinazi wrote: >> >>> [DS] I think "showin

Re: [IPsec] Privacy attack vectors against IKEv2 and Postquantum

2017-08-14 Thread David Schinazi
Thanks Paul, responses inline. > On Aug 11, 2017, at 18:23, Paul Wouters <p...@nohats.ca> wrote: > > On Fri, 11 Aug 2017, David Schinazi wrote: > >> 1) Active man-in-the-middle attack against the initiator >> An attacker that can intercept and spoof packets can

[IPsec] Privacy attack vectors against IKEv2 and Postquantum

2017-08-11 Thread David Schinazi
rties of the current draft, it also does not leak any information to any party that does not possess PPK, and it mitigates the attack vectors discussed above. What are your thoughts? Thanks, David Schinazi Apple ___ IPsec mailing list IPsec@ietf.org

Re: [IPsec] [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.txt

2017-04-03 Thread David Schinazi
Thanks for the update! I've reviewed -04 and I think the draft is ready to move forward. Regards, David Schinazi > On Mar 28, 2017, at 15:43, Daniel Migault <daniel.miga...@ericsson.com> wrote: > > Hi, > > Thank you Jim for the update. Here is the version resulting from

Re: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv

2017-03-29 Thread David Schinazi
Hello all, I strongly support adoption of this document. I have read it and implemented it. The document reads well, and allows independent implementations. I personally think Implicit IV is a great step forward for IKEv2/IPsec, even outside of IoT. Regards, David Schinazi > On Mar 29, 2

Re: [IPsec] The IPSECME WG has placed draft-mglt-ipsecme-implicit-iv in state "Call For Adoption By WG Issued"

2017-03-29 Thread David Schinazi
Hello all, I strongly support the WG adoption of this draft. Regards, David Schinazi > On Mar 29, 2017, at 14:17, IETF Secretariat <ietf-secretariat-re...@ietf.org> > wrote: > > > The IPSECME WG has placed draft-mglt-ipsecme-implicit-iv in state > Call For Adopti

Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

2017-03-12 Thread David Schinazi
Yoav, The diff looks good to me. Based on the discussion in this thread, it looks like there is consensus to not use 0 as the value for Identity. Would it make sense to reflect that in the document? The "IANA Considerations" section currently states: IANA is requested to assign a new value from

Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

2017-02-09 Thread David Schinazi
me >> consensus on this. At this point, I'm mildly in favor of a new value (5). >> >> Thanks, >> Tommy >> >>> On Feb 9, 2017, at 4:40 AM, Tero Kivinen <kivi...@iki.fi> wrote: >>> >>> Ah I noticed that my last call email had wrong d

Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

2017-02-08 Thread David Schinazi
Tero, I've reviewed this draft. I support it and believe it is ready to move forward towards becoming a standards-track RFC. Also, would it make sense to ask IANA for early assignment of the code point? Using 0 sounds reasonable to me. Minor typo in the introduction: "we define a new value

Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients

2016-12-09 Thread David Schinazi
You'll need to play DNS games if the VPN server if IPv4-only (or if your VPN config gives you a server IPv4 address to connect to). In that case you'll need to query the DNS64 server for the NAT64 prefix. Apple's IKEv2 client uses an OS-provided API to synthesize an IPv6 address from the

Re: [IPsec] meeting at IETF-95 ?

2016-01-14 Thread David Schinazi
+ 1 David > On Jan 13, 2016, at 14:51, Yoav Nir wrote: > > I believe around that time CFRG and TLS will be done with the signatures > document and rfc4492bis respectively, so we could proceed and finish > draft-ietf-ipsecme-safecurves. > > So count me as a +1 as well.