Re: [TLS] Downgrade protection, fallbacks, and server time
Hi, > > > > I agree with Hubert. The big question is how you get the bug report to > the server operator. Automated mail to webmaster@domain_of_requested_hostname? Maybe a few thousand new mails in the operator's inbox of sorts "we have encountered a situation where your version intolerance broke things. Fix it." (with all the technical details you can dump on an admin and expect him to understand; which is more than a user can take) wakes them up. That is, for domains still using webmaster@ like they should. Greetings, Stefan Winter > > With servers which are currently maintained, it should be possible, > although difficult in specific instances to contact the owner. With > servers which aren't being maintained, e.g. those in imbedded devices, > the problem becomes much harder. > > If the client has a UI, it could explain the problem to the user and > ask if the user wants to continue with degraded security. If so, then > always use the remembered highest supported version with that server > domain name, with perhaps occasional reminders to the user of the > situation. > > In any case, we should be addressing our efforts to getting bugs > fixed, not just coding around them. > > Cheers - Bill > > - > Bill Frantz| The first thing you need when | Periwinkle > (408)356-8506 | using a perimeter defense is a | 16345 Englewood Ave > www.pwpconsult.com | perimeter. | Los Gatos, CA 95032 > -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 0x8A39DC66.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR #493: Multiple concurrent tickets
Hi, Le 2016-06-04 16:51, Eric Rescorla a écrit : I wanted to call out to cryptographers/analysts that this formalizes the existing practice (going back to RFC 5077) of having multiple ticket values tied to the same basic secret (though less so with 1.3 because tickets issued on connection N+1 don't have the same RMS as those on connection N). If there is a problem with this, that would be good to know. Looking at the pull request, I don't think it will have much impact on the protocol analysis given that it doesn't introduce any adversarial capability that wasn't already present before. If anything, your change may enable a proof of session unlinkability for well-behaved clients connecting to honest servers, under a number of restrictions. My main complain about the current specification is that it doesn't clearly state that the specified restriction mechanisms for ticket lifetime and usage only partially bound the forward secrecy loss of PSK; implementations themselves must independently keep track of the lifetime of any given PSK in addition to managing the lifetime of tickets and ticket encryption keys by servers. For instance, if a server keeps re-issuing allow_psk_resumption tickets based on the same PSK it is up to the client to expire the session at some point even if still has valid ticket(s). Similarly, if servers do not store PSK lifetime information inside tickets it may end up using an ancient PSK although the ticket may have been encrypted under a recent ticket key. Best, Antoine ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
On Friday 03 June 2016 16:16:13 Dave Garrett wrote: > The idea of using an empty extension as an indicator really isn't > fundamentally different from what I'm suggesting here. We'd just have > an arbitrary set of new version indicators mixed in with extensions > instead of inside a new generalized basket. My replacement was > (again, it's over a year old) designed to be a general purpose > long-term solution that could handle 1.3, 1.4, draft versions, > experiments, etc, without special-casing. I'm not fundamentally > against just adding a TLS 1.3 version indicator extension and > freezing the old version number to 1.2. It just feels a little more > hacky to me, though in the short-term it's simpler. The reason why we want to add this is because there are programmers that get the normal version negotiation wrong. What makes you think that a new version negotiation that works more or less in the same way will _not_ be implemented incorrectly? Counter example: there are servers which handle TLSv1.2 and do not handle TLSv1.3 (e.g. ebay.com), and there are implementations that do not handle multiple names in SNI extension. Both are supported only by either recent or very recent implementations. And don't forget that what we are proposing here is significantly complicating implementations that most likely _are_ behaving properly and _are_ handling unknown versions/extensions/ciphersuites correctly; just because there are few bad apples. > With respect to the concern of version numbers being moved to a > non-fixed position, we could just require that the new version list > extension be first or last in the extensions list. it's still after the variable-length list of ciphersuites... -- Regards, Hubert Kario Senior 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
[TLS] Adoption of TLS-LTS
TLS-LTS, https://tools.ietf.org/html/draft-gutmann-tls-lts-03, has more or less stabilised, incorporating all the feedback I've had for it (there's only one open question still remaining), so I'd like to request that it now be adopted as a WG item. I'd also like to request an early/temporary assignment for an extension ID, to provide something a bit more usable than the much-overloaded 0x42 that's currently being used. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR #493: Multiple concurrent tickets
Hi, On 06/06/2016 11:53 +0200, Antoine Delignat-lavaud wrote: > Le 2016-06-04 16:51, Eric Rescorla a écrit : >> I wanted to call out to cryptographers/analysts that this formalizes >> the existing practice (going back to RFC 5077) of having multiple >> ticket values tied to the same basic secret (though less so with 1.3 >> because tickets issued on connection N+1 don't have the same RMS as >> those on connection N). If there is a problem with this, that would be >> good to know. > > Looking at the pull request, I don't think it will have much impact on > the protocol analysis given that it doesn't introduce any adversarial > capability that wasn't already present before. If anything, your change > may enable a proof of session unlinkability for well-behaved clients > connecting to honest servers, under a number of restrictions. I agree with Antoine that I don't expect multiple ticket values for the same cryptographic key to have a (negative) impact on the/our security results. As the ticket value is, through ClientHello, part of the handshake hash, hence flowing into the key derviation, separate ticket values should "domain-separate" the keys established from the same RMS. And yes, might be one can establish some form of cryptographic session/handshake unlinkability for honest client-server communication. Cheers, Felix signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Downgrade protection, fallbacks, and server time
The IMO most reasonable way forward would be to side-step the TLS version negotiation through ClientHello.client_version entirely, because of the well-known interop problems. Simply use the presence of *ANY* TLSv1.2+ TLS cipher suite in the offered list of TLS cipher suites as an indication that a TLS client is capable and willing to actually _use_ TLSv1.2, even when ClientHello.client_version might indicate (3,2) or (3,1) for better interop. The same approach will work for TLSv1.3, where the presence of a TLSv1.3 could be used to tell the server that the client is capable and willing to talk TLSv1.3, even when ClientHello.client_version might indicate a lower version of the protocol. Only the client is in the position to decide whether aborting the TLS handshake and retrying with a more feature-creeping ClientHello could provide additional benefits to the client (that it previously didn't offer, for whatever reason), and only the client is in the position to know how many TLS handshake attempts with which properties it previously attempted, and when to better stop retrying automatically and silently and to perform risk management (such as warning user/admin that something odd is going on). To get a smooth migration to using newer TLS protocol versions, we first need to define a scheme that lets new implementations recognize each other without upsetting the installed base. We know what works, the code points already exist, we will just have to align the documented semantics to provide a more forward-interoperable and more reasonable behaviour. Viktor Dukhovni wrote: > >> David Benjamin wrote: >> >> I'm not sure I follow. The specification certainly spells out how >> version negotiation is supposed to work. That hasn't stopped servers >> from getting it wrong. Fundamentally this is the sort of thing where >> bugs don't get noticed until we make a new TLS version, and we don't >> do that often enough to keep rust from gathering. > > A better way to keep rust from gathering is to not instutionalize fallback, > force the broken sites to deal with the issue. It's not the sites, but rather the software vendor providing the underlying TLS implementation. Sometimes you don't actually have a choice and an alternative to using what exists. > > While 2% is noticeable, you can probably drive 1.3 version intolerance > out of the ecosystem relatively quickly if Chrome implements fallback > for a limited time (say 6 months after TLS 1.3 RFC is done) and with > a diminishing probability (60% first month, 10% less each month > thereafter), season to taste. There exist various different flavour of TLS version intolerance, and the amount of defective servers out there is probably much larger. The entire installed base of Windows 2008R2 and Windows 20012R2 is TLS version intolerant with respect to TLSv1.2. If you send propose TLSv1.2 inside an SSLv2Hello to such a server, it will negotiate TLSv1.1 (rather than TLSv1.2). If you send an extensionless SSLv3 Hello proposing TLSv1.2, these Windows server with choke and close the network connection. An extension-less SSLv3 Hello with at client_version = TLSv1.1 or TLSv1.0 will succeed. -Martin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Fwd: I-D Action: draft-lemon-tls-blocking-alert-00.txt
I've posted a new document to the datatracker that adds some TLS alert codes that can be sent to indicate that a particular TLS request has been blocked by the network. This attempts to address the problem of notifying the user of what went wrong when a site is blocked, without creating a channel that can be used by a hostile network to attack a user. Feedback is solicited, naturally. Thanks! A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Blocked Site Alerts for TLS Author : Ted Lemon Filename: draft-lemon-tls-blocking-alert-00.txt Pages : 7 Date: 2016-06-06 Abstract: Hosts connecting to the Internet should generally be able to connect to all available services. However, as a matter of policy, need or preference, some services may be blocked by the network. TLS correctly treats attempts to communicate the reason for such blockage to the client as an attack. This memo describes a safe way for hosts to be notified using the TLS alert mechanism that a connection has been blocked by the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-lemon-tls-blocking-alert/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-lemon-tls-blocking-alert-00 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
On Monday, June 06, 2016 06:48:20 am Hubert Kario wrote: > What makes you think that a new version negotiation that works more or > less in the same way will _not_ be implemented incorrectly? The list-based extension doesn't work in quite the same way. The current mechanism compares two values and picks the lower one. This new mechanism compares two lists and picks the highest mutually listed. Also note that I wish to officially drop any meaning from the version IDs such that we're using an arbitrary 16-bit serial number rather than two 8-bit major & minor numbers. The new supports discontinuous lists, e.g. support of 1.0, 1.2, & 1.4, but not 1.1 or 1.3, without risking accidental negotiation of a lower version that isn't desired. (if 1.3 is eventually declared less ideal than 1.2 or 1.4 due to some unforeseen problem, this gives us a safe mitigation, and it extends to arbitrary future scenarios) Also, as with any new system, we now have the ability to loudly stress to TLS 1.3+ implementers to not screw it up and test for future-proofing this time around. At a minimum, implementations will not be able to use the exact same code to negotiate in both systems and would have to go out of there way to add intolerance stupidly, rather than stumble into it stupidly again. Just sticking a new field in an extension lets implementers route it into the same code and risk the same mistakes; adding a bit of complexity here is an unfortunate cost of fixing this mess. Just adding a new _empty_ extension, as was more recently proposed, is something I think could also work ok. Again, if we're more likely to get consensus on that, I think it's viable too. The idea of a compliance test suite has come up before and I will again say: YES, PLEASE! I certainly don't claim anything proposed here is perfect, but nothing is or will be in a 20 year old protocol. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
>> That being said, I would prefer the solution to be a compliance test suite >> that checks if servers do handle correctly future versions, future >> extensions and future ciphersuites correctly. > > I agree with Hubert. The big question is how you get the bug report to the > server operator. > > With servers which are currently maintained, it should be possible, although > difficult in specific instances to contact the owner. With servers which > aren't being maintained, e.g. those in imbedded devices, the problem becomes > much harder. There are two ways. First, use the Administrative and Technical contacts in the WHOIS database. They are ICANN contractual requirements, and they must be valid. Second, RFC 2142, MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS. Jeff ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]
Dave Garrett writes: >Also, as with any new system, we now have the ability to loudly stress to TLS >1.3+ implementers to not screw it up and test for future-proofing this time >around. I think that's the main contribution of a new mechanism, it doesn't really matter whether it's communicated as a single value, a list, or interpretive dance, the main thing is that there needs to be a single location where the version is given (not multiple locations that can disagree with each other as for TLS < 1.3), and the spec should include a pseudocode algorithm for dealing with the version data rather than just "implementations should accept things that look about right". Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
