On 8/28/15, Dang, Quynh wrote:
> Hi all,
>
>
> DSA is supported in the previous versions of TLS. It would be nice if
> someone who uses DSA can use it in TLS 1.3 as well.
>
>
> People who don't use DSA, then they don't use DSA. People who use DSA right,
> it should be fine for them to use DSA.
>
>
On 9/16/15, Jeffrey Walton wrote:
> On Wed, Sep 16, 2015 at 4:45 AM, Stephen Farrell
> wrote:
>>
>>
>> On 16/09/15 09:19, Peter Gutmann wrote:
>>> Jeffrey Walton writes:
>>>
Somewhat off-topic, why does TLS not produce a few profiles. One can be
"Opportunistic TLS Profile" with a compa
On 9/21/15, Daniel Kahn Gillmor wrote:
> On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni
> wrote:
>> So the client would now need to cache some session data by transport
>> address, and other data by name and port. That's rather complex.
>
> This is already done by HTTP/2 clients, since they c
Dear Bryan,
On 11/30/15, Bryan A Ford wrote:
> Thanks Bill for the feedback.
>
> On 11/29/15 6:11 PM, Bill Cox wrote:
>> Thanks for the detailed description of why we might want to obfuscate
>> TLS record lengths. From a security point of view, the only potential
>> attack vector this might crea
On 11/30/15, Hubert Kario wrote:
> On Monday 30 November 2015 10:58:48 Bryan A Ford wrote:
>> On 11/30/15 2:40 AM, Peter Gutmann wrote:
>> > Nikos Mavrogiannopoulos writes:
>> >> I believe your proposal is a nice example of putting the cart
>> >> before the horse. Before proposing something it sh
On 12/1/15, Viktor Dukhovni wrote:
> On Mon, Nov 30, 2015 at 10:34:27AM +, Peter Gutmann wrote:
>
>> Bryan A Ford writes:
>>
>> >It would work just as well and in exactly the same way if the AEAD is
>> >replaced with the traditional Encrypt-then-MAC construction, for
>> > example.
>>
>> No it
On 12/1/15, Yoav Nir wrote:
>
>> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum wrote:
>>
>> On 12/1/15, Viktor Dukhovni wrote:
>>> On Mon, Nov 30, 2015 at 10:34:27AM +, Peter Gutmann wrote:
>>>
>>>> Bryan A Ford writes:
>>>>
>
On 12/2/15, Peter Gutmann wrote:
> Jacob Appelbaum writes:
>
>>I think the only thing that comes close is when I've named a classified US
>>government surveillance program (XKeyscore) that would probably have
>> trouble
>>with it.
>
> Why would XKeyscore
On 12/2/15, Yoav Nir wrote:
>
>> On 2 Dec 2015, at 1:38 PM, Jacob Appelbaum wrote:
>>
>> On 12/1/15, Yoav Nir wrote:
>>>
>>>>
>>>> Which would those be? And what is the definition of capital-intensive
>>>> for those watchi
On 12/2/15, Eric Rescorla wrote:
> On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford wrote:
>
>> On 02 Dec 2015, at 06:02, Martin Thomson
>> wrote:
>> > On 1 December 2015 at 08:22, Bryan A Ford
>> > wrote:
>> >> The 2-byte length field in each record's header no longer indicates
>> >> the length of t
On 12/2/15, Mike Copley wrote:
>
> On 2/12/2015, at 1:38 pm, Yoav Nir wrote:
>
>>
>>> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum wrote:
>>>
>>>
>>>> These are corporate
>>>> firewalls. When it comes to filtering HTTPS conn
On 12/2/15, Eric Rescorla wrote:
> On Wed, Dec 2, 2015 at 5:38 AM, Yoav Nir wrote:
>>
>> I don’t think Bryan’s proposal will hurt the capabilities of a Check
>> Point
>> firewall, and it will make life difficult for me as a developer no more
>> than it will make life difficult for developers of O
On 12/2/15, Martin Rex wrote:
> Jacob Appelbaum wrote:
>>
>> I hope that we'll hide the SNI data by default and I understand that a
>> discussion about encrypted SNI is currently scheduled for some point
>> in the future.
>
> Hiding SNI data is completel
On 12/2/15, Salz, Rich wrote:
>> I think that is false. One could easily use the "cleartext" SNI field and
>> insert an encrypted value. A hash of the name would be a simple example
>> but not a secure example, of course.
>
> Encrypted SNI doesn't give you the kind of protection you think that it
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 the
> security theater in US airports.
It provides protection. Spe
On 12/2/15, Martin Rex wrote:
> Jacob Appelbaum wrote:
>> On 12/2/15, Martin Rex wrote:
>>>
>>> So your client will have to know a-priori, out-of-band or be configured
>>> to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello
>>> wi
On 12/2/15, Dave Garrett wrote:
> On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote:
>> Encrypted SNI doesn't give you the kind of protection you think that it
>> does. We (me and a colleague) did a pretty thorough analysis that showed
>> this. It was not a conclusion we expected, or
On 12/3/15, Salz, Rich wrote:
>> It provides protection. Specifically it provides confidentially.
>
> It is far from clear that the privacy gains anything in the form of
> practical protection. Having looked at it, I'm unconvinced. And I've been
> a privacy/crypto advocate for a very very long t
On 12/3/15, Eric Mill wrote:
> 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 blindingl
On 12/3/15, Martin Thomson wrote:
> There are a lot of inaccuracies in that presentation, so I wouldn't
> pin too much on it.
>
I'm not pinning too much on it and I was surprised by the amount it
was suggested would win me over. I actually went in thinking that I'd
be crushed and concede; imagine
On 12/2/15, Eric Rescorla wrote:
> On Wed, Dec 2, 2015 at 7:34 AM, Jacob Appelbaum
> wrote:
>
>> On 12/2/15, Eric Rescorla wrote:
>> > On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford
>> wrote:
>> >
>> >> On 02 Dec 2015, at 06:02, Martin Thomso
On 12/3/15, Salz, Rich wrote:
>> I actually went in thinking that I'd be crushed and concede; imagine my
>> surprise!
>
> The fact that you viewed it as "crushed and concede" implies to me that your
> mind was already made up, and that no description of trade-offs was going to
> sway you. Is that
Hello,
On 12/3/15, Aaron Zauner wrote:
> PS:
>
> Aaron Zauner wrote:
>> No it's not. It's a very short presentation from a TLS-WG interim
>> meeting. The threat-model concerns Akamai's (and other's) current and -
>> possibly - future use of TLS. We're not trying to build an Onion routing
>> proto
On 12/3/15, Watson Ladd wrote:
> On Thu, Dec 3, 2015 at 6:36 AM, Jacob Appelbaum
> wrote:
>> On 12/2/15, Eric Rescorla wrote:
>>> On Wed, Dec 2, 2015 at 7:34 AM, Jacob Appelbaum
>>> wrote:
>>>
>>>> On 12/2/15, Eric Rescorla wrote:
>>&g
On 12/3/15, Martin Rex wrote:
> Jacob Appelbaum wrote:
>>>
>>>> To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less
>>>> secure
>>>
>>> That is a myth.
>>
>> Are you asserting that TLS 1.3 will be less secure
On 12/4/15, Peter Gutmann wrote:
> Jacob Appelbaum writes:
>
>>TCP/IP and DNS are out of scope, though obviously related.
>
> Why are they out of scope?
They are out of scope for the TLS working group as far as I understand
the organization of the IETF in terms of manda
On 12/2/15, Watson Ladd wrote:
> On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum
>>
>> I think that it eliminates all static distinguisher in the protocol
>> for all data covered by the encryption. That is a fantastically
>> wonderful benefit.
>
> What's a
On 12/5/15, Ryan Carboni wrote:
>>
>> If Akamai wants to leave their users insecure, I look forward to
>> another CDN offering privacy options. Such choice is missing if that
>> isn't an option and it isn't on as a strong default.
>
>
> The NSA has contracts with ISPs to have access to their user'
On 12/6/15, Peter Gutmann wrote:
> Jacob Appelbaum writes:
>
>>On 12/4/15, Peter Gutmann wrote:
>>> Jacob Appelbaum writes:
>>>>TCP/IP and DNS are out of scope, though obviously related.
>>> Why are they out of scope?
>>
>>They are out of
On 12/6/15, Dave Garrett wrote:
> On Saturday, December 05, 2015 08:58:58 pm Salz, Rich wrote:
>> Can we embed an EncryptedExtension inside an existing EE? That would let
>> us do TOR purely within TLS, right?
>
> If clients are allowed to send any encrypted extensions other than the
> tunneling
30 matches
Mail list logo
