Re: [Acme] Happy Birthday ACME!

Hi, Rob The first question whenever someone proposes a bis document is, of course, “are you volunteering to edit?” Jokes aside, it’s always a question of whether or not it is worth the effort. Not just for whoever is editing, but the usual effort associated with any document, such as WG

Re: [Acme] ACME leadership changes

lations on your new AD role! Thank you for your leadership in > the WG. > > Yoav (Nir): Despite these transitions, thank you for your continued service > as co-chair in the WG! > > Deb isn't going too far from ACME. After the AD transition in Brisbane, the > responsible AD fo

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

> On 14 Nov 2023, at 19:46, Michael Richardson wrote: > > > Yoav Nir wrote: >> - Although it is implied, it should be stated explicitly that >> TS_MAX_QUEUE does not mean no more child SAs with these TS ever. As >> some child SAs get deleted and perha

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

> On 13 Nov 2023, at 12:31, Sahana Prasad wrote: > > Hello, > > I've read the draft and support its adoption. To clarify, the draft is already adopted since July 2021. The question now is whether it is ready to proceed to publication. > Specifically, we (at Red Hat) have use cases where

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

Hi. I’ve read the draft. Overall, it’s similar to a non-standardized solution we did at Check Point several years ago, so I agree that it is a solution that works. Of course, since there *are* a bunch of working implementations, that is not particularly insightful. With a lot of flows, it’s

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

> On 8 Nov 2023, at 8:34, Loganaden Velvindron wrote: > > I support moving forward with hybrids as a proactively safe deployment > option. I think that supporting > only Kyber for KEX is not enough. It would make sense to have more options. > > Google uses NTRU HRSS internally: >

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

For signatures or keys in something like a certificate, I understand how you would want to have both the PQ and classical keys/sigs in the same structure, so satisfy those who want the classical algorithm and those who prefer the post-quantum. For key exchange? For the most part a negotiation

Re: [TLS] [EXT] Re: What is the TLS WG plan for quantum-resistant algorithms?

> On 7 Nov 2023, at 0:29, Blumenthal, Uri - 0553 - MITLL > wrote: > > Do we want rfc describing the final NIST standards? And for which? I'm ok > with that — in this order of priority: ml-kem, ml-dsa, slh-dsa. > > Probably yes, and in the order you described. Sure, as long as by

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

> On 6 Nov 2023, at 21:44, Watson Ladd wrote: > > > > On Mon, Nov 6, 2023, 10:07 AM Kris Kwiatkowski > wrote: >> So, based on FIPS 140-3 I.G., section C.K., resolution 5, [1]. "SP800-186 >> does not impact the curves permitted under SP 800-56Arev3. Curves that

Re: [Lsr] Secdir last call review of draft-ietf-lsr-ip-flexalgo-11

> On 16 May 2023, at 10:25, Peter Psenak wrote: > > Yoav, > > thanks for comments, please see inline: > > > On 15/05/2023 21:36, Yoav Nir via Datatracker wrote: >> Reviewer: Yoav Nir >> Review result: Has Nits >> Hi. >> I have reviewed thi

[Lsr] Secdir last call review of draft-ietf-lsr-ip-flexalgo-11

Reviewer: Yoav Nir Review result: Has Nits Hi. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors

[IPsec] Scheduling for London

Hi, folks. As you know, we have a 90-minute session on Wednesday, November 9th at 15:00. In addition to all the document status and solemn recitation of the Note Well, we have so far received 4 requests for agenda time: From Hang Shi about draft-ls-6man-ipcomp-exclude-transport-layer, a

Re: [TLS] Can flags be responded to with an extension?

at 19:21, Benjamin Kaduk wrote: > > Hi Ekr, > > On Mon, May 09, 2022 at 08:56:26AM -0700, Eric Rescorla wrote: >> On Mon, May 9, 2022 at 8:43 AM Benjamin Kaduk > 40akamai@dmarc.ietf.org> wrote: >> >>> On Mon, May 09, 2022 at 06:10:43PM +0300, Yoav Nir

Re: [TLS] Can flags be responded to with an extension?

> On 14 Apr 2022, at 1:51, Benjamin Kaduk > wrote: > > On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote: >> Consider the case where the client wants to offer some capability that >> the server then responds to with real data, rather than just an >> acknowledgement. >> >> For

[IPsec] Tomorrow's SAAG meeting

Hi all In case you missed it, tomorrow's SAAG meeting will feature an "Introduction to IPSec" (yes! with a capital S) by Paul Wouters. See you all there Yoav ⁣Sent from my phone ​___ IPsec mailing list IPsec@ietf.org

Re: [TLS] tlsflags and "responses"

Hi. I have merged the PR following review and proposed changes by Chris and Martin Thomson. The only point that remains open is Ekr’a suggestion to allow (require?) sending the extension when empty. Yoav > On 22 Feb 2022, at 7:35, Yoav Nir wrote: > > I have just submitted PR #20

Re: [TLS] tlsflags and "responses"

I have just submitted PR #20 to allow unacknowledged flags. It is a rewrite of section 3 (rules) https://github.com/tlswg/tls-flags/pull/20 It still requires that the flag extension not be sent when empty. Let me know if that’s a problem as well.

Re: [TLS] IANA Registry for TLS-Flags

So now that that is settled, publish a new draft? > On 13 Dec 2021, at 21:19, Martin Thomson wrote: > > > > On Tue, Dec 14, 2021, at 01:47, Salz, Rich wrote: >>> How about we split the difference and go with the first 0-15 flags for >>> standards action? We can keep the initial value of 8

Re: [TLS] IANA Registry for TLS-Flags

Well, that’s two voices for Martin’s PR and just me liking the convoluted text that I wrote. Chairs, care to call consensus? Yoav > On 7 Dec 2021, at 23:21, Yoav Nir wrote: > > Hi. > > We have one outstanding issue about the TLS-Flags draft. It’s about the IANA >

[TLS] IANA Registry for TLS-Flags

Hi. We have one outstanding issue about the TLS-Flags draft. It’s about the IANA registry. The way the extension is defined, low identifiers for flags result in shorter extension encoding. For this reason, we want the most popular flags to have low numbers. This is especially true for flags

Re: [IPsec] Cost-efficient quantum-resistant DoS protection

> On 10 Nov 2021, at 16:41, Michael Richardson wrote: > > > Yoav Nir wrote: >>>> Tero Kivinen wrote: >>>>>> Even without surpassing the 64KB limit, this must be a concern. >>>>>> IKEv2's cookie mechanism and puzzles try to incre

Re: [IPsec] Cost-efficient quantum-resistant DoS protection

> On 1 Nov 2021, at 13:07, Valery Smyslov wrote: > > Hi Michael, > >> Tero Kivinen wrote: Even without surpassing the 64KB limit, this must be a concern. IKEv2's cookie mechanism and puzzles try to increase the cost of the attacker per each connection. Now, an attacker must

[OAUTH-WG] Secdir last call review of draft-ietf-oauth-iss-auth-resp-02

Reviewer: Yoav Nir Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG

Re: [TLS] tls-flags: abort on malformed extension

Hi. I updated the PR. If there are no further objections, I will commit and submit a new version in time for the submission deadline. Yoav > On 7 Oct 2021, at 21:37, Yoav Nir wrote: > > Since I prefer to have the discussion in a single place, I’m copying below a > comm

Re: [TLS] tls-flags: abort on malformed extension

Since I prefer to have the discussion in a single place, I’m copying below a comment by David Benjamin from GitHub: > On 28 Aug 2021, at 23:36, Yoav Nir wrote: > > Hi. > > To address Michael StJohns comment from 19-July, I submitted PR #12: > > https://github.com/tl

[Acme] Interim Meeiting Minutes

Hi. I’ve posted the minutes to datatracker: https://datatracker.ietf.org/meeting/interim-2021-acme-01/materials/minutes-interim-2021-acme-01-202109291400-00 Let me know if

[TLS] tls-flags: abort on malformed extension

Hi. To address Michael StJohns comment from 19-July, I submitted PR #12: https://github.com/tlswg/tls-flags/pull/12 What is says is that any implementation receiving a malformed tls_flags extensions should abort the handshake. The text provides a

[IPsec] Publication has been requested for draft-ietf-ipsecme-ikev2-intermediate-07

Yoav Nir has requested publication of draft-ietf-ipsecme-ikev2-intermediate-07 as Proposed Standard on behalf of the IPSECME working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate

Re: [TLS] WGLC for draft-ietf-tls-flags

Thanks for the review. Comments inline. > On 19 Jul 2021, at 2:26, Michael StJohns wrote: > > On 7/16/2021 7:55 PM, Christopher Wood wrote: >> This is the second working group last call for the "A Flags Extension for >> TLS 1.3" draft, available here: >> >>

Re: [TLS] WGLC for draft-ietf-tls-flags

> On 22 Jul 2021, at 21:35, Viktor Dukhovni wrote: > > On Fri, Jul 16, 2021 at 04:55:49PM -0700, Christopher Wood wrote: > >> This is the second working group last call for the "A Flags Extension for >> TLS 1.3" draft, available here: >> >>

Re: [Acme] Changes in ACME WG leadership team

Welcome aboard, Deb! > On 9 Jul 2021, at 19:26, Roman Danyliw wrote: > > Hi! > > To follow up on the announcement during IETF 109, after 6 years of leading > the ACME WG from the very first BoF, Rich will be stepping down as co-chair. > Under his stewardship, a working group was formed,

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

[no hats] I don’t want to start (or resume) a religious holy war about uppercase MUSTs, but they’re usually about protocol compliance. What people should (not SHOULD) do with their systems is not subject to requirements language, because the IETF does not engineer administrators. What? You are

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

ote: > > > I sent substantive comments on this draft to the list on May 6th of this > year. They were not addressed so they apply to this WGLC. > > Dan. > > On 6/26/21 1:38 AM, Yoav Nir wrote: >> Hi, all. >> >> Although this draft is really new,

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

Forgot to add a link to the draft: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic/ <https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic/> > On 26 Jun 2021, at 11:38, Yoav Nir wrote: > > Hi, all. > > Although this draft

[IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

Hi, all. Although this draft is really new, having been submitted in April of this year, its predecessor draft has been under discussion since March of 2019. This begins a 2-week WGLC. Please read the draft and post comments to the list. Since this is rather new, short messages in the vein of

[Acme] Publication has been requested for draft-ietf-acme-dtnnodeid-04

Yoav Nir has requested publication of draft-ietf-acme-dtnnodeid-04 as Proposed Standard on behalf of the ACME working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/ ___ Acme mailing list Acme

Re: [Acme] WGLC for ACME Integrations

be to tell teh authors that the WG doesn’t seem to care much for this, and advise them to turn to the ADs to ask to submit this as individuals. Yoav > On 31 Mar 2021, at 22:50, Yoav Nir wrote: > > Hi. > > This starts a WGLC for the subject draft entitled “ACME Integrations. The

Re: [Acme] WGLC for ACME DTN Node ID

Thanks to Russ Housley and Ryan Sleevi for the reviews. Thanks to the authors for the revised version. This is not a great showing in terms of quantity of review, but the quality is sufficient. I will write the shepherd write-up and submit. Yoav > On 31 Mar 2021, at 22:50, Yoav Nir wr

[Acme] WGLC for ACME DTN Node ID

Hi. This starts a WGLC for the subject draft entitled “Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension”. The call will end at EOD Monday, April 19th, 2001. The document has been with the WG since last August, and has received too

[Acme] WGLC for ACME Integrations

Hi. This starts a WGLC for the subject draft entitled “ACME Integrations. The call will end at EOD Monday, April 19th, 2001. The document has been with the WG since last January, and has received some review. Following the closing of the last two issues, the authors believe and the sense of

Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

gy is not encumbered at all so, yea, let's do it. > > If an individual draft was to appear would the WG adopt it as a work item? Up to the WG, but I would support it. Yoav > > regards, > > Dan. > > On 2/28/21 1:47 PM, Yoav Nir wrote: >> IIRC the license has all

Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

IIRC the license has allowed OCB to be used for TLS for several years. They haven’t taken it up. There are no AES-OCB ciphersuites inhttps://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-4

Re: [TLS] Flags extension and announcing support

OK. I think we have as much consensus as we’re likely to get. I’ve updated the patch branch and PR to reflect this. Yoav > On 22 Jan 2021, at 7:45, Martin Thomson wrote: > > On Fri, Jan 22, 2021, at 16:16, Yoav Nir wrote: >> See this PR: https://github.com/tlswg/tls-flags/pull/

[TLS] Flags extension and announcing support

Hi. See this PR: https://github.com/tlswg/tls-flags/pull/5 The PR is for clarifying what TLS messages may carry the flags extension. So any message that can carry an extension, can carry a flags extension (if there are flags defined for that

Re: [TLS] TLS Flags Open Question

As all (OK, both) of the responses have been supportive, I have created a pull request: https://github.com/tlswg/tls-flags/pull/5 <https://github.com/tlswg/tls-flags/pull/5> Yoav > On 5 Dec 2020, at 17:04, Yoav Nir wrote: > > Hi. > > At IETF 108 a question was raise

[TLS] TLS Flags Open Question

Hi. At IETF 108 a question was raised about The TLS Flags extension. What payloads on the server side can include this extension? The “candidates” are ServerHello, EncryptedExtensions, Certificate, and NewSessionTicket. The only one that is controversial here (I think) is ServerHello,

Re: [I2nsf] Request for Online Meeting for I2NSF WG Rechartering

pwd=RHpTUWpMVE42VFkzV1RWd0F5ZXRxZz09> Linda & Yoav > On 18 Nov 2020, at 14:02, Yoav Nir wrote: > > Hi. > > I\ve set a Zoom meeting for December 3rd. The link is below: > https://Dell.zoom.us/j/97095207458?pwd=RHpTUWpMVE42VFkzV1RWd0F5ZXRxZz09 > <http

Re: [I2nsf] Request for Online Meeting for I2NSF WG Rechartering

support for this proposed new work.  Ideally, there were would be excitement and willingness to implement from beyond the current set of authors on the inflight documents. Regards,Roman   From: I2nsf <i2nsf-boun...@ietf.org> On Behalf Of Mr. Jaehoon Paul Jeong Sent: Wednesday, November 11, 2

Re: [I2nsf] I2NSF Re-chartering Text

NSF work > items > other than the authors of the current I2NSF WG and individual drafts. > With those people, I hope our I2NSF WG can have more energy. :) > > Thanks. > > Best Regards, > Paul > > On Mon, Nov 16, 2020 at 1:59 AM Yoav Nir <mailto:ynir.i...@gmail.com>

Re: [I2nsf] I2NSF Re-chartering Text

Hi, Paul As Roman said in a separate email message, we can’t schedule a meeting during IETF week. It also requires two weeks notice, so it anyway can only be done on the week of the 29th / first week of December. That’s not a bad thing: it will give people enough time to read the charter and

Re: [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt

> On 31 Oct 2020, at 15:12, tom petch wrote: > > On 30/10/2020 22:42, Tero Kivinen wrote: >> Roman Danyliw writes: >> It seems to me that the IANA entries for IKEv2 are incomplete. >> RFC8247 does a fine job of specifying algorithms and adding >> information such as status

Re: [I2nsf] [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt

> On 31 Oct 2020, at 15:12, tom petch wrote: > > On 30/10/2020 22:42, Tero Kivinen wrote: >> Roman Danyliw writes: >> It seems to me that the IANA entries for IKEv2 are incomplete. >> RFC8247 does a fine job of specifying algorithms and adding >> information such as status

Secdir last call review of draft-ietf-quic-invariants-11

Reviewer: Yoav Nir Review result: Ready The contents of the "security and privacy considerations" section seems to be advice for middlebox authors. I think that it may have been better to name the section something else. However, there is no information that is missing, so I don't r

[Acme] WGLC on draft-ietf-acme-star-delegation

Hello all This memo proposes a profile of the ACME protocol that allows the owner of an identifier (e.g., a domain name) to delegate to a third party access to a certificate associated with said identifier. A primary use case is that of a CDN (the third party) terminating TLS

[Acme] Meeting Materials Uploaded

Hi all, I’ve just uploaded the meeting materials for tomorrow’s session. https://datatracker.ietf.org/meeting/materials#acme If you’re presenting tomorrow, please check that your slides are there. See you all tomorrow. Yoav

Re: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting

Hi. I uploaded a PDF version to the meeting materials. Also added a list of action items for the chairs. Comments are welcome on that part as well. https://www.ietf.org/proceedings/108/minutes/minutes-108-ipsecme-00 Yoav

Re: [IPsec] Teaser for pitch talk at IETF 108

> On 24 Jul 2020, at 23:42, Michael Rossberg > wrote: > > Wiliam, Yoav, > > thanks for the comments, I’ll try to elaborate in a single mail as you are > heading in a similar direction. > >> RFC 6311 allows multiple members in a cluster of IPsec gateways to have >> independent parallel SAs

Re: [IPsec] Teaser for pitch talk at IETF 108

Hi, Michael. Thanks for bringing this to the group. > On 22 Jul 2020, at 13:26, Michael Rossberg > wrote: > > > We have been analyzing issues ESP has in current data-center networks and > came to > the conclusion that changes in the protocol could significantly improve its > behavior. Some

[IPsec] Agenda Uploaded

Please note that the times given are UTC. https://www.ietf.org/proceedings/108/agenda/agenda-108-ipsecme-00 Yoav___ IPsec mailing list IPsec@ietf.org

Re: [IPsec] ipsecme - Requested session has been scheduled for IETF 108

send your request to the chairs. Valery has already sent three requests; no need to re-send them. Tero & Yoav > On 3 Jul 2020, at 3:20, IETF Secretariat wrote: > > Dear Yoav Nir, > > The session(s) that you have requested have been scheduled. > Below is the schedul

Re: [TLS] Proposed change in TLS-Flags

> Sent: Wednesday, July 1, 2020 5:55 PM > To: Yoav Nir ; > Subject: Re: [TLS] Proposed change in TLS-Flags > > Yoav, > > I looked at the draft and the PR. I am fine with the proposed changes. > This is a short and useful draft. > > Ciao > Hannes >

Re: [TLS] Proposed change in TLS-Flags

d you elaborate on the rationale for this change please? > I was assuming that the ability for servers to send extensions not requested > by clients was useful. > > Thanks, > David > > On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir <mailto:ynir.i...@gmail.com>> wrote: > Hi >

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

[talking as another individual and co-author of RFC7296, not as the other chair] > On 18 Jun 2020, at 21:03, Tero Kivinen wrote: > > [talking as individual and one of RFC7296 authors, not as WG chair]. > > Toerless Eckert writes: >> On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters

[TLS] Consultation About Assignment of ExtensionTypes

Hi. I’m posting this on behalf of the IANA experts for the TLS registries. The IANA experts function is described in RFC 8447 [1]. We’ve received a request from ETSI to assign three ExtensionType values from the ExtensionType registry [2]. ETSI is the European Telecommunications Standards

Re: [IPsec] Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2 draft

[With chair hat on] Yes, the charter says that we are to make a guidance document. If the working group feels that it’s better to put the specification and guidance in a single document, we can work on that and clear it with the ADs. Charters can be modified. Yoav > On 29 Apr 2020, at

Re: [TLS] WGLC for "A Flags Extension for TLS 1.3"

with such a flag. > On 23 Apr 2020, at 3:07, Martin Thomson wrote: > > On Wed, Apr 22, 2020, at 05:31, Yoav Nir wrote: >>> Third, more substantially, and invalidating the above, I don't think that >>> we should make flags introduce a new style of negotiation just because it

Re: [TLS] WGLC for "A Flags Extension for TLS 1.3"

Inline... > On 7 Apr 2020, at 1:39, Martin Thomson wrote: > > I like this work, but I don't believe this to be ready yet. > > S1 > None of the current proposed extensions are such that the server > indicates support without the client first indicating support. So as > not to preclude

[IPsec] Holding a virtual interim meeting. Or not

Hi all. As you know, the in-person IETF meeting in Vancouver has been cancelled. There is a reduced schedule for virtual meetings [1], but it does not include IPsecME. The IESG chair has published a recommended schedule [2] for the working groups to hold virtual meetings in April instead of

[Acme] Holding a virtual interim meeting. Or not

Hi all. As you know, the in-person IETF meeting in Vancouver has been cancelled. There is a reduced schedule for virtual meetings [1], but that does not include ACME. The IESG chair has published a recommended schedule [2] for the working groups to hold virtual meetings in April instead of

Re: [Acme] IETF 107; agenda

I thought it was a possibility to have the week consist of all virtual > meetings. Or has that been totally removed from the table? Some of us like > that option as we've already blocked that week in our calendars. > > On Tue, Mar 10, 2020 at 3:07 PM Yoav Nir <mailto:yni

Re: [Acme] IETF 107; agenda

> On 9 Mar 2020, at 17:11, Salz, Rich wrote: > > Yaron and I cannot attend and will be remote. We have volunteers to act as > chairs for us (on CC). Looking at the list below, it seems reasonable to > cancel our session. PLEASE POST IF YOU DISAGREE. Of course "they" may > decide to

Re: [Acme] IETF 107; agenda

…and Yoav won’t be there either. No idea about Yaron. > On 9 Mar 2020, at 17:11, Salz, Rich wrote: > > Yaron and I cannot attend and will be remote. We have volunteers to act as > chairs for us (on CC). Looking at the list below, it seems reasonable to > cancel our session. PLEASE POST IF

[Acme] The session in Vancouver - Looking for a volunteer

Hi As it turns out, both Rich and I will not be able to attend IETF 107 due to company and government (in my case) restrictions on travel. For now we hope not to cancel the ACME session. Since neither of us is going to be on-site, we are looking for a volunteer to sling the slides, send

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

> On 26 Feb 2020, at 19:56, Michael Richardson wrote: > > > Yoav Nir wrote: >> The draft says “IPsec tunnel mode is required ”, so it’s not >> transport. What goes in the TS payloads? > > TSi=HostA-LL/128, TSr=HostB-LL/128, Protocol = GRE(47) or IPIP(41) If

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

The draft says “IPsec tunnel mode is required ”, so it’s not transport. What goes in the TS payloads? > On 26 Feb 2020, at 3:20, Michael Richardson wrote: > > >> Michael: Yoav talked about the non-GRE case. > > In the non-GRE case, then it's just IPIP-over-IPSEC-transport mode. > Which is

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

Hi, Toerless. I trimmed below most of your background info. > On 24 Feb 2020, at 21:50, Toerless Eckert wrote: > > [hope its fine to cross-post ipsec and ipsecme given how one is concluded, > but may have > more long-time subscribers] ipsec is this group’s mailing list. I don’t know that

[TLS] tls-flags Guidance on Allocating Bits

Hi Following the discussion last month, especially my message from 31-Jan [1], I’ve submitted a PR [2] for guidance on allocating the TLS flags with the goal to minimize the size of the typical extension. Please comment here or in github. Yoav Nir [1] https://mailarchive.ietf.org/arch/msg

Re: [TLS] New direction for TLS?

> On 14 Feb 2020, at 22:03, Benjamin Kaduk wrote: > > Hi Mike, > > On Fri, Feb 14, 2020 at 09:46:56AM -0500, Michael D'Errico wrote: >> Hi, >> >> It's been a long time since I posted to this list but saw that the charter >> is being updated and wanted to share an idea I had a while ago but

[IPsec] Publication has been requested for draft-ietf-ipsecme-ipv6-ipv4-codes-04

Yoav Nir has requested publication of draft-ietf-ipsecme-ipv6-ipv4-codes-04 as Proposed Standard on behalf of the IPSECME working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes

Re: [TLS] Feedback on draft-ietf-tls-tlsflags

> On 31 Jan 2020, at 14:26, Hubert Kario wrote: > > On Thursday, 30 January 2020 21:08:39 CET, Stephen Farrell wrote: >> >> On 30/01/2020 17:57, Yoav Nir wrote: >>> Hi folks. >>> In case you’re not following GitHub, there was an issue with a brief &g

Re: [TLS] Feedback on draft-ietf-tls-tlsflags

> On 30 Jan 2020, at 22:08, Stephen Farrell wrote: > > > > On 30/01/2020 17:57, Yoav Nir wrote: >> Hi folks. >> >> In case you’re not following GitHub, there was an issue with a brief >> discussion ([1]) and a resulting pull request ([2]). >> &g

Re: [TLS] Feedback on draft-ietf-tls-tlsflags

Hi folks. In case you’re not following GitHub, there was an issue with a brief discussion ([1]) and a resulting pull request ([2]). If there are no objections by late next week, I will merge the PR. Yoav [1] https://github.com/tlswg/tls-flags/issues/1 [2]

Re: [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06

ote: > > > <#secure method=pgpmime mode=sign> > > Yoav Nir via Datatracker wrote: > >> The draft is short and to the point and easy to understand. The security >> considerations (and privacy considerations!) sections are well written and >> c

[6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06

Reviewer: Yoav Nir Review result: Has Nits The draft is short and to the point and easy to understand. The security considerations (and privacy considerations!) sections are well written and cover everything. I'm just missing one clause. The first paragraph reads: All of the contents

Re: [IPsec] [Last-Call] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard

Hi, Paul > On 11 Dec 2019, at 20:03, Paul Hoffman wrote: > > On 11 Dec 2019, at 8:23, Salz, Rich wrote: > >> We are seeing a flurry of these kind of “post quantum protection” things. > > This is the only one I have seen that is a method, not a new key exchange > algorithm. It is

[I2nsf] Publication has been requested for draft-ietf-i2nsf-sdn-ipsec-flow-protection-07

Yoav Nir has requested publication of draft-ietf-i2nsf-sdn-ipsec-flow-protection-07 as Proposed Standard on behalf of the I2NSF working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection

[Ace] Secdir telechat review of draft-ietf-ace-cwt-proof-of-possession-11

Reviewer: Yoav Nir Review result: Ready This is the second secdir review of this document. I'm reviewing version -11. The previous review was of version -08. All my concerns were addressed, except one: I still think it's strange that the Introduction section is an exact repeat of the Abstract

Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs

I have read the -01 version of this draft. I believe it addresses a useful use case and that the solution presented there is a good starting point. I support its adoption. Yoav > On 26 Oct 2019, at 18:17, Tero Kivinen wrote: > > So this is fast (one week) adoption call for the >

Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT)

Hi, Éric. Please see inline. > On 11 Oct 2019, at 10:02, Éric Vyncke via Datatracker > wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-ipsecme-implicit-iv-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses

[Ace] Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08

Reviewer: Yoav Nir Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG

[regext] Secdir telechat review of draft-ietf-regext-epp-fees-18

Reviewer: Yoav Nir Review result: Has Nits The changes in revision -17 are fine. I would still like to have it stated that financial information is not at risk of leaking because the account information of a customer is only sent in communications with that customer. The Security Considerations

Re: [regext] Secdir last call review of draft-ietf-regext-epp-fees-16

ote: > > Good Morning, > > Thank you for your comments Yoav, please see my responses below. A new > version of the draft will be published shortly and will address all of the > review comments that needed edits. > > > Thanks > Roger > > -----Original Messag

Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt

f the Transport Layer Security WG of the IETF. >> >>Title : A Flags Extension for TLS 1.3 >>Author : Yoav Nir >> Filename: draft-ietf-tls-tlsflags-00.txt >> Pages : 6 >> Date: 2019-08-12 &g

Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt

019, at 20:48, 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 Transport Layer Security WG of the IETF. > >Title : A Flags Extension for TLS 1.3 >

[I2nsf] Publication has been requested for draft-ietf-i2nsf-capability-05

Yoav Nir has requested publication of draft-ietf-i2nsf-capability-05 as Proposed Standard on behalf of the I2NSF working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability/ ___ I2nsf mailing list

[I2nsf] Fwd: New Version Notification for draft-nir-i2nsf-ipsec-dc-prof-00.txt

t > Date: 23 July 2019 at 23:25:52 GMT-4 > To: "Yoav Nir" > > > A new version of I-D, draft-nir-i2nsf-ipsec-dc-prof-00.txt > has been successfully submitted by Yoav Nir and posted to the > IETF repository. > > Name: draft-nir-i2nsf-ipsec-dc-prof > Re

[TLS] Fwd: New Version Notification for draft-nir-tls-tlsflags-02.txt

tps://en.wikipedia.org/wiki/Law_of_triviality#Examples> > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-nir-tls-tlsflags-02.txt > Date: 23 July 2019 at 23:22:50 GMT-4 > To: "Yoav Nir" > > > A new ve

[IPsec] Heads up: IDR meeting on Wednesday

Hi This may be of interest to IPsec folks. The IDR working group is meeting tomorrow and has several IPsec-related items on its agenda: Secure EVPN - where BGP is used instead of IKEv2 to key IPsec and distribute policy. BGP Signaled IPsec Tunnel Configuration - where IKEv2 is configured by

Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

ld > act in this situation to ensure that the consistence of the > network is preserved despite all the possible delays etc. > > Regards, > Valery. > > > From: Rafa Marin Lopez > Sent: Monday, July 22, 2019 6:11 PM > To: Valery Smyslov > Cc: Rafa Marin Lopez ; Yoav Nir ;

Re: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

ld > act in this situation to ensure that the consistence of the > network is preserved despite all the possible delays etc. > > Regards, > Valery. > > > From: Rafa Marin Lopez > Sent: Monday, July 22, 2019 6:11 PM > To: Valery Smyslov > Cc: Rafa Marin Lopez ; Yoav Nir ;

  1   2   3   4   5   6   7   8   9   10   >