On Tue, Sep 22, 2015 at 2:37 PM, Salz, Rich wrote:
> We discussed this before. Not that we can't discuss it again. Here's a link
> to slides I presented at the Toronto Interim in July 2015.
>
>
> https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view?usp=sharing
>
Thanks f
Thanks for your detailed and thoughtful review.
It's all trade-offs. In previous emails on this thread I acknowledged the
co-dependant issue, by calling out dkg's excellement statement of it.
At the TLS interim earlier this week, Brian Sniffen (from Akamai) started a
proposal that makes SNI-en
Salz, Rich wrote:
>
> At the TLS interim earlier this week, Brian Sniffen (from Akamai) started
> a proposal that makes SNI-encryption something that can be deployed and
> tested on the Internet in TLS 1.3. So we'll see if it gets used and works.
> The earlier slides notwithstanding, it's somethi
Martin Rex wrote:
> Salz, Rich wrote:
> >
> > At the TLS interim earlier this week, Brian Sniffen (from Akamai) started
> > a proposal that makes SNI-encryption something that can be deployed and
> > tested on the Internet in TLS 1.3. So we'll see if it gets used and works.
> > The earlier slides
Various paddings (is that a word?) will be needed, but the ability to pad
things is also in TLS 1.3. We think all the necessary TLS protocol bits are
present.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
___
T
On Friday, September 25, 2015 01:10:37 pm Martin Rex wrote:
> Because it is not necessarily immediately obvious, you will need
> padding also for the Server Certificate handshake messages.
> And, because the key exchange is side-effected by properties of
> the Server Certificate, you may additional
How about making fixed length(s) for each message type, then pad it with 0x01
then optional 0x00s?
Quynh.
From: TLS on behalf of Dave Garrett
Sent: Friday, September 25, 2015 2:11 PM
To: tls@ietf.org; m...@sap.com
Subject: Re: [TLS] Encrypted SNI (was
On 23/09/15 06:55, Tony Arcieri wrote:
> They should not be relying on a poorly conceived feature
> which has been repeatedly demonstrated to introduce vulnerabilities in what
> is supposed to be a *security protocol* just because they don't want to
> implement compression themselves.
I see peopl
On Fri, Sep 25, 2015 at 07:40:05PM +0100, Jeremy Harris wrote:
> Why is it not possible for TLS1.3 to provide that same service
> combination, but implemented by design in a layered fashion?
TLS is correctly agnostic of semantic boundaries, in application
data. For this to work, applications wou
> > This requires new application protocol verbs "STARTCOMPRESSION",
> > "STOPCOMPRESSION", and underlying support in the TLS layer.
> I wonder if it would have been possible to do this via renegotiation, though
> this has overhead.
Intriguing, but moot of course, since renegotiation is gone. :
On Tuesday, September 22, 2015 07:27:35 pm Sean Turner wrote:
> I’ve gone ahead and posted the minutes/list of decisions to:
>
> https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3
Issue #185 has the "discuss-seattle" tag on it, but I don't see mention of it
On Fri, Sep 25, 2015 at 6:13 PM, Dave Garrett
wrote:
> On Tuesday, September 22, 2015 07:27:35 pm Sean Turner wrote:
> > I’ve gone ahead and posted the minutes/list of decisions to:
> >
> >
> https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3
>
> Issue #185
On Sat, Sep 26, 2015 at 12:19:17AM +, Salz, Rich wrote:
> > I wonder if it would have been possible to do this via renegotiation, though
> > this has overhead.
>
> Intriguing, but moot of course, since renegotiation is gone. :) Interesting
> corner-cases to think about: is compression resta
13 matches
Mail list logo
