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 extension (that contains the tunneled he
> On 6 Dec 2015, at 4:44 AM, Watson Ladd wrote:
>
> If you disagree, please cite the sentence of the TLS
> RFC which prohibits accepting application data records during the
> handshake.
OK, I’ll bite. Top of page 36:
Client Server
Cli
On Sat, Dec 5, 2015 at 8:20 PM, Tom Ritter wrote:
> On 5 December 2015 at 21:31, Eric Rescorla wrote:
> >
> >
> > On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter wrote:
> >>
> >> On 5 December 2015 at 12:32, Eric Rescorla wrote:
> >> > Subject: SNI Encryption Part XLVIII
> >>
> >> A small concern t
On 5 December 2015 at 21:31, Eric Rescorla wrote:
>
>
> On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter wrote:
>>
>> On 5 December 2015 at 12:32, Eric Rescorla wrote:
>> > Subject: SNI Encryption Part XLVIII
>>
>> A small concern that probably is "No, that can't happen", but I would
>> want to be sur
On Sat, Dec 5, 2015 at 5:58 PM, Salz, Rich wrote:
> Can we embed an EncryptedExtension inside an existing EE?
>
I'm not sure I understand the design you're suggesting.
> That would let us do TOR purely within TLS, right?
>
See above.
>
> You said “in the interest of explicit signaling”
On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter wrote:
> On 5 December 2015 at 12:32, Eric Rescorla wrote:
> > Subject: SNI Encryption Part XLVIII
>
> A small concern that probably is "No, that can't happen", but I would
> want to be sure that a normal (non-encrypted SNI) ClientHello would be
> unabl
On 5 December 2015 at 12:32, Eric Rescorla wrote:
> Subject: SNI Encryption Part XLVIII
A small concern that probably is "No, that can't happen", but I would
want to be sure that a normal (non-encrypted SNI) ClientHello would be
unable to be wrapped in a new ClientHello to a gateway by a MITM
(wi
On Sat, Dec 5, 2015 at 9:48 PM, Peter Gutmann wrote:
> Watson Ladd writes:
>
>>please cite the sentence of the TLS RFC which prohibits accepting application
>>data records during the handshake.
>
> Please cite the sentence of the TLS RFC which prohibits accepting SSH messages
> during the handsha
Watson Ladd writes:
>please cite the sentence of the TLS RFC which prohibits accepting application
>data records during the handshake.
Please cite the sentence of the TLS RFC which prohibits accepting SSH messages
during the handshake.
Please cite the sentence of the TLS RFC which prohibits exe
On Sat, Dec 5, 2015 at 9:33 PM, Peter Gutmann wrote:
> Watson Ladd writes:
>
>>miTLS did not claim to be consistent with the RFC. Rather it claimed to be
>>secure, and to interoperate with most other implementations in circumstances
>>tested. The informal nature of the RFC makes it impossible to
Watson Ladd writes:
>miTLS did not claim to be consistent with the RFC. Rather it claimed to be
>secure, and to interoperate with most other implementations in circumstances
>tested. The informal nature of the RFC makes it impossible to carry out
>formal verification against it.
By that argument
On Sat, Dec 5, 2015 at 8:18 PM, Peter Gutmann wrote:
> Watson Ladd writes:
>>On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann
>>wrote:
>>> Hubert Kario writes:
>>>
miTLS does accept Application Data when it is send between Client Hello and
Client Key Exchange and rejects it when it is sen
Can we embed an EncryptedExtension inside an existing EE? That would let us do
TOR purely within TLS, right?
You said “in the interest of explicit signaling” but I think you meant in the
interest of avoiding that, right?
I still think the “inner/real SNI” is simpler, but will have to think abo
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 scope for the TLS working group as far as I understand t
Watson Ladd writes:
>On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann
>wrote:
>> Hubert Kario writes:
>>
>>>miTLS does accept Application Data when it is send between Client Hello and
>>>Client Key Exchange and rejects it when it is sent between Change Cipher Spec
>>>and Finished.
>>
>> Given that
On Sat, Dec 5, 2015 at 4:24 PM, Bill Cox wrote:
> I am not sure why we have a 0-RTT connect, but only a 1-RTT resume. If
> anything, it seems like it would be easier to have a secure 0-RTT resume
> than a 0-RTT connect, though the 0-RTT connect does use some information
> from prior connections.
On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann wrote:
> Hubert Kario writes:
>
>>miTLS does accept Application Data when it is send between Client Hello and
>>Client Key Exchange and rejects it when it is sent between Change Cipher Spec
>>and Finished.
>
> Given that miTLS is a formally verified i
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 scope for the TLS working group as far as I understand the
>organization of the IETF in terms of ma
Hubert Kario writes:
>miTLS does accept Application Data when it is send between Client Hello and
>Client Key Exchange and rejects it when it is sent between Change Cipher Spec
>and Finished.
Given that miTLS is a formally verified implementation, would this imply that
there's a problem with the
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'
>
> 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's content.
Is a CDN an ISP?
On Saturday, December 05, 2015 01:32:11 pm Eric Rescorla wrote:
> Subject: SNI Encryption Part XLVIII
>
> Folks,
>
> TL;DR.
> This message describes a technique for doing SNI encryption that just
> requires (re)adding EncryptedExtensions to the client's first flight [0]
> defining an extension th
On Sat, Dec 05, 2015 at 02:15:07PM -0500, Watson Ladd wrote:
> I've got another question: how does the client know that the gateway
> is supposed to be the gateway? As it stands it seems an attacker can
> MITM the Gateway, and recover all SNIs.
That's a whole lot different than passively reading
On Sat, Dec 5, 2015 at 1:32 PM, Eric Rescorla wrote:
> Subject: SNI Encryption Part XLVIII
>
> Folks,
>
> TL;DR.
> This message describes a technique for doing SNI encryption that just
> requires (re)adding EncryptedExtensions to the client's first flight [0]
> defining an extension that indicates
Subject: SNI Encryption Part XLVIII
Folks,
TL;DR.
This message describes a technique for doing SNI encryption that just
requires (re)adding EncryptedExtensions to the client's first flight [0]
defining an extension that indicates "tunnelled TLS" and (maybe) a new
TLS content type. We would only t
On Sat, Dec 05, 2015 at 11:32:40PM +0800, Xuelei Fan wrote:
> Hi,
>
> Any one know why the negotiated FFDHE draft hang on MISSREF state for more
> than 180 days?
>
> http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/
Normatively depends on the false-start draft that isn't sent
Hi,
Any one know why the negotiated FFDHE draft hang on MISSREF state for more
than 180 days?
http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/
Thanks & Regards,
Xuelei
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/
27 matches
Mail list logo
