On Wed, Dec 2, 2015 at 7:52 PM, Jacob Appelbaum wrote:
> On 12/2/15, Salz, Rich wrote:
> >> it seems blindingly obvious to me that we want it
> >
> > Few things, particularly in the security arena, are blindingly obvious.
> If
> > it actually provides no true protection, then it's just as bad as
On Sun, Mar 18, 2018 at 12:09 PM, Darin Pettis wrote:
> Agreed. I know a lot of good work has gone into TLS 1.3 and having
> visibility to the data once it hits the data center seems like a new
> capability to the good folks working that have had TLS 1.3 in mind for the
> last couple years. B
On Mon, Mar 19, 2018 at 9:23 AM, Yoav Nir wrote:
[snip]
> > On 19 Mar 2018, at 7:32, Daniel Kahn Gillmor
> wrote:
> > So if this technology were deployed on a network where not all parties
> > are mutually trusting, it would offer network users a choice between
> > surveillance by the network on
If we're looking for precedent and support, the Canadian government
recently (like in the last week or two) issued a policy requiring TLS 1.0
and 1.1 be disabled:
https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-se
On Thu, Nov 8, 2018 at 9:31 PM Ryan Carboni wrote:
> On Thursday, November 8, 2018, Eric Rescorla wrote:
>
>> It's also worth noting that in practice, many sites are served on
>> multiple CDNs which do not share keying material.
>>
>
> Encrypting common knowledge is cargo cult fetishism for cry
On Wed, Aug 31, 2016 at 7:05 PM, Richard Barnes wrote:
> I am in total agreement with Nick here. "TLS 1.3" accurately describes
> what we're doing here, and it's consistent with our past naming scheme.
>
> There is no upside to changing away from 1.3, and as Nick notes, lots of
> potential downs
On Thu, Nov 17, 2016 at 9:12 PM, Sean Turner wrote:
> At IETF 97, the chairs lead a discussion to resolve whether the WG should
> rebrand TLS1.3 to something else. Slides can be found @
> https://www.ietf.org/proceedings/97/slides/slides-97-tls-
> rebranding-aka-pr612-01.pdf.
>
> The consensus i
It seems like TLS 2 and TLS 2.0 have very little support, so it's really
just deciding between:
TLS 1.3
TLS 4 (or maybe 4.0)
I'll just amplify Rich's and djb's points by noting that the cost of
switching away from TLS 1.3 really only affects a very small number of
people -- really just the people
On Sun, Nov 20, 2016 at 2:17 PM, Filippo Valsorda wrote:
> I'm definitely for 1.3.
>
> I get where 4 is coming from, but 1.2 is not going anywhere soon, and we
> spent the last 10 years training people that the high-numbered one is
> bad, and that the 1.x ones are cool.
>
> I really don't want to
On Fri, Jul 7, 2017 at 4:04 PM, Russ Housley wrote:
>
> The enterprise wants forward secrecy on the public Internet. Terminating
> the TLS session at the load balancer preserves forward secrecy on the
> public Internet.
>
> In your response, you ignored a fairly significant point in my previous
On Sat, Jul 8, 2017 at 11:31 AM, Paul Turner wrote:
>
> The Internet Draft describes the use of static (EC)DHE for traffic
> entirely inside enterprise networks and intends to clearly state that it
> should not be used for "information passed across the Internet". If we have
> not been clear enoug
On Sun, Jul 9, 2017 at 2:04 AM, Colm MacCárthaigh wrote:
>
> On Sat, Jul 8, 2017 at 9:27 AM, Watson Ladd wrote:
>>
>> > They also don’t want to install TLS proxies all over the place. That’s
>> a
>> > large extra expense for them.
>>
>> Nginx exists. What's the blocker?
>
>
> Here's how these n
On Mon, Jul 10, 2017 at 6:07 PM, Russ Housley wrote:
>
> >> So, I failed to convince you. However, you have also failed to
> >> convince me that the proposal is wiretapping under the definition in
> >> RFC 2804, Section 3.
> >
> > Consider SMTP/TLS. Where one MTA on the path supports this.
> > Sa
13 matches
Mail list logo
