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

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

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

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

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

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

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

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

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

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

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

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

Re: [TLS] tlsflags and "responses"

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

Re: [TLS] tlsflags and "responses"

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

Re: [TLS] IANA Registry for TLS-Flags

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

Re: [TLS] IANA Registry for TLS-Flags

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

[TLS] IANA Registry for TLS-Flags

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

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

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

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

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

[TLS] tls-flags: abort on malformed extension

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

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

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

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

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

Re: [TLS] Flags extension and announcing support

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

[TLS] Flags extension and announcing support

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

Re: [TLS] TLS Flags Open Question

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

[TLS] TLS Flags Open Question

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

Re: [TLS] Proposed change in TLS-Flags

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

Re: [TLS] Proposed change in TLS-Flags

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

[TLS] Consultation About Assignment of ExtensionTypes

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

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

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

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

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

[TLS] tls-flags Guidance on Allocating Bits

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

Re: [TLS] New direction for TLS?

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

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

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

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

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

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

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

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

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

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

019, at 20:48, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > >Title : A Flags Extension for TLS 1.3 >

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

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

Re: [TLS] A flags extension

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

Re: [TLS] A flags extension

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

Re: [TLS] A flags extension

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

Re: [TLS] A flags extension

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

Re: [TLS] A flags extension

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

Re: [TLS] A flags extension

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

Re: [TLS] A flags extension

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

[TLS] A flags extension

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

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

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

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

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

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

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

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

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

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

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

Re: [TLS] Breaking into TLS to protect customers

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

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

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

Re: [TLS] Breaking into TLS to protect customers

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

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

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

Re: [TLS] Breaking into TLS to protect customers

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

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

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

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

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

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

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

Re: [TLS] TLS 1.3 : small fragments attack

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

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

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

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

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

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

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

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

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

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

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> On 24 Oct 2017, at 22:54, David A. Cooper wrote: > > Why would these schools settle for a half measure that only allows them to > snoop on traffic between their students and servers provide the keys to their > Internet traffic to the schools? If a school wants to

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> On 24 Oct 2017, at 22:27, Ralph Droms wrote: > > >> On Oct 24, 2017, at 3:23 PM, Salz, Rich wrote: >> >> I use an airplane as an example of a “captive” population, substitute any >> similar group you want. >> >> • Yes, any box that sits

Re: [TLS] editorial error in draft-ietf-tls-rfc4492bis-17

Thanks, Martin. This is correct. So there are two ways to fix this: As Martin suggests, make TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA one of the MTI instead of the current, or Add 0xC0,0x23 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256) to the list of ciphersuites. The first seems more consistent to

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> On 22 Oct 2017, at 21:40, Ted Lemon wrote: > > On Oct 22, 2017, at 1:54 PM, Russ Housley > wrote: >> No one is requiring TLS 1.3 that I know about. However, there are places >> that require visibility into TLS. I will

Re: [TLS] Update on TLS 1.3 Middlebox Issues

> On 7 Oct 2017, at 17:17, Nick Sullivan wrote: > > Yoav, > > Let me make a correction to your scenario:. Instead of: > "You’ll need it for Chrome to work with Google." > it's: > "You’ll need it for Chrome to work with Google, Facebook, and most of the 10% > of

Re: [TLS] Update on TLS 1.3 Middlebox Issues

> On 7 Oct 2017, at 4:01, Salz, Rich wrote: > > Thanks very much for the update. > > There is a third option, name the devices which are known to cause problems, > and move forward with the draft as-is. +1. I like this third option. > 2. Tell all those vendors "You have 1

Re: [TLS] Should CCM_8 CSs be Recommended?

> On 4 Oct 2017, at 16:29, Russ Housley <hous...@vigilsec.com> wrote: > > >> On Oct 4, 2017, at 3:30 AM, Yoav Nir <ynir.i...@gmail.com >> <mailto:ynir.i...@gmail.com>> wrote: >> >>(IoT) - This requirement is for interoperability with I

Re: [TLS] Should CCM_8 CSs be Recommended?

What we did in IPsec in RFC-tp-be 8221 is the following. This (including the IoT marker) is also going to appear in the IANA registry: +-++-++ | Name| Status | AEAD| Comment|

Re: [TLS] Is there a way forward after today's hum?

> On 20 Jul 2017, at 8:01, Russ Housley wrote: > > Ted, if we use a new extension, then the server cannot include it unless the > client offered it first. I am thinking of an approach where the server would > include information needed by the decryptor in the response.

Re: [TLS] datacenter TLS decryption as a three-party protocol

> On 19 Jul 2017, at 17:07, Blumenthal, Uri - 0553 - MITLL > wrote: > This is exactly right. We have a real problem here. We should really solve it. We should do the math. :) >>> >>> Is there appetite to do this work? If we restrict this to two paths,

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On 17 Jul 2017, at 17:06, Roland Dobbins wrote: > > On 16 Jul 2017, at 11:19, Salz, Rich wrote: > >> The key point here is Within the enterprise. > > +1 It’s an illusion that inside the enterprise uses different technologies than outside the enterprise. IP was for

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On 17 Jul 2017, at 16:20, Roland Dobbins <rdobb...@arbor.net> wrote: > > On 17 Jul 2017, at 16:15, Yoav Nir wrote: > >> Obligatory XKCD link: > > This one is actually more relevant, IMHO: > > <https://xkcd.com/538/> ISTM that this is a great argu

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On 17 Jul 2017, at 13:48, Salz, Rich wrote: > >>> DDoS mitigation can be done at endpoints >> >> Not at scale. That's why it isn't done that way. > > Sometimes it is. > > Can we stop making definitive declarations like this? > > There are more things in the world,

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On 15 Jul 2017, at 9:12, Daniel Kahn Gillmor wrote: > > On Sat 2017-07-15 05:58:31 +, Salz, Rich wrote: >> Unless I missed the reply, I did not see any answer to my question as >> to why it must be opt-in. Do we think evildoers will tell the truth >> about what

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On 14 Jul 2017, at 18:35, Joseph Lorenzo Hall wrote: > > Just want to +1 the notion that this should be opt-in for both sides and in > an extension! It’s a good notion, but “we have to change one side” usually wins over “we have to change both sides” signature.asc

Re: [TLS] chairs - please shutdown wiretapping discussion...

> On 12 Jul 2017, at 0:21, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > > On 11/07/17 22:10, Yoav Nir wrote: >> If one of the parties to a conversation cooperates with the wiretap, >> this isn’t an attack. > Lemme try on this one again fro

Re: [TLS] chairs - please shutdown wiretapping discussion...

> On 11 Jul 2017, at 23:54, Christian Huitema wrote: > > On 7/11/2017 1:31 PM, Stephen Farrell wrote: > >> PS: There are also genuine performance reasons why the same >> DH public might be re-used in some cases, so there would be >> false positives in a survey to consider

Re: [TLS] chairs - please shutdown wiretapping discussion...

> On 10 Jul 2017, at 17:16, Stephen Farrell wrote: > > >> 2. this proposal offers >> significantly better security properties than current practice >> (central distribution of static RSA keys) > > I fail to see any relevant difference in security properties >

Re: [TLS] chairs - please shutdown wiretapping discussion...

> On 8 Jul 2017, at 18:39, Tony Arcieri wrote: > > I was one of the people arguing my hardest against the BITS Security proposal > to continue to (ab)use RSA static keys to allow passive MitM, even though TLS > 1.3 had already moved forward on what I would call a more

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On 8 Jul 2017, at 6:18, Timothy Jackson wrote: > > As an earlier poster asked, what advantage does this approach have over > TLS-inspecting proxies? Every IPS/IDS/next gen firewall with which I am > familiar is able to terminate at TLS connection,

Re: [TLS] Separate APIs for 0-RTT

> On 23 Jun 2017, at 5:10, Timothy Jackson wrote: > > +1 and a preference for MUST, just so people understand the importance. > > Since we're agreed that 0-RTT data and 1-RTT data have (almost) the same > security properties once the handshake completes, it seems to

Re: [TLS] Security review of TLS1.3 0-RTT

> On 5 Jun 2017, at 6:06, Bill Cox wrote: > > On Sun, Jun 4, 2017 at 4:08 PM, Benjamin Kaduk > wrote: > > Do we have a good example of why a non-safe HTTP request in 0-RTT would lose > specific properties required for

Re: [TLS] AD Review of draft-ietf-tls-tls13

> On 22 May 2017, at 20:27, Benjamin Kaduk wrote: > > On 05/22/2017 12:17 PM, Viktor Dukhovni wrote: >>> On May 22, 2017, at 1:06 PM, Benjamin Kaduk >>> wrote: >>> >>> Given the apparent strength of opinion against removing

Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

Hi. Draft-17 submitted. Yoav > On 4 May 2017, at 23:09, Kathleen Moriarty <kathleen.moriarty.i...@gmail.com> > wrote: > > Yoav, > > On Thu, May 4, 2017 at 1:59 PM, Yoav Nir <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> wrote: >>

Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

Thanks! That would have been an embarrassing erratum. > On 5 May 2017, at 14:31, Hubert Kario <hka...@redhat.com> wrote: > > On Thursday, 4 May 2017 19:59:29 CEST Yoav Nir wrote: >>> 2) In Section 6: >>> Server implementations SHOULD support all of

Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

> On 4 May 2017, at 16:09, Kathleen Moriarty > wrote: > > I haven't approved it yet as I noticed there was no response (that I saw) to > Alexey's comment and no change in the draft as a result of his comments. You mean these comments?

Re: [TLS] draft-ietf-tls-tls13-19 section 1.2 cleanup

Hi. So I’ve just submitted PR #931 to resolve this. https://github.com/tlswg/tls13-spec/pull/931 Yoav > On 28 Mar 2017, at 23:31, Dave Garrett wrote: > > On Tuesday, March 28, 2017 11:31:56 am Short, Todd wrote: >> I

Re: [TLS] Updated Code Execution Draft

Cute. But these documents are supposed to be sent to either the RFC editor or the ISE directly, and no later than early March. > On 1 Apr 2017, at 20:03, Yolo Crypto wrote: > > Hello all, > > I have just revised my draft which describes how to extend TLS with a general

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

> On 21 Mar 2017, at 11:04, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > Thanks Yoav, > > On 21/03/17 07:44, Yoav Nir wrote: >> Some that are not addressed, I’ve answered below. Let me know if you >> want me to merge and submit. > &

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

> On 21 Mar 2017, at 14:28, Sean Turner wrote: > > >> On Mar 21, 2017, at 08:02, Eric Rescorla wrote: >> >> What we probably should actually do is make this depend on the IANA draft >> and then mark >> these Not Recommended. > > That is an option as none of

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

Hi This pull request addresses most of these comments. https://github.com/tlswg/rfc4492bis/pull/39 There is some discussion on that PR Some that are not addressed, I’ve answered below. Let me know if you want me to merge and submit. Yoav On

Re: [TLS] RFC 6066 - Max fragment length negotiation

hat case, adding the extension to the ClientHello should not be infeasible. Yoav > On Thu, Mar 16, 2017 at 4:48 PM, Yoav Nir <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> wrote: > Hi, Nitin. > > In section 7.4.1.4 of RFC 5246 it says: > >An extension type MUST NO

Re: [TLS] RFC 6066 - Max fragment length negotiation

Hi, Nitin. In section 7.4.1.4 of RFC 5246 it says: An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello. So the answer is no. Only the client may request this. Yoav > On 16 Mar 2017, at 21:12, Nitin Shrivastav

Re: [TLS] Uplifting 5289

be uplifted then. Yoav > On 16 Mar 2017, at 21:23, Eric Rescorla <e...@rtfm.com> wrote: > > This is actually uplift to PS. > > On Thu, Mar 16, 2017 at 12:16 PM, Yoav Nir <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> wrote: > >> On 16 Mar 201

Re: [TLS] Uplifting 5289

> On 16 Mar 2017, at 21:01, kathleen.moriarty.i...@gmail.com wrote: > > > > Please excuse typos, sent from handheld device > >> On Mar 16, 2017, at 11:37 AM, Yoav Nir <ynir.i...@gmail.com> wrote: >> >> >>> On 16 Mar 2017, at 17:17, Eri

Re: [TLS] Uplifting 5289

> On 16 Mar 2017, at 17:17, Eric Rescorla wrote: > > Hi folks > > I note that we are proposing to uplift RFC 5289 to PS, despite the fact that > it > standardizes some CBC cipher suites, which the WG is looking to move away > from. I recognize that these are the only cipher

Re: [TLS] RFC4492bis next steps

OK, so I’ll merge the PRs tomorrow morning and start working on ekr’s comments over the weekend. Yoav > On 16 Mar 2017, at 14:41, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > > On 16/03/17 06:20, Yoav Nir wrote: >> Hopefully I’ll be all done and re

[TLS] RFC4492bis next steps

Hi. There are now three PRs pending for this draft: https://github.com/tlswg/rfc4492bis/pulls These all look fine to me. There is also ekr’s review that requires some more changes: https://www.ietf.org/mail-archive/web/tls/current/msg22628.html

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

LGTM > On 15 Mar 2017, at 21:32, David Benjamin <david...@chromium.org> wrote: > > How's this look? https://github.com/tlswg/rfc4492bis/pull/37 > <https://github.com/tlswg/rfc4492bis/pull/37> > > On Wed, Mar 15, 2017 at 2:45 PM Yoav Nir <ynir.i...@gmail.c

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

There is (going to be a re-spin). There already is a PR there. If you can make a PR to solve your issue, that would be great. > On 15 Mar 2017, at 19:20, David Benjamin wrote: > > If there's to be a respin anyway, I have another small editorial comment: >

  1   2   3   >