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

> On 15 May 2016, at 10:54 PM, Yaron Sheffer <yaronf.i...@gmail.com> 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

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

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

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

Re: [IPsec] EdDSA Signatures in IKE

rom: Yaron Sheffer > 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 "id

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 <ynir.i...@gmail.com> wrote: > > Replying to myself... > > I’ve been told off-list that it didn’t make sense to i

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

Re: [IPsec] EdDSA Signatures in IKE

:43 PM, Yoav Nir <ynir.i...@gmail.com> 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 anyth

[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

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

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

> On 1 Apr 2016, at 12:35 AM, David Mazieres > <dm-list-tcpcr...@scs.stanford.edu> wrote: > > Yoav Nir <ynir.i...@gmail.com> writes: > >> It’s been discussed extensively on the IETF and attendees lists. >> >> The requirement has been lifted o

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

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

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 2:15 PM, Hubert Kario <hka...@redhat.com> wrote: > > On Friday 25 March 2016 22:07:02 Yoav Nir wrote: >>> On 25 Mar 2016, at 8:16 PM, Yuhong Bao <yuhongbao_...@hotmail.com> >>> wrote: >>> >>> I wonder if it would be p

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 ,

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

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

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 >

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

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

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

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

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.

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

Re: [TLS] RSA-PSS in TLS 1.3

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

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

Re: [TLS] RSA-PSS in TLS 1.3

> On 2 Mar 2016, at 3:03 AM, Andrey Jivsov <cry...@brainhub.org> wrote: > > On 03/01/2016 11:20 AM, Yoav Nir wrote: >> >> On 1 Mar 2016, at 8:23 PM, Alyssa Rowan <a...@akr.io> wrote: >> >>>> [YN] It would be cool to ban PKCS#1.5 from certi

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

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

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

[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] =

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]

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

On 17 Feb 2016, at 6:09 PM, Yoav Nir <ynir.i...@gmail.com> 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

[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

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

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

curity Maintenance and Extensions > Working Group of the IETF. > >Title : Curve25519 and Curve448 for IKEv2 Key Agreement > Authors : Yoav Nir > Simon Josefsson > Filename: draft-ietf-ipsecme-safecurve

Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-06.txt

oup of > the IETF. > >Title : Elliptic Curve Cryptography (ECC) Cipher Suites for > Transport Layer Security (TLS) Versions 1.2 and Earlier > Authors : Yoav Nir > Simon Josefsson > Manuel Pegourie-Gonnard &

Re: [TLS] 0-RTT, server Application Data, and client Finished

> On 27 Jan 2016, at 8:38 PM, Andrei Popov wrote: > > Ø The CertificateVerify message is still listed as an option in the 0-RTT > client's first flight at t = 0. Is this a mistake? I have not heard that > anyone wants to do this, as there is no possibility of a

Re: [TLS] ECDH_anon

> On 27 Jan 2016, at 5:51 AM, Martin Thomson wrote: > > 4472bis has a TBD regarding a missing "E" in the name of ECDHE_anon > cipher suites. > > I raised an issue: https://github.com/tlswg/rfc4492bis/issues/17 Quoting: > My view: just because DH_anon is confused,

Re: [TLS] Require deterministic ECDSA

> On 25 Jan 2016, at 5:08 PM, Salz, Rich wrote: > >> But any system running a TLS stack is already going to have a high quality >> entropy source for client/server randoms and IVs and such > > That's assuming a constraint that isn't accurate. Eh. Just s/is/should/

Re: [TLS] Require deterministic ECDSA

> On 24 Jan 2016, at 2:47 AM, Michael StJohns wrote: > > On 1/23/2016 2:13 PM, Joseph Birr-Pixton wrote: >> Hi, >> >> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA. >> >> For discussion, here's a pull request with possible language: >> >>

Re: [TLS] Require deterministic ECDSA

Hi, Mike > On 24 Jan 2016, at 2:53 AM, Michael StJohns <m...@nthpermutation.com> wrote: > > On 1/23/2016 7:17 PM, Yoav Nir wrote: >> Also if the signatures are done in a separate hardware module, that module >> is even less likely to have a good random source. &g

Re: [TLS] Require deterministic ECDSA

Also if the signatures are done in a separate hardware module, that module is even less likely to have a good random source. And if we make it rely on external input for the random, that’s a good way of getting it to reveal information about the private key, whereas keeping the private key

Re: [IPsec] RFC4307bis working version 3

> On 21 Jan 2016, at 7:25 AM, Paul Wouters wrote: > > > "high interoperability" does not really work for me. How about "wide > interoperability" or industry-wide or "a wide range of > interoperability". > > > a user -> an user Nope:

Re: [IPsec] ESN question regarding wording in 4304

Hi, Paul At some point there was talk of allowing people to omit the ESN attribute from the SA payload, and that would mean “ESN yes only”. That was not in the final 4306, but apparently a trace of this remains in 4304. As for what my implementation does, we send only “ESN no” and accept only

Re: [IPsec] SLOTH & IKEv2

> On 16 Jan 2016, at 7:17 AM, HU, Jun (Jun) <jun...@nokia.com> wrote: > > > >> -Original Message- >> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of EXT Yoav Nir >> Sent: Friday, January 15, 2016 8:15 PM >> To: Valery Smyslov >>

Re: [IPsec] SLOTH & IKEv2

> On 15 Jan 2016, at 3:55 PM, Valery Smyslov wrote: > > Hi Yoav, > What does IPsec community think of it? Should we fix the protocol to thwart this attack completely? Is the recommendation to move the COOKIE to the end of the message enough to achive that?

Re: [IPsec] SLOTH & IKEv2

> On 15 Jan 2016, at 11:15 PM, Paul Wouters <p...@nohats.ca> wrote: > > On Fri, 15 Jan 2016, Yoav Nir wrote: > >>> The initiator cannot validate the cookie - it is an opaque blob for him. >>> Should he reject >>> the cookie if its length is more th

Re: [IPsec] SLOTH & IKEv2

> On 15 Jan 2016, at 10:32 PM, Valery Smyslov wrote: > > >>> What about the responder - he doesn't see any cookie in this attack - the >>> attacker >>> sends the crafted cookie only to the initiator and sends a crafted >>> IKE_SA_INIT message w/o cookie to the responder (as

Re: [IPsec] SLOTH & IKEv2

> On 15 Jan 2016, at 10:55 AM, Yaron Sheffer wrote: > > However, thank you for bringing in the SLOTH attack. >> As fas as I understand from the paper >> http://www.mitls.org/downloads/transcript-collisions.pdf it is based on the >> ability for an attacker to find

Re: [IPsec] meeting at IETF-95 ?

I believe around that time CFRG and TLS will be done with the signatures document and rfc4492bis respectively, so we could proceed and finish draft-ietf-ipsecme-safecurves. So count me as a +1 as well. > On 12 Jan 2016, at 4:56 PM, Paul Wouters wrote: > > > I hope we are

Re: [TLS] Fixing TLS

Hi, Peter Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0) that this WG is working on right now, why? Other groups are not working on HTTP/1.2 or IKEv1.1 or any other $protocolv$(major-1).$(minor+1). Any TLS library that exists now doesn’t have an implementation of

Re: [TLS] Data volume limits

> On 17 Dec 2015, at 10:19 AM, Nikos Mavrogiannopoulos wrote: > > On Wed, 2015-12-16 at 09:57 -1000, Brian Smith wrote: > >> Therefore, I think we shouldn't add the rekeying mechanism as it is >> unnecessary and it adds too much complexity. > > Any arbitrary limit for a TLS

Re: [IPsec] FWD from Tero Kivinen: [IANA #879113] General Request for Assignment (ikev2-parameters)

Hi, Tero I realise you are not the one to ask about this, but why not use CFG_SET? This IMEI information is about as trustworthy as the “APPLICATION_VERSION” type. Yoav > On 15 Dec 2015, at 2:18 PM, Tero Kivinen wrote: > > FYI, I just rejected the DEVICE_IDENTITY

Re: [TLS] TLS Record Size Limitation

> On 7 Dec 2015, at 11:00 PM, Software Engineer 979 > wrote: > > >> Hello, >> >> I'm currently developing an data transfer application using OpenSSL. The >> application is required to securely transfer large amounts of data over a >> low latency/high bandwidth

Re: [TLS] Fresh results

> On 3 Dec 2015, at 8:40 PM, Fabrice Gautier wrote: > > On Wed, Dec 2, 2015 at 2:14 AM, Nikos Mavrogiannopoulos > wrote: >> On Tue, 2015-12-01 at 21:02 +0100, Hanno Böck wrote: >>> On Tue, 1 Dec 2015 14:28:49 -0500 >>> Watson Ladd

Re: [Acme] Server on >= 1024 port

> On 2 Dec 2015, at 11:52 AM, Paul Millar wrote: > > Hi all, > > I'm writing just to summarise this thread and check a consensus has been > reached. > > On 25/11/15 11:13, Paul Millar wrote: >> I was wondering whether people have considered services running on a >> port

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

> On 2 Dec 2015, at 1:38 PM, Jacob Appelbaum <ja...@appelbaum.net> wrote: > > On 12/1/15, Yoav Nir <ynir.i...@gmail.com> wrote: >> >>> >>> Which would those be? And what is the definition of capital-intensive >>> for those watching on

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum wrote: > > >> These are corporate >> firewalls. When it comes to filtering HTTPS connections, firewalls have >> three ways to classify the connection: >> 1. Look at the SYN and SYN-ACK packets. Make decisions by IP addresses. >>

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

> On 1 Dec 2015, at 4:55 PM, Bryan A Ford <brynosau...@gmail.com> wrote: > > On 12/1/15 10:12 AM, Yoav Nir wrote: >>> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum <ja...@appelbaum.net> wrote: >>> On 12/1/15, Viktor Dukhovni <ietf-d...@dukhovni.org&g

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum wrote: > > On 12/1/15, Viktor Dukhovni wrote: >> On Mon, Nov 30, 2015 at 10:34:27AM +, Peter Gutmann wrote: >> >>> Bryan A Ford writes: >>> It would work just as well

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 1 Dec 2015, at 1:02 PM, Hubert Kario wrote: If you think it is practical for the TLS 1.3 standard to specify a single, fixed record size that all implementations of TLS 1.3 must use (i.e., explicitly freeze not only the version field but the length

Re: [TLS] Early code point assignments for 25519/448 curves

> On 28 Nov 2015, at 4:48 PM, Ilari Liusvaara wrote: > > On Mon, Nov 23, 2015 at 01:16:35PM -0800, Martin Thomson wrote: >> >> Are we happy that we will only be needing the PureEdDSA variants and >> that no-one will be asking for the HashEdDSA versions? I ask because

Re: [Acme] Server on >= 1024 port

> On 26 Nov 2015, at 11:49 AM, Paul Millar wrote: > > On 25/11/15 19:22, Roland Zink wrote: >> The resolution of a certificate is the domain name, e.g. it is valid for >> all services on the machine. If you get the certificate for a port then >> you may misuse it to

Re: [Acme] Server on >= 1024 port

> On 26 Nov 2015, at 1:16 PM, Randy Bush wrote: > >> The resolution of a certificate is the domain name, e.g. it is valid for >> all services on the machine. > >X509v3 extensions: >X509v3 Key Usage: critical >Digital Signature, Key

Re: [Acme] Issue: Allow ports other than 443

> On 26 Nov 2015, at 1:00 PM, Stephen Farrell wrote: > > > > On 26/11/15 08:36, Eliot Lear wrote: >> Yes. The real issue here is that the cert contains the hostname and not >> the port. > > So one could define a new always-critical certificate extension > saying

Re: [Acme] Issue: Allow ports other than 443

I think Eliot meant RFC 5785 /.well-known/ locations, rather than well known ports Yoav > On 24 Nov 2015, at 6:37 PM, Kathleen Moriarty > wrote: > > I agree with Eliot, I don't think a scan is needed to make a decision > here. Having managed several

Re: [Acme] New issue: Clarify how to handle bad requests

> On 21 Nov 2015, at 8:02 PM, Salz, Rich wrote: > > Please see https://github.com/ietf-wg-acme/acme/issues/47 for background, but > discuss it here on the mailing list. The A in ACME stands for automated, and the protocol we are chartered to develop is designed to allow

Re: [IPsec] New revision of TCP Encapsulation draft

> On 21 Nov 2015, at 1:10 AM, Yaron Sheffer wrote: > > Hi Tommy, > > I also think this is very relevant work. Here are some comments to -01: > > I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited > under "prior work” That’s

Re: [TLS] Record header size?

> On 18 Nov 2015, at 3:32 AM, Peter Gutmann wrote: > > Eric Rescorla writes: > >> The concern here is backward compatibility with inspection middleboxes which >> expect the length field to be in a particular place. > > Given that the rest of TLS 1.3

Re: [IPsec] WGLC on draft-ietf-ipsecme-safecurves?

> On 12 Nov 2015, at 12:13 PM, Simon Josefsson wrote: > > There have been no additional comment on the list, and we have had one > positive review from an implementer [1]. Is there any reason to wait > further with WG last calling this document? Its dependency on >

Re: [Acme] Spec change to allow retrieval of Terms of Service URL

> On 12 Nov 2015, at 4:06 AM, Daniel Kahn Gillmor > wrote: > > On Fri 2015-11-06 14:03:35 -0500, Matthew Holt wrote: >> I'd like to propose a change that allows clients of the ACME protocol to >> obtain the URL to the CA's current Terms of Service (if any) without >>

Re: [IPsec] Clarification regarding USE_TRANSPORT_MODE notification

Hi, Hema USE_TRANSPORT_MODE is a notification, so it is outside the structures in the SA payload. As a consequence, the protocol does not allow you to propose AES-GCM in transport mode or ChaCha20/Poly1305 in tunnel mode. Note also that USE_TRANSPORT_MODE does not force transport mode. It

Re: [IPsec] RFC 4307bis

:39 PM, Yoav Nir <ynir.i...@gmail.com> wrote: > > Hi all. > > I’ve uploaded the XML source of this document to github and submitted the > first pull request: > https://github.com/ietf-ipsecme/drafts/pull/7/files > <https://github.com/ietf-ipsecme/drafts/pull/7/

Re: [IPsec] RFC 4307bis

://github.com/mglt/drafts/blob/d2d31f6f9f0b4d57c8343826ad23fc546b99a467/draft-ietf-ipsecme-rfc4307bis > > We added some text to recommend the status of each recommended algorithms. > > On Mon, Nov 9, 2015 at 11:27 AM, Paul Hoffman <paul.hoff...@vpnc.org > <mailto:paul.hoff...@vpnc.or

Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-05.txt

Thanks! Fixed in master. > On 4 Nov 2015, at 9:45 PM, Hubert Kario wrote: > > On Tuesday 03 November 2015 19:05:11 internet-dra...@ietf.org wrote: >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-05 > > > typo: >

[IPsec] RFC 4307bis

Hi all. I’ve uploaded the XML source of this document to github and submitted the first pull request: https://github.com/ietf-ipsecme/drafts/pull/7/files We had a side meeting about the algorithms specified in this draft and came up with

Re: [TLS] Deprecating tls-unique for TLS 1.3

Can’t we just say that all previous uses of tis-unique will instead get an exporter generated with the label “tis-unique” ? > On 4 Nov 2015, at 11:12 AM, Alexey Melnikov wrote: > > Just to clarify, I think it is fine to define TLS 1.3 replacement for > tls-unique

Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-05.txt

(TLS) Versions 1.2 and Earlier > Authors : Yoav Nir > Simon Josefsson > Manuel Pegourie-Gonnard > Filename: draft-ietf-tls-rfc4492bis-05.txt > Pages : 31 > Date: 2015-11-03 > &

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

Reminder. It’s tonight at 7:00 PM Japan time, 10:00 UTC. We won’t have Meetecho or audio streaming, but if a few remote people want to participate, we might be able to do something with Skype. Yoav > On 2 Nov 2015, at 10:28 AM, Yoav Nir <ynir.i...@gmail.com> wrote: > > Hi,

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

> On 3 Nov 2015, at 1:33 PM, Tero Kivinen <kivi...@iki.fi> wrote: > > Yoav Nir writes: >> There is 1 for “RSA Digital Signature” and you can encode any hash >> function the you would like, but for ECDSA there is: >> 9 - ECDSA with SHA-256 on the P-256 curve &g

Re: [TLS] AES-GCM and ChaCha-Poly1305: how many bytes are safe?

> On 3 Nov 2015, at 4:59 AM, Brian Smith wrote: > > Watson Ladd > wrote: > For these results a > sender of 2^60 messages can tolerate 2^60 forgery attempts while the > probability of forgery is at most 1.002/2^52. > >

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

> On 2 Nov 2015, at 6:32 PM, Yaron Sheffer wrote: > > If not here, where does this advice go? I see your point. But for instance for X509 certificates, I really would like to not make any statement and point to whatever equivalent of PKIX

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt

> On 3 Nov 2015, at 9:42 AM, Tero Kivinen wrote: > > John Mattsson writes: >> - BTW, What does it mean that an algorithm like ENCR_RC5 is not >> listed, does that mean “MAY”, “MUST NOT”, or “totally unspecified”? > > It means this document does not specify whether they should

[websec] Sniffly

https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf (presentation) https://zyan.scripts.mit.edu/blog/sniffly/ (blog) This tool manages to track which sites a user has visited

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

> On 3 Nov 2015, at 10:48 AM, Dan Harkins <dhark...@lounge.org> wrote: > > > > On Sun, November 1, 2015 7:21 pm, Yoav Nir wrote: >> >>> On 2 Nov 2015, at 11:44 AM, Paul Wouters <p...@nohats.ca> wrote: >>> >>> On Mon, 2 Nov 2015,

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

Forgot the link… > On 2 Nov 2015, at 12:38 PM, Yoav Nir <ynir.i...@gmail.com> wrote: > > >> On 2 Nov 2015, at 12:27 PM, Paul Wouters <p...@nohats.ca> wrote: >> >> On Mon, 2 Nov 2015, Yoav Nir wrote: >> >>>>> P.S. Someo

[IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

Hi, all Since we’ve had quite a bit of bikeshedding about this on the list, we’d like to gather and has it out face to face. So this Wednesday at 7:00 PM, right after the plenaries, we’ll meet at room 421 to hash this out. Everyone’s invited, obviously. Yoav P.S. Someone’s asked me off-list

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

> On 2 Nov 2015, at 11:44 AM, Paul Wouters <p...@nohats.ca> wrote: > > On Mon, 2 Nov 2015, Yoav Nir wrote: > >> P.S. Someone’s asked me off-list whether there is any IPsecME document that >> says not to trust SHA-1 in signatures, both AUTH payload and certifi

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

> On 2 Nov 2015, at 12:27 PM, Paul Wouters <p...@nohats.ca> wrote: > > On Mon, 2 Nov 2015, Yoav Nir wrote: > >>>> P.S. Someone’s asked me off-list whether there is any IPsecME document >>>> that says not to trust SHA-1 in signatures, both AUTH paylo

Re: [Captive-portals] Tokyo

Or talk in a bar/restaurant if we are few enough. Or talk first in some room or hallway here. Make it short enough that we can go for food later. > On 2 Nov 2015, at 1:28 PM, Roscoe, Alexander > wrote: > > Depending on how many people would like to meet,

Re: [TLS] [PATCH RFC4492bis] Add EdDSA signature support

LGTM. Can you push this to GitHub? > On 20 Oct 2015, at 8:35 PM, Ilari Liusvaara <ilari.liusva...@welho.com> wrote: > > From: Ilari Liusvaara <ilariliusva...@welho.com> > > --- > On Tue, Oct 20, 2015 at 10:42:14AM +0300, Yoav Nir wrote: >> Hi Ilari >

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

> On 20 Oct 2015, at 10:42 AM, Yoav Nir <ynir.i...@gmail.com> wrote: > > >> - In public key validation, X448 resists invalid point attacks >> the same way as X25519 (of course, all bits of X448 public >> keys can be nonzero, as the value can get to almost 256^

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

Hi Ilari > On 19 Oct 2015, at 8:14 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > On Mon, Oct 19, 2015 at 06:58:52PM +0300, Yoav Nir wrote: >> Hi >> >> I’ve submitted version -04 of this draft, incorporating the new curves >> Curve25519 and C

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

Of course, if anyone wants to help with the merge via pull requests, that would be great. Yoav > On 19 Oct 2015, at 6:58 PM, Yoav Nir <ynir.i...@gmail.com> wrote: > > Hi > > I’ve submitted version -04 of this draft, incorporating the new curves > Curve25519 and

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

ded message: > > From: internet-dra...@ietf.org > Date: 19 October 2015 at 6:56:17 PM GMT+3 > To: "Yoav Nir" <ynir.i...@gmail.com>, "Manuel Pegourie-Gonnard" > <m...@elzevir.fr>, "Simon Josefsson" <si...@josefsson.org>, "Simon Josefss

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

> On 19 Oct 2015, at 6:24 AM, Martin Thomson wrote: > > On 18 October 2015 at 16:59, Eric Rescorla wrote: >> Yeah, I am starting to think I was getting too clever here and it would be >> better >> to just say "tear down the connection" > > > I can't

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

Hi Two things that bothered me that I think have not been mentioned by either Mirja or David: Section 2 says: "If the TLS handshake fails for non-cryptographic reasons … endpoints SHOULD behave as if the the TCP-TLS option was not present.” I’m missing what counts as “cryptographic” vs not. So

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