Re: [TLS] Computation of static secret in anonymous DH
On Fri, Jul 31, 2015 at 07:42:12PM +0300, Ilari Liusvaara wrote: > On Fri, Jun 26, 2015 at 01:41:29PM -0500, Nico Williams wrote: > > tls-unique depends on the Finished message strongly binding the entire > > transcript up to that point. I find this elegant (despite the > > resumption problem, which anyways, should be fixed by the session hash) > > and easy to understand and analyze. > > > > If the Finished message no longer has this property in 1.3 then that's a > > problem for tls-unique, and we'd have to fix one or the other. Surely > > 1.3 will have some handshake message that binds the transcript, and why > > that wouldn't be the Finished message is beyond me (but I am missing a > > lot of the 1.3 context, so please forgive and inform me). > > Also, it turns out some are assuming tls-unique is both connection nonce > and secret value. :-/ RFC5929 quite rightly says not to do that. Do you have examples of apps doing this? (The Finished message is generally sent encrypted, so that's not that terrible an assumption.) > I don't think the present construct for Finished values is appropriate > for such values, which means one would have to redefine tls-unique > so it meets the need. I'd rather avoid this unless we really need to. Examples of applications mis-using tls-unique would be nice. > (TLS-Exporter values already look to be secret and connection > nonces, and I have already seen stuff relying on both properties). A proper TLS-Exporter can be used (was intended to be used!) as secret and whatever "connection nonces" are. > Basically, the value needs to derive from both "master secret" (to make > it secret) and session hash /w configs (to make it connection > nonce). Which Finished messages do! The only problem with Finished messages as secrets is that the cipher used might not provide confidentiality protection. (Again, I'm not endorsing the use of tls-unique as a secret.) If we have no such ciphersuites left in TLS 1.3... Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate DH_anon in favor of raw public keys?
On Fri, Aug 28, 2015 at 06:33:17PM +, Viktor Dukhovni wrote: > On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote: > Furthermore, anon-DH has strong privacy properties, the server > sends no identity information, not even a public key. Any > channel-binding at the next layer is privacy protected. Using raw public signature keys doesn't change that. It just requires generating a signature key every time. For devices/protocols where DH_anon is common (perhaps because they do channel binding) the proposal at hand is annoying and CPU-wasting, but hardly fatal. I'm not sure how I feel about this. The idea that we always do a DH key exchange and always have a server signature means we can greatly reduce the number of ciphersuites, so that's quite helpful. We'd have to apply this to PSK too to make it really worthwhile. > My view is that anon_DH should either be supported properly (be > defined for the same symmetric cipher combinations as ciphersuites > with certs or public keys) or as proposed not supported at all. Yes, DH_anon should be first-class. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate DH_anon in favor of raw public keys?
On Mon, Aug 31, 2015 at 09:18:34AM -0700, Eric Rescorla wrote: > On Mon, Aug 31, 2015 at 9:13 AM, Nico Williams > wrote: > > I'm not sure how I feel about this. The idea that we always do a DH key > > exchange and always have a server signature means we can greatly reduce > > the number of ciphersuites, so that's quite helpful. We'd have to apply > > this to PSK too to make it really worthwhile. > > Certainly it would be nice to get rid of PSK too but just getting rid of > DH_anon makes a non-trivial difference. How would we get rid of PSK [without DH]? What would the impact be on IoT devices? Could we have a fake-DH-and-signature PSK scheme to make it easy on IoTs? Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate DH_anon in favor of raw public keys?
On Mon, Aug 31, 2015 at 09:48:10AM -0700, Eric Rescorla wrote: > On Mon, Aug 31, 2015 at 9:45 AM, Nico Williams > wrote: > > How would we get rid of PSK [without DH]? What would the impact be on > > IoT devices? Could we have a fake-DH-and-signature PSK scheme to make > > it easy on IoTs? > > I guess I wasn't clear: I'm not in favor of getting rid of PSK. I'm > saying that even if we still have PSK, removing DH_anon as an explicit > mode makes things simpler. I wasn't either. I was asking about requiring the use of DH [and a server signature] when using PSK. Let's get back to removing DH_anon for a minute. What would the impact be on TCPINC proposals using TLS as their basis? They really need anonymity, leaving it to the application to do channel binding. (The application might be using TLS itself, oddly enough.) Do we really want to force servers to generate an unnecessary signing key, compute an unnecessary signature, and to then force clients to verify said unnecessary signature (if they don't then there's a subliminal channel)?? I think "no", unless the signature algorithm used is cheap [and weak], which probably adds other complications. Back to PSK: How is PSK with PFS going to work? How is PSK w/o PFS going to work? Anyways, my current take is that we should not get rid of the DH_anon ciphersuites. I grant that the existing applications (ignoring TPCINC?) could take the performance hit, but in the longer term it seems likely to be more problematic than helpful. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Tue, Sep 15, 2015 at 03:18:30PM +0200, Florian Weimer wrote: > On 09/12/2015 10:49 PM, Eric Rescorla wrote: > > Issue: https://github.com/tlswg/tls13-spec/issues/242 > > > > In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues: > > > > "Nobody must ever be *required* to send an alert. Any requirement for > > sending an alert should be SHOULD, at most." > > Using full-duplex TCP, it's difficult to get a fatal alert over the wire > if you want to close the connection immediately: But if you have a fatal error you'll be closing immediately anyways. Does sending the fatal alert cause a problem other than increase the likelihood of RSTs? What is the alternative considering that the next step is to close the connection anyways? Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Wed, Sep 16, 2015 at 12:02:57PM +0200, Florian Weimer wrote: > On 09/15/2015 06:29 PM, Nico Williams wrote: > > But if you have a fatal error you'll be closing immediately anyways. > > I'm trying to explain that any requirement to send fatal alerts will be > difficult to implement. With the BSD sockets API, the only way to do > that reliable is *not* to close the socket immediately, which is > apparently not what you (or existing APIs) expect, and which is where > the difficulty lies. *Sending* the fatal alert is not hard at all. Giving the peer a fair chance to get them is the difficult thing. Strictly speaking then, requiring that fata alerts be sent is not difficult to implement. :^) Tongue-in-cheek aside, I think it's fair to say that fata alerts SHOULD be sent rather than MUST be sent. And it's a good idea to explain that sending a fatal alert, by itself, does not really mean that the peer is even more likely than not to see it, that more effort is required by the sender to give the peer a fair chance of seeing it. Fatal alerts are useful for diagnostics purposes at least, but there's no real need to tell a peer why you're slamming the door on them, is there. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Wed, Sep 16, 2015 at 03:29:40PM -0400, Dave Garrett wrote: > I'd be fine with phrasing it as: implementations MUST send all alerts > when indicated, and SHOULD make a best-effort to ensure they get > delivered to the peer. +1. Perhaps some text explaining the difficulty in the latter and offering some implementation advice. Something like: Sending a fatal alert is easy, but ensuring that the peer gets it when running over TCP or similar can be difficult because a shutdown or close will result in the peer getting an RST if data is received from it before the alert is sent. Depending on the TCP stack, giving the alert a chance of being received may require delaying the closing of the connection by some amount of time. A "simple" way to do this is to "service" a pool of pending-close connections on a timer, or at the next new connection or insertion of a new delayed-close connection into the pool. A reasonably low implementation cost method is to have a fixed-sized pool of pending-close connections, closing the oldest connection whenever adding a new pending-close connection to a full pool. Note that any scheme that can leave pending-close connections alive possibly indefinitely will also consume the associated TCP PCB resources indefinitely. The second paragraph might be giving too much implementation advice. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 10:40:28AM -0700, Martin Thomson wrote: > On 15 September 2015 at 18:00, Joseph Salowey wrote: > > remove anonymous DH > > +1 > > It's not like we're making the use case impossible, just that the > solution will look different. And will be more costly. I'm neutral on this, as I don't think the extra cost will lead to, say, MTAs forgoing TLS for SMTP. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 01:20:37PM -0700, Brian Smith wrote: > I think it is a good idea to remove DH_anon_* and similar ECDH_anon_* > cipher suites. > > This isn't an endorsement of the raw public key modes. Sure, one can always use self-signed certs (at an even higher cost to do anonymity). If we're going to raise the cost of anonymity for the sake of simplicity in TLS 1.3, do let's try to keep that cost from escalating. Raw public keys are not a large additional complexity cost. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 02:12:07PM -0700, Tony Arcieri wrote: > On Wednesday, September 16, 2015, Eric Rescorla wrote: > > > In addition, they are already part of TLS, so the question would be if we > > have > > consensus to remove them > > > > I see a bunch of +1s and zero -1s. Just saying... I think Eric meant raw public keys. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 02:25:52PM -0700, Brian Smith wrote: > On Wed, Sep 16, 2015 at 2:05 PM, Eric Rescorla wrote: > > > In addition, they are already part of TLS, so the question would be if we > > have > > consensus to remove them > > > > This thread is about the removal of DH_anon_*, not about raw public keys. Yes, but you implied that you might not support keeping raw public keys. I'm not in favor of removing the anon cipher suites if we also remove raw public key support. This is important. I don't want the cost of doing anon with TLS to escalate piecemeal. All cards on the table please. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
On Wed, Sep 16, 2015 at 06:37:21PM -0400, Dave Garrett wrote: > On Wednesday, September 16, 2015 05:38:27 pm Viktor Dukhovni wrote: > > On Wed, Sep 16, 2015 at 03:03:54PM -0400, Dave Garrett wrote: > > > The suggestion that started this thread was to have a "Standard TLS > > > Profile" > > > that actually allowed EXPORT ciphers & SSL3. So yeah, this proposal feels > > > like a suggestion to keep allowance of obsolete junk as the norm with > > > "defensive" as a separate option, because that's what it specifically > > > says. > > > > Object to such a profile, and rather than the idea of profiles. > > There is no need for the TLS WG to define any profiles that include > > SSL3 or EXPORT ciphers. > > That's a fair point, but I don't see the need for a profile once that > stuff is not allowed anywhere. I could accept the notion of a TLS > strict mode, where it's TLS 1.2 + PFS + AEAD + no > SHA1/DSA/SSL2HELLO/etc. only, but that's not really a "profile" so > much as one paragraph that could be added. Application profiles are > already a thing, so I don't see why we also need a new mechanism here. It's a profile. Call it what you will. The rest of us call this a profile. All the more so when profiles are named in an IANA registry. Applications can then very trivially select an appropriate TLS profile using standard profile naming. > Let me put it this way, I see no way for the WG to reasonably agree on > this without a proposed _set_ of profiles to go with it that we all > could also live with. Just the vague notion of more profiles in > abstract isn't sounding great on its own. We've certainly had a few proposed profiles over time. Your estimation of what the WG would or would not agree to is not as interesting as, you know, actually attempting to get consensus. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 07:07:31PM -0400, Dave Garrett wrote: > This appears to just be a miscommunication. It is not. > The current poll is to remove anon ciphers in favor of raw public > keys. We're not considering removing raw public keys, as far as I > know, and I think most of us would be against that. Once more, with feeling. I would oppose the current proposal if there was to be a follow-on proposal to remove raw public keys, which I wouldn't have even though plausible but for Brian's intimating that he'd be fine with removing raw public keys. Otherwise I would be neutral as to removing anon ciphersuites. I would also be neutral as to removing raw public keys if anon ciphersuites are to remain. Whichever one is removed, I shall oppose the removal of the other. I.e., these two features are interrelated. It is difficult to consider the removal of one without considering the possible removal of the other. I leave it at that. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 06:40:47PM -0700, Bill Frantz wrote: > I agree with both Nico and Viktor. For me the big win of RPK over > anon_(EC)DH is it allows TOFU. If TOFU isn't needed, short public > keys should ease many of Viktor's cons. I also like the idea of > simpler implementations. Eh, certs also allow TOFU. That's what key pinning is, in a way. :) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Wed, Sep 16, 2015 at 12:53:53PM -0700, Brian Smith wrote: > Further, the alerting mechanism has encouraged the unsafe practice of > "version fallback." It is clear from looking at the bug databases of > Firefox and Chrome that their attempts to make security decisions based on > what alerts they received was bad for security. Do we think that silent connection closings wouldn't also lead to version fallback? "Let's try this. Nope, didn't work. Let's try this other thing... Nope, didn't work. ..." Fatal alerts are quite handy for diagnostics on the client side, really. I'd rather keep them than remove them, but I'd be OK with clients never sending them. I'm OK with fata alerts being SHOULD send. I'm OK with having text explaining how to send them such that peers (clients) will get a fair chance of receiving them. We shouldn't always fight the last war. I hope the browsers won't implement reconnect version fallbacks again, ever. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Thu, Sep 17, 2015 at 02:46:39PM -0700, Brian Smith wrote: > On Thu, Sep 17, 2015 at 1:50 PM, Nico Williams > wrote: > > Do we think that silent connection closings wouldn't also lead to > > version fallback? > > Let's ask the browser vendors: > > Browser vendors, if web servers were to stop sending alerts during > handshake failures, would you start doing version fallback when a > connection is closed? That's not how we answers to questions like that. These behaviors (on the part of developers) arise long after we think ask the question. The point is: if they did it then, why would we think they wouldn't do it now without fatal alerts? Spoiler alert!1!!: developers want the user experience to be smooth, security be damned, so yes, they will in fact implement version fallbacks on connection close. But now consider a fatal alert that conveys a "it's not gonna work with earlier versions either, you dummy" message. That's got a slightly better chance of working. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Thu, Sep 17, 2015 at 05:47:50PM -0400, Dave Garrett wrote: > On Thursday, September 17, 2015 03:27:10 pm Brian Smith wrote: > > (We should focus on conformant implementations because non-conformant > > implementations can do whatever they want, by definition). > > The flaw in your logic here is the fact that specifications change. > Firefox will receive a protocol_version alert from a > version-incompatible server. Both implementations could be fully > conformant to their target specifications, just different versions. > Without this alert being consistently sent, everyone gave up and > implemented a sloppy fallback mechanism which made downgrade attacks > rather simple. Yes, exactly. Thanks. > Certificate alerts can happen pretty much anywhere and this is a > user-configurable area so it's not the implementations fault, but it > needs to know what happened for anyone to be able to handle it. User certificates will be useless without alerts for validation or authorization failures. > We could probably build a whole list here, but that's enough for me to > say that alerts matter in conformant implementations and that we need > to always expect they're used correctly. +1 Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Sat, Sep 12, 2015 at 01:49:49PM -0700, Eric Rescorla wrote: > Issue: https://github.com/tlswg/tls13-spec/issues/242 > > In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues: > > "Nobody must ever be *required* to send an alert. Any requirement for > sending an alert should be SHOULD, at most." There have been two main lines of argument in this thread, paraphrased: a) don't send them, they are dangerous, and b) making it even just likely that fatal alerts reach the peer is hard, therefore why bother. I believe (a) is flawed and wrong. Fatal alerts are not the cause of version fallback reconnects, and they should not be a problem with any of the ciphersuites in 1.3. I believe (b) is no reason not to send the fatal alerts. It is reason to have text about how an implementation that cares can improve the likelihood of the peer receiving them. Yes, fatal alerts should be required to be sent. Servers should be encouraged to improve the chances of the alerts being received by clients by attempting to delay close the connection. (A simple timer is not enough; a hard limit on the number of pending-close connections is desirable. IMO.) Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Thu, Sep 17, 2015 at 03:00:05PM -0700, Brian Smith wrote: > On Thu, Sep 17, 2015 at 2:55 PM, Nico Williams > wrote: > > On Thu, Sep 17, 2015 at 05:47:50PM -0400, Dave Garrett wrote: > > > > Yes, exactly. Thanks. > > > > There's no evidence that the presence or absence of an alert when a > connection is closed makes any positive difference in the security of any > non-secure fallback mechanism. Keep in mind that the alerts during the > handshake are NOT authenticated, and the TLS threat models thus assumes > that the attacker can remove or alter them. I thought your argument was that their presence led to version fallbacks. My response is that silent connection closes will too. My apologies if I misunderstood your argument. > > User certificates will be useless without alerts for validation or > > authorization failures. > > First, this is due to flaws in the design of applications and TLS in how > client certificates are handled. Yes: they shouldn't be relying on TLS to authenticate users. Got it. :^) Nonetheless, there is the feature, and if we have it then we might as well build it right, which includes meaningful error messages. > Secondly, if a server doesn't deal with client certificates, why > should it be forced to send alerts? That was just one case. > > > We could probably build a whole list here, but that's enough for me to > > > say that alerts matter in conformant implementations and that we need > > > to always expect they're used correctly. > > Again, the alerts are generally unauthenticated so there is really no > correct use of them. Diagnostics. And not all alerts need be unauthenticated. And heck, we could have the server send signed alerts in handshake failure cases. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] invariant or not: one TLS connection per TCP connection?
On Tue, Jul 07, 2020 at 09:22:24PM -0700, Benjamin Kaduk wrote: > There's an interesting note in draft-ietf-nfsv4-rpc-tls-08 (currently > in IESG Evaluation): > >The protocol convention specified in the current document assumes >there can be no more than one concurrent TLS session per TCP >connection. This is true of current generations of TLS, but might be >different in a future version of TLS. > > Can we envision wanting to do such a thing (e.g., with connection IDs for > non-D TLS)? If not, I can give them guidance that this type of statement > is not needed. I can see an application that starts TLS in a TCP connection, ends TLS without also ending the TCP connection, then starts TLS again. But multiple concurrent TLS connections in one TCP connection? I don't see that happening. Maybe with DTLS, but they are using TLS. I would just remove the above paragraph. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)
On Wed, Sep 30, 2020 at 10:17:53PM +1000, Martin Thomson wrote: > The costs you describe are trivial. And we limit replay with a binding > to remote address, and a short timer. But the benefit is mostly down > to reduced code variations. We also implement DTLS where this is > properly useful. You need a replay cache system if you're going to allow 0-rtt and the 0-rtt part of the application protocol is sensitive (e.g., it sends passwords, or missile launch commands). Replay caches are hard enough to get right when you're clustering servers. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections
On Fri, Mar 05, 2021 at 05:01:04PM +, John Mattsson wrote: > On Friday, 5 March 2021 at 15:02, Fries, Steffen wrote: > > I've got a question regarding application of TLS 1.3 to protect long > > lasting connections. Specifically on the trigger to perform a > > revocation check for the utilized certificates in the handshake. You can perform OCSP or CRL checks on the RPs at any time. You don't need a protocol trigger for it. You can use a timer. The issue is that the EE certificate (or intermediates in the chain perhaps) could expire or be replaced before the connection ends, and then you might want the EE to present a new certificate and, if for a new key, then also a proof of possession. One could use session renegotiation back when it existed, but it does not now. > > Hence the question if there is a feature in TLS 1.3, which would > > provide the functionality to invoke a mutual certificate based > > authentication. While renegotiation will never be re-added, there is post-handshake authentication (RFC 8446, section 4.6.2), and while that is currently about authenticating the _client_ to the server, it should be trivial to extend the protocol to support re-authenticating the server to the client as well. Authenticating the client to the server and vice-versa would be independent, at least when using certificates, though not so much when using PSK. Each relying party would send a CertificateRequest message on a timer based on local configuration of certificate freshness policy and/or the peer's certificate's expiration time, or whatever you like. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections
On Fri, Mar 05, 2021 at 06:42:40PM +, John Mattsson wrote: > >While renegotiation will never be re-added, there is post-handshake > >authentication (RFC 8446, section 4.6.2), and while that is currently > >about authenticating the _client_ to the server, it should be trivial to > >extend the protocol to support re-authenticating the server to the > >client as well. > > I think the current Post-Handshake authentication is not really > suitable for long-term connections. It assures that the other party is > still alive but it does not shut out any other third parties with > access to application_traffic_secret_N. Such parties may have gotten > the key with or without collaboration with one of the nodes. We assume local security, so the only way the TLS keys could have leaked to third parties is if either a) the local security assumption fails, in which case you have bigger problems, or b) the cryptographic security of TLS itself failed, in which case you have bigger problems, or c) you're exceeding usage limits on a symmetric cipher. Changing session keys wouldn't help you in cases (a) or (b). I think the only interesting case is (c). If you're using a 128-bit block cipher, you're not in case (c) as you'd have to transfer something like 2PB before you exceed AES key usage limits. At some point you have to be prepared to reconnect. Application protocols that work like BGP (destroy the world on RST) simply need to be fixed to not do that. > Agree that the negotiation part of renegotiation should not come back. > Below is a sketch of what I think would be needed Post-Handshake for That's essentially renego-lite. Note that there's protocol timing trickiness in getting this right. SSHv2, which does have proper re-keying, has experience with that. > DTLS/SCTP with DTLS 1.3: What's special about DTLS vs. TLS? Why should one get this but not the other? Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections
On Fri, Mar 05, 2021 at 01:13:57PM -0500, Viktor Dukhovni wrote: > This harks back to another recent thread where it was noted that one > needs to make a distinction between authentication and authorisation. > > The integrity of a TLS 1.3 session (which always performs ephemeral key > agreement that offers forward-secrecy) is not compromised if later the > signing keys of one of the parties is compromised. So there is no need > to check CRLs or renegotiate to just to maintain a secure connection. > > On the server side, if the client's identity is used as a key into an > authorisation table, one just needs to periodically (or even at each > logical request) to revalidate the client's authorisation, there is > generally no need to "re-authenticate" the client. Yes, authorization is probably getting conflated here. Suppose the authorization is local and slow to be updated. E.g., when an employee separates from their employer, local authorization may not get updated with much celerity, so if the subject's certificate expires sooner than local authz could get updated, then re-authenticating the subject would help. (This assumes credentials do expire with celerity, but that is good practice.) That might seem weird, but consider a stateful file server, something like NFSv4, say, and suppose that a client connects, authenticates, successfully opens some file to which they were authorized and... maybe now they can use that open file reference forever, much as one expects in POSIX. Except NFSv4 will require reauthentication though, so the client cannot in fact use that open file reference forever. But the NFSv4 server (I think) will not re-evaluate ACLs for existing open file handles as the ACLs change (per POSIX). Re-authenticating the client does serve something of an authorization purpose in the file server example. (Of course, a file server doesn't need to hew to POSIX on this, and could re-evaluate ACLs for open file references, and/or it could have a revocation feature like BSD's revoke(2) that lets users forcibly close open file references.) > If there is a concern that a server may somehow mid-session cease to be > [...] +1 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections
On Fri, Mar 05, 2021 at 04:46:15PM -0800, Eric Rescorla wrote: > This leaves us with the case where Bob's certificate is no longer valid but > Bob has a new certificate [0]. In this case, just re-validating does not > help. Does that happen so often that we need protocol machinery other than > just tearing down the connection and starting over? Probably not. I've seen 5 day server certificates in use. And while it's possible to keep connections open that long or longer, as Viktor points out, if you do keep a connection open and active longer than that and the server is still there (i.e., some node has its address and the connection's traffic keys), then that's probably good enough evidence that the server is still valid and still would have a fresh cert if you were to reconnect to it. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections
On Sat, Mar 06, 2021 at 06:55:52AM +, Peter Gutmann wrote: > Nico Williams writes: > > >I've seen 5 day server certificates in use. > > For IEC-62351 work you're far more likely to see certificates issued with an > expiry date of never, because the last thing you want is your power grid to be > taken offline due to a cert someone forgot to renew. When expirations are short, you will not forget to renew. That's part of the point of short-lived certificates. Set lifetime long enough that you have enough time to renew in most outage scenarios (i.e., pick N days such that you expect no outage will take longer than that to resolve, and be conservative for things like power grids), but short enough that you simply must automate renewal. > In terms of CRL updates the situation is similar, the spec may say you need to > check once every X time interval but in practice you forget to perform the > check in case it takes your grid offline. Or set a flag saying "cert revoked" > and continue anyway, I've seen both. [...] Sure. > [...]. The 24-hour thing sounds like someone's > checkbox requirement rather than anything practically useful, or usable. Short-lived certs are a "checkbox requirement" where the theory is that if it's short enough (doesn't have to be 1 day) then you will be forced to automate renewal, so you'll never fail to renew. It's about improving ops, not so much about security. That it also helps with revocation -so you don't have to bother with it- is also an ops (and dev) benefit. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections
On Sat, Mar 06, 2021 at 01:21:14AM -0500, Viktor Dukhovni wrote: > I suspect that in at least some cases the motivation to revalidate the > server certificate is only requested because it could be done in > principle, and ticks some checkbox about using CRLs, because they > exist, rather than from a clear threat this addresses. I agree. There's no need. > However, it is possible that there actually exist use-cases where this > makes some sense, and that case, If connection lifetimes would otherwise > last unacceptably long, make a new connection, and close the old (in > some appropriate order). Yeah, but then, in 2021 BGP still depends on long-lived connections... ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections
On Sun, Mar 07, 2021 at 09:57:40AM +, Peter Gutmann wrote: > Nico Williams writes: > > When expirations are short, you will not forget to renew. That's > > part of the point of short-lived certificates. > > So instead of getting one chance a year for your control system to break > itself if the renewal fails, you get hundreds of them? Yes. Exactly. It's a human factors problem. And this solution works. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections
On Sun, Mar 07, 2021 at 11:19:49PM +, Blumenthal, Uri - 0553 - MITLL wrote: > On 3/7/21, 17:36, "TLS on behalf of Nico Williams" behalf of n...@cryptonector.com> wrote: > > > >On Sun, Mar 07, 2021 at 09:57:40AM +, Peter Gutmann wrote: > >> Nico Williams writes: > >> > When expirations are short, you will not forget to renew. That's > >> > part of the point of short-lived certificates. > >> > >> So instead of getting one chance a year for your control system to > > break > >> itself if the renewal fails, you get hundreds of them? > > > >Yes. Exactly. It's a human factors problem. And this solution works. > > With all due respect, *absolutely not*. I'm not sure what it is you're imagining. What actually happens in the cases I'm familiar with is that there is one very long-lived root of trust (e.g., an endorsement key in a TPM) credential that is used to get all the short-lived credentials, and this is fully automated. In some cases the short-lived credentials are obtained by apps using the host's credentials, and then only when the application is running but still, periodically. The benefits of this arrangement are: a) no need for revocation of short-lived credentials, b) no need to worry about credential expiration (because the process is automated). I've also seen environments with very long-lived credentials where someone has to remember to renew them. I've seen lots of failures in those, but none in the case described above. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections
On Sun, Mar 07, 2021 at 11:47:45PM +, Blumenthal, Uri - 0553 - MITLL wrote: > I'm not sure what it is you're imagining. What actually happens in the > cases I'm familiar with is . . . . . > > Well-put - the point being that the cases you're familiar with do not > cover the entire spectrum of use cases. Specifically, they do not > match *my* operating environment. > > You may claim that my environment does not represent yours. Sure, > fine. Similarly, *yours does NOT represent mine*. I'm not telling you what to do. > And let's dispose with the "you're imagining" crap, shall we? I think > we've known each other long enough to be more polite. Otherwise, suit > yourself. No offense was meant. It's reasonable to suspect that even someone I know and I know is smart may not have all the relevant details. Besides, your >>> With all due respect, *absolutely not*. followed by no explanation, seems like much more likely to be intended to cause offense than "I'm not sure what it is you're imagining" followed by an explanation. I took it at face value however, and followed up. What a crime. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] last call: draft-ietf-kitten-tls-channel-bindings-for-tls13-02
+1 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [lamps] [EXTERNAL] Re: Q: Creating CSR for encryption-only cert?
On Thu, Oct 06, 2022 at 05:09:21PM +, John Gray wrote: > For a use case like an HSM or TPM where private keys can never leave > rules out option 1 (plus who wants to send their private key anyway > unless it is for server backup or escrow purposes). Option 3 would > work but is bad for CT log spamming. Option 2 of using an encrypted > challenge seems like the best choice, but obviously causes a 2nd round > trip. There doesn’t seem to be an ideal solution. Apart from amortizing the cost of the extra round trip, I don't see an acceptable alternative to (2). When you have already done a two round trip PoP enrollment of _some other_ encryption-only public key, you can just send new certificates for encryption-only public keys encrypted to the first one, thus amortizing the cost of the first two round trip enrollment by turning subsequent enrollments into one round trip affairs. In TPM parlance you'd enroll a machine and the public key of a decrypt-only, restricted primary, fixedTPM private key, complete with a two round-trip proof of possession protocol, and thereafter you would just send new certificates for new decrypt-only, possibly-fixedTPM keys, via TPM2_MakeCredential() with the new key as the activation object and the original key as the target. You don't need a TPM to make a protocol like that work, though one might want to use a TPM for this to secure the first key. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
On Tue, Feb 27, 2018 at 11:24:31AM -0500, Shumon Huque wrote: > On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote: > > Several of us were well aware of this during the early days of the > > draft, but perhaps many folks did not fully appreciate the impacts > > until I elaborated on them last year, and added text that described > > the "adversary with fraudulently obtained PKIX credentials" attack. > > Following up to my own message, sorry .. > > It occurred to me that perhaps a good way to mitigate this risk is > a combo of mechanisms like CAA and Certificate Transparency logs. NO. That's insanely complicated. A pin-for-X-minutes TTL is trivial. Let's do this pin-to-DANE thing. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
On Tue, Feb 27, 2018 at 05:36:12PM -0600, Nico Williams wrote: > On Tue, Feb 27, 2018 at 11:24:31AM -0500, Shumon Huque wrote: > > On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote: > > > Several of us were well aware of this during the early days of the > > > draft, but perhaps many folks did not fully appreciate the impacts > > > until I elaborated on them last year, and added text that described > > > the "adversary with fraudulently obtained PKIX credentials" attack. > > > > Following up to my own message, sorry .. > > > > It occurred to me that perhaps a good way to mitigate this risk is > > a combo of mechanisms like CAA and Certificate Transparency logs. > > NO. That's insanely complicated. A pin-for-X-minutes TTL is trivial. > Let's do this pin-to-DANE thing. And I should add that if you'd work around downgrades by using CT, then why bother with this extension *AT ALL*?! I can't be emphatic enough about this. This is an utter waste of everyone's time here if we don't have this pin-to-DANE feature in this draft. The authors' time, the WG's time, the IESG's time, and implementors' time. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
IF there's an objection to modifying the extension in order to add a pin-to-DANE TTL field, I would propose the following instead: Make the pin-to-DANE be "forever" but make it so it can easily be cleared if DANE is undeployed for the service. That would look like this: - if the server sends the extension with a valid DANE RR chain -> pin to DANE (no TTL needed; see below) - if the server sends the extension with a non-existence proof for DANE -> clear the PIN to DANE - if the server sends the extension with proof that an intermediate domain is not signed -> clear the PIN to DANE This has the great benefit that it is simple. Also, I'm not at all sure that a pin TTL is actually useful. If I know bar.foo.example. supports DANE, why would I want to asynchronously stop expecting it to use DANE when it could just tell me (with a suitable proof)? Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, Apr 04, 2018 at 10:50:15AM -0700, Joseph Salowey wrote: > Some objections were raised late during the review of > the draft-ietf-tls-dnssec-chain-extension. The question before the working > group is either to publish the document as is or to bring the document back > into the working group to address the following issues: For the record, I've had a document need changes after IESG publication approval that were then made with a WG LC for those changes rather than a repeat of WG LC, IETF LC, and IESG review. I'm surprised that this changes should require "bring[ing] the document back into the working group" if by that you mean going through the full process all over. Though, to be sure, I don't object if that's the required path now, but I don't want people to feel compelled to be against this LC on account of the delay in publication being much bigger, not if there's a shorter method. (Also, I don't mind a delay all that much: it's hardly that big a deal; RFCs often end up stuck in AUTH48 for much much longer!) > - Recommendation of adding denial of existence proofs in the chain provided > by the extension > - Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > > This is a consensus call on how to progress this document. Please answer > the following questions: > > 1) Do you support publication of the document as is, leaving these two > issues to potentially be addressed in follow-up work? I do not. > If the answer to 1) is no then please indicate if you think the working > group should work on the document to include > > A) Recommendation of adding denial of existence proofs in the chain > provided by the extension > B) Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > C) Both At least (B), and preferably (C). My rationale for (B) is that this is the sort of thing where adding it from the get-go will yield deployment where DANE is not mandatory for the application whereas not adding it now will yield non-deployment of DANE in such applications for a very long time. My rationale for (C) is that (A) is trivial, so might as well throw it in. Mind you, (B) is also trivial (two bytes! to be conveyed however you want, with 0 -> clear the pin to DANE). Thanks, Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote: > I don't think that this comparison is particularly apt.The > representation in HSTS is simply "I support HSTS". The representation > in HPKP is "I will use either consistent keying material *or* a > consistent set of CAs". The representation here is "I will continue to > have DNSSEC-signed DANE records". That is a significantly more risky > proposition than continuing to support TLS (and I'm ignoring the risk > of hijacking attacks that people were concerned with with HPKP), and > so this seems rather more like HPKP to me. Without a TTL (with zero meaning "clear the pin to DANE") this extension can only really be used with mandatory-to-use-with-DANE protocols, where the commitment to "continue to have DNSSEC-signed DANE records" is implied. The TTL allows one to put a bound on that commitment, thus alleviating the risk. That's the whole point: to alleviate the risk of commitment to DANE in order to not discourage opportunistic deployment. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 05, 2018 at 12:07:57PM +1000, Martin Thomson wrote:
> Given what we've learned about pinning (it is being removed from
> browsers), this seems like a bad plan to me.
You can use this TTL, or not. You're not required to set it to any
value other than the max ("infinity") or min (zero) if you don't want
to. You can pin or not pin. You can make DNAE mandatory (TTL set to
infinity) or not.
Adding this TTL cannot have a negative impact on the initial application
of this extension.
Nico
--
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, Apr 04, 2018 at 05:33:27PM -0400, Paul Wouters wrote: > On Wed, 4 Apr 2018, Joseph Salowey wrote: > >A) Recommendation of adding denial of existence proofs in the chain provided > >by the extension > >B) Adding signaling to require the use of this extension for a period of > >time (Pinning with TTL) > >C) Both > > These options need a bit of clarification. > > If you do A) then by publishing the proof of non-existance records, you > can cancel any outstanding kind of pin done. And you would not need B) Hmm, not quite. You might want to publish the "clear the pin" (TTL == zero) without having to first stop publishing TLSA RRs. The idea is to first ramp up the TTL, and if there's any problems / change of mind, ramp it down and remove the TLSA RRs when the last possible extant pin must have expired. Therefore I think (B) is more urgent. (A) is even more trivial than (B), so there's no reason not to do both ((C)). > [..] > > So to support all cases, I would say C) but I think B) would get us > pretty far on a lot of deployments. +1 > The document's intension is clearly to staple DNSSEC answers for the > TLSA query on the TLS handshake. Omiting proof of non-existence means > it fails to achieve its specified goal and makes this TLS extension > completely useless[*] +1 Thanks, Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 05, 2018 at 02:39:43AM +, Richard Barnes wrote: > Re-adding the list. Removing one level of quotes. > On Wed, Apr 4, 2018, 22:34 Nico Williams wrote: >> On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote: >> > I don't think that this comparison is particularly apt.The >> > representation in HSTS is simply "I support HSTS". The representation >> > in HPKP is "I will use either consistent keying material *or* a >> > consistent set of CAs". The representation here is "I will continue to >> > have DNSSEC-signed DANE records". That is a significantly more risky >> > proposition than continuing to support TLS (and I'm ignoring the risk >> > of hijacking attacks that people were concerned with with HPKP), and >> > so this seems rather more like HPKP to me. >> >> Without a TTL (with zero meaning "clear the pin to DANE") this extension >> can only really be used with mandatory-to-use-with-DANE protocols, where >> the commitment to "continue to have DNSSEC-signed DANE records" is >> implied. > > This is just not true. As I said in my earlier message, servers can > switch based on the ClientHello. > > Clients advertise which methods they support, servers switch, and they > both see how often DANE gets used. When it gets high enough, they turn off > the fallback. Just like every other TLS feature we've ever done. If clients and servers just negotiate the use of DANE, then there's a downgrade attack when DANE is the only outcome desired by the server operator but some WebPKI CA is willing to issue a rogue certificate for it. That downgrade is a fatal flaw for any protocols where this extension isn't mandatory. QED. We cannot be serious about security while promoting a protocol with a glaring downgrade attack. The TTL with pin-to-DANE semantics alleviates this by allowing the use of DANE to become mandatory-like for some time after first-use. It's TOFU-ish (Trust On First Use). TOFU has worked rather well for some protocols, and it will probably work well in the future. This mechanism to make this extension mandatory-for-some-time negates the downgrade attack *and* simultaneously provides a path to undo the use of DANE -- something that operators can reasonably be expected to demand for any protocol where this extension is not mandatory. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, Apr 04, 2018 at 07:44:53PM -0700, Eric Rescorla wrote: > On Wed, Apr 4, 2018 at 7:20 PM, Nico Williams wrote: > > > On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote: > > > I don't think that this comparison is particularly apt.The > > > representation in HSTS is simply "I support HSTS". The representation > > > in HPKP is "I will use either consistent keying material *or* a > > > consistent set of CAs". The representation here is "I will continue to > > > have DNSSEC-signed DANE records". That is a significantly more risky > > > proposition than continuing to support TLS (and I'm ignoring the risk > > > of hijacking attacks that people were concerned with with HPKP), and > > > so this seems rather more like HPKP to me. > > > > Without a TTL (with zero meaning "clear the pin to DANE") this extension > > can only really be used with mandatory-to-use-with-DANE protocols, where > > the commitment to "continue to have DNSSEC-signed DANE records" is > > implied. > > > > This simply isn't true, for the reasons Richard Barnes indicated in his > response > to you. See my response to him. For any non-mandatory use of this extension, without the pinning semantics there is a glaring downgrade attack. > HPKP had a TTL and yet as a practical matter, people found it very > problematic. I can see why: you have to commit to one certificate in the chain not changing. Whereas here you only have to commit to continue to publish TLSA RRs (and signing them and your zone). This is a big difference. > And, of course, if you're concerned with hijacking attacks, the > hijacker will just advertise a very long TTL. But it's a TOFU-ish thing. The server impersonator has to have the right timing or else be detected -- that's very risky for them, and a deterrent to even trying. It's not fool-proof, but it's not nothing either. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, Apr 04, 2018 at 07:56:37PM -0700, Eric Rescorla wrote: > On Wed, Apr 4, 2018 at 7:31 PM, Nico Williams wrote: > > We cannot be serious about security while promoting a protocol with a > > glaring downgrade attack. > > Unfortunately, you are conflating the assertive and restrictive use cases. I'm conflating nothing. I want to be able to use this HTTPS with DANE, but this extension as-is cannot be used in any protocol where it isn't mandatory. (Richard B. proposes that one can use this with HTTPS when using a CA that is not likely to be trusted by some clients. But that's hardly the enticing use of this extension for HTTPS. The interesting use-case is DANE for HTTPS, with or without WebPKI, and having a method of possibly deploying this. By "possibly" I mean "incremental".) > To recap, there are two potential reasons why one might want thi > technology: > > [...] You're not being serious. You're rationalizing the document as-is. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 05, 2018 at 03:04:03AM +, Richard Barnes wrote: > And just to be clear, by "downgrade attack", you mean "normal PKI > authentication that we rely on today". There's nothing in here that It's NOT that using WebOKI is a downgrade. It's that if an operator wants to use DANE (with any usage), then they want to use DANE. If an impersonator can make that not happen, it's a downgrade from the operator's perspective (because they then don't get what they wanted). > degrades security (except maybe the legacy crypto in the DNS); it's > just not meeting the bar that you are setting. That doesn't mean > there's not still some utility to be had. Nonsense. The operator wants DANE? They should be able to get it. If an active attacker can make that not happen at will, then that is and can only be called a downgrade attack. Waving your hands doesn't make this go away. The WebPKI's security is irrelevant to this discussion. Only the server operator's desired outcome is relevant. If they can't get it, then this protocol is not useful to them. And this protocol is all about using DANE in TLS applications!!! Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, Apr 04, 2018 at 08:06:42PM -0700, Eric Rescorla wrote: > On Wed, Apr 4, 2018 at 7:34 PM, Nico Williams wrote: > > > > HPKP had a TTL and yet as a practical matter, people found it very > > > problematic. > > > > I can see why: you have to commit to one certificate in the chain not > > changing. > > No, this isn't correct, in two respects. > > 1. HPKP pins the SPKI, not the certificate, it's about the *key* not > changing, and intermediates and roots change quite infrequently. > (https://tools.ietf.org/html/rfc7469#section-2.1.1) Either way it's the same impact: you cannot roll that key over. Whereas with pin-to-DANE there's no such problem. I thought I made that clear. > 2. It's not one key. HPKP allowed you to pin multiple keys and in fact > *required* you to set a backup pin > (https://tools.ietf.org/html/rfc7469#section-2.5) The problem remains: you're pinning to key material, which complicates key management. > Whereas here you only have to commit to continue to publish > > TLSA RRs (and signing them and your zone). This is a big difference. > > > > I don't think that's it all obvious that this is going to be easier to > guarantee, especially given the rather high DNSSEC misconfiguration > rate > (https://link.springer.com/content/pdf/10.1186%2Fs13388-015-0023-y.pdf, > https://indico.dns-oarc.net/event/14/contribution/14/material/slides/0.pdf). I flubbed that up a bit. With the pin you commit to continue to using this extension for as long as the clients have pinned it (which you control via the TTL). You can actually stop signing your zone provided that you continue to use the extension. > > And, of course, if you're concerned with hijacking attacks, the > > > hijacker will just advertise a very long TTL. > > > > But it's a TOFU-ish thing. The server impersonator has to have the > > right timing or else be detected -- that's very risky for them, and a > > deterrent to even trying. It's not fool-proof, but it's not nothing > > either. > > Given that the motivation for this kind of hijacking was generally > expected to be vandalism or ransom, this doesn't seem very comforting. The motivation for opportunistically using this is to be able to incrementally deploy DANE for HTTPS (and browsers). Without that it won't get deployed at all for HTTPS. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 05, 2018 at 06:33:10AM -0700, Eric Rescorla wrote: > On Thu, Apr 5, 2018 at 2:02 AM, Paul Wouters wrote: > > On Wed, 4 Apr 2018, Eric Rescorla wrote: > >> HPKP had a TTL and yet as a practical matter, people found it very > >> problematic. > >> And, of course, if you're concerned with hijacking attacks, the > >> hijacker will just advertise a very long TTL. > > > > By publising DANE records with either a TLSA record or a denial of > > existence proof, you can override any longterm TTL. > > > > If an attacker puts in a 1 year PIN/TTL, any TLS-dnssec extension > > containing a valid NSEC proof of non-existence overrides the > > previous TTL/PIN.' > > Thanks. This is a good point that I agree does not apply to HPKP. > > However, that doesn't mean that hijacking isn't a problem (though I > agree a less serious one). If I have no provisions for DNSSEC at all > and the attacker does pin hijacking I could be offline for hours to > days while I figure out how to get and serve them. I've been calling this pin-to-DANE because it's short, but, really, it's pin-to-using-this-extension. You can use this extension even if your domain is not signed because the proof that it isn't signed would be delivered in this extension. I believe the only way pinning to this extension can cause the hijacking you propose is if the root zone stops being signed as then there would be no way to prove that you're no longer using DANE :) Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, Apr 04, 2018 at 08:39:37PM -0700, Eric Rescorla wrote: > On Wed, Apr 4, 2018 at 8:09 PM, Nico Williams wrote: > > Either way it's the same impact: you cannot roll that key over. > > > > Whereas with pin-to-DANE there's no such problem. I thought I made that > > clear. > > Yes, I agree that you're relying on a different guarantee from your > parent zone, I just don't think it's particularly obvious that that > guarantee is easier to ensure, for the reasons I indicated previously. Sure it is. As long as the root zone is signed you can use this extension and prove that you are / are not using DANE. > > > And, of course, if you're concerned with hijacking attacks, the > > > > > hijacker will just advertise a very long TTL. > > > > > > > > But it's a TOFU-ish thing. The server impersonator has to have the > > > > right timing or else be detected -- that's very risky for them, and a > > > > deterrent to even trying. It's not fool-proof, but it's not nothing > > > > either. > > > > > > Given that the motivation for this kind of hijacking was generally > > > expected to be vandalism or ransom, this doesn't seem very comforting. > > > > The motivation for opportunistically using this is to be able to > > incrementally deploy DANE for HTTPS (and browsers). Without that it > > won't get deployed at all for HTTPS. > > I don't see how this is responsive to the concern that this technique will > be used for hijacking. You're right. I believe this has been answered now separately by others, and also by me. This is not a pin-to-DANE feature we're asking for, but a pin-to-using-this-extension. I shouldn't have called it pin-to-DANE, but I did because it's short -- short, but not sufficiently pithy :( Now, it's true that an impersonator could force you to use this extension when you were not ready to, and that's a DoS, though an easy one to fix, relatively. I'll take that DoS over a downgrade attack. We could mitigate the DoS by saying that the pin TTL must be coerced to zero (or maybe 1) if the extension only bore an authenticated denial of existence. I would prefer to not have to do this, but I'd accept it. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] DPRIV has the downgrade too (Re: Consensus Call on draft-ietf-tls-dnssec-chain-extension)
On Thu, Apr 05, 2018 at 02:46:12AM -0400, Viktor Dukhovni wrote: > So I rather suspect that even the DPRIV use-case, which supposedly does not > need > the proposed changes, actually does need them for meaningful security from > using > DANE, and we've not just not looked at the details closely enough yet. It may > well turn out not substantially different from the browser use-case that is > not > adequately met by the current draft. > > Can someone explain briefly how DPRIV avoids the same downgrade issues, and > negative adoption incentives (cost-benfit comparison)? If it turns out that > no adequate explanation is possible, and indeed the same issues are present, > then the proposed changes (which are still needed elsewhere) are all the > more pressing. Oh, right, DPRIV isn't a work-in-progress. It's already here. Thus it cannot be an application that makes draft-ietf-tls-dnssec-chain-extension mandatory. Therefore it's subject to the downgrade attack we want to address with (C). I think now the WG should really want this LC to succeed and get this change made. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Tue, Apr 10, 2018 at 09:48:24AM -0400, Shumon Huque wrote: > Yes. I support the publication of the document as is. > > and would like to explain my position a bit. > > I'm very sympathetic to Viktor's desire to enhance this protocol > to provide downgrade resistance against PKIX attacks, and I > generally would share that desire too. > > But I would also like to publish a document that has the solid > consensus of the community that is one of key potential target > [...] Assertion of facts not in evidence. We're here because there is a question as to consensus (and/or process). We need to address that. The earlier consensus is not just applicable, as if it were, we would not be having this LC. Using the earlier consensus as justification is not responsive to the substantive issues, and is just not a good argument. A valid argument would be that this extension works for DPRIV, but you should consider that even for DPRIV there is a downgrade unless the client knows a priori that the server does (or does not) support this extension. > I also feel that the amount of time it has taken to finish up > this draft has significantly hurt its deployment chances. In the I'll be blunt: I do not care about how long it's taken and neither should anyone else (besides, it will take longer on the RFC-Editor queue anyways; as an RFC author myself, I know this all too well). I care about the quality of the end result, and so should you, and so should the WG, IETF, and IESG. There is bug in the spec. The bug affects DPRIV as well as other applications -- it affects any application where the client does not know a priori whether the server will or will not be using this extension. > early days of this draft there was (in my view) a window of opportunity > where some browsers had actual interest in implementing this spec. See the point that even DPRIV is affected. You might argue that your DPRIV clients will know a priori whether the server supports this extension, but that would have to be true of all DPRIV clients. > But in the intervening time, there have been enough bandaids (CT > and strengthed CAB forum requirements) applied to the WebPKI that > to many people in the web community, the risk of bad actors has been > sufficiently mitigated. But to the extent that there are still some > folks interested in this proposal, I see no benefit in proposing an > additional feature that they've stated doesn't work for them, or > that they will not use. Contradition. Then why bother with DANE and this extension? Your argument is to cancel the Internet-Draft, not to publish it as-is, yet you are also arguing to publish as-is. Pick one. > Another important facet of this debate that so far has not surfaced > on recent mailing list discussions is an assessment of the relative > benefits of webpki versus dane, and the recognition that there are > strongly divergent views on this topic. [...] This is not the subject matter of this LC. > Viktor has asserted that no-one will be motivated to deploy DANE > without protection against PKIX downgrade, because there is no > compelling enough additional gain of security. He may be right or > wrong, but I've already heard several web folks disagree with him. > [...] You're not addressing the glaring downgrade attack. > As for other applications, we've already heard from a number of > folks in the DNS over TLS camp that the draft works for them in > the current form. Most DNS over TLS clients are expected to have > explicit configuration of their resolver addresses and DANE > capabilities. "Most" != "all". To live with the downgrade you'd have to make that "all". You might want to think about all the deployment scenarios ruled out by having this bug. > Some possible ways forward I see for folks wanting to develop a version > of this spec with PKIX downgrade resistant capabilities (I've already > stated earlier, that I would be happy to participate in such efforts): > > * Develop a new spec, with a new codepoint, and let the specs compete > for adoption. > * Develop a -bis document - if we manage to get WG consensus on the > approach at a later date. > * Do something outside the protocol, and specific to applications > that want to include mechanisms to mandate DANE usage (like a HTTP > header). Needless to say, I oppose your proposal for reasons I've stated before. Two specs is not better than one, and we can count on implementors missing one. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Tue, Apr 10, 2018 at 11:48:58AM -0500, Benjamin Kaduk wrote: > On Tue, Apr 10, 2018 at 10:20:01AM -0400, Viktor Dukhovni wrote: > > > On Apr 10, 2018, at 9:48 AM, Shumon Huque wrote: > > > But I would also like to publish a document that has the solid > > > consensus of the community that is one of key potential target > > > consumers of this draft (web browsers and servers). So I'm giving > > > more weight to their views and preferences. To date, the only > > > people from that community that have spoken up have expressed > > > strong opposition to Viktor's proposed enhancement. > > > > There'll be negligible adoption of this draft as-is by Web Server > > operators on the public Internet. It offers them all pain and no > > gain. ZERO additional security over and above what they get with > > Let's Encrypt, only additional operational complexity and a new > > way to fail when the client supports DANE and the TLSA records > > are stale. > > I'd like to expand the discussion a little bit, on the question of > what the goals of this document are, as well as that they should be. I don't think that's necessary for settling this LC, but let's follow this for now: > Your text above seems to imply that you see the goal of the document > as being a security mechanism to DANE-authenticate TLS connections. Without precluding DANE + WebPKI. > But it's not clear to me that this is the best reading of the current > document text. Re-quoting some text you had included in the thread > previously: > >[...] The intent of this >proposal is to allow TLS clients to perform DANE Authentication >[RFC6698] [RFC7671] of a TLS server without performing additional DNS >record lookups and incurring the associated latency penalty. It also >provides the ability to avoid potential problems with TLS clients >being unable to look up DANE records because of an interfering or >broken middlebox on the path between the client and a DNS server >[HAMPERING]. And lastly, it allows a TLS client to validate the >server's DANE (TLSA) records itself without needing access to a >validating DNS resolver to which it has a secure connection. The last-mile problem described in the last sentence in the above quote is the most important point. This extension is not merely an optimization so that the client need not perform those additional DNS queries: it is a workaround to the last-mile problem. Moreover, this isn't just a run-time optimization, but also a developer optimization. Lastly, sometimes run-time and/or developer optimizations are actually necessary to get traction. >This mechanism is useful for TLS applications that need to address >the problems described above, typically web browsers or SIP/VoIP >[RFC3261] and XMPP [RFC7590]. [...] > > I'd like to see if we can agree on what "the problems described above" are. > I am reading the quoted text to say that the problems are: > > 1) needing to incur additional latency by doing DNS lookups > 2) interfering/broken middleboxes that drop DANE records > 3) needing a secure connection to a validating resolver (2) -> this extension is for clients to be able to use DANE when they otherwise could not. In order to be able to mix WebPKI and/or DANE, it is necessary to have the proofs of non-existence in order to be able to decide to dispense with DANE. Therefore this isn't just an optimization for when you want to use DANE: it is for when you are willing to use DANE, and willing to not do DANE, but you need to know which to do. It is because the choice is WebPKI and/or DANE that the downgrade attack, and the pinning mitigation (with TOFU semantics) matter. For example, on the web, in IMAP, ..., the WebPKI *and* (not *or*) DANE usage (DANE usages PKIX-TA #0 and PKIX-EE #1) are likely to matter. > While it is true that performing DANE Authentication generally does have > a security role, the three items I list above are essentially matters of > convenience, and not themselves relevant for security. In this sense, the > immediate goal of the document is more to play a role as a transport than to > provide security directly. I don't follow. The security role for DANE here is the whole story, and it is essential. How can we say that this is just about latency or last-mile problems when what DANE is doing at the end of the day is... provide authentication (security). > I concede that it remains useful to consider what the client will do > with the received DANE records or denial thereof, so as to not unduly > block off future routes for development. But it seems at least > possible to take a very broad view in this space, including even the > possibility of additional TLS extensions that can modify the behavior > of this one (such as a modification to provide pinning-like behavior). > Such extensions could be introduced closer in time to when the desire > to implement and use such behavior appears. Again, my concern is that the fo
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Tue, Apr 10, 2018 at 04:17:14PM -0800, Melinda Shore wrote: > On 4/10/18 3:53 PM, Nico Williams wrote: > > The earlier consensus is not just applicable, as if it were, we would > > not be having this LC. > > I have no idea what that even means, to be honest. We're through > last call, and it's not that the earlier wg consensus isn't > "applicable," it's that you've raised new issues. So let's be > clear about that. It means that because we are having this LC, we cannot use the previous consensus as evidence for ending this LC with a "no". We might as well never have had the LC in that case, and it is not a substantive response to the LC anyways. It's a "please go away" response. > I've been watching this discussion and trying to get a handle > on what's been going on (and how this fits into several other > IETF issues more generally), and I think this discussion would > be over if the people arguing in favor of changing the use > of the extension had plans to implement it. But so far nobody [...] Viktor began implementing DANE 8 months after it was published. That spec was ready. This spec is not. > It's unfortunate that over in DNS-land they're discussing how > to get rid of unused features that increase complexity, while over > here we're having a discussion of how to add unused features that > increase complexity. Sure, this is true, but it doesn't mean that we should exclude features that are necessary to making the protocol work in the first place. This is a TLS extension for stapled DANE, not a DPRIV extension to TLS. > I think those of us who care about the institutional effectiveness > of the IETF and the value of the standardization process care > quite a bit about the amount of time it takes to push a document > through to publication. Aside from negatively affecting the chances > [...] What is it to "care about the institutional effectiveness of the IETF "? Is it to care only about speediness? Or only about correctness? How about a bit of both? Honestly, if all you want is speediness, why not go to OASIS? Register the extension codepoint with IANA and publish elsewhere, why not? Doing things in the IETF means... the peanut gallery are not just spectators. Bringing work to the IETF means incurring the risk that others may glom onto it. It happens *all the time*, it's happened to me, and it will happen to others. There is nothing special to this piece of work that should exempt it. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] A new argument (Re: Consensus Call on draft-ietf-tls-dnssec-chain-extension)
Let me synthesize one new argument, though I've implied it before, but I think making it explicit may be useful: The cost of making the requested changes is fixed and can be estimated -- measured even, after the fact. I argue that cost is low. But the cost/risk of not making the requested changes is intangible -- could be very high, or barely more (but not less) than the cost of making the changes. We'd have to be sanguine to dismiss my estimate of the cost/risk of fixing this later. Perhaps that's right anyways, but it can plausibly be very large too, and that surely should trump a small fixed cost, therefore we're better off taking this hit now. I might clarify other points on the main thread, but, really, for me, the whole thing boils down to: are we looking out for the future, and is our contention of risk to future DANE deployment even plausible. It won't surprise anyone that I believe my estimate of the risk to future DANE deployment is not merely plausible. It won't surprise anyone either that I believe that even if the likelihood of reduction of future DANE deployment were low, we, the IETF, and in particular the IESG, ought to care about making our protocols sufficiently generic when the cost of doing so is low, as surely it would be here. We've already incurred what should be much of the cost of making the requested changes. A wee bit little more won't hurt. Let us now then proceed to proposed text. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 12, 2018 at 04:40:25AM -0400, Paul Wouters wrote: > On Wed, 11 Apr 2018, Benjamin Kaduk wrote: > > >I don't really agree with that characterization. To state my understanding, > >as responsible AD, of the status of this document: this document is in the > >RFC Editor's queue being processed. > > That was a process mistake. > > 1) ekr filed a DISCUSS > 2) other people raised issues in response > 3) ekr's DISCUSS was resolved but not the other people's concern > 4) document was placed in RFC Editor queue despite this > 5) TLS consensus call done on the list > 6) here we are > > I think it is not good to use this process as a way of approving things. > A process mistake was made. Yes, though this consensus call cures that (and moots that grounds for appeal). However, since it's become clear that the I-D undeniably has a problem because it describes pinning behavior and lacks sufficient functionality for that -- we really must now make a change. IMO, the question is no longer whether to make changes, but which changes to make. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 12, 2018 at 09:51:12PM -0700, Eric Rescorla wrote: > On Thu, Apr 12, 2018 at 9:40 PM, Viktor Dukhovni > wrote: > > > On Apr 13, 2018, at 12:07 AM, Melinda Shore < > > melinda.sh...@nomountain.net> wrote: > > > > > > I'm okay with putting denial-of-existence in there as a should, > > > but I do feel strongly that pinning belongs in a separate document. > > > As I said earlier, I have a problem with putting features in protocols > > > that nobody intends to use. It's bad enough when it happens by > > > circumstance but doing it deliberately strikes me as a bad idea. > > > > The great irony of the situation, is that present draft already > > describes pinning: > > > >If TLS applications want to mandate the use of this extension for > >specific servers, clients could maintain a whitelist of sites where > >the use of this extension is forced. The client would refuse to > >authenticate such servers if they failed to deliver this extension. > > > > And I've seen no discussion or working group consensus to *prohibit* > > such pinning, only observations that it would be rather fragile in > > general. > > Thanks for pointing this out. I agree that this text is likely to cause > interop problems and should be removed or at least scoped out in > the case where client and server are unrelated. I regret that I didn't > catch it during my IESG review. I think that means we'll end up with consensus to make a change, and indeed, we cannot not make some change. We can still debate whether to do (A), (B), (C), or, now, (D) (remove the text quoted by Viktor). I think it will be easier to get consensus for (A) or (C) than (D), though, of course, that's to be seen. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 12, 2018 at 04:10:27PM -0700, Eric Rescorla wrote: > On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni > wrote: > > Proposed text: > > > >When the server has DNSSEC-signed TLSA records, the first RRset in > >the chain MUST contain the TLSA record set being presented. > >However, ... > > > >When the server either has no TLSA records, or its domain is not > >DNSSEC-signed, it is RECOMMENDED that the server return a denial > >of existence of either the TLSA records, or proof of insecure > >delegation at some parent domain, rather than omit the extension. > >Clients that are willing to fall back from DANE to some alternative > >mechanism may require the denial of existence to make that possible. > > > > I believe that that this text would harm ineteroperability. > > The difficulty here is what the server knows about the clients behavior. > Specifically, if the server serves TLSA records and then ceases doing > without serving authenticated denial of existence, then it is unable to > determine if this would cause clients to fail because it doesn't know if > the client implements the text in the final paragraph. One could argue > that current clients could pin, but that's totally extratextual, as opposed > t having a noninteroperable behavior in the document. It's better to send the denial of existence than no extension -- the client could just as well be pinning (because the I-D said it could, or because the client does it regardless), and not having extension then will cause failure. Now, clients that don't do opportunistic pinning would have to... notice the lack of TLSA RRs, but not necessarily bother validating the denial of existence chain. There's not even a need to say that the client SHOULD (let alone MUST) validate the denial of existence chain. It suffices that the server SHOULD send it. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Fri, Apr 13, 2018 at 04:38:55PM -0400, Richard Barnes wrote: > On Fri, Apr 13, 2018 at 4:30 PM, Nico Williams > wrote: > > It's better to send the denial of existence than no extension -- the > > client could just as well be pinning (because the I-D said it could, or > > because the client does it regardless), and not having extension then > > will cause failure. > > > > Now, clients that don't do opportunistic pinning would have to... notice > > the lack of TLSA RRs, but not necessarily bother validating the denial > > of existence chain. There's not even a need to say that the client > > SHOULD (let alone MUST) validate the denial of existence chain. It > > suffices that the server SHOULD send it. > > Sure seems like it would be simpler to say "Client MUST NOT cache TLSA > state". Yes, that cuts off some use cases. But it avoids all the That's not the right way to say "no pinning". > transition pain that EKR has pointed out. The I-D needs *some* updates. You and I disagree about which updates, but it needs updates. It cannot be published as-is. Even removing any kind of pinning requires WG consensus at this point. And we've already seem that at least one author support (A), and we could probably easily get support for a (C') where we get the two bytes we're asking for as well but with as much semantics as possible left for a follow-on I-D. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Fri, Apr 13, 2018 at 12:16:43PM -0700, Jim Fenton wrote: > From reading the abstract and introduction to this draft, it appears to > be proposing mostly a performance improvement for retrieving web pages > using DANE authentication. There is some security improvement, but that > seems to be incidental to the performance improvement. That would argue > in favor of publishing the draft as-is. However: It's not just a performance improvement. It's also a last-mile technology: for clients that cannot perform DNS lookups due to being in, e.g., hotel networks. And it adds security. Using DANE adds security, that's for sure, since one can then rely on both, PKIX *and* DNSSEC, which can only add security. Or, if one does not trust the WebPKI, then only DNSSEC. I have no opinion as to which of WebPKI alone, WebPKI + DNSSEC, or DNSSEC alone, is best, but I have an opinion as to who ought to decide that: the server operator. This document gives the server operator that power, but it does not give the server operator any power over client pinning behavior, which means that operators will not turn this on for apps where it's not mandatory. That is, without revision, this document really does not help security as much as with a rather minor revision. We should want that minor revision because the (at-this-time-intangible) gain is potentially large, while the (at-this-time-intangible) cost/risk of not making that revision is equally large. > From the discussion I have read, there seems to be disagreement about > what even the semantics of this pinning would be. And if it's unclear to Among proponents there are no disagreements over pinning semantics. Pinning would be only to the use of the _extension_, not to the use of DANE, nor to any particular DANE usage. That is, if the server does not have TLSA RRs, it could still use this extension [to satisfy a client pin] to send the denial of existence proof, and the client's pin would be satisfied. > the WG participants, it's going to be even less clear to others that are > implementing this. I am also of the opinion that pinning is somewhat How would that follow? Shouldn't we see proposed text before we can tell if it would be unclear to implementors? > subtle; it requires a detailed understanding of the mechanism to remove > (expire) the pin, and if done wrong can result in availability problems. Exactly! (A) gives us a modicum of pin-clearing capability: if you get a denial of existence then you could clear the pin on the client. However, (A) + (B) (i.e., (C)) would give us the ability to separate the pin set/clear from the DNSSEC payload of the extension. *This* would give server operators all the control they need to feel safe enabling pinning behavior. It is much simpler to change a TTL in a server configuration than to make changes in the relevant DNS zone(s). Thus (C) or some (C') (see below) would be much better than (A). > In addition, the pins here would be maintained in individual browsers. And other user-agents for other application protocols (e.g., MUAs). > There is less benefit from pinning because unlike some other pinning > mechanisms, there isn't any leverage of the TOFU experience had by others. TOFU works reasonably well. It's risky for an attacker to mount an active attack that will be detected if the client has a pin -- this risk acts as deterrent. > This requires further thought, and I do not support adding pinning to > this draft. Perhaps as a separate draft, but the WG needs to decide on that. I wouldn't mind a (C'): a variant of (C) where we get denial of existence and a one- or two-byte TTL (one by count of weeks or two-byte count of hours) with de minimis text about it, leaving pinning semantics to a separate document. In such a (C') we'd elide all pinning (or most*) in this document. * We might want to say that if the TTL is zero then the clients MUST NOT pin and must clear any pin. And we might do this in spite of not describing any pinning semantics -- explicitly leaving pinning semantics to a future document. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication
On Mon, Apr 16, 2018 at 11:38:28AM -0700, Tony Arcieri wrote: > On Mon, Apr 16, 2018 at 9:11 AM, Viktor Dukhovni > wrote: > > A major obstacle to making access control decisions during the TLS > > handshake is that at that time the server often does not yet have enough > > information to determine which specific resource the client will ask to > > access. > > There's also the problem that (at least in an SOA/"microservice > architecture") people will inevitably want some resources to be accessible > without a client certificate, e.g. status endpoints or anything consumed by > clients which do not support TLS certificates. In these cases it really > helps to force things up a level out of the TLS handshake into something at > the application level like an ACL language that lets you whitelist > unauthenticated access to these resources. Indeed, one might even say that user authentication should be driven by application needs. This is done in HTTP, for example, via 401 responses, which can trigger HTTP authentication. Granted, HTTP authentication methods are fairly limited. If a client is authenticated at the TLS layer, authorization should still happen at the application layer as much as possible, as otherwise access control is very coarse-grained. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Mon, Apr 16, 2018 at 04:21:27PM -0400, Paul Wouters wrote: > On Mon, 16 Apr 2018, Viktor Dukhovni wrote: > >>* We might want to say that if the TTL is zero then the clients MUST NOT > >> pin and must clear any pin. And we might do this in spite of not > >> describing any pinning semantics -- explicitly leaving pinning > >> semantics to a future document. > > > >Exactly. I'd like to suggest that this is the most reasonable > >common ground, and would urge the WG and authors to get behind > >this as a consensus position. > > This seems dangerous. If an attacker can re-route and get a rogue > cert, they can set TTL to 0, negating a previously set TTL, without > requiring proof by presenting the denial-of-existence of the TLSA > record. That is also a downgrade attack. The extension would have to be present and contain either the TLSA RRs and chain, OR the denial of existence chain, in order to even to carry any TTL value. Only in the denial of existence case could an impersonator set a TTL value of the impersonator's choice, and in this case the client must treat it as zero in order to avoid a DoS. In the other case, the impersonator could *not* set a TTL of their choice without compromising DNSSEC. > How to go from TTL != 0 to TTL == 0 should be specified carefully, > either in this document or its own document. If the server sends a denial of existence, then the TTL can't be fully trusted, and there is a DoS if the client uses non-zero TTL values. If the server sends TLSA RRs and chain then all TTL values can be trusted and should be used, though we might specify how in a later document. > The only known save way of going to TTL == 0 is by presenting DoE of > TLSA records (but it does bind using the TLS extension to the existence > of TLSA records) The TTL will be coerced zero on DoE, but it can be set to zero in the TLSA case as well. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, Apr 18, 2018 at 04:52:14PM -0400, Richard Barnes wrote: > On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni > wrote: > > > > > > > > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote: > > > > > > I do not support adding a field to the protocol with semantics to be > > defined later. Especially a 16-byte field, which is a fair bit of cruft to > > carry around. > > > > The 16-byte is a typo. It was supposed to be 16-bit. My fault. Sorry. > > > > Secondary point. Still don't think we should deliberately include > undefined fields, e.g., because part of the discussion is whether 16 bits > is the right size. It's not as if we've never had reserved fields. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, Apr 18, 2018 at 05:01:54PM -0400, Richard Barnes wrote: > On Wed, Apr 18, 2018 at 4:56 PM, Viktor Dukhovni > wrote: > > > On Apr 18, 2018, at 4:52 PM, Richard Barnes wrote: > > > > > > Secondary point. Still don't think we should deliberately include > > undefined fields, e.g., because part of the discussion is whether 16 bits > > is the right size. > > > > 16 bits is clearly enough. If the units are hours that gets you ~7.5 > > years. Pinning for less than an hour is pointless, it then becomes smaller > > than typical DNS TTLs for the TLSA RRset the client got previously, which > > it can cache without any pinning. > > > > Pinning for more than 7.5 years is absurd, it only protect clients that > > connect less than twice per decade... > > 640k should be enough for anyone. That's just silly. Really, 7.5 years (relative, not absolute) measured in hours is plenty good enough, and more than outlives current device obsolescence. This isn't subject to Moore's law or anything like it. > `preload`? `includeSubdomains`? Experience with HSTS and HPKP shows you > need more than an integer. No, we need none of those things. We want only to pin the presence of this extension. Anything else would be operationally difficult (as seen with HPKP). As to subdomains, we're willing to live with TOFU semantics for all of them. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, Apr 18, 2018 at 11:34:14PM -0400, Viktor Dukhovni wrote: > > On Apr 18, 2018, at 11:25 PM, Peter Gutmann > > wrote: > >> That's just silly. Really, 7.5 years (relative, not absolute) measured in > >> hours is plenty good enough, and more than outlives current device > >> obsolescence. This isn't subject to Moore's law or anything like it. > > > > I don't know what devices you work with, but for the ones where my code is > > used ten years is the baseline life expectancy, going out to 15-20 years for > > longer-life ones (I still have to deal with SSH bugs from the late 1990s, > > because the lifetime of the equipment that's used in is 20 years and > > counting. > > I think I've finally managed to get away from having to do SSLv3 within the > > last year or two). > > > > OTOH I doubt any of these devices will do pinning, they just bake in the > > certs > > at manufacture/provisioning, so I'm fine with any kind of lifetime. Just > > wanted to point out, yet again, that the entire world doesn't live in a "we > > can patch the entire deployed base in 24 hours" situation. > > Indeed, but if pinning were desired, all the device would have to do > is call the mother ship at least twice per decade, it can then work > for multiple decades. Exactly. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Proposed text for dnsssec chain extension draft
On Wed, Apr 25, 2018 at 11:51:58AM +0200, Melinda Shore wrote:
> On 4/25/18 7:33 AM, Viktor Dukhovni wrote:
> > Perhaps a concrete proposal will make it
> > easier to reach a mutually-agreeable consensus position, and make it
> > clear that the requested 16-bits are a reasonable consensus outcome.
>
> Hi, Viktor:
>
> This doesn't actually reflect the consensus called by the
> chairs, as I understand what was posted. It may be useful
> to start work on a new draft describing your proposal.
The chair said there is consensus for (A) with no pinning. Viktor's
proposal is (A) with no pinning. It's not at all clear to me that the
two reserved bytes are outside the consensus, and anyways, their cost is
minimal.
However, if you object to turning the extension contents into a struct,
then I would propose a slight tweak to Viktor's proposal:
Two-byte elements of the AuthenticationChain are reserved for future
use. Pending future specifications, clients MUST discard any two-
byte elements of the AuthenticationChain, and servers MUST NOT send
any such elements.
We might as well say that all too-small-to-be-DNS-payloads elements of
the AuthenticationChain are reserved and discarded:
Any elements of the AuthenticationChain that are too small to contain
DNS RRset payloads are reserved for future use. Pending future
specifications, clients MUST discard any such AuthenticationChain
elements, and servers MUST NOT send any such elements.
The nice thing about this is that it makes it easier to extend this
extension later, while also adding minimal complexity now ("clients MUST
discard such elements").
Nico
--
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Proposed text for dnsssec chain extension draft
On Wed, Apr 25, 2018 at 09:57:22AM -0500, Nico Williams wrote: > On Wed, Apr 25, 2018 at 11:51:58AM +0200, Melinda Shore wrote: > > On 4/25/18 7:33 AM, Viktor Dukhovni wrote: > > > Perhaps a concrete proposal will make it > > > easier to reach a mutually-agreeable consensus position, and make it > > > clear that the requested 16-bits are a reasonable consensus outcome. > > > > Hi, Viktor: > > > > This doesn't actually reflect the consensus called by the > > chairs, as I understand what was posted. It may be useful > > to start work on a new draft describing your proposal. > > The chair said there is consensus for (A) with no pinning. Viktor's > proposal is (A) with no pinning. It's not at all clear to me that the > two reserved bytes are outside the consensus, and anyways, their cost is > minimal. > > However, if you object to turning the extension contents into a struct, > then I would propose a slight tweak to Viktor's proposal: > >Two-byte elements of the AuthenticationChain are reserved for future >use. Pending future specifications, clients MUST discard any two- >byte elements of the AuthenticationChain, and servers MUST NOT send >any such elements. Ay, never mind, this isn't XDR, so that wouldn't work. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Proposed text for dnsssec chain extension draft
On Wed, Apr 25, 2018 at 10:40:02AM -0500, Nico Williams wrote: > On Wed, Apr 25, 2018 at 09:57:22AM -0500, Nico Williams wrote: > > On Wed, Apr 25, 2018 at 11:51:58AM +0200, Melinda Shore wrote: > > > On 4/25/18 7:33 AM, Viktor Dukhovni wrote: > > > > Perhaps a concrete proposal will make it > > > > easier to reach a mutually-agreeable consensus position, and make it > > > > clear that the requested 16-bits are a reasonable consensus outcome. > > > > > > Hi, Viktor: > > > > > > This doesn't actually reflect the consensus called by the > > > chairs, as I understand what was posted. It may be useful > > > to start work on a new draft describing your proposal. > > > > The chair said there is consensus for (A) with no pinning. Viktor's > > proposal is (A) with no pinning. It's not at all clear to me that the > > two reserved bytes are outside the consensus, and anyways, their cost is > > minimal. > > > > However, if you object to turning the extension contents into a struct, > > then I would propose a slight tweak to Viktor's proposal: > > > >Two-byte elements of the AuthenticationChain are reserved for future > >use. Pending future specifications, clients MUST discard any two- > >byte elements of the AuthenticationChain, and servers MUST NOT send > >any such elements. > > Ay, never mind, this isn't XDR, so that wouldn't work. Actually, since the extension's body is an opaque<1..2^16-1>, and the extension is itself an opaque<>, it's possible to have data past the end of the body of the extension. But at this point I prefer Viktor's struct proposal. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Proposed text for dnsssec chain extension draft
On Wed, Apr 25, 2018 at 09:13:37PM -0700, Joseph Salowey wrote: > This proposal is quite a bit more than just a two byte reserved field. What, Viktor's text? Most of it has to do with the denial of existence, not with those two bytes. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Proposed text for dnsssec chain extension draft
On Wed, Apr 25, 2018 at 11:30:02PM -0700, Eric Rescorla wrote: > Thanks for producing some text. I understand why one might think that > having a reserved 16-bit field is useful here, but I don't really > agree. > > The conventional reason to reserve this kind of field is that you need > to leave space for an extension in some PDU, because it's hard to add > later. But that's not true here (or in TLS in general) because we -07 has text on pinning. There is no consensus on making that work _now_. There is only consensus on removing that text and revisiting pinning later. Well, later we will need these two bytes. So there's the conventional reason to reserve this kind of field: because we know we will need it, and adding it via some extension facility will be harder than... already having it. And yes, we (the IETF) do use reserved fields even in protocols where there is extensibility. > already have an extension mechanism (indeed, the one that's being used > by this specification). If we end up having consensus to do pinning, > then it's straightforward to define a new TLS extension that provides > it. Having these two bytes now will mean that they are always present, which will make it a lot easier for implementations to a) start sending non-zero values, b) start handling non-zero values, once we write a spec on what non-zero values mean. (And we know what that spec will say, which is why we know we need two bytes.) > If you look at HPKP and Expect-CT, you will note that there are a > [...] HPKP is completely different. The idea here is NOT to pin key material, CAs, or anything of the sort. The idea here is to pin only the use of this extension, and this does not even bind one to use DANE because the extension can carry a denial of existence. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Proposed text for dnsssec chain extension draft
On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote: > On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni > wrote: > > On Apr 26, 2018, Eric Rescorla wrote: > > > > * a lifetime field > > * enforce vs. test > > * a report URI We will need only the TTL. We will not need anything else. This is NOT like HPKP. This will pin only the use of the extension, and NOT EVEN the use of DANE since you can send a denial of existence and you can *always*[*] do that if you stop wanting DANE. [*] unless you're operating in an alternate DNS universe where no zone is signed, not even the root zone, but then you wouldn't have used this extension ever, and you'd not have pinned it). Because we'd pin only to the use of this extension, the TTL is sufficient. > > This specification is always "enforce" (though my pull request > > changes a MUST use DANE to a SHOULD with some necessary added > > conditions) and since the report URI is in good measure to > > support non-enforce mode, we're back to just max-age. > But this reinforces my point. I think we ought to have an enforce vs > test flag and a report URI (and I I don't find your arguments above > about why we shouldn't do this persuasive.) Standardizing this > functionality would require resolving these issues. Strawman. These are make-believe issues. Is it just to give the appearance that we couldn't possibly reach consensus on just two bytes? Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Proposed text for dnsssec chain extension draft
On Thu, Apr 26, 2018 at 11:41:05AM -0400, Richard Barnes wrote: > On Thu, Apr 26, 2018 at 11:22 AM, Nico Williams > wrote: > > > On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote: > > > On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni > > > > > wrote: > > > > On Apr 26, 2018, Eric Rescorla wrote: > > > > > > > > * a lifetime field > > > > * enforce vs. test > > > > * a report URI > > > > We will need only the TTL. We will not need anything else. This is NOT > > like HPKP. This will pin only the use of the extension, and NOT EVEN > > the use of DANE since you can send a denial of existence and you can > > *always*[*] do that if you stop wanting DANE. > > Until my DNSSEC signing infra breaks, the signatures expire, and now my > server is bricked. There is no way in which you can break your zone such that this pinning gets you into trouble. Here's why, there are only these possible states: - you have TLSA RRs with a valid chain all the way to the root (works) - you don't have TLSA RRs and have a denial of existence chain (works) - your zone isn't signed, in which case you can prove this and we call that a denial of existence too (works) - your zone is bricked (fails because lookups fail) If your zone is bricked then this extension doesn't even come into play because clients will not be able to resolve your servers' hostnames, therefore they won't even connect. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Proposed text for dnsssec chain extension draft
On Thu, Apr 26, 2018 at 08:41:18AM -0700, Eric Rescorla wrote: > On Thu, Apr 26, 2018 at 8:22 AM, Nico Williams > wrote: > > Because we'd pin only to the use of this extension, the TTL is > > sufficient. > > I explained in my response to Victor why this isn't so. I don't accept that explanation. It's based on a strawman argument. > > > But this reinforces my point. I think we ought to have an enforce vs > > > test flag and a report URI (and I I don't find your arguments above > > > about why we shouldn't do this persuasive.) Standardizing this > > > functionality would require resolving these issues. > > > > Strawman. These are make-believe issues. Is it just to give the > > appearance that we couldn't possibly reach consensus on just two bytes? > > This discussion would probably be a lot more productive if you were able to > have it without accusing other participants of acting in bad faith. Sounds good to me. One way to make this more civil is to not make strawman arguments. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Proposed text for dnsssec chain extension draft
On Thu, Apr 26, 2018 at 11:53:29AM -0400, Viktor Dukhovni wrote: > Of course given evermore sophisticated BGP attacks: > > https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/ > > you might actually want to consider DNSSEC, implement it properly > and monitor, and the bricking won't happen. Good point! DNSSEC is the only defense against such attacks at this point. Pinning this extension sure seems like a desirable thing in that context! We're not asking for pinning _now_ because as the WG chair says there is no consensus to add pinning _now_. We're only trying to make it *easier* to add it _later_. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] early code points assigned (was Re: early code point assignment for draft-ietf-tls-certificate-compression)
On Thu, May 24, 2018 at 09:30:59AM -0700, Adam Langley wrote: > On Wed, May 23, 2018 at 8:23 PM Peter Gutmann > wrote: > > That's going to cause clashes with implementations that use that value for > > TLS-LTS, it would be better to use a value other than 26 that isn't > already in > > use. > > Obviously I'm not adverse to using the occasional, non-IANA code point. But > they need to be picked randomly and outside the dense, IANA area. > Otherwise, this is certain to happen in short order. Why can't we make it so IANA does early codepoint assignment? Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations
On Mon, Jun 25, 2018 at 09:20:16PM -0700, Joseph Salowey wrote: > 1. Do you support the working group taking on future work on a pinning > mechanism (based on the modifications or another approach)? Yes with a caveat: I don't much care whether pinning work gets done as an individual submission, as a TLS WG work item, or some other WG's work item. > 2. Do you support the reserved bytes in the revision for a future pinning > mechanism? Yes. I prefer just the two bytes we asked for, but I'm also happy with the optional up-to-255-byte hole. I'm not at all interested in more complex holes. > 3. Do you support the proof of denial of existence text in the revision? Yes. > 4. Do you support the new and improved security considerations? Yes. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday
On Wed, Jul 18, 2018 at 01:54:09AM -0700, Eric Rescorla wrote: > On Tue, Jul 17, 2018 at 7:30 PM, Viktor Dukhovni > wrote: > > > > c. Testing is not a good fit at this layer, all that's > >pinned is the ability to deliver the extension, after a > >previous connection delivered DANE TLSA records and a > >non-zero extension support lifetime. There is no TLS-layer > >mechanism for the client to inform servers that don't > >offer the extension that this extension was expected > >while continuing the connection. The closest we get is > >the TLS 1.3 missing_extension(109) alert, which does not > >carry the id of the mission extension, and is a failure > >alert. Out-of-band notification would require HTTP > >support in applications that can't generally be expected > >to include an HTTP implementation. > > > > To the extent to which this is true, it's an argument that one should be > pinning at a different layer. Whichever layer the pinning is to be done at, the thing to pin, and for how long, all need to be transported, and since that thing is in TLS, so should the "for how long". Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday
On Wed, Jul 18, 2018 at 08:41:59AM -0400, Shumon Huque wrote: > At yesterday's WG meeting, Sam Weiler suggested that the pinning > information could be conveyed via the DNS. That way you would not need new > holes/fields in the TLS extension. Paul said it doesn't work. But Willem > Toorop and I discussed it after the meeting, and think that it does. I agree that it _could_ be done with a DNS RR. However, that has two negative effects: 1) it will bloat the extension's payload more than the two bytes we're asking for, 2) it complicates deployment / the operator's life. With a pin TTL in the extension the server operator can change it at any time without further ado -- it's just a config file setting. With a pin TTL in a DNS RR the server operator has to make a zone file update. That could be easy or not -- it varies. > This could also express a generic DANE pinning capability that is not tied > only to a TLS channel. That's more like the other flavors of pinning we've been told have rougher operations characteristics. It's certainly true that we could specify and implement such a thing, and that it would be useful for some applications. However, it wouldn't be as convenient as just the extension pinning in this case. For example, with pinning to the extension + DoE, a server could implement the extension asynchronously from deploying DANE. In fact, it could just be enabled by default, and always send DoE when you don't have DANE deployed. And then the moment you deploy DANE, presto, you're protected. And if you want to turn off pinning? Just edit the server's configuration file -- no need to go update the zone(s). We should always look to make deployment easier, and extension pinning does that more than a DANE pin DNS RR type would. Surely we want our protocols to be deployable. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday
On Thu, Jul 19, 2018 at 12:16:18PM -0400, Viktor Dukhovni wrote: > On Wed, Jul 18, 2018 at 10:23:49PM -0500, Nico Williams wrote: > > > At yesterday's WG meeting, Sam Weiler suggested that the pinning > > > information could be conveyed via the DNS. That way you would not need new > > > holes/fields in the TLS extension. Paul said it doesn't work. But Willem > > > Toorop and I discussed it after the meeting, and think that it does. > > > > I agree that it _could_ be done with a DNS RR. However, that has two > > negative effects: 1) it will bloat the extension's payload more than the > > two bytes we're asking for, 2) it complicates deployment / the > > operator's life. > > In any realistic deployment, the publisher of the TLSA records is > the *same* entity that provisions the certificate chain, anything > else is operationally untenable. To make it short, the problem is that with A RRs the customer has to update TLSA RRs to match the hosting site's, and has to do this on a timely basis. That can certainly be arranged, but I agree that at least initially, and until this is generally automated, that will indeed be a problem. But I'm not too concerned because it is just a matter of automation. My issues with a new DNS RR for specification of pinning remain. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Interim meeting information
Shortening the link works. Basically you can join with the app or web page, using the 9-digit meeting code. You end up having to register. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps
On Mon, Oct 08, 2018 at 05:09:40PM -0700, Christopher Wood wrote: > Notes from the TLS interim meeting held in September are now online > [1]. To recap, the meeting attempted to focus on three primary > questions: > > 1. What is the fundamental security issue? What is the purpose of this > extension? Broad utility vs. narrow utility. As specified the extension is only of use to clients that can mandate it and hard-fail when it is not supported. We are asking for Motherhood and Apple Pie. Who could disagree?! And yet many do. There is a reason for that. >From the concall and off-list exchanges I believe that the disagreement with Motherhood and Apple Pie stems from a belief that we can't get them at an acceptable price. People have been traumatized by the HPKP experience and want nothing like it -- and *this* sure is something I believe we *all* agree on at this time. Therefore I propose that we put the cart before the horse. I propose that we start by showing that the proposed Motherhood and Apple Pie feature is indeed cheap and risk-free, and not HPKP redux. If we can examine that statement, that the proposal is cheap and risk-free, and if we can come to agreement on that, then agreement that we should aim for broad utility will surely follow. Otherwise, and if no one else has an alternative cheap-and-risk-free Motherhood and Apple Pie proposal, then we can safely reject broad utility. HPKP is a *footgun*. Any attempt to add new footguns like HPKP must be rejected. > 2. Under what circumstances should DNS records received in the > extension be cached and reused for future use? The payload contents are DNS responses. They may be cached, or not, as usual. The choice of transport does not affect this. > 3. Is pinning required? If so, what is pinned, and at what layer(s) > should it be implemented? If clients keep no state at all (about the DANE extension) between TLS handshakes, then the extension can be stripped off (or the client redirected to a server that won't provide it). This is the source of the observation about broad vs. narrow utility. Now, we cannot, indeed MUST NOT, pin anything that would make this like HPKP. Otherwise we'd have a footgun for sure! That means: - MUST NOT pin *any facts* about how the server is to be authenticated! Meaning: - MUST NOT pin public key material (private keys get lost, rotated) - MUST NOT pin EE certs (same reason) - MUST NOT pin TLSA RRset RDATAs(same reason) - MUST NOT pin intermediate certs (operator might need to switch CAs) - MUST NOT pin trust anchors(same answer) - MUST NOT pin TLSA RRset existence (zone might stop being signed) - MUST NOT pin whether the server's RRsets are signed (same) - MUST NOT pin any other authentication facts not listed above That's a pretty extreme list of must-not-pin items. ALSO: whatever state is kept -whatever is pinned-, the pin must be trivial for server operators to clear. There is only one thing that's left to could get pinned: whether the server supports the extension, with an expiration time on the pin. We need to demonstrate that pinning server support for the extension does not a footgun make. That's on us. The test for whether we have a footgun is: can the server operator clear the client pins trivially in the event of a screwup? If the server operator can clear the pins trivially, then we have no footgun. Well, we have 1 way to set the pin, and 3 ways to clear it. There must be methods for clearing the pin that are no more difficult to execute than setting the pin. To set the pin: - the client MUST have requested the extension - the server MUST respond with the extension - the server MUST have TLSA RRs and a valid DNSSEC chain - the client MUST have authenticated the server per-DANE using the attached chain - the server MUST have advertised a non-zero pin time To clear the pin: - method #1: Same as setting the pin, server advertises a zero pin time. - method #2: Unpublish TLSA RRs or unsign the zone, therefore the server MUST send an authenticated denial of existence (DoE) back to the client. The client then MUST clear the pin after authenticating the DoE regardless of whether it successfully authenticates the server. (Recall that the fact of a zone's not being signed can itself be proved in DNSSEC, thus, no longer signing the zone leads to authenticated denial of existence.) - method #3: Same as method #2, but the client can independently check DNS if the server somehow does not support the extension. This only works for clients that can reach the DNS, but that would be e.g., most browsers, most of the time. That is, this works for clients for which this extension functions as an optimization. Clie
Re: [TLS] kicking off charter revision discussion
On Wed, Oct 24, 2018 at 08:19:33PM -0400, Sean Turner wrote: > Proposed Charter Text +1, but see comments below. First off, suppose we wanted to write a successor to RFC2712 for TLS 1.3, should we pursue that in the TLS WG, or KITTEN WG? I'm amenable to either, and even both. > [...] > > The second working group goal is to improve protocol extensibility, > usability, and deployability, e.g., GREASE, Delegated Credentials, > Certificate Compression, and Exported Authenticators. These working > group items will include a focus on privacy properties of (D)TLS, with > a particular emphasis on the following: Should the DANE DNSSEC chain extension be on the charter? We do need to finish it. > [...] Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] kicking off charter revision discussion
On Tue, Oct 30, 2018 at 09:53:47PM -0400, Sean Turner wrote: > > On Oct 30, 2018, at 17:41, Nico Williams wrote: > > On Wed, Oct 24, 2018 at 08:19:33PM -0400, Sean Turner wrote: > >> Proposed Charter Text > > > > +1, but see comments below. > > > > First off, suppose we wanted to write a successor to RFC2712 for TLS > > 1.3, should we pursue that in the TLS WG, or KITTEN WG? I'm amenable to > > either, and even both. > > I think both would be bad, but whether it goes in one or the other > would come down to whether there are enough people interested in doing > the work. OK. I suspect we can get it done in KITTEN WG, where we have the Kerberos expertise, as it's really just a use of PSK in TLS, so we'd not need to extend TLS in any way. I think most here would agree. > > Should the DANE DNSSEC chain extension be on the charter? We do need to > > finish it. > > In the current charter, we already have generic text about extensions > and no specific text about the DANE DNSSEC draft though we adopted the > draft and there is a milestone for it. I prefer not to list every > draft we are working on in the charter specifically because then we > have to change the darn charter every time we want to adopt a draft. Just making sure! > We are going to spend a lot of time discussing the DANE DNSSEC draft. > When it gets done and what is in it is certainly up for discussion. Indeed. Thanks, Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
On Mon, Nov 05, 2018 at 07:01:57AM -0600, Benjamin Kaduk wrote: > Once we start talking about pinning of any sort, we move from this > extension just being "transport some DNS records" into conveying some > sort of additional semantics. The I-D lost consensus over one issue. We should resolve that issue. There are some minor other things (like the fact that TLSA RR names include a port number and the TLS server needs to know, or that we shouldn't specify an RR sort order, or that the age of the chain payload needs to be included), but they are minor by comparison. Whether we discuss those first or the main event is not that interesting to me, but if we're going to make progress I think we should have time for the main event. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
We've had a couple of conference calls to discuss the I-D. One call ended up causing the consensus on the I-D to collapse. The second call ended too soon, but it was not unproductive. Indeed, I think at that call and in the subsequent off-list threads we identified the concerns with pinning: - footgun concerns - hostile abuse concerns Now, I believe we have demonstrated that there is no footgun: whenever you can set the pin, you can also clear the pin. At worst one might first upgrade a server to gain support for the extension, set a pin, then downgrade for some reason and thus footgun -- but the fix is to upgrade again, or not set the pin immediately upon upgrade. We also have a mitigation for upgrade-set-pin-downgrade case (exponential scaling of the pin timer with age of the RFC). The second concern is, IMO, a non-concern, but granting for argument's sake that it might be anyways, our answer to it is that sufficiently far into the future the victim's server will support the extension, thus it will be able to clear a hostile pin, therefore the exponential pin timer scaling idea will give servers time to gain support for the extension before anyone could ever make hostile use of the pin. I believe we have put away those two concerns. If we have not, please say so and explain such that we might (or that we might see the errors of our ways). Are there any other reasons not to accept the proposed pinning scheme? If no one can state any such reasons, why shouldn't we just accept the proposal? Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Thanks to Benjamin Kaduk
On Thu, Nov 08, 2018 at 11:49:45AM -0500, Paul Wouters wrote: > I wanted to thank Ben for the outreach he did in the last six months on > the tls dnssec chain extension. It has been a difficult issue and I do > wish the outcome was different. But during this time Ben put a lot of > effort in trying to get the issues clarified and resolved both on the > list of offlist. He repeatedly tried to engage more people of the WG > and he made me feel that my opinions were not ignored. > > I am going to think a bit more on how we as IETF could have done better > in this case, but I did want to share with the group that I think Ben > made a real difference in trying to get this document out. > > Thanks Ben! I'd like to second this. I'd also like to state a mea culpa. I did not understand the extent to which this controversy would become a DoS on the WG. Perhaps it would have been better to not get involved and then later publish a better version of the extension. I can't be sure, but certainly avoiding that large exchange of email would have been better. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ETSI releases standards for enterprise security and data centre management
On Sat, Dec 01, 2018 at 07:59:45AM -0800, Tony Arcieri wrote:
> This does not seem to address a problem which was brought up when the
> similar draft-green-tls-static-dh-in-tls13-00 was discussed, namely any
> system in possession of one of the non-ephemeral-ECDHE private keys,
> ostensibly for the purposes of passive traffic decryption, can arbitrarily
> resume decrypted sessions and therefore impersonate any observed clients.
>
> I'm not a fan of systems like this, but I believe for security reasons they
> should be designed in such a way that only the confidentiality of traffic
> is impacted, and a "visibility" system isn't able to leverage the decrypted
> traffic to resume decrypted sessions and thereby impersonate clients.
Any key escrow system will have this property. Given the session keys
(or a way to recover them) you can resume decrypted sessions.
If I had to I would build a corporate TLS 1.3 session key escrow system
as follows:
- use a keyed PRF/PRNG to generate the ephemeral DH keys, with two
inputs, a secret key shared with the escrow third party, and a number
generated randomly:
edh_key = DH_key_gen(seed = PRF+(escrowed_key, r = getrandom()));
- log to the escrow third party {connection ID, random} for each
connection (the connection ID can be a handshake transcript hash).
(it's even safe to log the random number r in the clear, as it alone
is insufficient for recovering session keys)
This would preserve all the properties of TLS 1.3 and would work for any
other version of TLS with EDH too, and also for any other protocols that
use ephemeral key agreement (SSHv2, IKE, ...).
It's more work to integrate this than to use RSA key transport with
escrowed RSA key orchestration, but it's one-time work (do it for about
six or so open source implementations and you've got 90+% coverage).
I'm sure upstreams would accept this sort of contribution as it is
better for everyone outside corporate environments if we can just stop
the pressure to go back to RSA key transport. It's also better for
corporate environments, as insiders are the largest threat there, so
forward security is still a plus even in corporate environments.
Nico
--
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ETSI releases standards for enterprise security and data centre management
On Tue, Dec 04, 2018 at 04:34:08PM +0100, Jonathan Hoyland wrote: > Is it necessarily true that any key escrow system must allow resumptions? > > Just to play devil's advocate, consider defining a new cipher suite that > appended a MAC to each message before applying one of the other cipher > suites. > If the MAC is keyed with a key not derived from the master secret, but from > some other value shared between the client and server, but not the > middlebox, then the middlebox would be able to read all* the traffic, but > would not be able to successfully resume the session. This MAC key would also have to be involved in the session resumption PSK, but yes. You don't even need this extra MAC past the handshake, you just need an extra key not known to the escrow agent for use in the session resumption PSK. (The extra MAC on every record would impose too much overhead.) > *The middlebox would not be able to verify the tag, so technically it can't > check /everything/, but it would be able to read the data on the channel > without being able to modify it. Oh sure, if you're willing to do such violence to TLS, then yes, it can be done. However, a constraint here is that an escrow design can't really require client-side modifications without the IETF approving of it and the client implementations accepting the change. The most obvious escrow design requiring no changes to the clients is to use a static eDH key on the server-side. The next most obvious such design is to have the server talk to the escrow agent. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ETSI releases standards for enterprise security and data centre management
On Tue, Dec 04, 2018 at 05:39:30PM +0100, Jonathan Hoyland wrote: > Isn't there a lower bar at the IETF for defining new cipher suites, as long > as you're not seeking a "recommended" setting? Yes, but then you have to get interoperability using them, which means patching clients and servers. You can't 100% escrow this way. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
On Wed, Dec 05, 2018 at 06:59:07PM +, Stephen Farrell wrote: > My main concern is that a server playing a > draft-green-like game could just choose DH > values more cleverly and avoid detection. We can forbid static server DH keys, and should attempt to preclude them by encouraging clients to do _some_ work to detect them. We can preclude Dual_EC style escrow systems by not providing a way to publish enough material on the wire for an eavesdropper with access to the Dual_EC secrets to recover the keys. Dual_EC style escrow systems are not protocol-neutral. We can forbid extension/ciphersuite registration for key escrow schemes. We'd have to direct experts designated for Expert Review to look for the possibility that an extension or ciphersuite could be used for in-band key escrow. But we can't preclude protocol-neutral (out-of-band) key escrow schemes. These are not detectable (implementation fingerprinting can always be defeated). > E.g. if the DH values are derived via some > function so that public shares never recur, > or only rarely. (And while such derived DH > values would in a sense represent the server > borking its own crypto, that's basically what > draft-green suggested anyway, so one might > expect a DH borking adversary in such cases > to not care so much about the client's > security.) Such a scheme requires some sort of counter to appear on the wire, similar to Dual_EC. With no nonces, this can't be done. But with small enough counters it will be difficult to preclude their appearance (or the appearance of a truncated counter, which would require some brute force on the part of the escrow agents, again like Dual_EC) as there will always be freedom to express some small number of arbitrary bits in-band. > I guess that testing would also be an issue > so it'd be great if someone was to try do > that to check if this might break things. > (Which'd be useful in any case if it found > some servers accidentally re-using.) > > Other than that, some more minor comments: > > It'd be good to describe in detail a way in > which one might efficiently retain the client > state required, e.g. via a bloom filter maybe? > (Assuming an occasional false positive isn't > too alarming;-) OK, but clients would have to share...: > It might also be good to outline how a survey > or CT-like mechanism (say logging some value > as a witness for the DH public) could be used > to detect this kind of badness even if common > TLS clients didn't deploy. Providing a way for clients to report what they see would have serious privacy concerns that, IMO, outweigh the static server DH key concerns. And none of this would help detect/preclude out-of-band escrow systems. Client-side detection of static/reused server DH keys will simply push server operators who must escrow to use undetectable out-of-band escrow, thus wasting all work on client-side detection. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ETSI releases standards for enterprise security and data centre management
On Fri, Dec 07, 2018 at 12:04:02AM +, Andrei Popov wrote: > > I don't think the TLS WG or IETF can win this skirmish. > > That's what I'm thinking as well, although I agree with the goals of > draft-dkg-tls-reject-static-dh-01. Yes. What we can, and IMO should do, is say that if you must do key escrow or session recording, to it out-of-band. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
On Fri, Dec 07, 2018 at 03:37:25AM +0300, Daniel Kahn Gillmor wrote:
> On Wed 2018-12-05 18:59:07 +, Stephen Farrell wrote:
> > it's feasible and not easily defeated.
>
> TLS endpoints can share their data (key material, cleartext, etc) with
> whoever they choose -- that's just how the universe is implemented.
> They can even do it out of band, on a channel that the peer has no
> knowledge of.
>
> The question for TLS implementers is what to do about risks or leakage
> that they *can* become aware of.
Sure.
> > It'd be good to describe in detail a way in which one might
> > efficiently retain the client state required, e.g. via a bloom filter
> > maybe? (Assuming an occasional false positive isn't too alarming;-)
>
> Yes, that would be great. the way i was going to write it that guidance
> was pretty dumb (i was thinking of just a hashtable combined with a
> fixed-size ring buffer to be constant-space and roughly constant-time,
> and hadn't even considered bloom filters), so i welcome suggested text.
False negatives are OK here. False positives... depends on whether the
application / library can reconnect and retry. (I doubt we'd add a TLS
extension by which the client can ask to retry with a fresher server eDH
key...)
When false positives are not OK a Bloom filter check prior to doing a
slower check that has no false positives is a good optimization. But
let's assume the client can reconnect and retry, no? If not then just
write all the eDH keys seen to a circular log and on Bloom filter
positive just do a linear search on the log.
Another possibility is to not fail on false positive but to mark a
server as "needs watching like a hawk" and use a more appropriate data
structure (w/o false positives) to watch it for a while. When you catch
a server cheating with that data structure, then fail hard.
> Given that the size of the set of elements to include is effectively
> infinite, standard Bloom filters seem likely to be trouble (way too fast
> to converge onto false-positives).
>
> Perhaps "stable bloom filters" would represent a better tradeoff:
>
> http://webdocs.cs.ualberta.ca/~drafiei/papers/DupDet06Sigmod.pdf
Nifty.
Another option is Scalable Bloom Filters. Basically, when a filter gets
full-ish, you close it to additions and add a new filter, thenceforth
checking all the closed filters and the one open filter. Delete filters
older than some number of days, and you limit storage use.
Looks like both Scalable and Stable BFs would fit the bill in terms of
limiting storage use and false positive rate.
> But hm, even a 0.1% false positive rate sounds pretty alarming too. 1
> in a thousand connections failing? yikes! I think we'd want to err on
> the false-negative side for this particular use case.
Depends on whether the client can retry, or whether you can do something
other than fail (see above).
> > It might also be good to outline how a survey or CT-like mechanism
> > (say logging some value as a witness for the DH public) could be used
> > to detect this kind of badness even if common TLS clients didn't
> > deploy.
>
> oof, CT itself is *really* heavyweight, and given our overall failure to
> get any sort of monitoring that would detect abuse by the CT logs
> themselves working (gossip hasn't had the necessary traction), i'm not
> sure i have the stamina to go down that route for ephemeral DH values.
+1
> > Section 4 could probably do with some text about how not to do this,
> > e.g. keeping a list of {servername,[DH values]} would be bad if a
> > client's disk were compromised.
>
> right, this would align with the bloom filter (or whatever)
> implementation guidance you mention above. I've been thinking about
> this, and i'm not sure that we even need servername as part of the key.
> is there any reason that a client should ephemeral DH reuse *across*
> hosts? If anything, ephemeral DH reuse across hosts *proves* that a DH
> secret has been shared (wittingly or unwittingly), which is one of the
> things we're trying to avoid, right? Simpler implementations are
> probably better, and it's certainly easier to not deal with the
> servername.
You're right, the server name isn't needed. In principle eDH keys
should be large enough and all randomly generated. The chances of reuse
anywhere, ever, should be very small.
This would help detect RNGs with shared seeds. Remember the bad RNG in
OpenSSL in Debian, about a decade ago? Yeah, let's not have that happen
again.
Nico
--
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
On Fri, Dec 07, 2018 at 06:31:21AM +, Peter Gutmann wrote: > Aren't you going to get into an adversarial machine learning problem where > your recogniser has to be smarter than the other side's DH-reuse code? In > other words if the server just reuses the same DHE public value again and > again you can detect it, but if they generate slightly different values from a > fixed seed or start point you're not going to be able to detect it unless you > know what they're doing. If it's different then that's costing the server the resources to generate it, which is precisely what its operator didn't want when they enabled eDH key reuse. Indeed, the client cannot detect the use of a fixed seed and counter shared with an escrow agent. > Not to mention a NOBUS DHE public value if they really want to be crafty. In > other words if someone wants to middlebox TLS, they're going to do it no > matter how much people may dislike it. No argument there. There's nothing wrong with server-side key escrow if that's what the server operator wants. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
On Fri, Dec 07, 2018 at 07:14:17AM +, Peter Gutmann wrote: > It depends on what those resources are, at one end you've got proper DHE with > a full modexp required, at the other end if you can fake it with something as > lightweight as a mod-add or similar it's essentially free while defeating DHE- > reuse detection. Fair. > I appreciate that people feel strongly about this, and I support the idea of > non-ephemeral DHE detection in principal [0] (along with many, many other > measures to strengthen TLS), but this draft reads a lot like the IETF blowing > raspberries at ETSI. That's my take as well. However, the possibility of detecting stuck RNGs like the Debian OpenSSL debacle of ten years ago is interesting. Still, it's more complexity for clients. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Further TLS 1.3 deployment updates
On Wed, Dec 12, 2018 at 04:21:43PM -0600, David Benjamin wrote: > We have one more update for you all on TLS 1.3 deployment issues. Over the > course of deploying TLS 1.3 to Google servers, we found that JDK 11 > unfortunately implemented TLS 1.3 incorrectly. On resumption, it fails to > send the SNI extension. This means that the first connection from a JDK 11 > client will work, but subsequent ones fail. > https://bugs.openjdk.java.net/browse/JDK-8211806 I'm told that OpenSSL accidentally takes the SNI from the initial connection on resumption if there's no SNI in the resumption. This seems like a very good workaround for the buggy JDK 11 TLS 1.3 client, as it has no fingerprinting nor downgrade considerations. If the server rejects resumption I guess the client would still fail, but this is much better than failing at 100% of all resumptions and better than adding fingerprinting and downgrades. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Further TLS 1.3 deployment updates
On Fri, Dec 14, 2018 at 10:11:38PM +0100, Martin Rex wrote:
> Nico Williams wrote:
> > On Wed, Dec 12, 2018 at 04:21:43PM -0600, David Benjamin wrote:
> >> We have one more update for you all on TLS 1.3 deployment issues. Over the
> >> course of deploying TLS 1.3 to Google servers, we found that JDK 11
> >> unfortunately implemented TLS 1.3 incorrectly. On resumption, it fails to
> >> send the SNI extension. This means that the first connection from a JDK 11
> >> client will work, but subsequent ones fail.
> >> https://bugs.openjdk.java.net/browse/JDK-8211806
> >
> > I'm told that OpenSSL accidentally takes the SNI from the initial
> > connection on resumption if there's no SNI in the resumption. This
> > seems like a very good workaround for the buggy JDK 11 TLS 1.3 client,
> > as it has no fingerprinting nor downgrade considerations.
>
> Just that this workaround is a no-go for any layered approach
> to SNI, where server-side processing of SNI is outside of the TLS stack.
I mean, that's already a problem for TLS 1.{0,1,2}, so I don't believe
that getting the SNI from the resumption ticket would be a problem on
this account.
Nico
--
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] Alternative ESNI?
OpenSSL extracts and uses SNI from session resumption tickets.
This gave Viktor Dukhovni and Matt Caswell an idea that I'll relay here
on their behalf.
Also, while we're at it, I'd like to note that SNI is not the only thing
requiring privacy protection from the client. There's also the PSK
identity payload for non-resumption PSKs... Not as important as SNI,
perhaps, nonetheless I think we should maximize privacy, else we'll be
engaging in repeated encrypted-{fill-in-the-blank} exercises.
Our proposal makes DNS optional (for co-tenancy fronting discovery) and
DNSSEC not necessary.
The basic idea is to use a HelloRetryRequest to make a handshake traffic
secret available to the client for it to use in its subsequent hanshake
messages. This form is susceptible to an SNI disclosure active attack
-- same as the current ESNI proposal w/o DNSSEC. This variant adds one
round-trip to full handshakes.
We can then optionally piggy-back the server's Certificate and
CertificateVerify along with the HelloRetryRequest (provided the
client's initial key_share is acceptable to the server), and now we have
authenticated the server under its fronted name, which means there is no
active attack on the ESNI. This still only adds just the one round-trip
to full handshakes. And look ma', now w/ no DNSSEC requirement to avoid
active attacks.
And if the client already knows about the co-tenancy of the fronting
and desired servers, then no DNS lookups are needed to discover it.
E.g., dissidents might learn this by word of mouth.
The second variant can, sadly, add an extra round-trip when the server
finds the client's initial key_share unacceptable.
As to resumption, the real SNI should be the one from the original full
handshake, and the SNI in the resumption should be the fronting
service's name. Resumption retains the same latency as in RFC 8446.
Below are the flows for the three cases, all of these being full
handshakes. Naturally, these should be read after first reading figure
2 from RFC 8446.
ClientHello
+ key_share >
HelloRetryRequest
< + key_share
ClientHello
{EncryptedExtensions}
+ key_share >
{EncryptedExtensions}
{CertificateRequest*}
{Certificate}
{CertificateVerify}
{Finished}
< [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} >
[Application Data] <--->[Application Data]
Figure 1: Alternative ESNI w/o active protection
ClientHello
+ key_share >
ServerHello
+ key_share
{EncryptedExtensions*}
{Certificate}
{CertificateVerify}
< {HelloRetryRequest}
ClientHello
+ key_share
{EncryptedExtensions} >
{EncryptedExtensions}
{CertificateRequest*}
{Certificate}
{CertificateVerify}
{Finished}
< [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} >
[Application Data] <--->[Application Data]
Figure 2: Alternative ESNI w/ active protection
ClientHello
+ key_share >
HelloRetryRequest
< + key_share
ClientHello
+ key_share >
ServerHello
+ key_share
{EncryptedExtensions*}
{Certificate}
{CertificateVerify}
< {HelloRetryRequest}
ClientHello
+ key_share
{EncryptedExtensions} >
{EncryptedExtensions}
Re: [TLS] Alternative ESNI?
On Fri, Dec 14, 2018 at 08:01:35PM -0800, Eric Rescorla wrote:
> On Fri, Dec 14, 2018 at 6:54 PM Nico Williams wrote:
> > OpenSSL extracts and uses SNI from session resumption tickets.
> > This gave Viktor Dukhovni and Matt Caswell an idea that I'll relay here
> > on their behalf.
> >
> > Also, while we're at it, I'd like to note that SNI is not the only thing
> > requiring privacy protection from the client. There's also the PSK
> > identity payload for non-resumption PSKs... Not as important as SNI,
> > perhaps, nonetheless I think we should maximize privacy, else we'll be
> > engaging in repeated encrypted-{fill-in-the-blank} exercises.
> >
> > Our proposal makes DNS optional (for co-tenancy fronting discovery) and
> > DNSSEC not necessary.
> >
> > The basic idea is to use a HelloRetryRequest to make a handshake traffic
> > secret available to the client for it to use in its subsequent hanshake
> > messages. This form is susceptible to an SNI disclosure active attack
> > -- same as the current ESNI proposal w/o DNSSEC. This variant adds one
> > round-trip to full handshakes.
> >
>
> We looked at this class of design during the initial work on TLS 1.3
> because (a) it has trivial active attacks, as you note and (b) we
> don't want people to have to accept an extra round trip in order to
> get ESNI, because that's a major disincentive to doing it.
One of the two has no active attack, and the extra round trip is already
possible due to the existing HelloRetryRequest flow. The variant that
is resistant to active attack has a worst case additional round-trip,
but again, only on initial handshake.
BTW, the flows I presented have no multi-CDN keyshare private key
distribution issues because there are no keyshares to publish in the
DNS.
> WRT to the active attack point, DNSSEC isn't necessary with the
> current ESNI design. What's necessary is that the client be able to
> get the ESNIKeys record (and the A/ records) securely wrt to the
> attacker trying to get the SNI. However, in a large number of cases
> (e.g., an attacker on your local network, there are non-DNSSEC ways of
> obtaining this property, such as using DoH. In addition, if the
DoH?
> attacker controls DNS (or generally can observe DNS traffic) then
> getting the SNI encryption key securely isn't sufficient because the
> attacker can just learn the domain name from the DNS lookup (or return
> a unique IP for each query and then use that to look up the SNI from
> the IP).
Sure. DPRIV is still needed, no doubt.
> > We can then optionally piggy-back the server's Certificate and
> > CertificateVerify along with the HelloRetryRequest (provided the
> > client's initial key_share is acceptable to the server), and now we have
> > authenticated the server under its fronted name, which means there is no
> > active attack on the ESNI. This still only adds just the one round-trip
> > to full handshakes. And look ma', now w/ no DNSSEC requirement to avoid
> > active attacks.
> >
>
> This seems like a more invasive version of what David Benjamin et al.
> proposed the other day, just without the ESNI key at all. I don't
> think this is an acceptable general solution for latency reasons (as
> opposed to fallback), and of course you still need some way to
Again, it's comparable to the existing HelloRequestRetry flow case.
> securely obtain the domain name you put in the SNI, and if this isn't
> done with DNS, then you end up with a situation where very few people
> use ESNI and so you stick out.
Granted. But not having to coordinate privte keys for the keyshares to
be published in the DNS seems like a very big win.
Nico
--
Nico
--
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Alternative ESNI?
On Sat, Dec 15, 2018 at 01:08:50PM +, Stephen Farrell wrote:
> On 15/12/2018 02:53, Nico Williams wrote:
> > OpenSSL extracts and uses SNI from session resumption tickets.
> >
> > This gave Viktor Dukhovni and Matt Caswell an idea that I'll relay here
> > on their behalf.
>
> I agree this is worth exploring, though am not sure if it'd be
> better in the end. (I chatted with Viktor about this and said
> I'd try see if I could make it work once I've gotten further
> along coding up the current draft.)
Perhaps this alternative ESNI protocol can complement the current ESNI
proposal.
The idea would be to allow sites that cannot orchestrate ESNI keyshares
across multiple CDNs to opt for this alternative by publishing in DNS
only the fronting domainname(s). Only then would one pay the extra
round trip price to get ESNI, and only if the client wants it (but the
client should want it).
A client that finds a domain's fronting domain but not ESNI keys would
engage in the active attack resistant variant I posted with the fronting
domainname as the public SNI, and the server would know to respond with
the HRR.
The key is that we need to be able to deploy an ESNI protocol widely and
easily, but if ESNI keyshare orchestration is a big brake on deployment,
then it might take a long time to get traction.
(Note that I never said that DoH/DPRIV would not be needed. The
alternative would allow simple manual, local configuration, whereas
publishing ESNI keyshares does not.)
> I don't see any point in considering the variant with the easy
> active attack though; as ekr said, I think that was considered
Agreed. I included it mostly to show how we got to the one that is
resistant to active attacks. I thought it'd be useful to do that, but
instead it seems to have given everyone something bad to latch onto :(
> before and I'd say that'll just confuse matters and is better
> omitted, so I'm only really considering your figure 2 below.
I agree.
> > ClientHello
> > + key_share >
> > ServerHello
> > + key_share
> > {EncryptedExtensions*}
> > {Certificate}
> > {CertificateVerify}
> > < {HelloRetryRequest}
> > ClientHello
> > + key_share
> > {EncryptedExtensions} >
> > {EncryptedExtensions}
> > {CertificateRequest*}
> > {Certificate}
> > {CertificateVerify}
> > {Finished}
> > < [Application Data*]
> > {Certificate*}
> > {CertificateVerify*}
> > {Finished} >
> > [Application Data] <--->[Application Data]
> >
> > Figure 2: Alternative ESNI w/ active protection
> >
>
> Some questions:
>
> - How are you proposing the client knows of the existence of the
> hidden service? (Aside from local configuration, which is always
> possible.)
DNS (DPRIV, DoH).
Local config isn't really possible if it means the user has to type in
keyshares.
> - How does the server know to include the HRR in it's answers? (IOW,
> what ESNI signal is present in the client's 1st flight?
The client uses the fronting domainname as the public SNI payload. The
server, knowing via local configuration that it has no ESNI keyshares in
DNS, responds with the HRR as above.
> - Ought that be some more general signal? e,g. "client wants to send
> some EncryptedExtensions, let's do an extra RTT." (I'd like that
> I think, but the counter argument might be that that's overreach
> and we'd be better to just stick with an ESNI model that we're
> confident can get some deployment.)
Yes and no. In order to get ESNI widely adopted it will probably help
to have a way to trigger this denies the censors an unambiguous "pst,
hey, let's do this thing so the censors don't know your name" signal.
But for that I would think that yes, we'd want a general signal about
this.
> - Given HRR was a kludge for backwards compatibility could changing
> where that occurs in the protocol trigger more middlebox messes?
Dunno.
> -
Re: [TLS] Alternative ESNI?
On Tue, Dec 18, 2018 at 01:58:53AM +, Stephen Farrell wrote: > On 17/12/2018 23:33, Nico Williams wrote: > > Maybe we do both, the current ESNI proposal and this as an alternative > > for when ESNI keyshare orchestration is difficult, and in that case you > > don't get to do split mode. > > Interesting that the above overlaps a bit with the PR davidben > just posted. That seems promising. > > That said, I'd bet we're all generally unkeen on "do both" but > maybe the above-mentioned PR avoids that by casting the HRR-mode > as way to better handle a likely operational failure mode. I have no dog in this hunt, but ISTM that anything we can do to simplify deployment will help a great deal. The ESNI keyshare orchestration strikes me as a big impediment to deployment, but I understand too that adding a round trip to every initial handshake is a bit much. A combination of options, or some new thing -- it's all the same to me, as long as it gets us ESNI. Oh, and not just ESNI. I also want the PSK identity payloads for non-resumption handshakes encrypted. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Alternative ESNI?
On Fri, Dec 14, 2018 at 08:53:47PM -0600, Nico Williams wrote:
> Figure 1: Alternative ESNI w/o active protection
Figure 1 was expositional. Please forget it.
> Figure 2: Alternative ESNI w/ active protection
> Figure 3: Alternative ESNI w/ active protection,
> with worst-case latency
There's a different way to do the third case _without_ an extra round
trip in the worst case. Now there are no cases with worse latency than
the worst latency in RFC 8446.
This is the case where the client's initial key_share is not acceptable
to the server.
The key observation is that we can send the server's Certificate and
CertificateVerify in the clear when they are for the fronting name,
which means we can authenticate the server in the first flight, which
means that we can have handshake traffic keys in the second flight:
ClientHello
+ key_share >
ServerHello
+ key_share
Certificate
CertificateVerify
< HelloRetryRequest
ClientHello
+ key_share
{EncryptedExtensions} >
{EncryptedExtensions}
{CertificateRequest*}
{Certificate}
{CertificateVerify}
{Finished}
< [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} >
[Application Data] <--->[Application Data]
Figure 4: Like figure #2 but with initial client
key_share that is unacceptable to the server
Note that the server's Certificate and CertificateVerify goes
unencrypted. Why? Well, it is the Certificate for the *fronting*
name, the one that went unencrypted in the ClientHello, so it doesn't
really need protection.
As Stephen Farrell points out, we get to have *two* server key_shares,
one from the SH and one from the HRR, which gives us the opportunity to
have one of them be something of a static key share shared with a
traffic director. So we get to have *two* sets of handshake traffic
keys, one that gives a traffic director visibility, and one that does
not.
Do we ever need confidentiality protection relative to the traffic
director? If so we'll need notation for indicating which handshake
traffic key set to use for what encrypted extensions.
Nico
--
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Distinguishing between external/resumption PSKs
On Thu, Sep 19, 2019 at 08:06:26AM -1000, Christian Huitema wrote: > There is also a privacy angle. From a privacy point of view, it is > very nice that PSK cannot be distinguished from session resumption. This. PSK is the right way to, for example, integrate Kerberos into TLS 1.3 now. But it's no eavesdropper's business whether a session used Kerberos for setup or resumption tickets. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Distinguishing between external/resumption PSKs
On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote: > I don't think anyone's asking for these cases to be differentiable on the > wire. The question is whether the *server* can differentiate, in > particular, the application running on the server. And the answer to that one is "yes", because the server has control over the PSK IDs. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Distinguishing between external/resumption PSKs
On Thu, Sep 19, 2019 at 06:03:44PM -0400, Richard Barnes wrote: > On Thu, Sep 19, 2019 at 5:49 PM Nico Williams wrote: > > On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote: > > > I don't think anyone's asking for these cases to be differentiable on the > > > wire. The question is whether the *server* can differentiate, in > > > particular, the application running on the server. > > > > And the answer to that one is "yes", because the server has control over > > the PSK IDs. > > That glosses over an important distinction made up-thread: When we say "the > server", there is typically a distinction between the TLS stack and the > server application logic. Resumption PSKs are typically controlled by the > TLS stack, while external PSKs are provided by the application logic. The > question is how the application logic, when presented with a session > authenticated under a given PSK ID, can distinguish whether the PSK used > was one provided by the TLS stack for resumption, or provided by the > application logic. Depends on which gets a first crack at it. You could have a plugin system as well where the plugins are invoked by the TLS stack. And again, order may matter if there's no reliable way to "taste" the PSK IDs. So the answer is that order of evaluation matters, and that's OK. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
