On Thu, Dec 14, 2017 at 5:43 PM, David Benjamin
wrote:
> Another observation about the middlebox issue: if we leave the text as-is,
> where it is defined for TLS 1.2 server certificates, but we all silently
> agree that servers should decline it at TLS 1.2, clients are still
> obligated to implem
On Thu, Dec 14, 2017 at 4:47 PM Ilari Liusvaara
wrote:
> On Tue, Dec 12, 2017 at 06:43:19PM -0600, Martin Thomson wrote:
> > On Tue, Dec 12, 2017 at 6:32 PM, Victor Vasiliev
> wrote:
> > > https://github.com/tlswg/certificate-compression/pull/8
> >
> > That's a lot cleaner. Thanks. Some minor
On Tue, Dec 12, 2017 at 06:43:19PM -0600, Martin Thomson wrote:
> On Tue, Dec 12, 2017 at 6:32 PM, Victor Vasiliev wrote:
> > https://github.com/tlswg/certificate-compression/pull/8
>
> That's a lot cleaner. Thanks. Some minor quibbles, but I like this
> construction far better.
Yeah, same her
On Wed, Dec 13, 2017 at 5:39 PM Hanno Böck wrote:
> Hi,
>
> The deployment of TLS 1.3 was delayed because Internet middleboxes
> broke when they saw unknown TLS data.
>
> I guess it's plausible to assume that the same problem will show up
> with compressed certificates. Has any thought been given
Hi,
The deployment of TLS 1.3 was delayed because Internet middleboxes
broke when they saw unknown TLS data.
I guess it's plausible to assume that the same problem will show up
with compressed certificates. Has any thought been given to that?
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...
Exactly, but since are different messages I think the draft needs to say that.
And, to be on the safe side the draft should if you send one don’t send the
other.
spt
> On Dec 13, 2017, at 13:58, Victor Vasiliev wrote:
>
> You mean sending both of those messages in series? This would be
> eq
What should happen when my silly implementation sends both the Certificate and
CompressedCertificate messages?
spt
> On Dec 9, 2017, at 07:21, internet-dra...@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of
On Tue, Dec 12, 2017 at 6:32 PM, Victor Vasiliev wrote:
> https://github.com/tlswg/certificate-compression/pull/8
That's a lot cleaner. Thanks. Some minor quibbles, but I like this
construction far better.
A question about client certificates prior to TLS 1.3: Are we happy
making compression f
Certificates are pretty wasteful, outside of the keys themselves.
There has to be some significant gains to be had. I think that we
have discussed generating a dictionary that would be useful for
certificates, so if we do that we won't know the full answer yet (I
see no mention of that in the draf
The discussion of this draft makes it sound like implementations
will have additional complexity to support certificate
compression. Complexity adds security risks, so just how much
benefit does certificate compression provide? My naive thinking
is that most of the data in certificates is signa
On Mon, Dec 11, 2017 at 9:00 AM, Ilari Liusvaara
wrote:
> I searched the drafts (both -00 and -01). I find absolutely nothing
> to suggest this extension would play any games with the handshake
> hash. And considering that extension playing such games is AFAIK
> unprecidented, that would warrant r
On Mon, Dec 11, 2017 at 08:50:17AM -0600, Martin Thomson wrote:
> On Mon, Dec 11, 2017 at 12:09 AM, Ilari Liusvaara
> wrote:
> > Transforming messages before putting them in transcript? That sounds
> > like recipe for some very nasty implementation headaches.
> >
> > AFAIK, nothing else in TLS doe
On Mon, Dec 11, 2017 at 12:09 AM, Ilari Liusvaara
wrote:
> Transforming messages before putting them in transcript? That sounds
> like recipe for some very nasty implementation headaches.
>
> AFAIK, nothing else in TLS does this. TLS 1.3 has reset hash and inject
> synthetic message, but that is a
On Mon, Dec 11, 2017 at 09:59:56AM +1100, Martin Thomson wrote:
> A codepoint might be premature just yet.
>
> The idea of using a new handshake message type is to allow someone to
> choose between compressing and not. But consider the case where both
> client and server support non-intersecting
A codepoint might be premature just yet.
The idea of using a new handshake message type is to allow someone to
choose between compressing and not. But consider the case where both
client and server support non-intersecting sets. This negotiation
would cause failure, but that would be unnecessary
> On Dec 9, 2017, at 07:43, Ilari Liusvaara wrote:
>
> On Sat, Dec 09, 2017 at 12:30:23PM +, Alessandro Ghedini wrote:
>> Hello,
>>
>> Sorry for the long delay from the last update.
>>
>> On Sat, Dec 09, 2017 at 04:21:39AM -0800, internet-dra...@ietf.org wrote:
>>>
>>> A New Internet-Dra
On Sat, Dec 09, 2017 at 12:30:23PM +, Alessandro Ghedini wrote:
> Hello,
>
> Sorry for the long delay from the last update.
>
> On Sat, Dec 09, 2017 at 04:21:39AM -0800, internet-dra...@ietf.org wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directorie
Hello,
Sorry for the long delay from the last update.
On Sat, Dec 09, 2017 at 04:21:39AM -0800, internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
>
>
18 matches
Mail list logo
