Re: [TLS] Should we require implementations to send alerts?
On 09/16/2015 09:53 PM, Brian Smith wrote: > Assume the client and the server implement the mandatory-to-implement > parameters and that both the client and the server are otherwise > conformant. In this scenerio, when would an alert other than the non-fatal > close_notify be sent? I have been told that mandatory-to-implement does not mean mandatory-to-enable, and that it is possible to run a nominally RFC-conforming client or server in a mode which is not interoperable with anything else. Under such a scenario, fatal alerts happen without an attack. Most fatal alerts in the wild appear to be harmless in the sense that they are not due to attacks, but due to interoperability failures (due to not enabling mandatory-to-implement cipher suites, self-signed certificates, incomplete certificate chains, or just bugs). -- Florian Weimer / Red Hat Product Security ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Wednesday 16 September 2015 12:53:53 Brian Smith wrote: > Thus, the empirical evidence from Mozilla's > widely-deployed implementation shows that (a) the requirement to send > alerts is difficult to conform to, and (b) it is unimportant in > practice to send alerts. and yet Firefox depends on them to report human-readable errors to users when it can't connect to a server... Making the alerts more predictable and with more pinned down meanings will only _help_ the opportunistic HTTPS and HTTPS-by-default campaigns. yes, we need to be careful about alerts that provide information about secret data, but there's very little of such data during handshaking, where the vast majority of alerts apply and where they are most useful -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ 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 Thursday 17 September 2015 03:27:22 Peter Gutmann wrote: > Viktor Dukhovni writes: > >Explicit profiles make some sense. They need not be defined by the > >TLS WG per-se, it might be enough for the TLS specification to > >reference an IANA profile registry, with the TLS-WG defining a > >"base" profile. Then other WGs (including the[ TLS WG) can define > >additional profiles. > That would be good, so the base spec could contain text like "This > document describes every possible option that the protocol can > support. It is not expected that TLS applications implement every > one of these options, since many will be inappropriate or unnecessary > in many situations. Profiles for specific situations like web > browsing, secure tunnels, IoT, embedded devices, and SCADA use can be > found at ...". You can count on one hand the Mandatory-to-Implement ciphersuites. It's quite obvious that if you don't support anything but non-export RSA key exchange, you don't need to be able to parse Server Key Exchange messages... -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ 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 9/16/15, 4:19 , "TLS on behalf of Peter Gutmann" wrote: >Jeffrey Walton writes: >>Somewhat off-topic, why does TLS not produce a few profiles. One can be >>"Opportunistic TLS Profile" with a compatible security posture and >>include >>ADH. Another can be a "Standard TLS Profile" and include things like >>export >>grade crypto, weak and wounder ciphers SSLv3, etc. Finally, there can be >>a >>"TLS Defensive profile" where you get mostly the strong the protocols and >>ciphers, HTTPS Pinning Overrides are not allowed so the adversary cannot >>break the secure channel by tricking a user, etc. > >+1. At the moment you're stuck with everything-all-the-time (or >alternatively >one-size-misfits-all) where you have to support every single mechanism and >quirk and add-on, when all you want most of the time is to set up a basic >secure tunnel from A to B. Having profiles would be a great help, so all >the >other standards groups that build on TLS can refer to, say, the emebedded- >device profile or the PFS-with-PSK profile rather than having to hack >around >the standard themselves. +2. I think this is necessary, *and* falls (or should fall) under the TLS WG prerogative. smime.p7s Description: S/MIME cryptographic signature ___ 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?
Hubert Kario wrote: > On Wednesday 16 September 2015 12:53:53 Brian Smith wrote: > > Thus, the empirical evidence from Mozilla's > > widely-deployed implementation shows that (a) the requirement to send > > alerts is difficult to conform to, and (b) it is unimportant in > > practice to send alerts. > > and yet Firefox depends on them to report human-readable errors to users > when it can't connect to a server... > In what situation will a conformant implementation send Firefox an alert? Firefox is conformant (AFAICT) and in particular Firefox implements the mandatory-to-implement cipher suite. Therefore no conformant implementation should be sending Firefox an alert other than close_notify. (We should focus on conformant implementations because non-conformant implementations can do whatever they want, by definition). > Making the alerts more predictable and with more pinned down meanings > will only _help_ the opportunistic HTTPS and HTTPS-by-default campaigns. > I've not seen any evidence that that is true. I have seen evidence in Firefox and other implementations that detailed alert information was harmful for security, and I shared a summary of that evidence in my early message. Also, instances of such harm are documented within the TLS RFCs themselves. > yes, we need to be careful about alerts that provide information about > secret data, but there's very little of such data during handshaking, > where the vast majority of alerts apply and where they are most useful > It's not clear that there is "little of such data" especially when you consider that more of the handshake is encrypted in TLS 1.3 and when you consider that an application may not process unencrypted data as soon as it has been received. Cheers, Brian -- https://briansmith.org/ ___ 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 1:50 PM, Nico Williams wrote: > 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 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? Fatal alerts are quite handy for diagnostics on the client side, really. > I agree that they are often marginally useful. However, the risks associated with the alert mechanism outweigh those benefits. > 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 suggest that, at most, implementations SHOULD NOT send them. IMO it would be better to remove the alert mechanism altogether in TLS 1.3. Most people that are arguing for retaining the alert requirements seem to be concerned about alerts sent from the server to the client. Does anybody think it is important to require clients to ever send alerts other than close_notify? Cheers, Brian -- https://briansmith.org/ ___ 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 Thursday, September 17, 2015 05:46:39 pm Brian Smith wrote: > 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? Well, what else would clients do instead? The answer is an unambiguous yes. There's no way to tell a microwave oven killing the WiFi and a legitimate handshake failure apart if no information is sent back. Implementors will always assume it's possible to retry, and we know from history that this will involve an unsafe fallback dance. > > 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 suggest that, at most, implementations SHOULD NOT send them. IMO it would > be better to remove the alert mechanism altogether in TLS 1.3. > > Most people that are arguing for retaining the alert requirements seem to > be concerned about alerts sent from the server to the client. Does anybody > think it is important to require clients to ever send alerts other than > close_notify? There's also user_canceled and cert errors when doing client authentication. The idea of restricting what alerts clients, specifically, should send is not necessarily something I'd object to, though I don't think it's useful. Dave ___ 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 2:55 PM, Nico Williams wrote: > 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. > 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. > > 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. > First, this is due to flaws in the design of applications and TLS in how client certificates are handled. Secondly, if a server doesn't deal with client certificates, why should it be forced to send alerts? > > 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. Cheers, Brian -- https://briansmith.org/ ___ 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 3:00 PM, Nico Williams wrote: > 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: > It is amusing when people pull this trick, but it gets old. There are more than two lines of argument against sending alerts, and your paragraphing mischaracterizes them. Cheers, Brian ___ 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] Should we require implementations to send alerts?
On Thursday, September 17, 2015 06:00:05 pm Brian Smith wrote: > 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. The whole handshake is retroactively authenticated upon completion. Just because an attacker can muck up the attempt to connect, doesn't mean all hope is lost. The primary benefit with the version alert, specifically, is that it allows a client to at least have a clue as to what to attempt. Without alert: client tries server stares blankly into the void and/or drops abruptly now, what does the client do? try again as-is, or try again with old stuff? With alert: client tries if server responds with an alert, react to it if not, try again until there's a response; give up eventually Sure, a MitM could try to downgrade by injecting an unauthenticated alert into the mix, but the handshake will fail once that is authenticated at the end. Just as the obvious footnote: it's impossible to make any of this resistant to an attacker killing the connection. Just assume that's always possible, at minimum with wirecutters. The goal is security or bust. Alerts give clients the confidence to actually bust when they have to. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
(Resending from the right address, again. Possibly I should have subscribed with the other one...) On Thu, Sep 17, 2015 at 6:23 PM David Benjamin wrote: > On Thu, Sep 17, 2015 at 5:46 PM Brian Smith wrote: > >> On Thu, Sep 17, 2015 at 1:50 PM, Nico Williams >> wrote: >> >>> 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 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? >> > > Connection close is already a fallback trigger. > > >> Fatal alerts are quite handy for diagnostics on the client side, really. >>> >> >> I agree that they are often marginally useful. However, the risks >> associated with the alert mechanism outweigh those benefits. >> > > I don't think the existence of alerts at all increases the "risk" that > people will do fallbacks. I think you've got causality flipped. It wasn't > "we get alerts, ergo we can get away with a fallback" but "Servers are > dumb, we want to fallback. If there's something easy we can do to constrain > when fallbacks happen, we should. Being more lenient means even more > unexpected dependencies on the fallback may crop up. (Not that this hasn't > happened anyway.)". > > Besides, fallback conditions tend to be extremely liberal in my > experience. Which makes sense since it's used against buggy servers. If a > buggy server blew up because it's version-intolerant, it's not likely to be > kind enough to tell you that. > > While I don't see much use in "your records don't authenticate" and > "that's not even a syntactically valid ServerKeyExchange!", not all > failures are protocol failures. There's also negotiation failures when > parameters aren't okay. When removing cipher suites or bumping minimum > versions, it's nice to show a dedicated error message when it goes wrong. > > And client certs break (even more) if you can't distinguish network errors > from the peer complaining at you. I wish they would go away, but I'm stuck > with supporting it right now and I doubt the world will rally behind > "client certs on the web are deprecated; you do not get TLS 1.3 if you use > client certs". > > David > > >> >> > 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 suggest that, at most, implementations SHOULD NOT send them. IMO it >> would be better to remove the alert mechanism altogether in TLS 1.3. >> >> Most people that are arguing for retaining the alert requirements seem to >> be concerned about alerts sent from the server to the client. Does anybody >> think it is important to require clients to ever send alerts other than >> close_notify? >> >> ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
Martin Thomson wrote: > On 17 September 2015 at 14:46, Brian Smith wrote: > > Browser vendors, if web servers were to stop sending alerts during > handshake > > failures, would you start doing version fallback when a connection is > > closed? > > I'm not sure. We still have a small amount of vestigal fallback code > in our code. We are gradually killing version fallback off and > removing alerts would likely set that effort back. > Actually, Firefox has already stopped doing version fallback completely for all versions of TLS it supports, unless the website is on a whitelist. That's not really "gradually." We're not sure where we stand with version fallback and 1.3. We don't > know how much version intolerance 1.3 will generate. That at least > might not depend on alerts, though we don't know just yet. > A conformant TLS 1.3 implementation cannot be version intolerant. If it were version intolerant then it would not be a conformant TLS 1.3 implementation. So, conformance requirements for TLS .1.3 servers don't matter as far as version intolerance is concerned. > I don't see much support for the notion that forbidding alerts is a > good idea. We use alerts quite a bit for basic diagnosis. Bad > configurations are pretty commonplace, the most common being one where > there is no common cipher suite. Being able to isolate the error that > is pretty useful. > I still think it is better to recommend to never send alerts. But, at least there are good reasons (which I gave much earlier in the thread) for why a server would choose not to send alerts, e.g. out of an abundance of caution. So, "MUST send" is clearly too far. Cheers, Brian -- https://briansmith.org/ ___ 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 3:15 PM, Dave Garrett wrote: > On Thursday, September 17, 2015 06:00:05 pm Brian Smith wrote: > > 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. > > The whole handshake is retroactively authenticated upon completion. Just > because an attacker can muck up the attempt to connect, doesn't mean all > hope is lost. > A fatal alert during the handshake is never authenticated, because (a) the alert record is the last record sent (i.e. there is no Finished message sent afterward to authenticate it), and (b) The handshake hashes only cover Handshake records, not Alert records. > The primary benefit with the version alert, specifically, is that it > allows a client to at least have a clue as to what to attempt. > > Without alert: > client tries > server stares blankly into the void and/or drops abruptly > now, what does the client do? try again as-is, or try again with old stuff? > A conformant TLS 1.3 implementation will not be version intolerant. If the client does insecure version fallback in response to an alert or connection close by a conformant TLS 1.3 implementation then it is guaranteed to be doing the wrong thing. > Sure, a MitM could try to downgrade by injecting an unauthenticated alert > into the mix, but the handshake will fail once that is authenticated at the > end. > This is not how the protocol works at all. The alert is unauthenticated, full stop. The only time an alert is authenticated is when it is sent after the Finished message. But then, since such alerts can be triggered by a MitM who does not have knowledge of the keys, such sending of alerts allows the MitM to effectively inject known plaintext (the alert record) into the connection, which runs the risk of facilitating attacks. > Just as the obvious footnote: it's impossible to make any of this > resistant to an attacker killing the connection. Just assume that's always > possible, at minimum with wirecutters. The goal is security or bust. Alerts > give clients the confidence to actually bust when they have to. > In general, the "when to bust" is "always." Again, there is no such thing as a secure non-secure fallback. Cheers, Brian -- https://briansmith.org/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
Brian Smith wrote: > > 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. Alerts can help troubleshooting/debugging, in particular when one only has access to logs/traces of one of the communication peers. Alerts are not authenticated, and whenever they're the last message on a connection, could get lost on socket closure (killed in a tcp socket when pipe is full and lingering not enabled), or could get stripped by an attacker. How many TLS implementation remove a session from the session cache if the session ends without close-notify? The original idea wasn't really well thought-out, because implementations may start TLS session "forking" (storing sessions in cache and proposing their resumption on parallel network connections) immedately when the TLS handshake has completed (and before any app-level request & response has completed, i.e. long before a close-notify alert will be exchanged. There are TLS implementations that use a transport-free programming API, which means that the decision to send a fatal alert over the transport is not a decision of the TLS implementation, but of the application caller on top. And that application caller may not bother with processing any "transport requests" that accompany a fatal API error code at all. Microsoft' TLS implementation (SChannel) is an example of a transport-less implementation, and neither MSIE nor IIS send fatal TLS alerts over the wire before they close the network connection after a TLS handshake failure. (I don't have any Windows 8.x or 10 machines, so I don't know whether this was ever changed). You'll have to dig out the TLS alert number from the windows system event log on the machine where it happened, which is often not an option when the remote peer from a different service provider hangs up half way through the TLS handshake. Easier troubleshooting is IMO a sufficient rationale to justify existence of the alert mechanism and a "SHOULD send the alert before closing the network connection". A "MUST send fatal alert" requirement, however, would be silly (and will be void in face of rfc2119 section 6 anyway). What would be the semantics of such a requirement anyway? If one of the communication peers closes the network connection prior to completion of the TLS handshake, then the result is a 100% interoperability failure. How is a "MUST send alert" supposed to affect that outcome when the server does not send one? Is it a 120% interop failure then? -Martin ___ 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 3:44 PM, Dave Garrett wrote: > The client initially has no way of telling apart a conformant TLS 1.3 > server, a TLS 1.2 server, a TLS 1.0 server full of bugs, or a potato. > Right. I am not saying anything about how to *receive* alerts. That's a separate topic. What I'm saying is that a conformant TLS 1.3 implementation shouldn't be required to send fatal alerts in any circumstance; i.e. there should be no "MUST send" requirements for (fatal) alerts. Also, I agree with Martin Rex's recent reply to this thread. Cheers, Brian -- https://briansmith.org/ ___ 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 4:15 PM, Dave Garrett wrote: > On Thursday, September 17, 2015 06:58:19 pm Martin Rex wrote: > > If one of the communication peers closes the network connection > > prior to completion of the TLS handshake, then the result is a 100% > > interoperability failure. How is a "MUST send alert" supposed to > > affect that outcome when the server does not send one? > > Is it a 120% interop failure then? > > Well, yeah, sort of. :p > > If it's going to fail, I want it to fail in a way we can get it fixed. If > I get a server in one of the giant tracking meta-bugs for servers that have > TLS failures and I can see what is wrong, we can point to something to get > fixed. If not, then we have nothing to go on and it probably won't be fixed > ever. > Whether or not the server sends an alert doesn't matter for that. The user gets a cryptic error message either way, and bugs get filed and tracked. Here are two of many examples: https://bugzilla.mozilla.org/show_bug.cgi?id=704990 https://bugzilla.mozilla.org/show_bug.cgi?id=698203 Cheers, Brian -- https://briansmith.org/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS 1.3 - Support for compression to be removed
Dear Ladies and Gentlemen of the TLS Working Group, my name is Christos Alewa and I am writing you on behalf HOB GmbH & Co KG, a software enterprise from Germany, which specialises in development of software particularly for secure remote access. Our main product HOB RD VPN has received the Common Criteria EAL 4+ certificate by the German Federal Office for Information Security (BSI) which inadvertantly proves the level of security achieved - being the highest certificate available for commercial software. I've been redirected to this e-mail in order to address our company's issue regarding the proposed cease of support for compression in the new TLS 1.3 protocol. That said, i will relay our modest request to you as I have done already before: Since we at HOB, use SSL to maintain long-running VPN connections, might it be possible to - at least - maintain the status quo of the TLS - protocol in this aspect, enabling and disabling compression if needed? As a proposal to negate the known side-attack on the compression rate, which is in my understanding the reason support for compression is to be removed altogether, our thoughts are that a possible way to prevent this kind of side-attack might be to insert a nonce (random data with random length) to SSL records of type "application data". These need to be inserted in the beginning of the SSL record payload, rendering the monitoring of the compression rate of an attacker useless. With regards, Christos Alewa Software Instructor +499103-715-3553 HOB GmbH & Co KG Cadolzburg,Germany Follow HOB: - HOB: http://www.hob.de/redirect/hob.html - Xing: http://www.hob.de/redirect/xing.html - LinkedIn: http://www.hob.de/redirect/linkedin.html - HOBLink Mobile: http://www.hob.de/redirect/hoblinkmobile.html - Facebook: http://www.hob.de/redirect/facebook.html - Twitter: http://www.hob.de/redirect/twitter.html - YouTube: http://www.hob.de/redirect/youtube.html - E-Mail: http://www.hob.de/redirect/mail.html HOB RD VPN - einfach, sicher und flexibel auf alle Unternehmensanwendungen und -daten zugreifen Praesentation unter: http://www.hob.de/rdvpn2/ HOB GmbH & Co. KG Schwadermuehlstr. 3 D-90556 Cadolzburg Geschaeftsfuehrung: Klaus Brandstaetter, Zoran Adamovic AG Fuerth, HRA 5180 Steuer-Nr. 218/163/00107 USt-ID-Nr. DE 132747002 Komplementaerin HOB electronic Beteiligungs GmbH AG Fuerth, HRB 3416 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
