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 ;

Re: [Acme] Slides for tomorrow.

It’s now past 11:00 PM and we still don’t have slides for telephony, TLS-ALPN, and STAR delegation. What’s up with that? Rich & Yoav > On 21 Jul 2019, at 12:19, Yoav Nir wrote: > > Hi, presenters. > > The meeting is tomorrow morning: > https://datatracker.ietf.org

[Acme] Slides for tomorrow.

Hi, presenters. The meeting is tomorrow morning: https://datatracker.ietf.org/meeting/105/materials/agenda-105-acme Please send your slides by EOD today, and also tell me who will be presenting. We want to have the slides up

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

Hi, Valery [no hats] Thanks for that. I think this demonstrates that the current document is not enough and we will need some follow-up documents explaining when to use either case. I don’t think it’s very useful for the controller to distribute a policy (SPD entries) but no SAs (SAD

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

Hi, Valery [no hats] Thanks for that. I think this demonstrates that the current document is not enough and we will need some follow-up documents explaining when to use either case. I don’t think it’s very useful for the controller to distribute a policy (SPD entries) but no SAs (SAD

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

Thanks for getting this done and published. We will wait with requesting publication until the I2NSF session next week. Between now and then, please re-read the draft and send a message to the list is something is seriously wrong. Barring any such shouting, we will request publication right

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

Thanks for getting this done and published. We will wait with requesting publication until the I2NSF session next week. Between now and then, please re-read the draft and send a message to the list is something is seriously wrong. Barring any such shouting, we will request publication right

Re: [Acme] Agenda for IETF 105

igure > that out according to interest. > > https://tools.ietf.org/html/draft-moriarty-acme-overview-00 > <https://tools.ietf.org/html/draft-moriarty-acme-overview-00> > > Best regards, > Kathleen > >> >> Thanks, >> Owen >> >>

Re: [bess] Can we have the IPSEC related drafts discussion before Friday during IETF 105?

Me too. If it doesn’t collide with ACME, I2NSF, LAKE, IPSECME, or TLS I’m around. > On 1 Jul 2019, at 21:14, Paul Wouters wrote: > > On Mon, 1 Jul 2019, Linda Dunbar wrote: > >> Hope we can have a face to face meeting discussing IPSEC related drafts in >> IETF105. >> I have hard conflict

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

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

Re: [I2nsf] IPR Statements about I2NSF documents

n. We will raise this issue one more time at the meeting, just to make sure everyone has been heard from. Thanks, Linda & Yoav > On 6 Jun 2019, at 20:27, Yoav Nir wrote: > > Hi > > Yesterday we got 5 IPR statements ([1], [2], [3], [4], [5]) related to the > following

Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX

In the days when I had an IKEv2 implementation, NO_PROPOSAL_CHOSEN was the go-to error code for everything the Responder didn’t like; wrong algorithms, wrong transforms (like transport instead of tunnel), unknown peer, INVALID_SYNTAX meant something like malformed packet. > On 20 Jun 2019, at

[I2nsf] IPR Statements about I2NSF documents

Hi Yesterday we got 5 IPR statements ([1], [2], [3], [4], [5]) related to the following drafts respectively: draft-ietf-i2nsf-nsf-facing-interface-dm draft-ietf-i2nsf-nsf-monitoring-data-model draft-ietf-i2nsf-capability-data-model draft-ietf-i2nsf-registration-interface-dm

Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-capability-data-model

There’s a bunch of disclosures with those terms. We’ll start a thread about this later today. > On 6 Jun 2019, at 6:53, Paul Wouters wrote: > > > On Jun 5, 2019, at 23:05, Mr. Jaehoon Paul Jeong > wrote: > >> Hi Linda and Yoav, >> As a coauthor, I am aware of

Re: [I2nsf] [yang-doctors] Need YANG Doctor reviewing the YANG module of draft-ietf-i2nsf-sdn-ipsec-flow-protection which I2NSF is about to call WGLC

description “The acceptable numbers are defined in IANA > Registry - Internet Key Exchange Version 2 (IKEv2) Parameters - IKEv2 > Transform Type 1 - Encryption Algorithm Transform IDs"; > } > > Is this reasonable? > > >> El 5 abr 2019, a las 20:13

Re: [TLS] A flags extension

I think I only allow the server to set bits that had been set by the client. A server that supports this extension and also supports at least one of the flag-type features that use this extension and that were declared by the ClientHello extension SHALL send this extension with the

Re: [TLS] A flags extension

> On 27 Mar 2019, at 12:26, Daniel Kahn Gillmor wrote: > > On Wed 2019-03-27 10:52:20 +0100, Nikos Mavrogiannopoulos wrote: >> Right. What about defining a set of extensions (e.g., 2 extensions) of >> flags as: >> >> struct { >> uint64 flags; >> } Flags; > > If we're going to be doing this

Re: [TLS] A flags extension

> On 26 Mar 2019, at 18:49, Hubert Kario wrote: > > On Tuesday, 26 March 2019 16:38:11 CET Yoav Nir wrote: >>> On 26 Mar 2019, at 14:45, Hubert Kario wrote: >>> >>> On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote: >>>> Hi. Today at th

Re: [TLS] A flags extension

> On 26 Mar 2019, at 14:45, Hubert Kario wrote: > > On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote: >> Hi. Today at the TLS meeting, there was a discussion at the mic about 1-bit >> extensions that only serve to indicate support for an optional feat

Re: [TLS] A flags extension

> On 26 Mar 2019, at 12:05, Peter Gutmann wrote: > > Yoav Nir writes: > >> Are we really worried that we’re going to have more than 255 optional >> features for TLS? > > You're new here aren't you? > No, but I’m looking at the TLS registries ( htt

Re: [TLS] A flags extension

> On 26 Mar 2019, at 10:35, Nikos Mavrogiannopoulos wrote: > > On Tue, 2019-03-26 at 10:11 +0100, Yoav Nir wrote: >>> On 26 Mar 2019, at 9:06, Martin Thomson wrote: >>> >>> This needs more space for each flag. 8 bits is a pretty small >>&g

Re: [TLS] A flags extension

> On 26 Mar 2019, at 9:06, Martin Thomson wrote: > > This needs more space for each flag. 8 bits is a pretty small space. If you > are concerned with the size of the result, we have some variable-length > integer encodings you could try. Ah, the beautiful variable length encodings. Like:

[TLS] A flags extension

Hi. Today at the TLS meeting, there was a discussion at the mic about 1-bit extensions that only serve to indicate support for an optional feature. EKR commented that such extensions take 4 bytes each and that maybe we need to replace them with a flags extension. So I threw together a quick

[TLS] Review of draft-ietf-tls-tls13-cert-with-extern-psk-00

Hi. I’ve read this draft. For the most part it seems fine, but I have a few editorial nits: Abstract: I realize that all of section 3 is dedicated to motivation, but there really needs to be something in the abstract. Otherwise, I’m reading “authenticate with a combination of a certificate

Re: [TLS] Concerns with draft-kinnear-tls-client-net-address

> On 25 Mar 2019, at 19:38, Hubert Kario wrote: > > On Monday, 25 March 2019 19:31:24 CET Yoav Nir wrote: >>> On 25 Mar 2019, at 19:23, Hubert Kario wrote: >>> >>> On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote: >>>> Yeah, so this looks

Re: [TLS] Concerns with draft-kinnear-tls-client-net-address

> On 25 Mar 2019, at 19:23, Hubert Kario wrote: > > On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote: >> Yeah, so this looks very much like the IKE mechanism (the draft even says >> so) >> >> In IKE the reason for this is to detect NAT because IPsec

Re: [TLS] Concerns with draft-kinnear-tls-client-net-address

Yeah, so this looks very much like the IKE mechanism (the draft even says so) In IKE the reason for this is to detect NAT because IPsec does not traverse NAT. We need to detect the NAT so as to choose an IPsec variant that traverses NAT. If the server (or IKE Responder) lies, you might use the

Re: [Acme] IETF 104 Agenda

Hi Rifaat. We only have one hour in total.  It's about 5 minutes for the administrative stuff, another 10 for status and reconfirming STAR, and maybe 5-10 for status of other things. The rest (about 40 minutes) is for device attestation and client certs. ⁣Sent from my phone ​

Re: [Acme] RFC 8555 on Automatic Certificate Management Environment (ACME)

Starting work on the champagne & ticker-tape slide for the meeting. Thanks everyone for all the work. > On 11 Mar 2019, at 23:44, Richard Barnes wrote: > > Thanks to everyone for your work on this! > > On Mon, Mar 11, 2019 at 5:08 PM > wrote: > A new

Re: [Acme] New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

> On 18 Jan 2019, at 1:20, Richard Barnes wrote: > > "Whatever you do, contemplate death" > — Seneca He must have been lots of fun at parties. Yoav ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [IPsec] On marking algorithms obsolete in IANA registries

Hi, Paul I think we need an RFC to at least categorize the algorithms, unless we want the IANA registry to have stuff like “SHOULD-“ and “MAY+: > On 18 Dec 2018, at 6:14, Paul Wouters wrote: > > > Recently we had a discussion about mapping IANA entries to a yang model, > and the question

Re: [IPsec] replacing PSKs: CFRG and PAKE

Hi, Valery > On 12 Dec 2018, at 11:02, Valery Smyslov wrote: > >>> I see this as a social issue, not a technical one. We can't prevent >>> administrators from being careless, either with PSKs or with passwords. >> >> We can make more secure deployments easier. >> >> If the only change on the

Re: [I2nsf] [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1)

A couple of remarks (with no hats) If we’re bikeshedding the names, I think the difference is that in one case the two NSFs generate traffic keys between themselves, and in the other it is the controller that generates the keys for them. So how about “distributed keying” vs “centralized

Re: [I2nsf] Reviewing sdn-ipsec-flow-protection

Thanks, Rafa. Just one response below. > On 14 Nov 2018, at 11:30, Rafa Marin-Lopez wrote: > > Hi Yoav: > >> El 8 nov 2018, a las 17:11, Yoav Nir > <mailto:ynir.i...@gmail.com>> escribió: >> >> Hi, all >> >> As discussed in the r

Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

> On 9 Nov 2018, at 13:40, Viktor Dukhovni wrote: > >> On Nov 9, 2018, at 1:19 AM, Peter Gutmann wrote: >> >>> Well, ECDH keys (not really ECDSA) can do key agreement, and EC keys can be >>> used for encryption with ECIES. >> >> Sure, in theory, but in practice I've never seen an (EC)DH

[I2nsf] Reviewing sdn-ipsec-flow-protection

Hi, all As discussed in the room, we need some reviewers for the sdn-ipsec-flow-protection draft ([1]) While any comments on any part of the document are welcome, I would like people to concentrate on the following issues: The YANG model in Appendix A Some of the crypto seems obsolete

[Acme] ACME implementation (was: Re: Draft minutes)

[changing the subject] That’s great, Marcos. We currently don’t have a list of implementations. If you want, you can start one. Good places for such a list could be: The GitHub project wiki: https://github.com/ietf-wg-acme/acme/wiki or The tools wiki: https://trac.ietf.org/trac/acme If you

[Acme] Authority Token at today's meeting

Hi, all We have a slot on our agenda reserved for the authority token drafts ([1],[2]) Who is going to present? And please send the slides. If the authors do not intend to present, please at least send a status update to the list or the chairs. Thanks Rich & Yoav

[IPsec] Heads Up: I2NSF Meeting Today

Hi all FYI: The I2NSF working group is meeting today immediately after IPsecME and in the same room (convenient!) We are going to spend some time on SDN-based IPsec Flow Protection [1]. We have had some discussion in the past about Case #2, which is about provisioning traffic keys (in the

Re: [Acme] high-value definition

High-value is not synonymous with a phishing site. If anything, it is a victim of phishing sites. Paypal.com and bankofamerica.com are high-value sites. paypaal.com and bank-of-america.com are

Re: [IPsec] Yoav's Comments (was RE: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes)

fy which "stuff" in 5739 you are referring to? > > The draft updates RFC7296 because it updates the behavior specified in > Section 3.15.4 of that RFC. > > Cheers, > Med > >> -Message d'origine- >> De : IPsec [mailto:ipsec-boun...@ietf.org] De la

Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes

I believe the final document should address the stuff in RFC 5739. Also, I’m not sure you need to update 7296 to add some new code points. Neither of these is a barrier for adoption. I have read the draft and support its adoption. Yoav > On 13 Oct 2018, at 3:09, Tero Kivinen wrote: > > Our

Re: [IPsec] [Technical Errata Reported] RFC7634 (5441)

This errata proposes to add the following sentence to section 4 of RFC 7634 : As with other transforms that use a fixed-length key, the Key Length attribute MUST NOT be specified. This sentence is correct. If this came up as a suggestion during WG

Re: [IPsec] Modp-12288 and Modp-16384

Hi. Since my message got lost in the overtime, I’ll say it again here. AFAIK there is very little usage of anything beyond 4096-bit groups. I don't sense a need for 16K. Engineering should be about creating what people need (or at least want). I haven’t heard anyone say they would like to

Re: [IPsec] Modp-12288 and Modp-16384

> On 18 Jul 2018, at 19:08, Graham Bartlett (grbartle) > wrote: > > Hi Tero > > I've no issues per se with this, but as per our chat in London, most VPN > consumers pick the group with the highest number (of course group24 is more > secure than group21, 24 is bigger than 21 ...!).. Hasn’t

Re: [I2nsf] [IPsec] How about simplified IKE? RE: IPsec Flow Protection @I2NSF

> On 17 Jul 2018, at 11:38, Rafa Marin-Lopez wrote: > Regarding the question about smart objects, I do not understand why a > constrained device cannot be a flow-based NSF. > I don’t think IOT devices are going to be NSFs. There is no hard definition for what a smart object is, but

Re: [IPsec] [I2nsf] How about simplified IKE? RE: IPsec Flow Protection @I2NSF

> On 17 Jul 2018, at 11:38, Rafa Marin-Lopez wrote: > Regarding the question about smart objects, I do not understand why a > constrained device cannot be a flow-based NSF. > I don’t think IOT devices are going to be NSFs. There is no hard definition for what a smart object is, but

Re: [IPsec] How about simplified IKE? RE: IPsec Flow Protection @I2NSF

ion? Issues? > > Linda Dunbar > >   <> > From: IPsec [mailto:ipsec-boun...@ietf.org <mailto:ipsec-boun...@ietf.org>] > On Behalf Of Yoav Nir > Sent: Monday, July 16, 2018 3:11 PM > To: IPsecME WG mailto:ipsec@ietf.org>> > Subject: [IPsec] IPsec Flow Prote

[IPsec] IPsec Flow Protection @I2NSF

Hi. I’d like to draw you attention to the agenda of the I2NSF working group: https://datatracker.ietf.org/meeting/102/materials/agenda-102-i2nsf-00 The I2NSF working group will meet on Wednesday after lunch. On the

Re: [IPsec] INITIAL_CONTACT in IKEv1

SA(SPI AA) —> NOT > DELETED When IC is received. > > For outgoing traffic from PEER-B, if SPI AA is chosen from SADB, will it NOT > get dropped at PEER-A with INVALID_SPI. > So does it not make sense to delete all IPSec SA’s when IC is received. > > Regards > Riyaz &

Re: [IPsec] INITIAL_CONTACT in IKEv1

> On 12 Jun 2018, at 11:53, riyaz talikoti wrote: > > Hi All, > Need help with couple of questions related to INITIAL_CONTACT in IKEv1 > > 1. Is it NOT wrong to send INITIAL_CONTACT notification in QUICK MODE? > Will it NOT end up in deleting the IKE SA(Phase 1 SA) which is being created > as

Re: [Acme] Question about finalizing an order

Hi Since you’re merging stuff, then please submit a new version of the draft ASAP. We *are* in IETF LC, and we wouldn’t want everyone to read an “old” version of the draft. Thanks Yoav > On 26 Mar 2018, at 17:52, Daniel McCarney wrote: > > PR #417 was merged. This

Re: [IPsec] Clarification on my comments during the WG about possible KE payloads > 64k

Hi, Scott. That was me. When they started talking about about PQC a decade ago, they mentioned algorithms like McEliece with public keys around 1MB. Not that this is a deal-killer. If necessary, we would come up with an IKE extension to have “jumbo-sized payloads” that had 24-bit lengths. IKE

[Acme] Wednesday meeting - minutes uploaded

Thanks to PHB for taking the minutes https://datatracker.ietf.org/meeting/101/materials/minutes-101-acme-00 Yoav___ Acme mailing list Acme@ietf.org

Re: [TLS] Breaking into TLS to protect customers

Hi, Daniel Inline... > On 19 Mar 2018, at 7:32, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: > > On Thu 2018-03-15 20:10:46 +0200, Yoav Nir wrote: >>> On 15 Mar 2018, at 10:53, Ion Larranaga Azcue <ila...@s21sec.com> wrote: >>> >>>

Re: [TLS] TLS interception technologies that can be used with TLS 1.3

before the first data record goes out. I don’t see how we can do that without interleaving it with the handshake. > On 16 Mar 2018, at 0:42, Salz, Rich <rs...@akamai.com> wrote: > > I think if we ship the keys over some kind of secure socket layer we should > be okay, right?

Re: [TLS] Breaking into TLS to protect customers

> On 15 Mar 2018, at 10:53, Ion Larranaga Azcue wrote: > > I fail to see how the current draft can be used to provide visibility to an > IPS system in order to detect bots that are inside the bank… > > On the one hand, the bot would never opt-in for visibility if it’s

Re: [TLS] TLS interception technologies that can be used with TLS 1.3

products come with their own OpenSSL package. TBH I don’t think an RFC would have that effect. Not every RFC gets implemented. > On 15 Mar 2018, at 13:38, Hubert Kario <hka...@redhat.com> wrote: > > On Thursday, 15 March 2018 05:51:31 CET Yoav Nir wrote: >> At the risk of stat

Re: [TLS] Breaking into TLS to protect customers

Hi, Rich. You are conflating customers and users. The customer that may be protected by breaking TLS in a bank’s server farm is the bank itself. An IPS system with visibility into the traffic may detect bots that are there to steal data or mine cryptocurrencies or whatever. If the customers

Re: [TLS] TLS interception technologies that can be used with TLS 1.3

At the risk of stating the obvious, it’s because server owners want to use the same OpenSSL, NSS, SChannel, or whatever you call the Java library that everybody else uses. They’re all widely used, actively maintained, and essentially free. None of these libraries support any of this

Re: [I2nsf] Calling for IETF101 I2NSF WG session agenda request. If you need remote presentations, please let us know as soon as possible

Hi, Paul That’s a total of 75 minutes, 70 of them for various drafts. So what is the intent here? Last time we had a whole bunch of presentations that were pretty much a primer on what this draft is about. Working group sessions are supposed to be about discussion, and the attendees are

Re: [websec] Question regarding RFC 6797: What is the proper reading of §8.3 #5

This is how I understand it: > On 1 Mar 2018, at 13:59, Svensson, Lars wrote: > > When implementing HSTS, my colleagues and I had discussions on how to > correctly interpret §8.3, #5 of RFC 6797 [1]. In our opinion the text is > ambiguous and we hope that you can help us

Re: [Acme] acme - Requested session has been scheduled for IETF 101

Hi, folks So we are going to have a 1.5 hour session in London. Anyone who needs agenda time, please send a note to Rich and me. Hope to see you all there. Yoav > On 28 Feb 2018, at 1:11, IETF Secretariat <age...@ietf.org> wrote: > > Dear Yoav Nir, > > The session(s) th

Re: [I2nsf] WG Adoption call for https://tools.ietf.org/html/draft-kim-i2nsf-nsf-facing-interface-data-model-04

it it before the I-D due. > > Thanks. > > Best Regards, > Paul > > > On Fri, Feb 16, 2018 at 4:14 AM, Yoav Nir <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> wrote: > Thanks to all who participated. > > We believe that there is rough conse

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

> On 16 Feb 2018, at 21:09, Tero Kivinen <kivi...@iki.fi> wrote: > > Yoav Nir writes: >>> 2) The privacy of the initiator's identity in the presence of a man in >>> the middle attacker is not protected. >>> >>> Today an attacker with full c

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

> On 16 Feb 2018, at 20:13, Tero Kivinen wrote: > > This item does not have charter text yet, we do have text which > explains what the problem is, but I think it requires some > reformatting to fit as charter text. > > The problem description is: > >

Re: [IPsec] Additional charter items 3/4: Labeled IPsec

> On 16 Feb 2018, at 20:06, Tero Kivinen wrote: > > This charter text was not ready during the IETF 100, we just had very > short description about the item, and I think most of the people did > not really understand it. > > The proposed charter text for this item is: > >

Re: [I2nsf] WG Adoption call for https://tools.ietf.org/html/draft-kim-i2nsf-nsf-facing-interface-data-model-04

Thanks to all who participated. We believe that there is rough consensus to adopt this document as a starting point for the group to work on. Authors, please resubmit this document as a working group document with the name draft-ietf-i2nsf-nsf-facing-interface-dm-00. Yoav (on behalf of the WG

Re: [I2nsf] WG Adoption call for https://tools.ietf.org/html/draft-jeong-i2nsf-consumer-facing-interface-dm-04

Thanks to all who participated. We believe that there is rough consensus to adopt this document as a starting point for the group to work on. Authors, please resubmit this document as a working group document with the name draft-ietf-i2nsf-consumer-facing-interface-dm-00. Yoav (on behalf of

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

> On 9 Feb 2018, at 18:40, Paul Wouters wrote: > > On Wed, 7 Feb 2018, Tero Kivinen wrote: > >> It depends. If we do not take the item as official working group >> chartered item, there are still few different options. You can either >> get it processed as AD sponsored draft,

Re: [IPsec] [Editorial Errata Reported] RFC7296 (5247)

Sorry. Resending with the correct To: and CC: lists > On 31 Jan 2018, at 7:04, Yoav Nir <ynir.i...@gmail.com> wrote: > > Hi. > > I don’t see anything wrong with the suggestion (it’s just adding “to indicate > NONE” in the last sentence). However: > A value marked “R

Re: [IPsec] [Editorial Errata Reported] RFC7296 (5247)

Hi. I don’t see anything wrong with the suggestion (it’s just adding “to indicate NONE” in the last sentence). However: A value marked “Reserved” in IANA just means that IANA should not assign it. It does not mean that it cannot appear in the protocol. Using a zero in a field to indicate no

Re: [TLS] A question for TLS middle-box/middleware vendors/implementers

Hi, Thomas Inline > On 28 Jan 2018, at 12:19, Fossati, Thomas (Nokia - GB/Cambridge, UK) > <thomas.foss...@nokia.com> wrote: > > Hi Yoav, > > Thanks for the answers - much appreciated. > > On 27/01/2018, 19:31, "Yoav Nir" <ynir.i...@gmail.com>

Re: [TLS] A question for TLS middle-box/middleware vendors/implementers

> On 27 Jan 2018, at 18:30, Fossati, Thomas (Nokia - GB/Cambridge, UK) > wrote: > > Hi TLS middle-box/middleware folks, > > If length's MSB in a D?TLS{Ciphertext,Plaintext,Compressed} record is > set, how does your software react? > > Is it going to drop the

Re: [IPsec] Dynamic PMTUD over IKEv2

> On 23 Jan 2018, at 12:29, Shibu Piriyath wrote: > > Hi All, > > We have come up with a proposal for discovering Path MTU between IPsec > head-ends dynamically using IKEv2 messages. > Please review the draft - >

Re: [I2nsf] draft-ietf-i2nsf-sdn-ipsec-flow-protection

Thanks, Benoit. Authors: Please change this in your working copy so that we can get it right in the next revision (-01) Something like: file "ietf-ip...@2018-01-08.yang” or file "ietf-ip...@2017-10-28.yang" It’s also fine to make the date earlier if

Re: [Acme] YA WGLC for draft-ietf-acme-acme

; > Hi Yoav, > > There are a few threads on the go from Sophie. Is there one in particular you > mean to reference here? Both? > > Thanks! > > > On Wed, Dec 27, 2017 at 2:15 PM, Yoav Nir <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> wrote: > I tak

Re: [TLS] TLS 1.3 : small fragments attack

> On 30 Dec 2017, at 7:03, Peter Gutmann wrote: > > Jitendra Lulla writes: > >> The client can have a rogue TLS implementation with the following intentional >> changes: >> >> 0. Choose CBC with AES256-SHA56 or any other heavier (in terms of

Re: [Acme] YA WGLC for draft-ietf-acme-acme

I take that back. Solve Sophie’s issue (from the other thread) first, and then publish a new draft. > On 27 Dec 2017, at 6:46, Yoav Nir <ynir.i...@gmail.com> wrote: > > Thank you for all who participated. > > There have been two editorial changes suggested and a

Re: [Acme] YA WGLC for draft-ietf-acme-acme

Thank you for all who participated. There have been two editorial changes suggested and accepted in the GitHub repository. As soon as a new draft is published, I think we can progress this. Thanks again. Yoav > On 14 Dec 2017, at 19:28, Yoav Nir <ynir.i...@gmail.com> wrote: > >

Re: [I2nsf] Document Action: 'Framework for Interface to Network Security Functions' to Informational RFC (draft-ietf-i2nsf-framework-10.txt)

> > Document Quality > > This framework is not directly implementable, but it underpins the work > of the working group. At least one vendor is building a system based on > the work of the working group and following this framework as an > architecture. There has also been ex

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

> On 15 Dec 2017, at 3:05, Colm MacCárthaigh wrote: > > > > On Thu, Dec 14, 2017 at 5:01 PM, Hanno Böck > wrote: > On Thu, 14 Dec 2017 16:45:57 -0800 > Colm MacCárthaigh > wrote: > >

[Acme] YA WGLC for draft-ietf-acme-acme

Hi Draft-09 is now available and has (IMO) addressed all or the outstanding issues. This starts an abbreviated WGLC for this draft. Please review the draft and send in your comments by EOD Monday the 25th. Please note that Monday the 25th is Christmas day, so don’t delay - send in your

Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-eddsa-04

> On 27 Nov 2017, at 16:09, Adam Montville wrote: > > Reviewer: Adam Montville > 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 >

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

Oh, and if you’re updating the draft anyway, you should update the references now that 8221 and 8247 have been published. Yoav > On 15 Nov 2017, at 10:30, Yoav Nir <ynir.i...@gmail.com> wrote: > > Hi, Daniel > > I think your text is confusing without the suggest

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

> so I presume we need to grab one of reserved bits in IKE header flags > > for this purpose. I admit it looks complicated, but I cannot come up > > with a simpler solution (except for not using IIV in IKEv2 at all). > > > > Regards, > > Valery

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

this case also. > > Regards, > Valery. > > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir > Sent: Monday, November 13, 2017 5:35 AM > To: IPsecME WG > Subject: [IPsec] Proposal for using Implicit IV for IKE > > Hi. > > So following Daniel’s mes

Re: [TLS] Tonight's Encrypted SNI Hangout Session

> On 14 Nov 2017, at 0:00, Tom Ritter wrote: > > Are you also interested in collecting reports of where SNI is used to > censor? Or the list of network vendors that support filtering and > manipulating traffic based on the value? I don’t think naming and shaming is a goal

[Trans] Short-term certificates side meeint

Hi As mentioned in the meeting, we’re going to have a side meeting on Thursday evening at 6 PM in the Hullet room. (Very) rough draft: https://tools.ietf.org/html/draft-nir-saag-star-00 Slides for the side meeting: https://www.dropbox.com/s/yi9cn35dk8h14te/starcons.pdf See you there. Yoav

[Acme] Slides for Thursday (was Re: Slides for the meeting tomorrow)

gt; > On Sun, Nov 12, 2017 at 9:56 PM, Yoav Nir <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> wrote: > Hi. > > Those people presenting tomorrow who have not yet sent us the slides, please > do so today. > &

[Acme] Slides for the meeting tomorrow

Hi. Those people presenting tomorrow who have not yet sent us the slides, please do so today. You know who you are. Thanks, Rich and Yoav signature.asc Description: Message signed with OpenPGP ___ Acme mailing list Acme@ietf.org

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

| > 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 13, 2017, at 10:51, Michael Richardson <mcr+i...@sandelman.ca> wrote: >> >> >> Yoav Nir <ynir.

[IPsec] Proposal for using Implicit IV for IKE

Hi. So following Daniel’s message in the room, here’s how I think we can make this work. The IKE header has a “Message ID” field that is a counter. It’s tempting to use this as a counter, same as we use the replay counter in IPsec. However, as Tero pointed out on Jabber, each such message ID

Re: [TLS] PR#1091: Changes to provide middlebox robustness

> On 8 Nov 2017, at 2:25, Watson Ladd wrote: > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar wrote: >> FWIW: In my experience middleboxes don't ossify based on what the spec says, >> they ossify based on what they see on the wire. So, if common >>

Re: [TLS] PR#1091: Changes to provide middlebox robustness

> On 8 Nov 2017, at 2:32, Salz, Rich wrote: > > ➢ Given that we're almost there, and that only really browsers are > asking for these hacks, and that even some of those were almost ready > to ship without these hacks, I don't think that this is entirely >

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

Hi, Hannes. I think it makes sense if the middlebox (whether a TLS proxy or a phone) cannot perform a MitM attack against the internal TLS. This can be achieved by having separate trust anchors for the application vs the ones used for HTTPS, specifically not including any “proxy CA

Re: [I2nsf] Request for WG Adoption Call for I2NSF Data Model Drafts

Hi, John > On 2 Nov 2017, at 7:08, John Strassner wrote: > Second, my worry is that draft-kumar is not ready. It is not an information > model; rather, it is (at best) requirements that could be turned into an > information model. In addition, it needs to be

Re: [Acme] Draft Agenda Uploaded

was editorial unless there is > any further thoughts on the technical aspects I’d be interested in seeing if > there is consensus for moving this towards LC. Given it’s a pretty simple > document this shouldn’t take much time. > >> On Oct 29, 2017, at 12:20 PM, Yoav Nir &l

[Acme] Draft Agenda Uploaded

https://datatracker.ietf.org/meeting/100/materials/agenda-100-acme/ If anything’s missing, please let us know really soon. Thanks Rich and Yoav signature.asc Description: Message signed with OpenPGP

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

And now it is. > On 29 Oct 2017, at 7:09, Paul Wouters wrote: > > On Sat, 28 Oct 2017, 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 Interface to Network Security

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