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:3
At the TRON workshop at NDSS there was interest in a hackathon project to
work on TLS 1.3 implementations and to test interoperability. I have added
this as a topic for the IETF 95 Hackathon. If you are interested in
participating, please sign up here:
https://www.ietf.org/registration/MeetingWiki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/07/2016 11:17 PM, Dave Garrett wrote:
> Permanently gobbling up the majority of the codespace feels like
> excessive force here.
This is not what the RFC-to-be is proposing. We are just marking the values
that can create an issue when used
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
Correct.
-Ekr
On Sun, Feb 21, 2016 at 11:41 AM, Cedric Fournet
wrote:
> 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:*
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,
On 21 February 2016 at 11:33, Watson Ladd wrote:
> Currently we client authenticate after handshake and during handshake.
> Why not unify these by making all client authentication take place
> after the handshake? This will simplify the state machine.
I believe that we discussed this extensively
This was discussed at the TLS interim and the argument against was that
there was limited demand for the post-handshake mode and that people
wanted to have a mode they were very comfortable with as the "main"
thing. Of course, it may be time to revisit that decision.
-Ekr
On Sun, Feb 21, 2016 at
+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
Currently we client authenticate after handshake and during handshake.
Why not unify these by making all client authentication take place
after the handshake? This will simplify the state machine.
https://github.com/tlswg/tls13-spec/issues/421 talks about this in the
last sentence.
__
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 is compromised.
We originally thought that we might want to do
On Fri, Feb 19, 2016 at 3:15 PM, Dave Garrett
wrote:
> On Friday, February 19, 2016 05:24:25 pm Eric Rescorla wrote:
> > My impression is exactly the opposite. All the infrastructure to
> PSK-resumption and
> > hence PSK-0RTT is already in place for TLS 1.2. And of course
> PSK-resumption
> > is
19 matches
Mail list logo
