The Transport Layer Security (tls) working group will hold a face-to-face
interim meeting at Microsoft in Redmond, Washington, USA on 21-22 September
2015 from 9am-5pm.
Date: 21-22 September 2015
Time: 9am-5pm
Location: Redmond, Washington, USA
Additional information, including agenda and more
Hi Martin,
thanks for your review.
On 08/06/2015 10:33 PM, Martin Thomson wrote:
> I've read this draft before, but this is considerably different to
> what I read, and I haven't been following the discussion, so consider
> this as a review with fresh eyes.
>
> First the high points. I think th
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the
IETF.
Title : A TLS ClientHello padding extension
Author : Adam Langley
Filename: dra
Hi Hannes,
On 24 August 2015 at 09:38, Hannes Tschofenig wrote:
>> I'd like to see the document explicitly note that msg_type and length
>> from the handshake message are not covered by the hash. The
>> description of what is covered is a little too terse (and badly
>> formatted).
>
> There are
Hi,
I am looking for a way to achieve identity hiding for DTLS 1.2, which also
hopefully can be used in (D)TLS 1.3, when available.
>From what I understand, for (D)TLS 1.2 it would be possible to perform an
anonymous unencrypted handshake and then to renegotiate the connection with
authentication
On Mon, Aug 24, 2015 at 1:56 PM, Viktor S. Wold Eide <
viktor.s.wold.e...@gmail.com> wrote:
> Hi,
>
> I am looking for a way to achieve identity hiding for DTLS 1.2, which also
> hopefully can be used in (D)TLS 1.3, when available.
>
> From what I understand, for (D)TLS 1.2 it would be possible to
On Mon, 24 Aug 2015, Eric Rescorla wrote:
TLS 1.3 encrypts both the client's and server's certificates already.
The server's certificate is secure only against passive attack.
Not having read the TLS 1.3 draft, in IKE parties can send a hash of the
CAs they trust, so unless you receive a hash
On Mon, Aug 24, 2015 at 2:33 PM, Paul Wouters wrote:
> On Mon, 24 Aug 2015, Eric Rescorla wrote:
>
> TLS 1.3 encrypts both the client's and server's certificates already.
>> The server's certificate is secure only against passive attack.
>>
>
> Not having read the TLS 1.3 draft, in IKE parties ca
Hi,
Another solution was approved for publication as experimental by IESG in
2009 but I declined to process with Pasi Eronen way (previous WG co-Chair)
of publishing the document.
It is available at
https://tools.ietf.org/html/draft-hajjeh-tls-identity-protection-09 and it
works for TLS and DTLS
On 22 August 2015 at 19:28, Dave Garrett wrote:
> Toggling solves the undesired bandwidth use concern stated by Tom by making
> it fully optional on both sides. The even simpler route of just having to
> check if there's bytes in the encrypted fragment other than the payload would
> avoid a lit
On 25/08/15 00:22, Tom Ritter wrote:
> it would be _amazing_ if browser vendors enabled
> browser extension authors to choose the padding strategy for
> individual origins. Then we can crowdsource the effort.
Excellent idea!
S.
___
TLS mailing list
On 24 August 2015 at 16:30, Stephen Farrell wrote:
>
>
> On 25/08/15 00:22, Tom Ritter wrote:
>> it would be _amazing_ if browser vendors enabled
>> browser extension authors to choose the padding strategy for
>> individual origins. Then we can crowdsource the effort.
>
> Excellent idea!
I belie
On Mon, Aug 24, 2015 at 05:33:18PM -0400, Paul Wouters wrote:
> On Mon, 24 Aug 2015, Eric Rescorla wrote:
>
> >TLS 1.3 encrypts both the client's and server's certificates already.
> >The server's certificate is secure only against passive attack.
>
> Not having read the TLS 1.3 draft, in IKE pa
On Tue, 25 Aug 2015, Viktor Dukhovni wrote:
Not having read the TLS 1.3 draft, in IKE parties can send a hash of the
CAs they trust, so unless you receive a hash of a known CA to you, you
can withold your own certificate from being sent.
Is a similar mechanism not planned for TLS 1.3?
This wo
On Mon, Aug 24, 2015 at 09:56:50PM -0400, Paul Wouters wrote:
> >>Not having read the TLS 1.3 draft, in IKE parties can send a hash of the
> >>CAs they trust, so unless you receive a hash of a known CA to you, you
> >>can withold your own certificate from being sent.
> >>
> >>Is a similar mechanis
The topic of encrypting the content type came up again, and a core WG charter
goal is to encrypt as much as possible. To this end, I suggest we consider
going all the way in this area: headerless records. Each protected record would
contain nothing but an aead-ciphered struct with the bare minim
16 matches
Mail list logo
