[TLS] tls - Requested sessions have been scheduled for IETF 100

Dear Sean Turner, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tls Session 1 (2:30:00) Thursday, Morning Session I 0930-1200 Room Name: Canning size: 250

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

On Fri, Oct 20, 2017 at 11:27 AM, Ilari Liusvaara wrote: > TLS 1.2 will very probably remain viable until quantum computers come > and demolish its security, unfortunately. As someone who has spent a lot of time working on compliance for payments systems, I have an

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

On 10/20/2017 02:16 PM, Russ Housley wrote: > > > Ben: > > I do not see the visibility extension taking any resources away from > the completion of TLS 1.3, so I do not see any reason to make it wait. > At risk of sounding overly self-important, there are a couple of old emails sitting in my

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

> On Oct 19, 2017, at 9:06 PM, Benjamin Kaduk wrote: > > On 10/19/2017 05:30 PM, Darin Pettis wrote: >> >> The question has been raised: "Why address visibility now?" The answer is >> that it is critical that the visibility capability is retained. It is >> available

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

On Fri, Oct 20, 2017 at 6:44 AM, Salz, Rich wrote: > >- A decade later, PCI-DSS is only ‘strongly encouraging’ TLS 1.2; the >actual requirement is TLS 1.1! Why should we expect that TLS 1.3 will >happen any faster? > > It's worse than that. PCI-DSS presently only

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

* Industry groups will force us to use newer versions * Likely there will be regulatory mandates in many of the marketplaces and business segments that large Enterprises participate in. * Business Partners or Government agency customers may require TLS1.3. These mandates/requirements

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

So it sounds like we are in agreement that continuing to use TLS 1.2 is not a viable long term alternative. Long-term is a subjective term, and using it can lead to misunderstandings. Based on current and previous actions around SSL and TLS versions, you can use TLS 1.2 for at

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

So it sounds like we are in agreement that continuing to use TLS 1.2 is not a viable long term alternative. -Original Message- From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Sent: Friday, October 20, 2017 12:14 PM To: Ackermann, Michael ; Salz, Rich

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

* Expressly reacting to the viability of continuing to use TLS1.2 forever. Nobody has said that, you are arguing a strawman. * Industry groups will force us to use newer versions * Policy standards will evolve in similar fashions. * Likely there will be regulatory mandates in

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

On 20/10/17 17:00, Ackermann, Michael wrote: > Expressly reacting to the viability of continuing to use TLS1.2 forever. Sorry, that's just misquoting. Rich asked "why do the WG need to debate this now" Darin said "we must, because we need snooping..." I said "no, you can use TLS1.2 and debate

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

Expressly reacting to the viability of continuing to use TLS1.2 forever. As a network person, this sounds a little like suggesting that if we feel there are operational shortcomings in IPv6, then we should just plan to stay with IPv4, forever. And that approach may even be viable for the

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

+1 to Rich. -- Regards, Uri Blumenthal From: TLS on behalf of Rich Salz Date: Friday, October 20, 2017 at 09:59 To: Darin Pettis , "tls@ietf.org" Subject: Re: [TLS] Publication of

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

On Oct 20, 2017, at 9:54 AM, Stephen Farrell wrote: > Others did > comment that the lack of client opt-in was a > bad aspect of draft-green, but I'm not sure > that anyone clearly said "I do want draft-green > snooping, but with client opt-in." I can say for myself

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

Minor clarification... On 20/10/17 14:44, Salz, Rich wrote: > Some members of the WG rose up and wanted explicit opt-in I don't think "wanted" is quite right. Some WG participants (e.g. me) wanted nothing like this to ever be done in the IETF. Others did comment that the lack of client opt-in

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

* The question has been raised: "Why address visibility now?" The answer is that it is critical that the visibility capability is retained. It is available today through the RSA key exchange algorithm. We understand that the issue was raised late and have fallen on the preverbal sword

Re: [TLS] Connection ID Draft

Hi Martin, According to the code you described in previous email, ISTM your idea of parsing the standard packet and CID packet is using the 5-tuple. The benefit is that no new contenttype or version is needed. But the precondition for well working is that the 5-tuple of the CID packet will not

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

I agree with Christian and Ben's points. I'd also add: On 19/10/17 23:30, Darin Pettis wrote: > The question has been raised: "Why address visibility now?" The answer is > that it is critical that the visibility capability is retained. It is > available today through the RSA key exchange