Re: [TLS] Commentary on the client authentication presentation slides

On Aug 10, 2015, at 8:10 PM, Andrei Popov andrei.po...@microsoft.com wrote: Hi Ilari, What sort of usecase you have in mind for this? This is to support a fairly common website design where the landing page does not require client auth, but subsequent request to a protected resource

Re: [TLS] Commentary on the client authentication presentation slides

On Aug 10, 2015, at 10:04 PM, Andrei Popov andrei.po...@microsoft.com wrote: Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2. Correct, anything less than this will create deployment problems. I’d

Re: [TLS] sect571r1

On Jul 15, 2015, at 9:19 PM, Benjamin Beurdouche benjamin.beurdou...@inria.fr wrote: Hey, Except if someone has a real need for it, I would favour removing p571 and keep secp521r1 as the maximum … +1 It should be noted that I have removed it from RFC4492bis. In terms of real-world

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

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: [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: [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: [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] [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] padding

On Aug 25, 2015, at 2:22 AM, Tom Ritter t...@ritter.vg wrote: On 22 August 2015 at 19:28, Dave Garrett davemgarr...@gmail.com wrote: Toggling solves the undesired bandwidth use concern stated by Tom by making it fully optional on both sides. The even simpler route of just having to check

Re: [TLS] TLS 1.3 - Support for compression to be removed

> On Oct 4, 2015, at 1:44 AM, takamichi saito wrote: > > > On 2015/10/03, at 0:24, Salz, Rich wrote: > >> >>> 1) We know CRIME threat, but it can not be risk for everyone. >>> e.g., CVSS v2 Base Score: 2.6 (LOW) >> >> CVSS isn't always appropriate; CVSS2 called

Re: [TLS] TLS 1.3 - Support for compression to be removed

> On Sep 24, 2015, at 7:40 AM, Jeffrey Walton wrote: > >> I have to wonder if it’s worth it. In the last decade bandwidth has >> increased and prices for networking have gone down much faster than CPU >> speeds. 10 years ago having 1 Mbps at home was the highest-end

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

Re: [TLS] Adoption of TLS-LTS

> On 8 Jun 2016, at 10:57 PM, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: > > Yoav Nir <ynir.i...@gmail.com> 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

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

> On 7 Jun 2016, at 8:33 PM, Hubert Kario <hka...@redhat.com> 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,

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

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

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

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,

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

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

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: [TLS] PR #23 for RFC4492bis

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

[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

Re: [TLS] TLS RSA-PSS and various versions of TLS

> On 8 Feb 2017, at 21:34, Timothy Jackson wrote: > > I have a question on RFC5246 (TLS 1.2) and how it’s going to interact with > RSASSA-PSS as we roll out TLS 1.3. Does the prohibition against RSASSA-PSS > apply only to the signatures that can be used for signing

Re: [TLS] New Draft: Using DNS to set the SNI explicitly

On 7 Feb 2017, at 18:12, Ben Schwartz wrote: > Hi TLS, > > Like a lot of people here, I'm very interested in ways to reduce the leakage > of users' destinations in the ClientHello's cleartext SNI. It seems like the > past and current proposals to fix the leak are pretty

Re: [TLS] PSS and TLS 1.3

> On 6 Feb 2017, at 4:36, Martin Thomson wrote: > > On 6 February 2017 at 11:12, Nikos Mavrogiannopoulos wrote: >> TLS 1.3 requiring a different key type, will provide an incentive for >> them to update. > > > I don't think that's how this works.

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

> On 22 Feb 2017, at 8:42, Martin Thomson wrote: > > On the interaction with TLS 1.3, we probably need a decision to be made: > > 1. strike TLS 1.3 from the document and only mention it in the way Joe > suggests, TLS 1.3 doesn't get the CCM suites (it already has the

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi, Quynh > On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) wrote: > > Hi Sean and all, > > Beside my suggestion at > https://www.ietf.org/mail-archive/web/tls/current/msg22381.html > , I have a > second

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

> On 14 Feb 2017, at 23:52, Atul Luykx wrote: > >> Why is that 2^48 input blocks rather than 2^34.5 input blocks? > Because he wants to lower the security level. The original text recommends > switching at 2^{34.5} input blocks, corresponding to a success

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

> On 15 Feb 2017, at 19:25, Martin Thomson <martin.thom...@gmail.com> wrote: > > On 16 February 2017 at 04:20, Yoav Nir <ynir.i...@gmail.com> wrote: >> No, not really, but TLS is not just the web, and there are connections that >> last for a long time and tran

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

On 15 Feb 2017, at 19:05, Martin Thomson wrote: > > Frankly, I'm more concerned that this isn't small enough and that it > could it be practical to deploy an implementation that don't support > KeyUpdate. That would cause a real interop problem. Maybe we should

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

And they all cost 10 cents a piece, never get updated, and control the floodgates that hold back the biblical flood. > On 1 Mar 2017, at 16:28, Salz, Rich wrote: > > You know what amazes about IoT? No matter what someone tries to do there is > a chip/SoC out there that

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

> On 1 Mar 2017, at 15:06, Aaron Zauner wrote: > > >> On 24 Feb 2017, at 14:07, Salz, Rich wrote: >> >>> Assuming 256-bit AES-CCM suites are needed, I think the better place to put >>> them is in the TLS 1.3 document. >> >> That's a really big assumption. ;)

Re: [TLS] AD review of draft-ietf-tls-rfc4492bis-12.txt

> On 17 Feb 2017, at 18:58, Stephen Farrell wrote: > > > Hiya, > > I've had a read of this and asked for IETF LC to start. > > My comments below can be handled with any other IETF LC > comments. > > Thanks, > S. > > - Bits of this are fairly complex reading,

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

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)

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

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

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

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 >

Re: [TLS] Industry Concerns about TLS 1.3

> On 28 Sep 2016, at 7:16 PM, Dan Brown wrote: > > As I understand the concern, the worry is that Bud is compromising Bob's > (TLS) server, to somehow send Bob's plaintext to the wrong place. > > The proposed (existing?) strategy has Bob compromising his own >

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

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

Re: [TLS] Industry Concerns about TLS 1.3

> On 27 Sep 2016, at 11:33 AM, Judson Wilson wrote: > > > > Yes, I know that changed. It was an example of something that works with > TLS 1.2 even when PFS is used. With TLS 1.3 server or client implementations > can find other ways to retain long-term records of

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

ernet-Drafts > directories. > This draft is a work item of the Transport Layer Security of the IETF. > >Title : Elliptic Curve Cryptography (ECC) Cipher Suites for > Transport Layer Security (TLS) Versions 1.2 and Earlier > Authors : Yoav Nir >

Re: [TLS] TLS Visibility Inside the Data Center (was: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt)

If I understand this draft correctly, this draft describes server behavior. It does not change anything within the TLS 1.3 protocol. IOW a server doing this will interoperate with any client. I searched the tls13 draft to see if it has anything to say about this, and the only thing I found was

Re: [TLS] Point validation in 1.3

I think the performance enhancement (in terms of handshakes per second) that you get by reusing ephemeral keys is so great, that we have to assume people will do it. You don’t have to keep the keys indefinitely. It’s fine to generate a new key every second or ten seconds or so. Which makes

Re: [TLS] record layer limits of TLS1.3

Hi, Nikos On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos wrote: > Hi, > Up to the current draft of TLS1.3 the record layer is restricted to > sending 2^14 or less. Is the 2^14 number something we want to preserve? > 16kb used to be a lot, but today if one wants to do fast

Re: [TLS] record layer limits of TLS1.3

On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos <n...@redhat.com> wrote: > On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: >> Hi, Nikos >> >> On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos <n...@redhat.com> >> wrote: >> >>> >

Re: [TLS] Re-use and export of DH shares

And if it wasn’t clear, this *is* a WGLC comment on the TLS 1.3 draft based on discussion in Tuesday’s session in Seoul. Yoav > On 20 Nov 2016, at 12:21, Yoav Nir <ynir.i...@gmail.com> wrote: > > Hi. > > I’ve created a PR for TLS 1.3 > https://github.com/tlswg/tls13-sp

Re: [TLS] Confirming consensus: TLS1.3->TLS*

> On 21 Nov 2016, at 20:43, Salz, Rich wrote: > > >> With this in mind, I'm voting in favor of any re-branding of TLS 1.3 where >> the >> protocol name remains "TLS" and major version becomes > 1. > > Me too. Agree ___ TLS

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

Hi, John Thanks for the review. See my responses below: > On 23 Nov 2016, at 12:15, John Mattsson wrote: > > I have not read the processing parts in detail. Here are comments on the > first and last sections of the document. > > Cheers, > John > > - Somewhere > I

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

> On 23 Nov 2016, at 12:22, John Mattsson wrote: > > On 2016-11-21, 06:31, "TLS on behalf of Yaron Sheffer" > on behalf of > yaronf.i...@gmail.com > wrote: > >> So the key schedule

Re: [TLS] record layer limits of TLS1.3

> On 24 Nov 2016, at 15:47, Hubert Kario <hka...@redhat.com> wrote: > > On Wednesday, 23 November 2016 10:50:37 CET Yoav Nir wrote: >> On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos <n...@redhat.com> wrote: >>> On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wr

Re: [TLS] Confirming consensus: TLS1.3->TLS*

Bleh. Can’t we get AOL to release the SSL trademark so that we can call it SSLv4? I hummed for TLS 4, so I’ll stay consistent: TLS 4. Yoav > On 18 Nov 2016, at 11:12, Sean Turner wrote: > > At IETF 97, the chairs lead a discussion to resolve whether the WG should > rebrand

[TLS] Re-use and export of DH shares

Hi. I’ve created a PR for TLS 1.3 https://github.com/tlswg/tls13-spec/pull/768 It adds a subsection to the Security Considerations section. It discusses key reuse (do it carefully or do it not). It has the "don't do this or this grape juice might ferment" weasel words suggested by someone at

[TLS] Resolving the Ed448 context issue in RFC4492bis

Hi, all As mentioned in Tuesday's session, Ed448 and Ed25519ctx add a new parameter to the signature function: a context string. Setting this string to a different value for each application (where application could be "PKIX", "TLS", "IKE") leads to different results and thus a signature made

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

I don’t think this makes any difference in applications written on commodity servers using regular socket APIs. It’s a kind of architecture that has a quick special purpose processor that terminates the TCP and splits the incoming stream into records. The application records are forwarded to a

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

> On 3 Nov 2016, at 20:20, Martin Rex <m...@sap.com> wrote: > > Yoav Nir wrote: >> >> On 3 Nov 2016, at 16:31, Martin Rex <m...@sap.com> wrote: >>> >>> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >>>

Re: [TLS] Harmonizing 4492bis with TLS 1.3

> On 14 Dec 2016, at 3:33, Martin Thomson <martin.thom...@gmail.com> wrote: > > On 13 December 2016 at 22:47, Yoav Nir <ynir.i...@gmail.com> wrote: >> 2. Change 4492bis: >> a. no new curves for ed25519 and ed448. >> b. Two new signature algorith

[TLS] Pull Request #26 for RFC4492bis

As Sean suggested, this PR removes two paragraphs from the Introduction section. They’re no longer needed in our opinion. https://github.com/tlswg/rfc4492bis/pull/26 If no objections are heard, I will merge this over the weekend. Yoav

[TLS] Harmonizing 4492bis with TLS 1.3

Hi One issue that came up during WGLC for 4492bis is the way EdDSA signatures are mentioned in SignatureAndHashAlgorithm and in In TLS 1.2 and 4492bis we have a SignatureAndHashAlgorithm struct with one byte for hash algorithm and another for signature algorithm.. The HashAlgorithm can be

Re: [TLS] Confirming consensus: TLS1.3->TLS*

> On 2 Dec 2016, at 10:33, Peter Gutmann wrote: > > Stephen Farrell writes: > >> IIRC that was sort-of a condition for adoption of the work in the IETF 20 >> years ago, when there were two different protocols already being deployed and >>

Re: [TLS] Confirming consensus: TLS1.3->TLS*

> On 2 Dec 2016, at 19:58, David Benjamin wrote: > > (To clarify, I was not at all suggesting we go back to SSL. If we had a time > machine, I might make other suggestions, but as far as I know we do not.) Can’t we borrow one from tictoc?

Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

> On 2 Jan 2017, at 20:59, Eric Rescorla <e...@rtfm.com> wrote: > > > > On Mon, Jan 2, 2017 at 8:58 AM, Yoav Nir <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> wrote: >> >> . >> >> Since I think the utility of this falls o

  1   2   3   >