Re: [TLS] Industry Concerns about TLS 1.3

> On 23 Sep 2016, at 10:08 PM, Salz, Rich wrote: > > > Look, pretty much the entire world is being spied on by national-scale > adversaries who are recording all traffic for eventual decryption and > correlation. *Almost everyone* is having their traffic surveilled. The > problems of debugg

Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

Hi. See responses below > On 23 Sep 2016, at 10:11 PM, Mirja Kuehlewind wrote: > -- > COMMENT: > -- > > Some questions: > > 1) sec 7.1.2: If there is a puzzl

Re: [TLS] Industry Concerns about TLS 1.3

Hi, Andrew. Thank you for bringing these concerns to the list. I agree with Kenny that this is rather late, but it’s also true that I don’t think it would change the outcome of the consensus in this working group. The quest to mandate FS in TLS-using applications goes back longer than this eff

Re: [TLS] Suspicious behaviour of TLS server implementations

> On 22 Sep 2016, at 8:11 AM, Peter Gutmann wrote: > > Martin Thomson writes: > >> The advantage with deploying a new protocol is that you can be strict. If, >> for example, all of the browsers implement TLS 1.3 and are strict, then >> Amazon won't be able to deploy a buggy 1.3 implementatio

Re: [TLS] [Cfrg] 3DES diediedie

> On 8 Sep 2016, at 7:08 PM, Kyle Rose wrote: > > On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann > wrote: > The only data point I have is that every time I've tried to disable DES in > a new release (and by DES I mean single DES, not 3DES) I've had a chorus of >

Re: [TLS] SHA-3 in SignatureScheme

> On 5 Sep 2016, at 11:17 AM, Nikos Mavrogiannopoulos wrote: > > On Fri, 2016-09-02 at 10:04 -0700, Eric Rescorla wrote: > I also am not following why we need to do this now. The reason we >>> defined SHA-2 in a new RFC was because (a) SHA-1 was looking weak and (b) we had >>> to make

Re: [TLS] SHA-3 in SignatureScheme

> On 2 Sep 2016, at 10:28 PM, Blumenthal, Uri - 0553 - MITLL > wrote: > We have SHA-256 and SHA-384. > > No. By the same token we have AES-128, AES-256, ECDHE over P256, etc. > > I support adding SHA-3 to the core. > > Alternatively, feel free to throw ChaCha out and define it separately

Re: [TLS] SHA-3 in SignatureScheme

> On 2 Sep 2016, at 8:27 PM, Hubert Kario wrote: > > On Friday, 2 September 2016 12:06:55 CEST Benjamin Kaduk wrote: >> On 09/02/2016 12:04 PM, Eric Rescorla wrote: >>> On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett >> >>> > wrote: >>>On Friday, September 02, 20

Re: [TLS] TLS 1.3 -> TLS 2.0?

> On 1 Sep 2016, at 6:31 PM, Dave Garrett wrote: > > On Thursday, September 01, 2016 02:05:25 am Judson Wilson wrote: >>> I like TLS/2 aesthetically, and represents a similar level of >>> progress/reset that HTTP saw when it jumped from 1.1 to /2. >> >> What is the slash in the name all about?

Re: [TLS] TLS 1.3 -> TLS 2.0?

> On 31 Aug 2016, at 8:28 PM, Andrei Popov wrote: > >> No they don’t always look at the 16-bit field (although they might), but >> they look at you funny when you tell them that 1.0 > 3.0 and that you should >> totally disable 3.0 and prefer to use 1.2 instead. > :) True, but when this happens

Re: [TLS] TLS 1.3 -> TLS 2.0?

> On 31 Aug 2016, at 12:21 AM, Daniel Kahn Gillmor > wrote: > > On Tue 2016-08-30 16:14:06 -0400, Hubert Kario wrote: >> On Tuesday, 30 August 2016 14:19:33 CEST Dave Garrett wrote: >>> * Keep the version ID as { 3, 4 } (already weird counting; changing risks >>> more intolerance) >> >> IMNSHO

Re: [IPsec] Mirja Kühlewind's Block on charter-ietf-ipsecme-10-00: (with BLOCK)

> On 31 Aug 2016, at 3:21 PM, Tero Kivinen wrote: > > Mirja Kuehlewind (IETF) writes: >> thanks for the reply. Very helpful background info. Maybe even put >> more information in the charter text. > > I think it belongs to the actual draft, not to the charter, perhaps we > should put the draft

Re: [IPsec] Stephen Farrell's Yes on charter-ietf-ipsecme-10-00: (with COMMENT)

Hi, Stephen > On 30 Aug 2016, at 4:38 PM, Stephen Farrell wrote: > I have a suggestion about this bit of work: > > "IKEv1 using shared secret authentication was partially resistance to > quantum computers. IKEv2 removed this feature to make the protocol > more usable. The working group will a

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

TF. > >Title : Curve25519 and Curve448 for IKEv2 Key Agreement > Authors : Yoav Nir > Simon Josefsson > Filename: draft-ietf-ipsecme-safecurves-04.txt > Pages : 7 > Date: 2

Re: [IPsec] 4307bis/7321bis key sizes

> On 23 Aug 2016, at 9:32 PM, Paul Hoffman wrote: > > On 23 Aug 2016, at 10:55, Paul Wouters wrote: > >> On Mon, 8 Aug 2016, Paul Wouters wrote: >> >> I haven't heard any objection to making 128 bit key sizes MUST- and >> 256 bit key sizes MUST. > > You can hear one now. > >> Answers that ag

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

> On 8 Aug 2016, at 3:51 PM, Tero Kivinen wrote: > > Yoav Nir writes: >> Hi. >> >> New in this version: >> - A few textual changes in the Introduction (suggested by Tero) > > You seemed to skip my proposed changes for the IANA considerations > section

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

t; This draft is a work item of the IP Security Maintenance and Extensions of > the IETF. > >Title : Curve25519 and Curve448 for IKEv2 Key Agreement > Authors : Yoav Nir > Simon Josefsson > Filename:

Re: [I2nsf] draft-abad-i2nsf-sdn-ipsec-flow-protection and SD-WAN

Hi, Dave. On 22 Jul 2016, at 1:02 PM, David Carrel wrote: > I am quite interested in the notion of integrating IKE (or IKE-like) security > and functionality into the SD-WAN controller messaging. My company does this > now, though not in a standard way. All IPSEC key management comes from th

Re: [IPsec] New charter proposal

+1 > On 22 Jul 2016, at 9:35 AM, Michael Richardson wrote: > > > New charter seems fine. > > (I am pessimistic about the milestones, but I suggest changing them as needed > rather than planning to take longer.) > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =-

[I2nsf] draft-abad-i2nsf-sdn-ipsec-flow-protection and SD-WAN

Hi In addition to what we said at the meeting, I’d like to mention that what the draft is proposing seems to be a subset of what SD-WAN vendors are doing. I apologize in advance for using the terms NSF and SD-WAN gateway interchangeably. For those not familiar, Wikipedia has a so-so article abo

Re: [tcpinc] Why retain negotatiation

IIUC the idea is that the TLS work is not ended, merely suspended, and will resume once TLS 1.3 is out the door. Whether that will actually happen is of course not known. Yoav > On 16 Jul 2016, at 6:58 PM, Watson Ladd wrote: > > Dear all, > Originally negotiation was proposed because EKR want

Re: [IPsec] IETF 96 IPsecME Agenda

> On 7 Jul 2016, at 9:57 PM, Waltermire, David A. (Fed) > wrote: > > We are scheduled for 2pm - 4pm CEST on Tuesday, July 19th. The chairs need > to pull together an agenda for this meeting. Here is an early draft to get us > started: > > 10 minutes: agenda, WG status > > The following dra

Re: [TLS] judging consensus on keys used in handshake and data messages

Hi, Joe > On 6 Jul 2016, at 8:39 PM, Joseph Salowey wrote: > > We are the unenviable position of calling consensus between three choices [0]: > > - Option 1 - use the same key for both handshake and applications messages. > - Option 2 - restore a public content type and different keys. > - Opti

Re: [TLS] PR #23 for RFC4492bis

> On 4 Jul 2016, at 7:12 PM, David Benjamin wrote: > > On Mon, Jul 4, 2016 at 7:59 AM Yoav Nir <mailto:ynir.i...@gmail.com>> wrote: > > > On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara > <mailto:ilariliusva...@welho.com>> wrote: > > > > On Mo

Re: [TLS] PR #23 for RFC4492bis

> On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara wrote: > > On Mon, Jul 04, 2016 at 03:46:00PM +0300, Yoav Nir wrote: >> Hi >> >> Based on an email exchange with Nikos Mavrogiannopoulos, I’ve submitted a PR. >> >> https://github.com/tlswg/rfc4492bis/pull/

[TLS] PR #23 for RFC4492bis

Hi Based on an email exchange with Nikos Mavrogiannopoulos, I’ve submitted a PR. https://github.com/tlswg/rfc4492bis/pull/23 If there are no objections, I will accept it and submit version -08 this Friday. Thanks Yoav ___ TLS mailing list TLS@ietf.o

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

On 4 Jul 2016, at 12:44 PM, Paul Wouters wrote: > On Sun, 3 Jul 2016, Yoav Nir wrote: > >>> 3) The Internet Draft Currently under consideration is not the best >>> starting point as it assumes that post-quantum pre-shared keys are the >>> preferred solutio

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

Hi, Mark > On 3 Jul 2016, at 9:08 PM, Mark McFadden wrote: > 3) The Internet Draft Currently under consideration is not the best starting > point as it assumes that post-quantum pre-shared keys are the preferred > solution for quantum resistance. This is not obviously the case; there are a

Re: [TLS] TLS client puzzles

> On 29 Jun 2016, at 10:25 PM, Brian Smith wrote: > > Dmitry Khovratovich wrote: >> It allows cheap and memoryless verification by the server even though the >> puzzle solving guaranteely requires dozens of MB of RAM from a client > > I feel like this is impractical simply because lots of peop

Re: [IPsec] Endless stream of NAT-T keepalive probes?

All three devices also run an SSL-VPN, so you can just go to https:// to see who owns them. The first one will also tell you the vendor as they didn’t customize the landing page… > On 22 Jun 2016, at 7:11 PM, Paul Wouters wrote: > > > Hi, > > One of my machines is seeing a continous stream

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

rsus an explicit IV > > > Please let us know if that address your purpose. > > BR, > Daniel > > On Fri, Jun 10, 2016 at 2:01 AM, Yoav Nir <mailto:ynir.i...@gmail.com>> wrote: > Hi, Paul > > On 10 Jun 2016, at 5:42 AM, Paul Wouters <mailto:p.

Re: [TLS] Consensus call for keys used in handshake and data messages

Hi, Nikos > On 15 Jun 2016, at 11:00 AM, Nikos Mavrogiannopoulos wrote: > > On Mon, 2016-06-13 at 12:00 -0700, Joseph Salowey wrote: >> For background please see [1]. >> >> Please respond to this message indicating which of the following >> options you prefer by Monday June, 20, 2016 >> >> 1.

Re: [TLS] Consensus call for keys used in handshake and data messages

> On 13 Jun 2016, at 10:00 PM, Joseph Salowey wrote: > > For background please see [1]. > > Please respond to this message indicating which of the following options you > prefer by Monday June, 20, 2016 > > 1. Use the same key for handshake and application traffic (as in the current > draft

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

nd IIV=1, there will need to be an ENCR_AES_CCM_16 >> with keylength=256 and no IIV attribute. >> >> """ >> >> [1] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ >> >> -Original Message- >> From: in

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

> On 10 Jun 2016, at 5:39 PM, Yaron Sheffer wrote: > > Hi, > > The document takes care to not define Implicit IV for AES-CBC, and I believe > the underlying reason is malleability of the encryption. The same would apply > to AES-CTR. So I would suggest to: > Exclude AES-CTR from this draft, o

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

Hi, Paul On 10 Jun 2016, at 5:42 AM, Paul Wouters wrote: > On Thu, 9 Jun 2016, Daniel Migault wrote: > >> Please find our new proposal with ESP using implicit IV [1]. We would like >> to present and discuss it at the next IETF meeting. > > I must understand it wrong... > > Aren't these IVs d

Re: [TLS] Adoption of TLS-LTS

> On 8 Jun 2016, at 10:57 PM, Peter Gutmann wrote: > > Yoav Nir writes: > >> Mostly timing. The TLS working group is now working on TLS 1.3, so 1.2 should >> be considered stable by now. > > As the draft says, this is intended for long-term support (on the o

Re: [TLS] Adoption of TLS-LTS

> On 8 Jun 2016, at 10:29 PM, Peter Gutmann wrote: > > Russ Housley writes: > >> I do not think the TLS WG should take on any document that makes changes to >> the TLS 1.2 protocol. > > So how is that different from any number of other TLS standards-track RFCs, Mostly timing. The TLS working

Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]

> On 7 Jun 2016, at 8:33 PM, Hubert Kario wrote: > > On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote: >> I’m not sure this helps. >> >> I’ve never installed a server that is version intolerant. TLS stacks >> from OpenSSL, Microsoft, > > are you sure a

Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]

> On 7 Jun 2016, at 5:47 PM, Salz, Rich wrote: > >> I’m not sure this helps. > > I'm pretty sure it wouldn't help at all, for the reasons you list. Which isn’t to say it’s not worth doing. I’d love to test my implementation against a test suite rather than just making sure it’s working with

Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]

I’m not sure this helps. I’ve never installed a server that is version intolerant. TLS stacks from OpenSSL, Microsoft, Java, and most any implementation we can name have been version tolerant forever. Certainly none of us can name any implementation that at any point had a version out that was

Re: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document

> On 5 Jun 2016, at 7:58 PM, Paul Wouters wrote: > > On Sun, 5 Jun 2016, Waltermire, David A. (Fed) wrote: > >> This is the official call for adoption of >> https://datatracker.ietf.org/doc/draft-pauly-ipsecme-tcp-encaps/ as an >> IPSecME working group (WG) document. >> >> By adopting this d

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

> On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos wrote: > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote: >> 2% is actually pretty good, but I agree that we're going to need >> fallback. > > Please not. Lets let these fallbacks die. Not every client is a > browser. TLS 1.3 must b

Re: [IPsec] Status of draft-ietf-ipsecme-ddos-protection

> On 31 May 2016, at 8:01 AM, Valery Smyslov wrote: > > Hi Paul, > >>> On the other hand, if we go this way and give the puzzles stuff an >>> Experimantal status, then probably very few vendors (if any) will implement >>> it and the real problem of defending against >>> (D)DoS attacks will re

Re: [IPsec] Status of draft-ietf-ipsecme-ddos-protection

Hi, On 26 May 2016, at 4:12 PM, Valery Smyslov wrote: > Hi, > > in Buenos-Aires it was expressed a proposal to split the DDoS protection > draft into two. One of them would > describe possible kinds of (D)DoS attacks and would suggest some counter > measures to thwart them without > introduci

Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

> On 23 May 2016, at 9:39 AM, Valery Smyslov wrote: > > Hi Tommy, > > thank you for clarifications. One more point. The draft is silent about > what the responder is supposed to do with the stream prefix. > Should it check it? In this case what should it do if the prefix is > different from "IK

Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

> On 16 May 2016, at 6:50 AM, Atul Luykx wrote: > > Here's a possible re-write of the second paragraph: > > Nonce re-use in AES-GCM results in failure of both confidentiality and > authenticity. Not only will confidentiality be breached by leaking the XOR of > any two packets processed under

Re: [websec] HPKP & different encodings of the same public key

> On 15 May 2016, at 10:54 PM, Yaron Sheffer wrote: > >>> On 15/05/16 10:22, Yoav Nir wrote: >>>> That’s interesting. With HPKP you can pin keys from existing certificates, >>>> or keys that are not (yet) in certificates. >>>> >&

Re: [websec] HPKP & different encodings of the same public key

> On 15 May 2016, at 8:10 PM, Yaron Sheffer wrote: > > > > On 15/05/16 10:22, Yoav Nir wrote: >> That’s interesting. With HPKP you can pin keys from existing certificates, >> or keys that are not (yet) in certificates. >> >> One of the early deploy

Re: [websec] HPKP & different encodings of the same public key

That’s interesting. With HPKP you can pin keys from existing certificates, or keys that are not (yet) in certificates. One of the early deployment scenarios (which got de-emphasized later on) was that you include two pins: your current production key and a spare key that you will certify if som

Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT)

> On 5 May 2016, at 5:14 PM, Stephen Farrell wrote: > > > > On 24/04/16 17:23, Alexey Melnikov wrote: >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-tls-chacha20-poly1305-04: Yes >> >> When responding, please keep the subject line intact and reply to all >> ema

Re: [Gen-art] Gen-ART LC review of draft-ietf-tls-chacha20-poly1305-04 - resend

Hi Roni. I think I can explain one of your questions. > On 8 Apr 2016, at 5:36 PM, Roni Even wrote: >> Also note, the registry rules are: >> >> 0-191Standards ActionRefers to value of >> first byte >> 192-254 Specification Required Refers to va

Re: [IPsec] EdDSA Signatures in IKE

; Sent: Friday, April 8, 2016 9:30 AM > To: Yoav Nir ; Tero Kivinen > Cc: IPsecME WG > Subject: Re: [IPsec] EdDSA Signatures in IKE > > "Identity" is the formally correct term, but I think "null" is much > clearer than "identity". Especially

Re: [IPsec] EdDSA Signatures in IKE

> On 7 Apr 2016, at 6:12 PM, Tero Kivinen wrote: > > Yoav Nir writes: >> Tero: What would it take to register an “identity” hash function for >> use with the EdDSA? > > I assume you mean new value for the RFC7427 Hash Algorithm registry? > That registry is by e

Re: [IPsec] EdDSA Signatures in IKE

No responses yet... Tero: What would it take to register an “identity” hash function for use with the EdDSA? Yoav > On 5 Apr 2016, at 11:09 AM, Yoav Nir wrote: > > Replying to myself... > > I’ve been told off-list that it didn’t make sense to introduce the hot, new >

Re: [IPsec] Next steps on TCP Encapsulation for IKEv2

ic byte at the beginning of their > stream over TLS. This means that the inner protocol diverges depending on > which set of protocols are being used for the stream. I would prefer that > these be consistent if possible. > > Thoughts? > > Tommy > >> On Apr 5,

Re: [IPsec] Next steps on TCP Encapsulation for IKEv2

Hi, Tommy. The changes look fine, although I’m still not convinced we even need the TLS. But that’s for another thread. We foresee that most TCP encapsulation is likely to be in on port 443. I think TCP encapsulation of IKEv2/IPsec should be easily distinguishable from other types of traffic o

Re: [IPsec] EdDSA Signatures in IKE

:43 PM, Yoav Nir wrote: > > Hi > > At the meeting today, I presented the SafeCurves draft status and asked the > room whether we wanted to wait for CFRG and Curdle to settle their respective > RFCs. The room was unanimously in favor of not having anything in the current >

[IPsec] EdDSA Signatures in IKE

Hi At the meeting today, I presented the SafeCurves draft status and asked the room whether we wanted to wait for CFRG and Curdle to settle their respective RFCs. The room was unanimously in favor of not having anything in the current draft, instead using RFC 7427 digital signatures. To be cert

Re: [Acme] [ietf-wg-acme/acme] Out-of-band challenge (#111)

I think that’s a fine idea. But as I understand the ACME protocol, it’s designed to be run by a programmatic client running on the web server (or some proxy thereof). It’s not run on a browser or a mail client. So at what point does a human user see this “url” or “uri” field and “click the lin

Re: [TLS] TLS 1.2 Long-term Support Profile vs HTTP/2.0

> On 3 Apr 2016, at 8:44 AM, Martin Thomson wrote: > > On 3 April 2016 at 18:18, Peter Gutmann wrote: >> I think the reason why there's no rationale is because there's no rational >> explanation for lumping TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 in with the likes >> of TLS_RSA_EXPORT_WITH_RC4_40_M

Re: [tcpinc] Argintina reciprocity fee waived for US citizens

> On 1 Apr 2016, at 12:35 AM, David Mazieres > wrote: > > Yoav Nir writes: > >> It’s been discussed extensively on the IETF and attendees lists. >> >> The requirement has been lifted on March 24th. People who have already >> paid will not get their

Re: [tcpinc] Argintina reciprocity fee waived for US citizens

It’s been discussed extensively on the IETF and attendees lists. The requirement has been lifted on March 24th. People who have already paid will not get their money back, but the airlines should not require proof anymore. Yoav > On 31 Mar 2016, at 10:58 PM, Flemming Andreasen wrote: > > I

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

> On 30 Mar 2016, at 10:44 PM, Daniel Kahn Gillmor > wrote: > > On Wed 2016-03-30 15:20:08 -0400, Ilari Liusvaara wrote: >> On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote: >>> On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote: I am not sure that we want to be in t

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

> On 30 Mar 2016, at 7:05 PM, Daniel Kahn Gillmor > wrote: > > On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote: >> I am not sure that we want to be in the business of explicitly marking >> things as insecure other than our own RFCs, though -- there could be an >> implication of more revi

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

Hi Sean I also strongly support this. I’m just wondering how we plan to enforce the "stable, publicly available, peer reviewed reference” part. As your examples below show, the reference tends to be an I-D. That’s stable and publicly available, but we have no idea if it’s peer reviewed or who

Re: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic

On 29 Mar 2016, at 5:42 PM, Hubert Kario wrote: > On Tuesday 29 March 2016 15:09:16 Yoav Nir wrote: >>> On 29 Mar 2016, at 2:15 PM, Hubert Kario wrote: >>> >>> On Friday 25 March 2016 22:07:02 Yoav Nir wrote: >>>>> On 25 Mar 2016, at 8:16 PM, Yuho

Re: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic

> On 29 Mar 2016, at 2:15 PM, Hubert Kario wrote: > > On Friday 25 March 2016 22:07:02 Yoav Nir wrote: >>> On 25 Mar 2016, at 8:16 PM, Yuhong Bao >>> wrote: >>> >>> I wonder if it would be possible to publish >>> draft-ietf-tls-56-bit-

[tcpinc] Review of tcpcrypt

Hi I’ve reviewed the tcpcrypt draft. Usual caveat: IANAC, so I won’t comment on the strength of the algorithms used. In general, the draft looks OK. There should be clarity improvements, but I think if I had a TCP stack, this draft and the ENO draft, I could probably implement this (assuming I

Re: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic

> On 25 Mar 2016, at 8:16 PM, Yuhong Bao wrote: > > I wonder if it would be possible to publish > draft-ietf-tls-56-bit-ciphersuites as Historic (in the sense of RFC 6101). > It would start with > https://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuites-01 , but the > ciphersuites 0x60

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

> On 21 Mar 2016, at 3:19 PM, Salz, Rich wrote: > > >> OK, I've posted another update that specifies this, as well as use of EMS, >> and >> cleans up a few other areas. It's a bit of a rush job because of the >> impending >> lockdown for IETF 95, but hopefully the gist is there: >> >> http:

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

> On 16 Mar 2016, at 2:27 PM, Paul Wouters wrote: > > >> >> Or perhaps we need the IKEv1 considered harmful draft / >> ikev1-diediediediedie... > > I don't think that will help. I've seen how reluctant people are to change > their 10 year old working VPN. > > IKEv1 is dying pretty quickly

Re: [tcpinc] The TCP-ENO draft

> On 11 Mar 2016, at 11:59 AM, David Mazieres > wrote: > > Yoav Nir writes: > >> I’ve reviewed version -01 of the TCP-ENO draft. In general I find it >> understandable enough that I could implement it from the spec. > > Thanks for the detailed feedback. Co

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

> On 13 Mar 2016, at 4:45 PM, Salz, Rich wrote: > >> I also think it is prudent to assume that implementers will turn on >> replayable >> data even if nobody has figured out the consequences. > > I very much agree. Customers, particularly those in the mobile field, will > look at this and sa

Re: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires

Regarding draft-ietf-ipsecme-safecurves I think this is pretty much done. I don’t see why I’d need 15 minutes to say, “Version -00 had Curve25519; version -01 added Curve448; we don’t need to wait for CFRG’s signature draft, because we have RFC 7427; I think we’re ready for WGLC” Yoav > On 11

Re: [TLS] AD review of draft-ietf-tls-chacha20-poly1305-04

I agree with Viktor and Dave. RSA with keys greater at least 2048 bit is a good requirement that can be made of old and new implementations. Even if for some reason you’re stuck with OpenSSL 0.9.6 and thus with TLS 1.0 and 3DES, you can conform to this requirement. I think it would be a shame t

[tcpinc] The TCP-ENO draft

Hi, I’ve reviewed version -01 of the TCP-ENO draft. In general I find it understandable enough that I could implement it from the spec. As a protocol, it is more complex than I would have liked, considering that its entire purpose is to choose between two mechanisms, and that we don’t really

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

> On 4 Mar 2016, at 5:29 PM, Paul Wouters wrote: > >> On Tue, Mar 1, 2016 at 9:03 PM, Waltermire, David A. (Fed) >> wrote: >> All: >> >> With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I >> believe the draft is shaping up nicely, >> but needs additional review.

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

> On 6 Mar 2016, at 5:28 PM, Graham Bartlett (grbartle) > wrote: > > Hi > > The only case I could imagine that this could occur is if the Initiators > Nonce and KE were purposely made very small and the Initiator did not > perform any validation on this, sending it¹s own reply where the KE and

Re: [IPsec] Proposed wording for a revised charter

+1 Speaking as an implementer, we have done something similar for our IKEv1 clients, and would be happy to have something standards-based for IKEv2. I would be happy to see this work become an RFC. Yoav > On 4 Mar 2016, at 7:05 PM, Tommy Pauly wrote: > > I would also like to see the draft f

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

> On 4 Mar 2016, at 7:02 PM, Tommy Pauly wrote: > > Hello Dave, > > I tend to agree with Paul that I find it unlikely, from an implementor’s > standpoint, that many Initiators will choose to implement the puzzle logic, > especially ones that are running on mobile devices. It is unlikely that

Re: [TLS] [Editorial Errata Reported] RFC4492 (4633)

> On 2 Mar 2016, at 10:59 PM, Bodo Moeller wrote: > > RFC Errata System >: > The following errata report has been submitted for RFC4492, > "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security > (TLS)". > >

Re: [TLS] RSA-PSS in TLS 1.3

> On 2 Mar 2016, at 5:57 PM, Eric Rescorla wrote: > > > > On Wed, Mar 2, 2016 at 1:25 AM, Yoav Nir <mailto:ynir.i...@gmail.com>> wrote: > > > On 2 Mar 2016, at 11:16 AM, Rob Stradling > <mailto:rob.stradl...@comodo.com>> wrote: &

Re: [TLS] RSA-PSS in TLS 1.3

> On 2 Mar 2016, at 11:16 AM, Rob Stradling wrote: > > On 02/03/16 09:10, Rob Stradling wrote: > >>> Neither you nor I can post in any of the CA/Browser forum’s lists, >>> because neither of us has either a browser or a public CA. >>> >>> There are some people who are active there and are read

Re: [TLS] RSA-PSS in TLS 1.3

> On 2 Mar 2016, at 3:03 AM, Andrey Jivsov wrote: > > On 03/01/2016 11:20 AM, Yoav Nir wrote: >> >> On 1 Mar 2016, at 8:23 PM, Alyssa Rowan wrote: >> >>>> [YN] It would be cool to ban PKCS#1.5 from certificates, but we >>>> are not the

Re: [TLS] ecdh_x25519 and ecdh_x448 code points

OK, I’ve created a pull request to update 4492bis. https://github.com/tlswg/rfc4492bis/pull/20 There’s still the curves for EDDSA that are not yet assigned. Yoav > On 2 Mar 2016, at 12:23 AM, Sean Turner wrote: > > All, > > After completing the early code point assignment process, IANA has ad

Re: [TLS] RSA-PSS in TLS 1.3

On 1 Mar 2016, at 8:23 PM, Alyssa Rowan wrote: > > [YN] It would be cool to ban PKCS#1.5 from certificates, but we > > are not the PKIX working group. Nor are we the CA/Browser forum. > > When a CA issues a certificate it has to work with every client > > and server out there, When we use TLS 1.

Re: [TLS] RSA-PSS in TLS 1.3

> On 1 Mar 2016, at 6:52 AM, Andrey Jivsov wrote: > > On 02/29/2016 02:36 PM, Hanno Böck wrote: >> We have an RFC for PSS since 2003. >> We had several attacks showing the weakness of PKCS #1 1.5. > > In the face of such danger, what's your opinion on PKCS #1.5 signatures being > perfectly fin

Re: [TLS] RSA-PSS in TLS 1.3

> On 1 Mar 2016, at 6:56 AM, Martin Thomson wrote: > > On 1 March 2016 at 04:32, Joseph Salowey wrote: >> We make RSA-PSS mandatory to implement (MUST implement instead of MUST >> offer). Clients can advertise support for PKCS-1.5 for backwards >> compatibility in the transition period. > >>

Re: [IPsec] Textual changes to the DDoS draft

curity and simplicity. > > Regards, > Valery. > >> - Original Message - >> From: Yaron Sheffer <mailto:yaronf.i...@gmail.com> >> To: Valery Smyslov <mailto:sva...@gmail.com> ; Yoav Nir >> <mailto:ynir.i...@gmail.com> ; Waltermire, Da

Re: [TLS] RSA-PSS in TLS 1.3

> On 29 Feb 2016, at 8:00 PM, Hanno Böck wrote: > > On Mon, 29 Feb 2016 09:32:04 -0800 > Joseph Salowey wrote: > >> We make RSA-PSS mandatory to implement (MUST implement instead of MUST >> offer). Clients can advertise support for PKCS-1.5 for backwards >> compatibility in the transition pe

Re: [TLS] RSA-PSS in TLS 1.3

> On 29 Feb 2016, at 7:39 PM, Viktor Dukhovni wrote: > > On Mon, Feb 29, 2016 at 09:32:04AM -0800, Joseph Salowey wrote: > >> We seem to have good consensus on moving to RSA-PSS and away from PKCS-1.5 >> in TLS 1.3. However, there is a problem that it may take some hardware >> implementations

Re: [IPsec] Textual changes to the DDoS draft

> On 26 Feb 2016, at 2:03 AM, Waltermire, David A. > wrote: > > I haven’t seen any additional feedback on the DDoS draft this week based on > Yoav’s note about the PR [1]. It also looks like the discussion on chaining > puzzles has wrapped up with no changes needed to the draft [2]. Oh. My i

[IPsec] Textual changes to the DDoS draft

Hi all Valery submitted a new PR with a couple of textual changes, mostly based on comments by Dave. https://github.com/ietf-ipsecme/drafts/pull/12 The changes (listed below) seem fine to me. If nobody objects, I will merge them in on Friday.

Re: [IPsec] DDoS Protection - single vs multiple solutions

> On 18 Feb 2016, at 4:20 PM, Valery Smyslov wrote: > >>> I tend to support this idea, but I think in this case the sub-puzzles must >>> be chained to deal with parallel solving. >>> Something like the following: >>> >>> Puzzle_data[0] = cookie >>> Puzzle_data[1] = Puzzle_solution[0] | cookie

Re: [IPsec] DDoS Protection - single vs multiple solutions

On 18 Feb 2016, at 2:58 PM, Valery Smyslov wrote: > > > I tend to support this idea, but I think in this case the sub-puzzles must be > chained to deal with parallel solving. > Something like the following: > > Puzzle_data[0] = cookie > Puzzle_data[1] = Puzzle_solution[0] | cookie > Puzzle_d

Re: [IPsec] DDoS Protection - single vs multiple solutions

On 17 Feb 2016, at 6:09 PM, Yoav Nir wrote: > A while ago Scott Fluhrer suggested a way to make this more fair As it turns out, this was first suggested by Yaron: https://mailarchive.ietf.org/arch/msg/ipsec/_JUTE8p5H6bhFOA1HCuaYX1NCKQ Scott’s idea was a little different. Sorry for

[IPsec] DDoS Protection - single vs multiple solutions

Hi As we’re nearing WGLC for the DDoS protection draft, there is a question we’ve left open in the past that should be resolved. The issue is with the variability of the time it takes to solve a puzzle. To demonstrate it, I ran a simulation of trying to solve a 20-bit puzzle 1000 times on some

Re: [Captive-portals] CAPPORT meeting at IETF95 in Buenos Aires.

> On 17 Feb 2016, at 1:53 AM, Mark Nottingham wrote: > > >> On 17 Feb 2016, at 3:59 AM, David Illsley wrote: >> >> I'm interested in the Sandboxing point in section 4. I understand these to >> be designed as a pro-user security feature. In general I don't trust random >> network devices in

Re: [IPsec] RFC4307bis working version 3

On 10 Feb 2016, at 1:43 PM, Paul Wouters wrote: > >> And for the digital signature method, why should we require SHA-1? > > Because it is very common to use right now. We cannot go from MUST to > MUST NOT. No, but RFC 4307 says nothing about hashes in signatures (whether RSA(1) or digital sig

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