.gov/library/publications/the-world-factbook/geos/ch.html
but see also
https://www.cia.gov/library/publications/the-world-factbook/geos/tw.html
--
Brian Sniffen
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
I worry that this tool is so weak against a GFW-style adversary for the
>> purpose of allowing dissident access to restricted web sites that it will
>> be dangerous if released. But maybe I misunderstand the purpose. If this is
>> just to keep Western ISPs from monkeying wi
t;
The first obligation of an extension, whether it's heartbeat or key
escrow, is to show that it isn't going to hurt core TLS to have it out
there in the ecosystem.
-Brian
--
Brian Sniffen
Akamai Technologies
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hilarie Orman writes:
>> From: Derek Atkins
>> Date: Wed, 31 Aug 2016 10:17:25 -0400
>
>> "Steven M. Bellovin" writes:
>
>> > Yes. To a large extent, the "IoT devices are too puny for real
>> > crypto" is a hangover from several years ago. It was once true; for
>> > the most part, it isn
Erik Nygren writes:
> I'm also very supportive for the reasons you outline.
>
> However, I think we should consider calling it TLS 4 or TLS 4.0 or TLS 5.
>
> In particular, much of the non-technical audience still calls it "SSL" (pet
> peeve of many of us, I suspect) and having a version number c
Folks" are slow or not working they
>>> are just as unhappy as we are.
>>>
>>
>> Isn't that the market operating as expected? Those who deliver a stable
>> product at a competitive price are rewarded, while those who fail to deliver
>> or del
rs,
>>
>> J&S
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
--
Brian Sniffen
Akamai Technologies
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
kamai and Cloudflare's various
patented
approaches)---then the primary benefit of delegated credentials is lower
latency for session establishment.
But maybe the idea is to avoid the first circumstance and emphasize that
these are for the second case. Authors, can you describe what you have
in mind
ons that scale linearly with number of sites hosted)
- not everybody's going to do this, not even every TLS 1.3 instance
- if networks can't track activity, some will push users to stay on
TLS 1.2.
-Brian
--
Brian Sniffen
Akamai Technologies
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
sumptions that blur away the difference.
-Brian
--
Brian Sniffen
/(* Akamai - Faster Forward
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
escribe above fits into an extension, so (a) it
doesn't have to be done to ship TLS 1.3, and (b) it can be available for
use in general purpose browsers, and then disabled for the "enterprise"
case, and (c) I don't have to worry through the performance implications
of not be
Kyle Rose writes:
> On Mon, Jul 24, 2017 at 10:03 AM, Brian Sniffen wrote:
>
>> I could imagine making the server ECDH share dependent on the
>> client ECDH share, plus a local random value. At the end of the
>> session, the server discloses that random value, sho
on the draft before 20170818. If you
> object to its adoption, please let us know why.
I support wg adoption of this draft and am willing to review before
20170818.
-Brian
--
Brian Sniffen
Akamai Technologies
___
TLS mailing list
TLS@ietf.org
https
Having promised a review before August 18, I have three issues I'd like
to talk about. But first, thanks for keeping pushing on this. I am not
sure it will ever see wide adoption, but we'll surely never find out if
we don't try.
## Don't stand out
I think the requirement that the browser check
14 matches
Mail list logo
