On Fri, Aug 28, 2015 at 04:27:28PM +0200, Viktor S. Wold Eide wrote:
> > I don't think this matches most TLS use cases very well, since the client
> > generally isn't authenticated at all, so there's no point in the server
> > progressively
> > revealing more.
> >
> >
> Although the client general
On Thu, Aug 27, 2015 at 1:18 PM, Eric Rescorla wrote:
>
>
> On Thu, Aug 27, 2015 at 2:14 AM, Viktor S. Wold Eide <
> viktor.s.wold.e...@gmail.com> wrote:
>
>> On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote:
>>
>>>
>>>
>>> TLS 1.3 encrypts both the client's and server's certificates alread
On Thu, Aug 27, 2015 at 2:14 AM, Viktor S. Wold Eide <
viktor.s.wold.e...@gmail.com> wrote:
> On Mon, Aug 24, 2015 at 11:17 PM, 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.
On Thu, Aug 27, 2015 at 1:37 AM, Viktor S. Wold Eide <
viktor.s.wold.e...@gmail.com> wrote:
>
> On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote:
>
>>
>>
>> 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 wa
On Mon, Aug 24, 2015 at 11:17 PM, 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. The
> client's is encrypted with a key that the client can authenticate as
> belonging to the server
On Tue, Aug 25, 2015 at 10:43 AM, Pascal Urien
wrote:
> Hi
>
> a working solution fot TLS 1.0,1.1, 1.2, DTLS 1.0, 1.2 is to encrypt
> the client certificat with an extra key computed from the master
> secret
>
> see
>
> https://tools.ietf.org/html/draft-urien-badra-eap-tls-identity-protection-01
On Tue, Aug 25, 2015 at 12:19 AM, Badra wrote:
> 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-h
On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote:
>
>
> 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 availab
Hi
a working solution fot TLS 1.0,1.1, 1.2, DTLS 1.0, 1.2 is to encrypt
the client certificat with an extra key computed from the master
secret
see
https://tools.ietf.org/html/draft-urien-badra-eap-tls-identity-protection-01
Rgs
Pascal
2015-08-24 22:56 UTC+02:00, Viktor S. Wold Eide :
> Hi,
>
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
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 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
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 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
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 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
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
17 matches
Mail list logo
