On 21 February 2016 at 21:46, Ilari Liusvaara wrote:
>> We originally thought that we might want to do this for
>> WebRTC/real-time. As it so happens, we have an alternative design
>> that doesn't need this, so...
>
> Got mailarchive or draft link?
No, this was a realization that we could just s
On Sun, Feb 21, 2016 at 11:31:04AM -0800, Martin Thomson wrote:
> I'm sitting here in TRON listening to Karthik describe all the various
> ways in which client authentication in 0-RTT is bad. I'm particularly
> sympathetic to the perpetual impersonation attack that arises when the
> client's ephem
+1
On Sun, Feb 21, 2016 at 11:31 AM, Martin Thomson
wrote:
I'm sitting here in TRON listening to Karthik describe all the various
ways in which client authentication in 0-RTT is bad. I'm particularly
sympathetic to the perpetual impersonation attack that arises when the
client's ephemeral key
I am strongly in favor of removing client auth from 0-RTT.
Cheers,
Andrei
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Sunday, February 21, 2016 11:37 AM
To: Martin Thomson
Cc: tls@ietf.org
Subject: Re: [TLS] Remove 0-RTT client auth
+1
On Sun, Feb 21, 2016 at 11
On 21 February 2016 at 12:06, Eric Rescorla wrote:
> I think we're going to have to invent a 0-RTT exporter (yes, I understand
> that this
> requires care).
We might disagree about that "have to". I'd be happier if the 0-RTT
data couldn't rely on the existence of an exporter. If that means
that
On Sun, Feb 21, 2016 at 12:05 PM, Martin Thomson
wrote:
> On 21 February 2016 at 12:01, Adam Langley wrote:
> > The token-binding(*) folks care about authenticating 0-RTT requests,
> > although they are currently working at the application-layer[1] and so
> > would be recreating 0-RTT client aut
On 21 February 2016 at 12:01, Adam Langley wrote:
> The token-binding(*) folks care about authenticating 0-RTT requests,
> although they are currently working at the application-layer[1] and so
> would be recreating 0-RTT client authentication on top of TLS. (They
> would thus have all the same is
On Sun, Feb 21, 2016 at 11:31 AM, Martin Thomson
wrote:
> I'm sitting here in TRON listening to Karthik describe all the various
> ways in which client authentication in 0-RTT is bad. I'm particularly
> sympathetic to the perpetual impersonation attack that arises when the
> client's ephemeral ke
1 February 2016 19:37
> *To:* Martin Thomson
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] Remove 0-RTT client auth
>
>
>
> +1
>
>
>
> On Sun, Feb 21, 2016 at 11:31 AM, Martin Thomson
> wrote:
>
> I'm sitting here in TRON listening to Karthik describe a
On 21 February 2016 at 11:41, Cedric Fournet wrote:
> Agreed. For what it is worth, 0-RTT with PSK would still provide implicit
> client authentication.
s/would/could
That implies many of the hazards that we were talking about here, so
none of this makes 0-RTT any less of a hazard.
___
Agreed. For what it is worth, 0-RTT with PSK would still provide implicit
client authentication.
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: 21 February 2016 19:37
To: Martin Thomson
Cc: tls@ietf.org
Subject: Re: [TLS] Remove 0-RTT client auth
+1
On Sun, Feb 21
+1
On Sun, Feb 21, 2016 at 11:31 AM, Martin Thomson
wrote:
> I'm sitting here in TRON listening to Karthik describe all the various
> ways in which client authentication in 0-RTT is bad. I'm particularly
> sympathetic to the perpetual impersonation attack that arises when the
> client's ephemer
12 matches
Mail list logo
