Re: [TLS] ban more old crap

(no hats and al that) On 25/07/15 06:46, Viktor Dukhovni wrote: I hope, that by ~2017, RC4 will no longer be required either, and we'll be able to disable RC4 in Postfix at that time. Seems to me that should be a reasonable match for expecting to see TLS1.3 getting deployed in lots of parts

Re: [TLS] padding

On 25/08/15 00:22, Tom Ritter wrote: it would be _amazing_ if browser vendors enabled browser extension authors to choose the padding strategy for individual origins. Then we can crowdsource the effort. Excellent idea! S. ___ TLS mailing list

Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK

On 31/10/15 13:55, Eric Rescorla wrote: > > Thanks again for your contribution here. It's really important to have > this kind of analysis, especially at this stage before the design is > completely > hardened. +many, Thanks, S. ___ TLS mailing

[TLS] TRON workshop

Hiya, First, thanks all for all your ongoing work on TLS1.3. I'm sure we're all aware that this is important stuff that needs to be, and is being, done carefully with due attention to security analysis. Early in the process we had some brief discussion of pausing towards the end of the work to

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

On 02/12/15 15:38, Jacob Appelbaum wrote: >> > It’s quite >> > useful in hotspot/public wifi environments where making policy decisions >> > based on hostname is more than sufficient, and explicit user configuration >> > of proxy settings is a non-starter. > That is an attack in my book and

Re: [TLS] [Editorial Errata Reported] RFC7568 (4561)

On 08/12/15 04:05, Martin Thomson wrote: > On 8 December 2015 at 14:49, RFC Errata System > wrote: >> TLS 1.1 was first drafted in 2002, but not published until 2006. Similarly, >> TLS 1.2 was drafted in 2006, but not published until 2008. > > > The date on the

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-cached-info-20: (with COMMENT)

On 17/12/15 14:58, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-tls-cached-info-20: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this

[TLS] TRON submission in 2 weeks...

Just a reminder that the TRON workshop [1] initial submission date is December 1st. Please get your good submissions in! (Or hassle folks you know who should be submitting:-) Thanks, S. [1] https://www.internetsociety.org/events/ndss-symposium-2016/tron-workshop-call-papers

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

A few notes on this: - Calling for the IETF to do something isn't how it works. People who want thing X to be done need to write the draft and then see if it gets support. I suspect an md5-die-die-die draft would get quite a bit of support but... - The points Victor made about long-term stored

[TLS] Fwd: New Non-WG Mailing List: Lurk -- Limited Use of Remote Keys

We discussed this topic briefly at IETF94 and in more detail at the Marnew workshop. There seemed to be at least enough interest for a list so... Cheers, S. PS: I'd say best to wait 'till next Wednesday or so to start list discussion so that folks have time to join the list.

Re: [TLS] [Unbearable] Early code point assignment requests for "Transport Layer Security (TLS) Extensions" registry

Hi All, (Adding the TLS wg list, just in case.) I think this is fine and IANA should allocate a codepoint as requested. Cheers, S. On 02/02/16 23:50, John Bradley wrote: > > The Tokbind WG would like to ask for an early allocation of an IANA > code point for the "TLS Extension for Token

Re: [TLS] 0.5 RTT

On 23/02/16 22:37, Hugo Krawczyk wrote: > > (In particular, if these semantics may be based on stuff that happens > outside TLS, as Karthik and Watson were pointing out, then maybe we really > put a "Surgeon General" warning on 0.5 data of equal size to that of 0-RTT.) That, and/or also do a

Re: [TLS] I-D Action: draft-ietf-tls-cached-info-22.txt

Hi all, I plan to send the approval message for this tomorrow but wanted to just check one thing first. In his IESG review [1] Barry Leiba suggested reserving the value zero in the registry created by section 8.2, which makes sense I think as otherwise people will just be puzzled about what to

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

Hiya, This is ready to go but I've one question. Sorry I don't recall if this was discussed previously, if it was, then just say and I'll move this along to IETF LC. My question is: Should the WG take the opportunity to more tightly define the key exchange parameters for these ciphersuites?

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

Hiya, On 13/03/16 14:01, Eric Rescorla wrote: > > This is not an accurate way to represent the situation. Those WGs can safely > move from TLS 1.2 to 1.3 *as long as they don't use 0-RTT*. I agree your 2nd sentence but not your 1st. I also think it is prudent to assume that implementers will

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

On 13/03/16 14:49, Eric Rescorla wrote: > Perhaps we could start by actually sponsoring some of those > reviews. Given that HTTP is the primary customer for 0-RTT, perhaps > Mark or Martin would be willing to start a review there? I think that'd really help esp. if we can get folks looking at

Re: [TLS] Fwd: Cached Info

Hiya, On 08/03/16 01:19, Sean Turner wrote: > All, > > The cached-info draft got all the way to the IESG and then we receive > a couple of comments that require we bring the draft back to the WG > to discuss. Please figure out what changes if any are needed and let me know. If those are

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

Hiya, I mostly agree with what you wrote about specific mitigating factors for specific potential threats. For this thread though, maybe we're better talking about how we might get to where we can be confident that replayable data in TLS1.3 won't cause significant harm. I'm happy to talk more

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

On 31/03/16 00:22, Eric Rescorla wrote: > We already have a proposal for this. Please see: > http://tlswg.github.io/tls13-spec/#iana-considerations I like, support and will buy that a beer:-) Thanks, S. smime.p7s Description: S/MIME Cryptographic Signature

Re: [TLS] Asymmetric TLS

On 05/04/16 18:29, Sean Turner wrote: > But, what I will say as chair is that this would most definitely > require a charter change for the WG. FYI: you'd also have to climb over an AD-dead-body to get that. S. smime.p7s Description: S/MIME Cryptographic Signature

[TLS] AD review of draft-ietf-tls-falsestart-01

Hiya, I've done my AD review of this and have three questions I'd like to ask before starting IETF last call. I mostly care about the answer to #3. #1 is just a suggestion that might avoid some process-crap and #2 is just me being curious (unless #2 turns out to be a part of #3). (1) Why

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

If smaller devices don't use algorithms that can be used to talk to random servers on the Internet, then they are choosing to not try to get interop. That seems like a shame to me, unless there's a really good reason and IMO, mostly there isn't, at the ciphersuite level. I would hope we all won't

Re: [TLS] AD review of draft-ietf-tls-falsestart-01

Hi Sean, Thanks for moving this along, On 01/04/16 02:19, Sean Turner wrote: > On Mar 24, 2016, at 05:56, Stephen Farrell > <stephen.farr...@cs.tcd.ie> wrote: >> >> >> Hiya, >> >> Thanks for the speedy response... >> >> Again #3 b

[TLS] draft-ietf-tls-falsestart rfc editor note done

Dear IESG secretariat, (bcc'd), As discussed on the telechat I've updated the intended status in the tracker, added an RFC editor note asking them to change the header and cut'n'pasted the writeup into it's proper place. So I think this one is ready for you to send the usual approval

Re: [TLS] Alia Atlas' No Objection on draft-ietf-tls-falsestart-02: (with COMMENT)

On 19/05/16 02:16, Alia Atlas wrote: > Alia Atlas has entered the following ballot position for > draft-ietf-tls-falsestart-02: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this >

Re: [TLS] DTLS 1.3

On 04/07/16 20:54, Nikos Mavrogiannopoulos wrote: > > where id is sent by the server to the client either via an extension, or > by simply assuming that the client will copy and keep the ID seen at the > server packets (it doesn't really matter that this ID is unprotected as > it doesn't

Re: [TLS] DTLS 1.3

On 05/07/16 14:49, Nikos Mavrogiannopoulos wrote: > - Original Message - >> On 04/07/16 20:54, Nikos Mavrogiannopoulos wrote: >>> >>> where id is sent by the server to the client either via an extension, or >>> by simply assuming that the client will copy and keep the ID seen at the >>>

Re: [TLS] DTLS 1.3

On 07/07/16 12:52, Nikos Mavrogiannopoulos wrote: > On Thu, 2016-07-07 at 10:37 +0100, Stephen Farrell wrote: >> Hiya, >> >> Just on this one thing... >> >> On 07/07/16 09:13, Nikos Mavrogiannopoulos wrote: >>> >>> does not make the situation

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

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, given that ECC isn't trivial and nor are the changes nor how they were done to keep some things more or less

[TLS] Fwd: Last Call: Uplifting RFC5289 from informational to proposed standard

FYI, S. Forwarded Message Subject: Last Call: Uplifting RFC5289 from informational to proposed standard Date: Fri, 17 Feb 2017 08:53:27 -0800 From: The IESG Reply-To: i...@ietf.org To: IETF-Announce The IESG has received a

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

Thanks Yoav, Those all look like fine resolutions for my comments. Cheers, S. On 02/03/17 06:47, Yoav Nir wrote: > >> On 17 Feb 2017, at 18:58, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: >> >> >> Hiya, >> >> I've had a read of this and

Re: [TLS] Industry Concerns about TLS 1.3

Andrew, On 23/09/16 21:31, BITS Security wrote: > We do however want to raise our concern (and hopefully your > awareness) of what appears to be an unintended consequence of the > move to PFS-only choices. I don't believe I've heard anything in this discussion so far that wasn't well-known and

Re: [TLS] Industry Concerns about TLS 1.3

On 22/09/16 19:36, Yuhong Bao wrote: > This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?id=1188657 Yuk. Prioritising the needs of those debugging networks over the maybe 5-6 orders of magnitude more folks using them is ass-backwards IMO. That result looks to me like a very bad

Re: [TLS] [Cfrg] 3DES diediedie

Peter, On 28/08/16 13:01, Peter Gutmann wrote: > David McGrew (mcgrew) writes: > >> I don’t think you understood my point. IoT is about small devices connecting >> to the Internet, and IETF standards should expect designed-for-IoT crypto to >> be increasingly in scope. It is

Re: [TLS] Industry Concerns about TLS 1.3

On 28/09/16 01:17, Seth David Schoen wrote: > People with audit authority can then know all of the secrets, How well does that whole audit thing work in the financial services industry? (Sorry, couldn't resist:-) S. smime.p7s Description: S/MIME Cryptographic Signature

[TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01

Hi all, Sean and Joe wrote up this IANA registry draft as per discussions at WG meetings and on the list. As they've done the initial work, but are WG chairs, they wanted me (as responsible AD) to call consensus for it. (They wrote this up as finding authors for such fairly boring stuff was hard

Re: [TLS] extending the un-authenticated DTLS header

On 14/11/16 12:58, Nikos Mavrogiannopoulos wrote: > Hi, > For draft‐mavrogiannopoulos­‐dtls­‐cid­‐00 and we needed to extend the > DTLS un-authenticated part of the DTLS record header with an additional > field. That works well if this is the only draft ever extending the > DTLS record header.

Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01

Looks to me like this is fine to go ahead. So Sean and Joe, please submit a draft-ietf-tls- version of this I-D. Thanks, S On 22/10/16 15:30, Stephen Farrell wrote: > > Hi all, > > Sean and Joe wrote up this IANA registry draft as per > discussions at WG meetings and on the l

Re: [TLS] cross-domain cache sharing and 0rtt

Hiya, On 29/12/16 19:08, Eric Rescorla wrote: > On Thu, Dec 29, 2016 at 10:50 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie >> wrote: > >> >> >> On 29/12/16 18:38, Eric Rescorla wrote: >>> On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell

Re: [TLS] cross-domain cache sharing and 0rtt

On 30/12/16 16:14, Eric Rescorla wrote: > On Fri, Dec 30, 2016 at 6:43 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > >> >> Hiya, >> >> On 29/12/16 19:08, Eric Rescorla wrote: >>> On Thu, Dec 29, 2016 at 10:50 AM, Stephen F

Re: [TLS] cross-domain cache sharing and 0rtt

On 30/12/16 19:41, Bill Frantz wrote: > On 12/30/16 at 8:17 AM, stephen.farr...@cs.tcd.ie (Stephen Farrell) wrote: > >> Fair enough. I didn't read enough text to get that clearly >> I guess, which is my fault:-) > > If you didn't read enough, is this a mistake that

[TLS] cross-domain cache sharing and 0rtt (was: Re: Requiring that (EC)DHE public values be fresh)

On 29/12/16 18:38, Eric Rescorla wrote: > On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie >> wrote: > >> >> Hiya, >> >> On 29/12/16 17:37, Adam Langley wrote: >>> https://github.com/tlswg/tls13-spec/pull/840 is a pu

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

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. I'd say give it a chance for one round of comments from Eric and/or others, and then submit. Or, submit before you head for an airport on your

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

Thanks Eric, Let's see what folks say in response to this and I can post anything not immediately resolved as a DISCUSS ballot. We can then process that in the coming week or two, and you can take over the DISCUSS for whatever's not resolved by the swap-over in Chicago. Or if someone else wants

Re: [TLS] RFC4492bis next steps

On 16/03/17 06:20, Yoav Nir wrote: > Hopefully I’ll be all done and ready to submit a new version as soon > as submissions are re-opened on the 27th. If we're ready sooner, I'd prefer try get that out of the way next week. I can tell to secretariat to accept updates for this draft. (I'll likely

Re: [TLS] RFC4492bis next steps

On 16/03/17 12:52, Yoav Nir wrote: > OK, so I’ll merge the PRs tomorrow morning and start working on ekr’s > comments over the weekend. Excellent, thanks, S > > Yoav > >> On 16 Mar 2017, at 14:41, Stephen Farrell >> <stephen.farr...@cs.tcd.ie> wrote: >&

Re: [TLS] Uplifting 5289

FWIW, the IETF LC for this has ended now and I plan to send the approval message for the uplift to the secretariat later today. Thanks, S. On 16/03/17 20:33, Yoav Nir wrote: > Oh, sorry. I missed that it was Informational. > > In that case there’s just the issue that it has ECDH ciphersuites at

Re: [TLS] security considerations for draft-rescorla-tls-subcerts

is non-negligible, which I assume is the case. Was that considered? Cheers, S. > > > Subodh > > ____ From: Stephen Farrell > <stephen.farr...@cs.tcd.ie> Sent: Wednesday, April 5, 2017 12:30:31 > PM To: Subodh Iyengar; Simon Friedberger; tls@ietf

Re: [TLS] security considerations for draft-rescorla-tls-subcerts

I've no strong opinion for or against this. One question below though. On 05/04/17 17:07, Subodh Iyengar wrote: > The threat model here is that since if a less-trusted host having a > key is compromised for a certain period of time without detection, > and an attacker can steal private keys

Re: [TLS] WG adoption call: SNI Encryption

On 17/08/17 05:18, Martin Thomson wrote: > https://tools.ietf.org/html/rfc7858 > > I hear that there are even implementations and deployments. Yes, I used the resolver doing this at the last IETF meeting. It worked. Not "just worked," but pretty good. > > It's certainly time to have the

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

Hi Russ, On 07/07/17 17:35, Russ Housley wrote: > Repeating from above, the non-ephemeral DH keys are associated only > with sessions that are inside the enterprise datacenter. I find it really hard to believe anyone is convinced of that. Yes, one could chose to use this proposed wiretapping

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

On 07/07/17 19:40, Kyle Rose wrote: > an informational draft submitted via the ISE ...has nothing to to with this WG and ought consume no cycles on this list or in meetings. Yes, the ISE is the route 2804 envisages for documenting wiretapping schemes such as this. The authors of this draft

Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!

Hiya, On 14/07/17 15:51, Sean Turner wrote: > Please let us know your thoughts. 80 minutes for wiretapping is too much. Zero would be better. But if not... I'd suggest: 10 minutes for draft-green, 10 minutes to describe issues with that (i.e. the slot for which I continue to ask) and then 10

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

On 09/07/17 07:23, Colm MacCárthaigh wrote: > Dismissing concerns with trivial and shallow analysis can serve to diminish > the success of TLS1.3, because the users don't need to adopt it, and can > end up blocking it and creating a failure of "TLS 1.3 doesn't work in XXX > environments". Over

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

On 07/07/17 22:38, Russ Housley wrote: > Stephen: > You didn't refer to 2804 and the standards track. As an author do you really think this can be on the standards track and yet not obsolete 2804? >>> >>> Yes. >> >> We disagree. >> >>> Section 3 of RFC 2804 offers pretty clear

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

On 07/07/17 22:38, Russ Housley wrote: > Stephen: > You didn't refer to 2804 and the standards track. As an author do you really think this can be on the standards track and yet not obsolete 2804? >>> >>> Yes. >> >> We disagree. >> >>> Section 3 of RFC 2804 offers pretty clear

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

Russ, You didn't refer to 2804 and the standards track. As an author do you really think this can be on the standards track and yet not obsolete 2804? If you do, then I don't understand that. (And would argue you are holding a counter-factual opinion.) If you do not, then why does the draft

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

On 11/07/17 20:01, Michael StJohns wrote: > Basically, 2804 is woefully out of date with respect to the current > state of the world. As I said before I do think the authors of this draft should indeed have said that it needs to obsolete 2804 as that is required for them to get the standards

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

On 11/07/17 20:11, Christian Huitema wrote: > > For various reasons, some implementations may be tempted to use static > (EC) DH private key. Using such keys lowers the security guarantees of > TLS 1.3. Adversaries that get access to the static (EC) DH private key > can now get access to the

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

To add to Ted's clarification requests: On 11/07/17 19:39, Steve Fenter wrote: > Network security monitoring is not just monitoring traffic that > results from communications with customers and partners. All it > takes is for one user to click on a phishing email and there is > malware inside

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

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 from a different angle. In classic telephony wiretaps the carrier does the tap. There are similar situations with TLS... In hosted

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

On 11/07/17 21:03, Ted Lemon wrote: > Ah, you mean the first time the attack happens in the wild. Well, the first time it's detected in the wild. > Sure, I > can see that, but that gains the attacker no real advantage over just > exfiltrating all the keys. I agree. I think one can

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

On 10/07/17 23:32, Russ Housley wrote: > Stephen: > > >> And to avoid a repeat of Russ' failed justification, many >> protocols use and depend on TLS where the entity >> controlling the TLS server private key materials is not the >> higher layer sender or receiver, so all

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

On 10/07/17 16:30, Ackermann, Michael wrote: > Given the above scenario, I do not understand how this can be construed as > "Wiretapping".2804 seems to make this clear. TLS is much more widely used that you seem to imagine. Please see the comments to the effect that there is no way to

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

On 10/07/17 23:07, Russ Housley wrote: > Stephen: > >>> And to avoid a repeat of Russ' failed justification, many protocols use and depend on TLS where the entity controlling the TLS server private key materials is not the higher layer sender or receiver, so all four points

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

will greatly detract from its development. > You did not respond about the Prague agenda. I continue to ask that you not give this bad idea more f2f time. If you do give it time, then I'd ask for equal time to debunk this bad idea. But better to have zero time. S. > J > >> On Jul

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

Regards, Uri Blumenthal > > On 7/10/17, 15:03, "TLS on behalf of Nico Williams" > <tls-boun...@ietf.org on behalf of n...@cryptonector.com> wrote: > > On Mon, Jul 10, 2017 at 08:01:32PM +0300, Yoav Nir wrote: >>> On 10 Jul 2017, at 17:16, Stephen F

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

On 10/07/17 17:42, Colm MacCárthaigh wrote: > It's clear that there is a strong distaste here for the kind of MITM being > talked about It is not (only) "distaste," it is IETF policy as a result of a significant debate on wiretapping. S signature.asc Description: OpenPGP digital signature

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

t should continue. I sincerely hope this will lead to > some mutually acceptable dialogue and related solutions. > > > > -----Original Message- From: Stephen Farrell > [mailto:stephen.farr...@cs.tcd.ie] Sent: Monday, July 10, 2017 3:37 > PM To: Ackermann, Michael <mac

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

On 10/07/17 22:26, Russ Housley wrote: > Stephen: > >> And to avoid a repeat of Russ' failed justification, many protocols >> use and depend on TLS where the entity controlling the TLS server >> private key materials is not the higher layer sender or receiver, >> so all four points in the

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

Hiya, On 07/07/17 22:12, Russ Housley wrote: > Stephen: > >> You didn't refer to 2804 and the standards track. As an author do >> you really think this can be on the standards track and yet not >> obsolete 2804? > > Yes. We disagree. > Section 3 of RFC 2804 offers pretty clear definition of

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

On 08/07/17 17:38, Jeremy Harris wrote: > The predicated architecture - tappable inside, non-tappable outside the > enterprise That's fiction. S signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org

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

On 08/07/17 16:39, Tony Arcieri wrote: > Clearly there are echoes of the scary protocols of yesteryear, i.e. > Clipper/LEAP. I think if you visit Matt Green's Twitter page and check the > image header you will discover he is quite familiar with these things, and > my personal presumption would

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

asing security. > > Consequently, we would ask that this discussion not be shut down as > you request. > > Paul > > -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On > Behalf Of Stephen Farrell Sent: Saturday, July 8, 2017 10:33 To: > Yaron Sheffer <yar

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

I don't believe the WG should adopt this as it goes against rfc2804 and encourages bad behaviour. We ought not be helping to normalise broken crypto. I'm happy to repeat that at the mic in Prague but would be even happier if this draft were not discussed there - these attempts to weaken security

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

On 08/07/17 18:05, Russ Housley wrote: > In draft-green-tls-static-dh-in-tls13, there is not one. I have not > thought about it in these terms. The server, if acting in bad faith, > can always release the client's traffic. Is it bad faith if the server is compelled to enable this wiretap

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

On 08/07/17 18:39, Watson Ladd wrote: > Why did static RSA not imply that? We never defined a standards track API for handing over the RSA private key. This draft proposes to do exactly the equivalent, hence the conflict with 2804. S. signature.asc Description: OpenPGP digital signature

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

Sean/Joe, This is a request that you, as chairs, shut down the distracting wiretapping discussion, at least until DTLS1.3 is done. I have planned to spend time reading draft 21 and DTLS, but that won't happen if we keep having to fight off the latest attempts to break TLS. I'd not be surprised

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

On 08/07/17 03:06, Ackermann, Michael wrote: > Converting all session traffic to clear text is not a viable > alternative for ANY enterprises or industries that I am aware of. In > particular those in financial sectors. Security policies, legislation > and in many cases just good practice would

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

On 12/07/17 21:01, Kathleen Moriarty wrote: > With no hat on... > > The difference with the WordPress & SMTP examples is that you know > content will sit in plaintext on the servers, whereas with POTS, you > need to wiretap to get the voice content. You only expect the log > that the call

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

On 12/07/17 16:54, Kyle Rose wrote: > On Wed, Jul 12, 2017 at 11:28 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie >> wrote: > >> >> >> On 12/07/17 16:27, Kyle Rose wrote: >>> The telco in the POTS case isn't either endpoint. The third-party >

[TLS] possible new work item: not breaking TLS

Hi again TLS WG chairs, I've done a bit more work on the collection of arguments against the latest break-TLS proposal. [1] I plan to keep working on that so more input is welcome. (Corrections where I've gotten stuff wrong are even more welcome.) I'd like to again request some time on the

Re: [TLS] possible new work item: not breaking TLS

as draft-green:-) Cheers, S. [1] https://github.com/sftcd/tinfoil On 13/07/17 13:00, Stephen Farrell wrote: > > Hi again TLS WG chairs, > > I've done a bit more work on the collection of arguments > against the latest break-TLS proposal. [1] I plan to keep > working on that so mor

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

Hiya, While we're waiting on Sean/Joe... :-) On 10/07/17 14:54, Polk, Tim (Fed) wrote: > First, I do not see this as a “wiretapping discussion” based on my > reading of 2804, although others may disagree. s/may/do/ Figure 3 in the draft is absolutely clearly describing an architecture for

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

On 19/07/17 14:09, Benjamin Kaduk wrote: > As Stephen noted in his presentation, a lot of the proposals for passive > decryption can be seen as trying to turn TLS from a two-party protocol > into a three-party protocol. Which is probably the right way to think > about it, even when all (three)

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

On 19/07/17 17:58, Benjamin Kaduk wrote: > On 07/19/2017 11:49 AM, Stephen Farrell wrote: >> >> On 19/07/17 14:09, Benjamin Kaduk wrote: >>> As Stephen noted in his presentation, a lot of the proposals for passive >>> decryption can be seen as trying to t

Re: [TLS] SAAG TLS working group report

Hi Joe, On 20/07/17 09:54, Joseph Salowey wrote: > We had presentations on the pros and cons of a proposed mechanism > to decrypt TLS messages within the data center. A hum indicated that > there was roughly equal support on both sides. Therefore, well will > continue the discussion and it

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

On 20/07/17 12:44, Paul Turner wrote: > > I believe Russ was outlining a method where an extension would be > added to TLS 1.3 that would provide for delivery of a decryption key > to a third party during the handshake (correct me if I got that > wrong, Russ). Because it would be during the

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

Hiya, On 20/07/17 13:04, Paul Turner wrote: > Let’s use the oppressive government institution that I believe you’ve > mentioned (pardon me if I got that wrong) with a connection over the > Internet in this case. Sorry, I'm not sure what you mean there, but guessing, yes, there can be multiple

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

On 20/07/17 18:08, Colm MacCárthaigh wrote: > On Thu, Jul 20, 2017 at 9:55 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > >> On 20/07/17 17:43, Colm MacCárthaigh wrote: >>> that's the term that people keep applying, >> >> That term was appr

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

On 20/07/17 17:43, Colm MacCárthaigh wrote: > that's the term that people keep applying, That term was appropriate for draft-green as justified in [1] That's disputed by some folks but it's the correct term. Claiming that current browsers "support" wiretapping is plain odd to me and not that

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

On 20/07/17 16:23, Paul Turner wrote: >> I'd assert there's no way TLS clients in general could know when to >> set or unset the "please wiretap me" evil bit in a ClientHello, >> regardless of how complex a configuration is used. > > > It seems like the guidance would be for all TLS clients

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

On 20/07/17 15:40, Paul Turner wrote: > I’m assuming that you’re referring to multiple nations being between > the TLS client and server. If a TLS client is set to not include the > extension, it seems the TLS client would simply close the connection. > It seems the client could choose whether

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

On 15/07/17 23:55, Colm MacCárthaigh wrote: > So far responses on the mailing list have been saying "Don't use > pcap, instead run proxies". Sorry, but that is incorrect. Some list participants have said "we need pcap" and others have said that "no, we do not need to use packet capture." And

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

Hiya, On 15/07/17 20:49, Roland Zink wrote: > TLS is a two endpoint protocol. It looks like many of the use cases > describe problems with more than two endpoints but are using TLS because > it is commonly available. So should TLS be extended to be an n-party > protocol (or is this always

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

Hiya, On 16/07/17 05:41, Colm MacCárthaigh wrote: > On Sat, Jul 15, 2017 at 5:39 PM, Stephen Farrell > <stephen.farr...@cs.tcd.ie> wrote: > >> On 15/07/17 23:55, Colm MacCárthaigh wrote: >>> So far responses on the mailing list have been saying "Don't

Re: [TLS] 32 byte randoms in TLS1.3 hello's

On 25/07/17 04:53, Peter Gutmann wrote: > Colm MacCárthaigh writes: > >> I think the fix for this is really at the application level; if you >> want defense-in-depth against PRNG problems, it's probably best to use >> separate RNG instances for public data (e.g.

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

On 23/07/17 13:43, Blumenthal, Uri - 0553 - MITLL wrote: > Ilari, > > I got your point. > > But in view of the request this WG is discussing now, I see only two > reasonable (IMHO) opinion: 1. Tell those requestors to go away > because TLS 1.3 has been designed to always be forward-secure; or

[TLS] 32 byte randoms in TLS1.3 hello's

Hiya, I'm guessing many folks interested in TLS may have been at the QUIC session in Prague and hence missed out on the excellent talk by Stephen Checkoway on the juniper dual-ec incident. (I highly recommend taking a peek at the slides [1] or reading the paper [2] or watching the video wherever

Re: [TLS] 32 byte randoms in TLS1.3 hello's

p and q, >> generated independently leading to an attack... >> >> Here if the seeds to initialize the RNGS are related, or one is weak, or >> worst if the seed is a raw source that doesn’t change in the moments >> between the two CSPRNG inits, that'd be bad, even

  1   2   3   4   5   >