Re: [TLS] PR for anti-downgrade mechanism

Would the values chosen there have a calamitous impact on Mon, 24 Dec 2125 11:21:51 GMT? I think that's the epoch when a regular TLS1.2 server would put that value in. I know it's 110 years in the future, but would it be better to choose a value that's in the past? On Mon, Nov 9, 2015 at 3:52 PM,

Re: [TLS] PR for anti-downgrade mechanism

No, you're right and I'm off : that value is in the past. I was treating it as a 64-bit epoch value. Bad me for having a 2038-ready timestamp interpreter. On Mon, Nov 9, 2015 at 5:20 PM, Eric Rescorla <e...@rtfm.com> wrote: > On Mon, Nov 9, 2015 at 5:15 PM, Colm MacCárthaigh <c...@

Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

Huge +1 to this I-D, just some minor comments: * I wonder if the document should be more forthright in specifying that the ChaCha20/Poly1305 implementations SHOULD actually attempt to use constant-time and constant-access patterns that the algorithm is designed to facilitate. If that's a selling

Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

On Tue, Nov 3, 2015 at 2:34 AM, Nikos Mavrogiannopoulos wrote: > > I agree that protecting the length of the communicated data is > important, but there is nothing specific to this cipher. I wouldn't contest that; I just think the I-D is over-selling ChaCha20's side-channel

Re: [TLS] TLS 1.3 - Support for compression to be removed

I think there is a compression extension for NNTP: http://tools.ietf.org/id/draft-murchison-nntp-compress-01.html it doesn't seem too hard. My 2c: even if this were not the case, optimizing NNTP in a backwards compatible way does seem like a more important goal than making transport security as

Re: [TLS] Consensus call for keys used in handshake and data messages

On Mon, Jun 20, 2016 at 5:39 PM, Eric Rescorla wrote: > > 2. It's odd to just use a piece of the AEAD cipher (the encryption > function), especially if we ever had a really non-composite cipher. > This can be alleviated by using HKDF-Expand to produce the stream > of bits. > If

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mon, Mar 14, 2016 at 4:32 AM, Eric Rescorla wrote: > For 1. Raw data throughput could be improved by envelope encrypting the > early data; and transferring the envelope key only once the session has > been fully authenticated > 1. Client generates a random secret and uses it

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 12:04 PM, Bill Cox wrote: > > IMO, 0-RTT is the most important new feature in TLS 1.3 ... Speed really > _is_ that important. > I just want to be super explicit on this. There is a trade off to be made here between fast and loose Vs security and

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox wrote: > As we all know, what matters most in security is the default mode. I am > suggesting making the default 0-RTT resumption mode stateful, with a > documented session-ID (and let's bring back the timestamp, too, since we'll

Re: [TLS] Simple, secure 0-RTT for the masses

On Tue, Mar 15, 2016 at 4:59 PM, Bill Cox wrote: > I prefer your solution, but it would require getting the TLS 1.3 protocol > changed. TLS 1.3 seems to be geared towards making stateless resumption > with reusable tickets. > We keep circling that alright, and it

Re: [TLS] Simple, secure 0-RTT for the masses

On Tue, Mar 15, 2016 at 3:51 PM, Bill Cox wrote: > I think it is worth documenting what we feel would be the simplest secure > 0-RTT mode that is safe for any company to use. I think we owe the users a > link to such a document in the TLS 1.3 spec. Here is my attempt at

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

On Wed, Mar 16, 2016 at 2:14 PM, Paterson, Kenny wrote: > Much better would be implementing an optional padding feature for the AEAD > modes. Something like this draft proposes: > > https://tools.ietf.org/html/draft-pironti-tls-length-hiding-02 I hadn't seen that! I

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

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

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

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.

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mon, Mar 14, 2016 at 11:04 AM, Subodh Iyengar wrote: > > Like Kyle mentioned the thing that 0-RTT adds to this is infinite > replayability. As mentioned in the other thread we have ways to reduce the > impact of infinite replayable data for TLS, making it reasonably replay >

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mon, Mar 14, 2016 at 11:27 AM, Subodh Iyengar wrote: > Currently the only way to express retry behavior in HTTP is by the method > (i.e. whether it is idempotent or not), which as you pointed out may have > unfortunate side effects, since it is not explicit. The proposal (at

Re: [TLS] Limiting replay time frame of 0-RTT data

On Mon, Mar 14, 2016 at 3:15 PM, Ryan Hamilton wrote: > > On Sun, Mar 13, 2016 at 4:36 PM, Jeffrey Walton > wrote: > >> 0-RTT seems to be a solution looking for a problem. >> > > ​Google has been using 0-RTT as part of the QUIC transport for quite a > while

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mon, Mar 14, 2016 at 11:41 AM, Ilari Liusvaara wrote: > > (Also, with regards to my comment about cryptographic screwedness, > such screwedness is not inherent in DH-0RTT, but is consequence of > the current implementation). > This is interesting ... is there a way

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mon, Mar 14, 2016 at 1:47 PM, Ryan Hamilton wrote: > On Mon, Mar 14, 2016 at 12:25 PM, Salz, Rich wrote: > >> > It's worth keeping in mind this recent paper about Replay attacks >> against HTTPS. TL;DR: Attackers can already force a browser to replay >>

Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto

On Fri, Apr 8, 2016 at 1:50 PM, Jim Roskind wrote: > If a symmetric-session-ticket-decryption-key was compromised by a server, > as a result of a break-in, or a subpoena, then all traffic that depended on > the session resumption tickets would be at risk. Moreover, a third

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

On Wed, Mar 16, 2016 at 2:30 PM, Adam Langley wrote: > On Wed, Mar 16, 2016 at 6:14 PM, Paterson, Kenny > wrote: > >>provokes me to bring it up. Here's the crux of it; is it really a > >>security win to recommend the AEAD cipher suites for TLS

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Fri, Mar 25, 2016 at 12:24 PM, Eric Rescorla wrote: > The issue isn't encouraged. It's whether we should design the protocol so > that it cannot be implemented any other way. > I think it is encouraged ... not really intentionally, but economically. We all know that the keys

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Fri, Mar 25, 2016 at 12:02 PM, Karthik Bhargavan < karthikeyan.bharga...@inria.fr> wrote: > > +1 but I think we can go further here and specify 0RTT in such a way > that it only works when the server maintains state, and so that any given > 0RTT ticket may only be used once (to preserve

Re: [TLS] Simple, secure 0-RTT for the masses

On Wed, Mar 16, 2016 at 4:17 AM, Ilari Liusvaara wrote: > > Benefits Forward Secrecy and Idempotence: > > > > * Client and server should erase the existing ticket upon use. > > > > (a captured early data section is mooted for replay quite quickly in the > > default

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Fri, Mar 25, 2016 at 2:29 AM, Karthik Bhargavan < karthikeyan.bharga...@inria.fr> wrote: > There has been much discussion on 0-RTT replay and here’s a quick summary > of my understanding. > We already knew that an active attacker, or a lossy network, or an > overzealous web browser could > and

Re: [TLS] Narrowing the replay window

On Tue, Mar 29, 2016 at 4:37 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 30 March 2016 at 06:53, Colm MacCárthaigh <c...@allcosts.net> wrote: > > It's likely I'm misunderstanding, but I'll ask to clear it up. Does this > > proposal imply that a 0RTT sect

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Mon, Mar 28, 2016 at 9:11 AM, Benjamin Kaduk wrote: > > I understand there are good reasons to want to make the default behavior > of a single-physical-server TLS server as secure as possible, but I think > it's also well-understood that the more "exciting" portions of 0-RTT

Re: [TLS] Narrowing the replay window

On Tue, Mar 29, 2016 at 6:25 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 30 March 2016 at 11:30, Colm MacCárthaigh <c...@allcosts.net> wrote: > > * How is the elapsed time on the wire authenticated? can't an attacker > > modify it and replay? > &

Re: [TLS] Narrowing the replay window

On Tue, Mar 29, 2016 at 6:52 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 30 March 2016 at 12:49, Colm MacCárthaigh <c...@allcosts.net> wrote: > > But isn't that too late? If you have to wait for the client finished > message > > before you can even de

[TLS] Resumption and Forward Secrecy, 0-RTT and Safety

Over the past week or so I've sent a few messages here on 0RTT but I've been muddling together some separate concerns, and I'd like to split them apart and treat them separately, with some concrete suggestions. *Resumption and Forward Secrecy* One of the reasons I'm excited about TLS1.3 is the

Re: [TLS] Comments on nonce construction and cipher text size restriction.

On Tue, May 24, 2016 at 9:13 AM, Martin Thomson wrote: > > 3. "The padded sequence number is XORed with the static client_write_iv > or > > server_write_iv, depending on the role.” I think the ivs are not needed. > > We discussed this at quite some length. I originally

Re: [TLS] TLS 1.3 -> TLS 2.0?

On Tue, Aug 30, 2016 at 11:19 AM, Dave Garrett wrote: > I think it's time we just renamed TLS 1.3 to TLS 2.0. +0.7 -- Colm ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

On Thu, Sep 22, 2016 at 4:59 PM, Hugo Krawczyk <h...@ee.technion.ac.il> wrote: > On Thu, Sep 22, 2016 at 7:50 PM, Colm MacCárthaigh <c...@allcosts.net> > wrote: > >> On Thu, Sep 22, 2016 at 4:41 PM, Hugo Krawczyk <h...@ee.technion.ac.il> >> wrote: >

Re: [TLS] Industry Concerns about TLS 1.3

On Thu, Sep 22, 2016 at 4:41 PM, Hugo Krawczyk wrote: > If the problem is the use of forward secrecy then there is a simple > solution, don't use it. > That is, you can, as a server, have a fixed key_share for which the secret > exponent becomes the private key exactly as

Re: [TLS] Additional warnings on 0-RTT data

On Wed, Nov 23, 2016 at 8:40 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 24 November 2016 at 15:11, Colm MacCárthaigh <c...@allcosts.net> wrote: > > Do you disagree that the three specific example security issues provided > are > > realistic, repre

Re: [TLS] Additional warnings on 0-RTT data

e of errors early in their testing than to leave a large hole looming for users to fall into. This style of "Always always test the attack case in production" is also just a good practice that keeps anti-bodies strong. Thanks for reading and the feedback. On 24 November 2016 at 0

[TLS] Additional warnings on 0-RTT data

I've submitted a PR with an expanded warning on the dangers of 0-RTT data for implementors: https://github.com/tlswg/tls13-spec/pull/776/files The text is there, and the TLDR summary is basically that time-based defenses aren't sufficient to mitigate idempotency bugs, so applications need to be

Re: [TLS] Additional warnings on 0-RTT data

On Wed, Nov 23, 2016 at 10:44 PM, Christian Huitema <huit...@huitema.net> wrote: > On Wednesday, November 23, 2016 7:20 PM, Colm MacCárthaigh wrote: > > > > Prior to TLS1.3, replay is not possible, so the risks are new, but the > end-to-end designers > > may not

Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

On Mon, Jan 2, 2017 at 11:43 AM, Yoav Nir wrote: > I’m assuming that the server generates private keys and saves them to a > file along with the time period that they were used, and another machine in > a different part of the network records traffic. It’s not so much that

Re: [TLS] Current TLS 1.3 state?

On Wed, Apr 5, 2017 at 2:03 AM, Karthikeyan Bhargavan < karthik.bharga...@gmail.com> wrote: > > What I am less confident about is the secure usage of features like 0-RTT, > 0.5 RTT, and post-handshake authentication. > Many researchers have looked at these aspects (and they can correct me if > I

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

On Tue, Aug 15, 2017 at 1:55 PM, Hubert Kario <hka...@redhat.com> wrote: > On Tuesday, 15 August 2017 00:55:50 CEST Colm MacCárthaigh wrote: >> On Mon, Aug 14, 2017 at 8:16 PM, Hubert Kario <hka...@redhat.com> wrote: >> > the difference in processing that is

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

On Mon, Aug 14, 2017 at 8:16 PM, Hubert Kario wrote: > the difference in processing that is equal to just few clock cycles is > detectable over network[1] The post you reference actually says the opposite; "20 CPU cycles is probably too small to exploit" ... and even today

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Mon, Jul 10, 2017 at 8:14 AM, Nikos Mavrogiannopoulos wrote: > Certainly, but that doesn't need to happen on this working group, nor > protocols which implement similar solutions need to be called TLS. > I'll belabor this point: rather than thinking about what these

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Fri, Jul 14, 2017 at 11:12 PM, Daniel Kahn Gillmor wrote: > * This proposed TLS variant is *never* acceptable for use on the public >Internet. At most it's acceptable only between two endpoints within >a datacenter under a single zone of administrative

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Sat, Jul 8, 2017 at 6:04 PM, Eric Mill wrote: > > Stating that proxies are not viable for enterprise organizations due to > the scale and complexity of their network environments is subjective, > generally not well-detailed, and much more open to skepticism. > > The burden

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Sat, Jul 8, 2017 at 9:27 AM, Watson Ladd wrote: > > > They also don’t want to install TLS proxies all over the place. That’s a > > large extra expense for them. > > Nginx exists. What's the blocker? Here's how these networks work today: * Key servers are configured

Re: [TLS] datacenter TLS decryption as a three-party protocol

On Wed, Jul 19, 2017 at 11:40 PM, Andrei Popov wrote: > Hi Colm, > > > >- Today browsers do turn on wiretapping support in the normal case. >There's nothing they can do about it, and it works right now. > > This is news to me; which browsers do this (so that I

Re: [TLS] datacenter TLS decryption as a three-party protocol

ll can work with tcpdump/wireshark etc, but not very useful to three letter agencies, etc. > > On Wed, Jul 19, 2017 at 7:45 PM, Colm MacCárthaigh <c...@allcosts.net> > wrote: > >> >> >> On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon <mel...@fugue.com> wro

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Wed, Jul 19, 2017 at 7:48 AM, Watson Ladd wrote: > > On Jul 17, 2017 12:29 PM, "Roland Dobbins" wrote: > > On 17 Jul 2017, at 21:11, Watson Ladd wrote: > > How do you detect unauthorized access separate from knowing what >> authorization is? >> > > I

Re: [TLS] datacenter TLS decryption as a three-party protocol

On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon wrote: > The problem is that the actual solution to this problem is to accept that > you aren't going to be able to decrypt the streams, and then figure out > what to do instead. Which is work the proponents of not doing that are >

Re: [TLS] datacenter TLS decryption as a three-party protocol

On Thu, Jul 20, 2017 at 9:55 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > On 20/07/17 17:43, Colm MacCárthaigh wrote: > > that's the term that people keep applying, > > That term was appropriate for draft-green as justified in [1] > That's disputed by some fo

Re: [TLS] datacenter TLS decryption as a three-party protocol

On Thu, Jul 20, 2017 at 12:44 AM, Salz, Rich wrote: > It’s like saying “all browsers that support TLS support wiretapping > because of the static RSA key exchange.” > > > > It’s a little disingenuous > It sure is! and hyperbolic, but that's the term that people keep applying,

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Sun, Jul 16, 2017 at 1:52 AM, Salz, Rich wrote: > I would also like to understand why TLS 1.2 is not sufficient for, say, > the next five years. > It probably is ... but isn't that the problem? If the answer is "Just let them stay on TLS1.2", I find it very hard to

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Sat, Jul 15, 2017 at 12:12 PM, Salz, Rich wrote: > > On the public internet, it's increasingly common for traffic to be MITMd > in the form of a CDN. > > A CDN is not a middlebox, it is not a MITM. It is a site that the origin > has hired to act as a "front" to it. > Don't

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Sun, Jul 16, 2017 at 12:59 AM, Stephen Farrell wrote: > > (*) I am not asking that people tell me that "pcap+key-leaking" > might work, but for them to describe when that works but nothing > else works. And that has to include the details of what it is > they can

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Sun, Jul 16, 2017 at 2:08 AM, Ted Lemon wrote: > What it means for users to be denied the benefits of TLS 1.3 is that they > don't get, for example, perfect forward secrecy. Since the proposal was to > do away with that anyway, but for all users, not just some users, that >

Re: [TLS] 32 byte randoms in TLS1.3 hello's

On Mon, Jul 24, 2017 at 8:15 AM, Stephen Farrell wrote: > Now if some TLS1.3 deployment were affected by a dual-ec > attack, it'd seem like the -21 version of Random might be > even better than the TLS1.2 version, for the attacker. > I think the fix for this is really

Re: [TLS] 32 byte randoms in TLS1.3 hello's

On Mon, Jul 24, 2017 at 8:29 AM, Watson Ladd wrote: > Don't use bad prngs. And don't buy products from vendors who ship back > doors and refuse to come completely clean when confronted. > Just yesterday DJB posted a blog post about AES-CTR-DRBG, one of the most

Re: [TLS] 32 byte randoms in TLS1.3 hello's

On Wed, Jul 26, 2017 at 6:22 AM, Martin Rex wrote: > Since you also have no idea whether and how the internal hardware design > behind Intel RDRAND is backdoored, you should not be using any of its > output without an at least 10x cryptographic compression in any case. > Obviously

Re: [TLS] 32 byte randoms in TLS1.3 hello's

On Wed, Jul 26, 2017 at 11:58 AM, Martin Rex wrote: > With RDRAND, you would use e.g. SHA-256 to compress 10*256 = 2560 Bits of > a black-box CPRNG output into a 256-bit _new_ output that you > actually use in communication protocols. > If the relation between the RDRAND input and

Re: [TLS] 32 byte randoms in TLS1.3 hello's

On Wed, Jul 26, 2017 at 1:57 PM, Martin Rex wrote: > > Through the 10x compression of the RDRAND output, which will provably > create an incredibly huge amount of collisions, the attacker will be > unable to identify any particular output values of RDRAND. > > Your conceived attack

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Wed, Jul 19, 2017 at 9:26 AM, Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > > Same question. At some point in time you need to decide to start examining > all the traffic. At that point you can start capturing its plaintext. The > proposed alternative seems to be capturing the

Re: [TLS] datacenter TLS decryption as a three-party protocol

On Wed, Jul 19, 2017 at 3:50 PM, Stephen Farrell wrote: > That is a perfect example of the hideous dangers of all of this. > The implication in the above is that browsers would/should turn > on wiretapping support in the normal case. > Today browsers do turn on

Re: [TLS] datacenter TLS decryption as a three-party protocol

On Thu, Jul 20, 2017 at 10:21 AM, Stephen Farrell wrote: > > > > It is odd ... and I'm being deliberately provocative to get at the > > doublethink. It is impossible to consider this mode wiretapping and not > > claim the browsers support it today. Plainly, they do. >

Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 2, 2017 at 4:49 PM, Peter Gutmann wrote: > Benjamin Kaduk writes: > > >I thought TLS clients were supposed to have even worse clocks (in terms of > >absolute time) than Kerberos clients. > > Many of the devices I work with don't have

Re: [TLS] Security review of TLS1.3 0-RTT

nt effort also related > to earlier IETF work on one-time-passwords). Your reference points to an > old OAuth specification that has been replaced by OAuth 2.0, which does > not use the same application layer signing anymore. > Thanks for letting me know! > > On 05/02/2017 04:44

Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 2, 2017 at 10:39 AM, Nico Williams wrote: > With existing APIs, dealing with "pools of meaningfully distinct > tickets" seems meaningfully non-trivial. > I would actually prefer if the client could request N tickets, but was advised that this was too large a

Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 2, 2017 at 10:33 AM, Viktor Dukhovni wrote: > > I believe that the proposed change is well intentioned but > counter-productive. > Note that the recommendation in the review is: 'TLS1.3 should require that TLS implementions handling 0-RTT "MUST" provide a

Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 2, 2017 at 11:08 AM, Viktor Dukhovni wrote: > Yes, if the change is narrowly tailored to 0-RTT, *and* if server TLS > stacks > don't stop supporting ticket reuse for "normal" (not 0-RTT) sessions, then > I have no direct concerns with changes that affect 0-RTT

Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 2, 2017 at 11:39 AM, Benjamin Kaduk wrote: > I thought TLS clients were supposed to have even worse clocks (in terms of > absolute time) than Kerberos clients. The current ticket_age scheme only > requires the client's clock *rate* to be reasonable, not its

Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 2, 2017 at 11:31 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > > On May 2, 2017, at 2:15 PM, Colm MacCárthaigh <c...@allcosts.net> wrote: > > > > In that case, I only reason I see to stop using tickets multiple times > is to protect &g

Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 2, 2017 at 11:00 AM, Nico Williams wrote: > I would think that the ticket itself is enough for that when using > 0-rtt. I.e., if you don't want connection correlation to be possible, > you can't use 0-rtt. I don't think so. If the ticket is encrypted when it

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 12:35 PM, Nico Williams wrote: > No, please don't remove the obfuscated ticket age. Either make it > encrypted or leave it as-is. > If it is to be encrypted, say AEAD'd, it needs to be encrypted under a key that the client and server share; because

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 1:20 PM, Viktor Dukhovni wrote: > The kind of application whose security requirements preclude use of RFC > 5077 > session tickets can and should likely also avoid both 0-RTT and session > resumption entirely. I don't agree with this. Why should

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 11:29 AM, Nico Williams wrote: > On Wed, May 03, 2017 at 12:10:12PM -0400, Viktor Dukhovni wrote: > > > On May 3, 2017, at 12:01 PM, Salz, Rich wrote: > > > The protocol design should avoid setting traps for the unwary. > > > > No,

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 2:20 PM, Nico Williams wrote: > It's what Kerberos has been doing for decades. RFC4120 (before that > RFC1510). > I'll take your word for it! > > > Type 2.1 - Ticket intended for 0-RTT, does include the ticket age > (maybe > > > > not in the

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 3:04 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > On May 3, 2017, at 4:27 PM, Colm MacCárthaigh <c...@allcosts.net> wrote: > > > On Wed, May 3, 2017 at 1:20 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> > wrote: > > &

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 3:56 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 3 May 2017 at 22:45, Colm MacCárthaigh <c...@allcosts.net> wrote: > > This is easy to say; the TLS layer is the right place. It is not > practical > > for applications to defe

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 5:25 PM, Martin Thomson wrote: > I was responding to an overly broad statement you made. In the > discussion you also talk about timing side-channels and other ways in > which information can leak. Nothing we do at the TLS layer will > prevent

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 8:13 PM, Eric Rescorla wrote: > I made some proposals yesterday > (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html). > > Specifically: > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining > both session-cache and strike

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 6:19 PM, Viktor Dukhovni wrote: > One obvious use case for 0-RTT is DNS queries. The query protocol is > idempotent, and latency matters. So for DNS over TLS, 0-RTT would be > a good fit. TLS session caches are not attractive on the DNS server >

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 6:59 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > > On May 3, 2017, at 9:39 PM, Colm MacCárthaigh <c...@allcosts.net> wrote: > > > > As it happens, DNS queries are not idempotent. Queries have > side-effects, > > T

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 3, 2017 at 5:51 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > > On May 3, 2017, at 6:29 PM, Colm MacCárthaigh <c...@allcosts.net> wrote: > > > > Pervasive forward secrecy is one of the central security goals of modern > > cryptography

Re: [TLS] The case for a single stream of data

even inadvertently - and that are a show-stopper for the stateless mitigation. It just doesn't work. Thankfully it's within our capabilities to fix this and there's nothing logically impossible about providing non-replay for the 0-RTT sections. > On 05/05/2017 11:28 AM, Colm MacCárthaigh wrote: > > "

Re: [TLS] The case for a single stream of data

On Tue, May 9, 2017 at 9:00 AM, Salz, Rich wrote: > To me, the argument against this comes down to this: The 0RTT data has > different security properties than the post-handshake data, and TLS > implementations should not hide that difference from applications. > I absolutely

Re: [TLS] The case for a single stream of data

On Tue, May 9, 2017 at 11:12 AM, Ilari Liusvaara wrote: > > Doesn't this imply that clients or CDN are using unsafe HTTP methods in > 0-RTT data? Which is of course _seriously_ broken. > It doesn't really. First; the CDN may be acting as a Layer 4 TLS proxy. Some CDNs

Re: [TLS] The case for a single stream of data

On Tue, May 9, 2017 at 9:41 AM, Salz, Rich wrote: > > It's actually impossible because a 0RTT request may be retried as a 1RTT > request and there's no way to correlate the two. So when the 1RTT request > shows up, we can't go "This might be a repeat" - for example the X-

Re: [TLS] Closing on 0-RTT

On Mon, Jun 12, 2017 at 11:19 AM, Salz, Rich wrote: > > The one case here where I'd really argue for a "MUST" is middle-boxes > like CDNs. The concern I have is if someone has an application that uses > throttling or is vulnerable to a resource-exhaustion problem and goes and >

Re: [TLS] Closing on 0-RTT

On Mon, Jun 12, 2017 at 11:19 AM, Salz, Rich wrote: > I agree with this. Which is why I prefer separate streams for early data, > and some kind of signaling to the content provider that is clear and > unambiguous. I don't know how to do that when, say, the intermediary/CDN >

Re: [TLS] Closing on 0-RTT

On Sun, Jun 11, 2017 at 8:18 AM, Eric Rescorla wrote: > Here's what I propose to do: > > - Describe the attacks that Colm described. > > - Distinguish between replay and retransmission > > - Mandate (SHOULD-level) that servers do some sort of bounded > (at-most-N times)

Re: [TLS] Closing on 0-RTT

On Sun, Jun 25, 2017 at 11:43 PM, Ilari Liusvaara wrote: > I understood that the cache probing attack requires much less replays > than the other side-channel ones. And furthermore, distributing the > replays among zones makes the attack easier (because replay with the

Re: [TLS] Security review of TLS1.3 0-RTT

On Mon, May 22, 2017 at 10:46 AM, Christian Huitema wrote > > Check DKG's analysis of 0-RTT for DNS over TLS: https://www.ietf.org/mail- > archive/web/dns-privacy/current/msg01276.html. There is only one point of > concern, a minor privacy leak if the DNS queries in the 0-RTT

Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 23, 2017 at 11:27 AM, Viktor Dukhovni wrote: > Actually, nonces in DNScurve protect clients from replayed server > responses (clients > are stateful). I see no explicit guidance to detect or refuse replays of > client > queries in DNScurve. While servers

Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 23, 2017 at 10:50 AM, Viktor Dukhovni wrote: > The fix is to amend DNSpriv to require stateless (random rather > than say round-robit) RRset rotation. With random rotation, the > next RRset order is independent of previous queries. > That's a good fix for

Re: [TLS] Security review of TLS1.3 0-RTT

On Wed, May 24, 2017 at 7:30 AM, Ilari Liusvaara wrote: > > > Right, this would bring replays down from the millions hypothesized for > > the weak time-based thing to more like tens, which is kind of in the > > regime that we are currently in with (at least some)

Re: [TLS] Security review of TLS1.3 0-RTT

On Fri, May 19, 2017 at 2:53 AM, Ilari Liusvaara wrote: > > To me, that reads as gross understatement about the dangers involved in > 0-RTT: > > - The side channel attacks with millions or billions of replays are hard > to protect against. This is if the side channels

Re: [TLS] Security review of TLS1.3 0-RTT

On Fri, May 19, 2017 at 11:44 AM, Eric Rescorla wrote: > Yup. There are no known reasons that prevent at-most-once 0-RTT delivery, > >> even with distributed servers for the origin. >> > > I don't disagree with that necessarily, but if the client responds by > retransmitting > in

Re: [TLS] Security review of TLS1.3 0-RTT

On Fri, May 19, 2017 at 11:40 AM, Ilari Liusvaara wrote: > > * In order to fully reason about when that message may later get > received, > > there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by > all > > potential middle-boxes in the pipe that may be

Re: [TLS] Security review of TLS1.3 0-RTT

On Mon, May 22, 2017 at 10:12 AM, Kyle Nekritz wrote: > The stateless technique certainly doesn’t solve all issues with replay. > Neither do the other techniques, unless a fairly unrealistic (imo, in most > use cases) retry strategy is used. > The stateless technique is

Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 30, 2017 at 2:38 PM, Victor Vasiliev wrote: > Thank you for your analysis! I appreciate the attention to the security > properties of the 0-RTT requests, as it is the more delicate part of the > protocol. It took me a while to get through the entire review, and

  1   2   >