On Tue, Jun 13, 2017 at 4:32 AM, Ilari Liusvaara
wrote:
> Also:
>
> - Note that 0-RTT exporters are not safe for authentication unless
> the server does global anti-replay on 0-RTT.
I do not think this is the case. Nick Harper has proposed an RFC for token
binding over 0-RTT:
https://to
On Fri, Jun 2, 2017 at 2:39 PM, Victor Vasiliev wrote:
>
> Now, imagine the following attack:
>
> a) Between (1) and (2), the attacker resets the TCP connection, after
> the client got the response and the session ticket.
> b) Since the client has the ticket, it 0-RTTs the POST to take o
On Fri, Apr 22, 2016 at 6:49 AM, Ilari Liusvaara
wrote:
> > The list will likely grow over time much like it has in the past. My
> guess
> > is that most clients will simply reuse the existing session cache from
> TLS
> > 1.2. All state will be remembered.
>
> If I was to implement this, I woul
In TLS 1.3, do we renegotiate all extensions on a PSK resumption, or do we
assume the full state of the prior connection is remembered (either in the
ticket, or in session caches)? Alternatively, do we let some extensions
require remembered state while other extensions require renegotiation?
This
I've been reviewing this issue because I want to help figure out how to do
token binding over TLS 1.3 PKS 0-RTT. When the server emulates a session
cache, then the RMS is unique on every PSK 0-RTT resumption. That means
the client handshake hash is also unique, and it therefore becomes an
attract
On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk wrote:
> On 03/31/2016 12:02 PM, Bill Cox wrote:
>
> On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> wrote:
>
>> Hi Sean,
>>
>> we at ARM would find it somewhat unfortunate
On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:
> Hi Sean,
>
> we at ARM would find it somewhat unfortunate to remove the client
> authentication feature from the 0-RTT exchange since this is one of the
> features that could speed up the exchange quite signif
On Wed, Mar 30, 2016 at 8:22 AM, Eric Rescorla wrote:
> This got a lot of discussion early in the design process and the consensus
> was that the risk of having the default mode (with existing certs) allow
> the
> creation of a long-term delegation was too high. See, for instance, the
> relative
On Tue, Mar 15, 2016 at 2:45 PM, Colm MacCárthaigh
wrote:
> I think I agree with that; but maybe would state it as: we can preserve
> forward secrecy and replay mitigation for 0RTT data, but at the cost of
> read-after-write consistency from a server-side data-store. The store
> needn't be transa
On Mon, Mar 14, 2016 at 12:23 PM, Ryan Hamilton wrote:
>
> On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating
> wrote:
>
>> So, I don't think HTTP is generally safe against attacker-forced
>> replay, and would suggest great caution in allowing it.
>>
>
> It's worth keeping in mind this recent pa
On Mon, Mar 14, 2016 at 4:39 AM, Eric Rescorla wrote:
> This is just my opinion, not Google's. Here is a dumb idea I just had:
>>
>> The current 0-RTT modes described in TLS 1.3 are clearly only for admins
>> who really know what they are doing. If the current 0-RTT modes are deemed
>> to dange
Just how strict do we want to be with forward secrecy? The choices I see
are:
1) Avoid 0-RTT connections, and do only 1-RTT connections when we want
strict forward secrecy and strong client authentication
2) Keep server-side state for decrypting each ticket, and issue new tickets
on each connecti
On Sun, Dec 6, 2015 at 11:39 AM, Eric Rescorla wrote:
> With PSK-DHE over 0-RTT, would we use the static DHE server share for the
>> first resume flight?
>>
>
> No. In All PSK-DHE modes, the PSK is used as SS.
>
That's cool. I need to re-read the spec more carefully.
>
>> You're talking about
On Tue, Nov 24, 2015 at 1:25 PM, Michael Hamburg wrote:
> I agree for new protocols, but the proposal for TLS isn’t all-DH. It’s
> allowing both all-DH and DHE+sign. That’s more complex than just allowing
> DHE+sign. But I suppose the difference in TLS as proposed is really just
> putting a DH
Much of the world seems to have switched to Schnorr-signature inspired ECC
signature schemes such as ECDSA-P256 and Ed25519. These schemes are very
fast, but require two point multiplications to do a Schnorr-style
verification. A simpler proof-of-possession can be verified with only one
point mul
15 matches
Mail list logo
