I assume that you would run a tight tolerance on the 0RTT resumption by
saving the client's clock error in the ticket. That a way only clients
with bad drift get no 0RTT. To do that all sessions need time.
I do not see how the server can do this in general without client help. But
the solution al
Hiya,
First, with no hats, if the WG were to have a poll on whether
or not to include 0rtt in TLS1.3, then as a participant in the
work here, I'd be firmly arguing to leave it out entirely. I
really think an over-emphasis on reducing latency for browsers
is going to bite us (and the Internet) in
On Sun, Mar 13, 2016 at 12:14 PM, Stephen Farrell wrote:
>
>
> However, if I'm in the rough about the above, (which seems
> to me to be the case now) then my job as AD when I get a publication
> request that includes 0rtt, will include figuring out if that's
> safe or not. And I've no clue how I'l
Hiya,
I mostly agree with what you wrote about specific mitigating factors
for specific potential threats.
For this thread though, maybe we're better talking about how we might
get to where we can be confident that replayable data in TLS1.3 won't
cause significant harm. I'm happy to talk more ab
On Sun, Mar 13, 2016 at 2:51 PM, Stephen Farrell
wrote:
>
> > That allows
> > the
> > experts in those protocols to do their own analysis, rather than somehow
> > making it the responsibility of the TLS WG. I agree that this is a sharp
> > object
> > and I'd certainly be happy to have such a requi
Hiya,
On 13/03/16 14:01, Eric Rescorla wrote:
>
> This is not an accurate way to represent the situation. Those WGs can safely
> move from TLS 1.2 to 1.3 *as long as they don't use 0-RTT*.
I agree your 2nd sentence but not your 1st.
I also think it is prudent to assume that implementers will t
> I also think it is prudent to assume that implementers will turn on
> replayable
> data even if nobody has figured out the consequences.
I very much agree. Customers, particularly those in the mobile field, will
look at this and say "I can avoid an extra RTT? *TURN IT ON*" without fully
un
On Sun, Mar 13, 2016 at 3:41 PM, Stephen Farrell
wrote:
>
> Hiya,
>
> On 13/03/16 14:01, Eric Rescorla wrote:
> >
> > This is not an accurate way to represent the situation. Those WGs can
> safely
> > move from TLS 1.2 to 1.3 *as long as they don't use 0-RTT*.
>
> I agree your 2nd sentence but no
> On 13 Mar 2016, at 4:45 PM, Salz, Rich wrote:
>
>> I also think it is prudent to assume that implementers will turn on
>> replayable
>> data even if nobody has figured out the consequences.
>
> I very much agree. Customers, particularly those in the mobile field, will
> look at this and sa
On 13/03/16 14:49, Eric Rescorla wrote:
> Perhaps we could start by actually sponsoring some of those
> reviews. Given that HTTP is the primary customer for 0-RTT, perhaps
> Mark or Martin would be willing to start a review there?
I think that'd really help esp. if we can get folks looking at a
> Is OpenSSL going to implement this? Are all the browsers?
>
> (only the first one is directed specifically at you, Rich…)
I can answer the second question more easily :) Yes the browsers will.
OpenSSL is unlikely to have TLS 1.3 before end of 2016 and I don't know what
we'll do. Right now
On Sun, Mar 13, 2016 at 04:51:49PM +0200, Yoav Nir wrote:
>
> Is OpenSSL going to implement this?
Personally, I think we should start without 0 RTT until we have a
better understanding of what the consequences are.
Kurt
___
TLS mailing list
TLS@ietf.
On Sun, Mar 13, 2016 at 3:51 PM, Yoav Nir wrote:
>
> > On 13 Mar 2016, at 4:45 PM, Salz, Rich wrote:
> >
> >> I also think it is prudent to assume that implementers will turn on
> replayable
> >> data even if nobody has figured out the consequences.
> >
> > I very much agree. Customers, particu
> Personally, I think we should start without 0 RTT until we have a better
> understanding of what the consequences are.
For those who don't know, Kurt is on the openssl-dev team (longer than me), but
is just more quiet and modest about it :)
___
TLS
On Sun, Mar 13, 2016 at 11:14:13AM +, Stephen Farrell wrote:
>
> I've been worried about this for a while now, but the recant
> thread started by Kyle Nekritz [3] prompted me to send this
> as I think that's likely just the tip of an iceberg. E.g., I'd
> be worried about cross-protocol attacks
What Stephen said about 0-RTT makes a lot of sense to me. However, if one major
browser implements this latency reduction feature, the rest will feel compelled
to do the same. And EKR’s message below indicates that at least one major
browser will support 0-RTT.
From: TLS [mailto:tls-boun...@iet
On Sun, Mar 13, 2016 at 11:14:13AM +, Stephen Farrell wrote:
> First, with no hats, if the WG were to have a poll on whether
> or not to include 0rtt in TLS1.3, then as a participant in the
> work here, I'd be firmly arguing to leave it out entirely. I
> really think an over-emphasis on reducin
On Sun, Mar 13, 2016 at 12:21 PM, Eric Rescorla wrote:
>
> On Sun, Mar 13, 2016 at 3:51 PM, Yoav Nir wrote:
>
>>
>> > On 13 Mar 2016, at 4:45 PM, Salz, Rich wrote:
>> >
>> >> I also think it is prudent to assume that implementers will turn on
>> replayable
>> >> data even if nobody has figured
On Sat, Mar 12, 2016 at 12:45 PM, Karthikeyan Bhargavan
wrote:
> Hi Kyle,
>
> In my talk at TRON, I was also concerned by potential attacks from allowing
> unlimited replay of 0-RTT data. I recommended that TLS 1.3 servers should
> implement replay protection using a cache, but requiring clients t
Bill Cox writes:
>> Most server admins won't be reading the TLSv1.3 spec. They're going to
>> see "shiny feature added specifically in this version that makes it
>> faster!" with *maybe* a warning that there are risks, which they'll
>> dismiss because "if it was so insecure, they wouldn't have in
On Sun, Mar 13, 2016 at 4:14 AM, Stephen Farrell
wrote:
> With 0rtt, I think it also becomes a dangerous
> implement. So, that's my personal opinion, while not wearing an
> AD hat.
>
+1 for this as 0RTT is outlined in the draft. But to expand a little:
* Losing forward secrecy for "GET" request
Dear spt,
The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.
tls Session 1 (2:30:00)
Tuesday, Morning Session I 1000-1230
Room Name: Atlantico B size: 125
---
Ar Dé Domhnaigh 13 Márta 2016, scríobh Eric Rescorla :
>
>
> 1. Nothing requires applications to use this feature at all. First, servers
> need to advertise it and are free to (a) not offer clients the ability to
> send
> 0-RTT data and (b) refuse to accept it if clients send it. Moreover,
> everyo
On Sun, Mar 13, 2016 at 09:26:14PM -0400, Harlan Lieberman-Berg wrote:
>
> I agree with a slight tweak in wording here, Bill. I think that we
> /should/ drop the parts of 0-RTT where we are not confident that an
> admin who blindly enables functionality in TLS 1.3 will not end up
> harming themse
24 matches
Mail list logo
