Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Jeffrey Walton]

>> 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

[TLS] Fwd: I-D Action: draft-lemon-tls-blocking-alert-00.txt

[Ted Lemon]

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] Downgrade protection, fallbacks, and server time

[Martin Rex]

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

Re: [TLS] PR #493: Multiple concurrent tickets

[Felix Günther]

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

[TLS] Adoption of TLS-LTS

[Peter Gutmann]

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] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Hubert Kario]

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

Re: [TLS] Downgrade protection, fallbacks, and server time

[Stefan Winter]

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=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