[TLS] Reviving draft-zauner-tls-aes-ocb?

[Tony Arcieri]

For those who are unfamiliar, the "pitch" of OCB mode is that it's fast
everywhere: on servers, desktops, smartphones, and low-power IoT devices
with some sort of hardware-accelerated block cipher, whereas currently GCM
is popular on higher-power devices like servers/desktops/smartphones
whereas the IoT/embedded space frequently uses CCM to be able to offload
encryption onto hardware accelerators instead of an MCU (where OCB would
double performance by cutting the number of block cipher invocations in
half).

This draft to add OCB ciphersuites to TLS expired in 2016:

https://datatracker.ietf.org/doc/html/draft-zauner-tls-aes-ocb

However, in the intervening time, the IPR story around OCB (its former
biggest drawback, IMO) has become significantly clearer.

OCB's creator Phil Rogaway has disavowed or intentionally allowed all of
his patents to lapse. "OCB is Free" declares his licensing page, which
notes all of his IP is now in the public domain:
https://www.cs.ucdavis.edu/~rogaway/ocb/license.htm

This Jutla/IBM patent expired in 2022:
https://patents.google.com/patent/US6963976B1/en

Given that, I'm curious if this resolves IPR concerns around OCB, and if it
does, if there are other concerns beyond those.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS Impact on Network Security draft updated

[Tony Arcieri]

On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) <
ncamw...@cisco.com> wrote:

> Hi,
>
> Thanks to all the feedback provided, we have updated the
> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
>
> draft.  At this point, we believe the draft is stable and would like to
> request its publication as an informational draft.
>

I read this draft as the latest attempt in a disinformation campaign by
manufacturers and users of middleboxes that passively decrypt TLS
connections to politicize and reframe the argument around what is, at its
core, a fundamentally insecure practice which is incompatible with
technically sound and highly desirable protocol improvements to TLS.

I implore you stop using overly broad terminology, euphemisms, weasel
words, and other deceptive language to argue your points.

This draft is titled "TLS 1.3 Impact on Network-Based Security", but the
subtext is quite clearly the much narrower subfield of middlebox TLS
decryption. By using such a grandiose title which is deceptively hiding the
true subject matter, you are implying that middleboxes are the sum total of
network security.

The draft begins "Enterprises [...] need to defend their information
systems from attacks originating from both inside and outside their
networks." I am co-owner of a company which heavily leverages firewalls for
layer 3/4 network security in conjunction with TLS. We care deeply about
network security, and believe that our network is *more secure*
specifically because we *don't* perform middlebox interception of TLS.

I consider our company to be in the category of enterprise TLS users, and
as an enterprise TLS user who cares deeply about network security, I do not
identify whatsoever with the claims this draft is making about the needs of
enterprise TLS users as a whole. In as much as what it describes to
"network security", it is but one niche consideration within a vastly
broader field, and one which is increasingly controversial.

I will point out, since you appear to work at Cisco, that your company
works on approaches to network security (e.g. malware detection) which
avoid decrypting TLS:

https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption

There is an entire world of network IDS systems beyond middleboxes which
passively decrypt TLS.

It is factually inaccurate for this draft to be described as "TLS 1.3
Impact on Network-Based Security". If you are going to write a draft about
the impact of TLS 1.3 on middleboxes for passive TLS decryption, please
call a spade a spade and don't try to hide your true intentions under a
bunch of weasel words and overly broad claims that make it sound like
middlebox-related TLS decryption problems are the end of network security
as we know it.

My 2c, on behalf of non-middlebox-using enterprise TLS users who feel that
attempts by middlebox-using enterprise TLS users to weaken TLS in order to
retain compatibility with their traffic decryption appliances is a threat
to the security of our enterprise TLS deployments.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-dkg-tls-reject-static-dh

[Tony Arcieri]

On Thu, Dec 6, 2018 at 11:14 PM Peter Gutmann 
wrote:

> [0] "In principal" because there's a fair bit of SCADA gear that does this
> because it doesn't have the CPU power to generate new DHE values, as I
> found out when I turned on non-DHE checking some years ago.
>

I think these concerns can largely be addressed by ECDHE with e.g. X25519:

https://eprint.iacr.org/2015/343.pdf

This implementation does variable-base X25519 scalar multiplication in
13,900,397 cycles, or ~0.869s on a 16MHz AVR CPU commonly found on
Arduinos. I imagine fixed-base scalar multiplication can be further
optimized.

-- 
Tony Arcieri
___
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

[Tony Arcieri]

On Thu, Dec 6, 2018 at 3:30 PM Viktor Dukhovni 
wrote:

> > On Dec 6, 2018, at 4:08 PM, Andrei Popov  40microsoft@dmarc.ietf.org> wrote:
> >
> > Widespread deployment of draft-dkg-tls-reject-static-dh-01 and failing
> connections to "enterprise TLS" servers would probably qualify as
> "essential circumstances", at least to some operators.
>
> I don't think the TLS WG or IETF can win this skirmish.
>

I think there are very strong technical/security reasons to reject using a
static D-H key in place of an ephemeral D-H key, namely compromise of this
key permits "impersonation" of any previously (passively) observed TLS
sessions by allowing a passive observer holding one of these keys to
recover the resumption master secret.

In as much as people are attempting to build standards around this
approach, based on the conversation earlier in this thread it seems they
were unaware of this security property. I hope this causes the creators of
"eTLS" to reconsider the security implications of their proposal.

I think a protocol which aims to fulfill the specific goals of "eTLS"
should focus on providing a way for a passive observer to recover the
*traffic* secrets, which would provide the ability to passively decrypt
traffic (something I think is a bad idea, but I digress), but *NOT* resume
observed sessions.

-- 
Tony Arcieri
___
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

[Tony Arcieri]

On Thu, Dec 6, 2018 at 12:33 PM Daniel Kahn Gillmor 
wrote:

> So it's conceivable that truly malicious servers would do this, of
> course, but they might also just publish the master secret on twitter
> too, and the client wouldn't know how to detect that inband either.  But
> for the misbehavior that we *can* detect in-band, a responsible client
> should be aware of it and avoid it, right?
>

If nothing else, implementations which reuse ephemeral keys for long
periods of time are buggy and contain a vulnerability which violates the
security assumptions of the protocol.

I think it's reasonable for clients to detect and reject this behavior, as
it's an indicator TLS has been deployed in an insecure way and therefore
the connection should be aborted. I think this could detect a wide range of
"real world" TLS implementation failures which have come up in the past,
including bugs in random number generation and bugs in the code in TLS
stacks responsible for rotating ephemeral keys.

-- 
Tony Arcieri
___
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

[Tony Arcieri]

On Wed, Dec 5, 2018 at 12:09 AM Bret Jordan  wrote:

> Now this WG is finally starting to talk about a solution to a real problem
> and need.  We can either address the use case and need here in the IETF, or
> we can let the solutions be done else where. I would personally prefer we
> take this work item back and solve it here in the IETF.
> [...]
>
> On Dec 5, 2018, at 1:18 AM, Tony Arcieri  wrote:
> [...]
> It seems like with an out-of-band escrow agent, the traffic secrets could
> be escrowed with no changes to TLS.
>
> Note that the solution I was proposing here requires no changes to TLS. I
am sure that there are many in the IETF who would be happy with people
exploring solutions which don't require changes to TLS.

Here are some others:

   - Endpoint agents (OSS - commercial options are also available):
   - https://osquery.io/
  - https://www.bro.org/ (now Zeek)
  - https://wazuh.com/
  - Encrypted traffic analytics:
   
https://blogs.cisco.com/security/tls-version-1-3-change-is-here-and-encrypted-traffic-analytics-has-got-your-back

--
Tony Arcieri
___
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

[Tony Arcieri]

On Sun, Dec 2, 2018 at 3:36 PM Nico Williams  wrote:

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


Wouldn't escrowing only the client/server application traffic secrets
(instead of keys higher in the schedule) avoid this problem? These keys
would permit the one capability "visibility" appliance vendors allege to
care about: traffic decryption, without permitting others like session
resumption.

 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.


It seems like with an out-of-band escrow agent, the traffic secrets could
be escrowed with no changes to TLS.

--
Tony Arcieri
___
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

[Tony Arcieri]

On Sat, Dec 1, 2018 at 8:12 AM Dmitry Belyavsky  wrote:

> I do not understand why the ETSI solution does not provide ability to
> impersonate clients/servers.
>

My understanding of this solution is a "visibility" system would have
access to a not-so-ephemeral ECDHE private key. This gives it access (via
passive observation) to all session keys ultimately derived from ECDHE key
agreement, including the resumption master secret.

See RFC 8446, section 7.1: Key Schedule

(EC)DHE -> HKDF-Extract = Handshake Secret
 |
 +-> Derive-Secret(., "c hs traffic",
 | ClientHello...ServerHello)
 | = client_handshake_traffic_secret
 |
 +-> Derive-Secret(., "s hs traffic",
 | ClientHello...ServerHello)
 | = server_handshake_traffic_secret
 v
   Derive-Secret(., "derived", "")
 |
 v
   0 -> HKDF-Extract = Master Secret
 |
 +-> Derive-Secret(., "c ap traffic",
 | ClientHello...server Finished)
 | = client_application_traffic_secret_0
 |
 +-> Derive-Secret(., "s ap traffic",
 | ClientHello...server Finished)
 | = server_application_traffic_secret_0
 |
 +-> Derive-Secret(., "exp master",
 | ClientHello...server Finished)
 | = exporter_master_secret
 |
 +-> Derive-Secret(., "res master",
       ClientHello...client Finished)
   = resumption_master_secret


-- 
Tony Arcieri
___
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

[Tony Arcieri]

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.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Drop "1.x" from future TLS version names?

[Tony Arcieri]

Apologies if the last thing people want to talk about right now is the next
version of TLS.

There was much discussion about bumping TLS 1.3's version number to "TLS 4"
or thereabouts (so as to be higher than "SSLv3"). The ship has sailed on
that and it is "TLS 1.3".

I think there was widespread agreement that TLS 1.3 represented something a
bit more substantial than a minor version bump, and a desire to have a TLS
version number bigger than the SSL version number lest people get confused
and deploy SSLv3 instead of TLS 1.3.

Modest proposal: TLS 1.4 => TLS 4

I bring this up so soon because I think a lot of the pushback regarding
doing this before was due to changing the version so late in the
development cycle.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

[Tony Arcieri]

On Tue, Jul 17, 2018 at 8:04 AM Johannes Merkle 
wrote:

> Crypto agility definitely has its value. There are not so many curves
> supported by TLS 1.3, and all of them use primes
> of a very special form. Of course, this is exactly what makes these curves
> faster than the Brainpool curves, but from a
> security perspective it might be advisable to have alternatives at hand
> which have very different properties


Between the NIST curves and Curve25519/Ed448 we have this already.


> (and have not been generated by the NSA using seeds of obscure origin).
>

We've been through this before, e.g.:

https://www.ietf.org/mail-archive/web/tls/current/msg10271.html
https://bada55.cr.yp.to/brainpool.html

the latter of which quotes you as saying the repeated digits in the "A"
and "B" values used in Brainpool seed generation process were "unfortunate".

There are no compelling practical reasons to continue to support the
Brainpool curves. They are both redundant and obscure.

--
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Tony Arcieri]

 Using something like DoH in conjunction with
dns.google.com, we can completely reduce the parties who are able to
determine which internal tools are being accessed to Google exclusively.

Is there enterprise value to actually protecting this information? Well,
like network security, it is (or at least should be) only defense-in-depth.
But I still see value in defense-in-depth.

As an industry practitioner, from the perspective of the sorts of companies
I work at, I see no downsides of this approach. Instead see an interesting
feature which I want to use.

Framing things in terms of "privacy" versus "industry concerns" is a false
dichotomy, and one we continue to see being perpetrated by the "visibility"
camp, e.g.
https://www.ncsc.gov.uk/blog-post/tls-13-better-individuals-harder-enterprises
(which had an awesome response from agl:
https://www.imperialviolet.org/2018/03/10/tls13.html). They are using this
as a rhetorical tactic to spin the "visibility" debate, when the reality is
that the interests of individuals and enterprises are not at odds. What are
at odds are improving Internet security for everyone versus the interests
of e.g. Blue Coat's customers whose compliance story presently depends on
their ability to break their own security from a single point of
compromise. More modern techniques like endpoint agents, tracing
frameworks, and other observability tools can tick the same compliance
checkboxes and solve the same problems like debugging complicated
service-oriented architectures. But it seems some people stuck on the Blue
Coat model would rather make Internet security worse for everyone than
invest in updating to a more modern approach.

Enterprises can benefit from privacy just as much as individuals. However,
not all enterprises within industry as a whole are ready to take advantage
of it. When seeking out industry input for IETF, make sure you're not only
paying attention to a particularly vocal segment whose views are not
representative of industry as a whole.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Mail regarding draft-ietf-tls-tls13

[Tony Arcieri]

On Mon, Jun 18, 2018 at 12:12 PM Ben Personick 
wrote:

>   So essentially TLS 1.3 drops support for DH/DHE ciphers on RSA keys, but
> willl otherwise work as expected?
>

DH/DHE ciphers are orthogonal to RSA key transport/encipherment. The latter
uses the RSA algorithm for encryption, without any DH(E) algorithm
whatsoever, and that is what is no longer supported in TLS 1.3.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Mail regarding draft-ietf-tls-tls13

[Tony Arcieri]

On Mon, Jun 18, 2018 at 6:30 AM Ben Personick 
wrote:

> There is a common thread circulating, that all support for RSA
> Certificates/Ciphers are dropped in TLS 1.3.
>

RSA certificates will continue to work in TLS 1.3+.

What will not be supported in TLS 1.3+ is RSA key transport / key
encipherment (which lacks forward secrecy, among other problems). However,
this is a property of how the protocol does key exchange / key agreement
and has nothing to do with certificates.

-- 
Tony Arcieri
___
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

[Tony Arcieri]

On Mon, Apr 16, 2018 at 9:11 AM, Viktor Dukhovni <ietf-d...@dukhovni.org>
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.

-- 
Tony Arcieri
___
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

[Tony Arcieri]

On Mon, Apr 16, 2018 at 2:56 AM, Tobias Gondrom <tobias.gond...@gondrom.org>
wrote:

> Are there any RFCs that speak (beyond the general verification of the
> certificate in mutual TLS authentication) to the need to also verify the CN
> inside the client certificate against an additional whitelist _*before*_
> establishing a TLS connection.
>

I'm not sure what you mean by "before establishing a TLS connection", as
certificates are generally exchanged during the TLS handshake, so doing
anything "before establishing a TLS connection" would require the server
somehow know the client's certificate a priori. There are several systems
that will abort the handshake unless they receive an acceptable client
certificate, however.

I don't know of any RFCs for this per se, or anything that uses the Subject
CN (I think almost everything has completely moved away from using the CN).
However, as an example, SPIFFE is a largely Kubernetes-focused identity
system which encodes a "SPIFFE ID" in the client cert's subjectAltName and
uses that to determine whether clients are authorized to continue a TLS
connection:

https://github.com/spiffe/spiffe/blob/master/standards/X509-SVID.md

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

[Tony Arcieri]

On Fri, Mar 23, 2018 at 11:26 PM, Alex C <immi...@gmail.com> wrote:

> As I understand it (poorly!) the idea is exactly to have a single system
> on the network that monitors all traffic in cleartext.
>

And more specifically: to be able to *passively* intercept traffic and
allow it to be decrypted by a central system. "Visibility" with an active
MitM is a solved problem: have the MitM appliance double as an on-the-fly
CA and install its root certificate in the trust stores of all the clients
you intend to MitM.

It's fundamentally impossible to prevent someone from copying all their
> traffic to another system in cleartext. If they're going to do it, they
> will.
> The functionality is exactly the same as what could be achieved by
> installing monitoring software on each endpoint, but the logistics are
> different since the monitoring is centralized.
>

The response from "visibility" proponents is "endpoint agents are hard".
However, it seems like there is a simple solution to this problem which
should be compatible with their existing monitoring architectures and
require no changes to TLS:

Instrument TLS servers and/or client libraries used by internal enterprise
applications with a little shim that extracts the session master secret,
then makes another TLS connection to a TLS session key escrow service, and
goes "here's the session master secret for a session between X.X.X.X and
Y.Y.Y.Y with nonce ...". It could even be encrypted-at-rest to a
particular public key in advance (which could correspond to e.g. an
HSM-backed decryption key).

Enterprises could continue to passively collect TLS sessions in whatever
manner they already do, and decrypt traffic at will, it would just require
looking up the session key for a particular session in a key escrow
database rather than having a single key-to-the-kingdom.

This approach requires no changes to TLS, no changes to how "visibility"
systems collect traffic, and should provide better security in that using
session master secrets better scope the authority conferred to the
decryption service than D-H keys which can grant authority to e.g. resume
TLS sessions.

The downsides are you have to instrument clients and/or servers and have
the decryption service maintain a key escrow database.

However, "visibility" proponents seem unwilling to accept any changes to
anything they presently do today. This is coupled with a sort of artificial
emergency where they claim (or outright lie) that compliance with industry
standards will require them to ship TLS 1.3 everywhere tomorrow. There is a
total unwillingness to compromise, and all sorts of weasel words being
thrown around, from the "visibility" euphemism itself to claims that TLS
1.3 will make them less secure because it makes implementing a
single-point-of-compromise for all their encrypted traffic more difficult.

The reality is for these slow-to-change enterprises, the industry standards
are also slow-to-change. There is no emergency. Many of them are still
using TLS 1.0. The PCI-DSS deadline to adopt TLS 1.1 isn't until this June.
I would challenge any "visibility" proponent to cite *any* industry
standard which will mandate TLS 1.3 any time in the next 5 years.

There is lots of time to solve this problem and better ways to solve it
than introducing codepaths which deliberately break the security of the
protocol.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 3rd WGLC: draft-ietf-tls-tls13

[Tony Arcieri]

Ship it

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future devices that will break TLS 1.4

[Tony Arcieri]

On Sat, Jan 13, 2018 at 12:02 AM, Hanno Böck <ha...@hboeck.de> wrote:
>
> The question I want to ask: What can we do *now* to stop this from
> happening when TLS 1.4 will be deployed? I have the feeling GREASE
> won't be enough...


Sidebar: TLS 4 ;)

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Tony Arcieri]

On Mon, Oct 23, 2017 at 6:31 PM Ackermann, Michael <mackerm...@bcbsm.com>
wrote:

> NO
> The objective is to be passively observe, out of band and not to be a MitM
> or modify/inject text.Just as we all do today.


You seem to be confused as to the difference between an active vs passive
MitM. Using the term “MitM” for a passive network observer, particularly
one which can decrypt traffic, is perfectly apt.

> --
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Tony Arcieri]

On Mon, Oct 23, 2017 at 12:11 PM, Adam Caudill  wrote:

> Those advocating for some standardized method of subverting the security
> properties of TLS have been offered numerous options in good faith, and
> continue to reject them all. I’m aware of extremely large enterprises that
> in fact require TLS 1.2 with PFS, as they made the investment in addressing
> this issue early on, and do so effectively. This can be solved without
> changes to the protocol or a standardized “backdoor” - and is being done
> today by at least some enterprises.
>

Having worked (and presently working) for more than one company of this
nature, in the payments business no less, I would like to restate that it's
incredibly disingenuous to cite the need for self-MitM capability as an
"industry" concern.

I think if it were possible to ask for a hum "from industry", you'd find
the field divided between those who have invested in a real observability
story, and those who think passive network traffic collection is the only
way to debug their systems. I think if you were to even take a straw poll
of the best approaches monitoring/observability among actual industry
practitioners, passive network traffic collection would rank close to the
bottom of the list.

I would go as far as to say that if you are among those requesting this
misfeature, you are doing a terrible job securing your infrastructure, and
should look into modern observability techniques as an alternative to
debugging by concentrating network traffic dumps into a single point of
compromise which represents a huge security liability. Yes, switching to a
new approach to observability is a huge investment that will take time, but
so is upgrading to a new version of TLS.

The "industry" reality is that many companies do not need a self-MitM
misfeature and could be actively harmed by it, and while a self-MitM
capability may be standard operating practice for some, it is not true for
all, and identifying those who want the self-MitM capability as "industry"
is a composition fallacy being leveraged as a rhetorical tactic, i.e. "IETF
is not listening to the concerns of industry".

As a member of "industry" myself, I implore the IETF: please don't make the
rest of us less secure at the request of those who are running insecure
infrastructures and apparently intend on keeping things that way.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Tony Arcieri]

On Fri, Oct 20, 2017 at 11:27 AM, Ilari Liusvaara <ilariliusva...@welho.com>
wrote:

> TLS 1.2 will very probably remain viable until quantum computers come
> and demolish its security, unfortunately.


As someone who has spent a lot of time working on compliance for payments
systems, I have an open question to the "visibility" advocates:

Can you provide a *specific citation* as to where you will be *required* to
use TLS 1.3 any time in, say, the next decade?

This is absolutely not the case for PCI-DSS.

To my knowledge any requirement of this nature simply doesn't exist. I
could be wrong but... citation needed.

If there is no pressing reason for legacy systems which are dependent on
"visibility"/self-MitM capability because their observability story is so
poor and they can't use endpoint agents to solve the same problems, what is
the case for trying to add MitM mechanisms now?

The answer is simple: stay on TLS 1.2 (or earlier) until you can improve
your observability story, or *specific* requirements which *mandate* use of
TLS 1.3 actually manifest. From previous experience: such mandates will not
be a fire drill, but will be years in the making, and repeatedly delayed
due to "industry" requirements / shortcomings.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Tony Arcieri]

On Fri, Oct 20, 2017 at 6:44 AM, Salz, Rich <rs...@akamai.com> wrote:

>
>- A decade later, PCI-DSS is only ‘strongly encouraging’ TLS 1.2; the
>actual requirement is TLS 1.1! Why should we expect that TLS 1.3 will
>happen any faster?
>
> It's worse than that. PCI-DSS presently only requires TLS 1.0. The
deadline to switch to 1.1 or higher is 30 June 2018:

https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption)

[Tony Arcieri]

On Fri, Aug 18, 2017 at 3:46 PM, Daniel Kahn Gillmor <d...@fifthhorseman.net>
wrote:

> While i think i understand where you're coming from, Tony, i can't help
> but note that this use case is difficult to distinguish from a regime
> that:
>
>  (a) wants to forbid anonymous speech, and
>
>  (b) wants to censor "unapproved" information sources, and
>
>  (c) wants the capacity to undermine freedom of association.
>
> That makes me wary, and i hope that SNI Encryption is *not* conflated
> with these particular use cases.
>

TLS tunnels have a multitude of use cases, from SNI encryption to service
discovery-aware load balancers to Tor-like anonymity networks to
privacy-preserving payment channel networks to my much more mundane
"Squid-like authenticated egress proxy" problem.

I'm simply asking that if tunnels become the mechanism by which SNI
encryption is ultimately implemented, that all of the potential use cases
of tunnels are considered, rather than observing the problem through the
microcosm that is "SNI Encryption".

Note that I'm proposing absolutely nothing new, just asking that the
tunneling problem be considered from more angles than one. If TLS contains
(mis)features which forbid anonymous speech or censor unapproved
information sources, I'm afraid that the ship has already sailed there. But
perhaps, well-implemented TLS tunnels could ultimately help route around
censorship.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call: SNI Encryption

[Tony Arcieri]

As I expressed on a separate thread, I think tunneling TLS is a very
interesting problem with many potential use cases, from SNI encryption to
egress proxies to service discovery proxies (e.g. linkerd, Envoy).

SNI encryption is one of the use cases, but SNI encryption is pointless
until we have encrypted DNS. That's not to say we shouldn't work on SNI
encryption, but that SNI encryption isn't immediately valuable, whereas I
think there are many other TLS tunneling use cases where the same proposed
mechanism is immediately valuable as opposed to a future "when the DNS
loophole is closed" scenario for SNI encryption.

I am all for tunneling as a general WG item, but I think framing the
discussion specifically in terms of SNI encryption is missing the forest
for the trees.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption)

[Tony Arcieri]

On Thu, Aug 10, 2017 at 7:07 PM, Martin Thomson <martin.thom...@gmail.com>
wrote:

> What makes you think that the implementation story here would be any
> different?  I'm not trying to destroy your idea, which seems fine on
> face value, but just trying to understanding the value proposition
> better.


As I said earlier, the implementation story is the same (or extremely
similar), but it's looking at the problem from a different perspective:

What I think is particularly interesting about this use case in the context
> of the SNI encryption discussion is it is in fact almost entirely the same
> problem from a technical perspective. Where it differs is largely in the
> framing of the problem: instead of using the gateway to reach a hidden host
> from the Internet, we are using the gateway to talk to the Internet from an
> internal network which needs to go through a proxy host to reach the
> Internet.


I did also list a few things I think are tangibly different:

There are a few additional things which are different between the cases
> beyond some of what I've just mentioned. Ideally the client verifies the
> gateway's server cert against an internal-only CA bundle, then verifies the
> tunneled destination host against a public CA bundle. We might want a
> client to present an internal client certificate to the gateway, but
> present no cert/a different cert to the destination host. That said, aside
> from minutia like that, the machinery seems largely the same.


Support for using different CA bundles for the gateway versus the
destination host seems important in this use case, IMO.
Also: support for sending different certs to the gateway versus the
destination host.

While these are ultimately just implementation details, I think they're
worth at least considering when such a draft is being authored.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption)

[Tony Arcieri]

On Thu, Aug 10, 2017 at 2:23 AM, Martin Thomson <martin.thom...@gmail.com>
wrote:

> I'm trying to work out whether there is anything new here.  I know
> that browsers implement proxying over HTTPS and CONNECT.  Can you
> summarize the ask more succinctly?  Because I'm thinking that this is
> a solved problem.
>
> See Section 8.3 of RFC 7540.  We didn't put that there for a lark.


Backing up a bit: my personal primary use cases are services running on a
network trying to speak outbound. Yes it's great browsers have support, but
what about anything else that wants to make an outbound TLS connection to
the Internet?

Trying to solve this problem with HTTP, rather than the TLS, forces every
single network client library on earth that wants to talk through these
proxies to implement both CONNECT and enough HTTP to speak to the proxy and
request CONNECT.

Do you really think (ab)using an HTTP proxy this way is a good idea? I
don't. I also don't think it's been particularly successful:

- We've wound up with a server-side ecosystem where, as far as I can tell,
Squid is the only service which implements all the features needed to
provide an HTTPS-authenticated outbound CONNECT gateway with
client-by-client ACLs

- Support is not as ubiquitous as you may think. For example Go's net/http
library does not support CONNECT through an HTTPS proxy:
https://github.com/golang/go/issues/11332

Solving this problem with TLS instead of HTTPS could result in a solution
where once it's implemented in a TLS library, any clients using that TLS
library could take advantage of it, rather than each client having to
implement CONNECT themselves.

I say this all as someone looking at rolling out Squid for this purpose as
we speak, and having worked places who have run Squid this way in the past.
CONNECT is widely supported enough to mostly make this work, but I think
things could be... much better than they are.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption)

[Tony Arcieri]

As I look at draft-huitema-tls-sni-encryption[1], I really think it's
putting the cart before the horse. I really like the proposed TLS-in-TLS
tunneling mechanism, but I feel it is a generally useful mechanism, and
this draft relegates it to providing a point solution specifically for the
purposes of SNI encryption and considering only that use case.

One of the things I like the most about TLS 1.3 is how it has harmonized
the sort of chunky stew of ill-conceived features found in previous TLS
versions (with nebulous and overlapping responsibilities) into a smaller
set of clearly-defined parsimonious ones which cover a wide range of use
cases.

In considering the general problem of "SNI encryption", and particularly
within the context of TLS-in-TLS tunneling solution, I humbly ask that
other use cases which would benefit from a TLS-in-TLS tunneling mechanism
are considered. I think any draft about this should have TLS-in-TLS
tunneling itself as the centerpiece, and "SNI encryption" off to the side
as one potential use case.

So, what other use cases are worth considering? Egress proxies!

Consider: a gateway server acting as an external proxy which bridges an
internal network with the Internet, acting as a forward proxy to
authenticated clients (either human-driven apps/tools or backend services).

What I think is particularly interesting about this use case in the context
of the SNI encryption discussion is it is in fact almost entirely the same
problem from a technical perspective. Where it differs is largely in the
framing of the problem: instead of using the gateway to reach a hidden host
from the Internet, we are using the gateway to talk to the Internet from an
internal network which needs to go through a proxy host to reach the
Internet.

More tangibly, I would like the following as the administrator of an
internal network:

- All outbound traffic flows through centrally managed gateway hosts which
act as TCP proxies. Outbound connections to the Internet are otherwise NOT
allowed

- As we're fans of actually using TLS to provide end-to-end transport
security and not "SSL added and removed here ;-)", we want the resulting
connection to be encrypted end-to-end between the internal network TLS
client and the requested destination server. Also, all "setup"
communication to the gateway should also happen over TLS

- The gateway authenticates clients (using e.g. a TLS client certificate)
and authorizes the outbound hostnames against an ACL. This way we can
control which clients are allowed to reach which external endpoints.

There are a few additional things which are different between the cases
beyond some of what I've just mentioned. Ideally the client verifies the
gateway's server cert against an internal-only CA bundle, then verifies the
tunneled destination host against a public CA bundle. We might want a
client to present an internal client certificate to the gateway, but
present no cert/a different cert to the destination host. That said, aside
from minutia like that, the machinery seems largely the same.

What are the real-world "rough consensus and running code" solutions to
this sort of problem in place today? There are all sorts of options that
are sort-of-not-quite like what I just described, e.g. a SOCKS proxy. But
the one I'm thinking of as I write this is CONNECT tunnels:

https://wiki.squid-cache.org/Features/HTTPS

These sorts of tunnels (ab)use a HTTP(S) forward-proxy to establish
outbound TCP connections (which, if you care about security, will carry TLS
encrypted traffic).

This approach is partly described in RFC 2817[2], but to tick all of the
checkboxes on the points I mentioned earlier using this method, you need to
implement features in draft-luotonen-web-proxy-tunneling-01[3], which has
never received an RFC and, as far as I can tell, is only properly
implemented by Squid. Using Squid as a TLS-in-TLS tunneling solution seems
less than ideal to me, and yet in many ways it seems like the "least
friction" option, especially for access control purposes.

I would really love a simple, straightforward approach to this problem with
a published RFC instead of an expired draft that's only implemented by
Squid. I also think TLS-in-TLS tunneling can solve this same problem in a
much more straightforward manner.

tl;dr: when making drafts regarding TLS-in-TLS tunneling, please consider
the forward-proxy use case in addition to the reverse-proxy case

[1]: https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/
[2]: https://www.rfc-editor.org/rfc/rfc2817.txt
[3]: https://tools.ietf.org/html/draft-luotonen-web-proxy-tunneling-01

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call: SNI Encryption

[Tony Arcieri]

On Fri, Aug 4, 2017 at 10:39 AM, Adam Langley <a...@imperialviolet.org>
wrote:

> If it wants to be a technical document, then the draft includes two very
> different designs with a note saying that one will be chosen at some point.
> So which are we talking about adopting? While drafts evolve during the WG
> process, there's a big gap between the two ideas and I'd support one but
> not the other.
>

The tunneling mechanism described in Section 4.1 seems useful (at least to
me) for more things than encrypted SNI, such as being able to use different
TLS extensions for the frontend load balancer versus a backend service,
while still eventually negotiating an end-to-end encrypted session with the
backend service.

I wonder if the draft should be framed around the TLS-in-TLS tunneling
mechanism, with encrypted SNI as a potential use case.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Tony Arcieri]

On Wed, Jul 19, 2017 at 6:09 AM, Benjamin Kaduk <bka...@akamai.com> wrote:

> As Stephen noted in his presentation, a lot of the proposals for passive
> decryption can be seen as trying to turn TLS from a two-party protocol into
> a three-party protocol.  Which is probably the right way to think about it,
> even when all (three) parties are within the same administrative domain.
>
> Stephen also said something about it being hard to shoehorn a three-party
> protocol into the API for a two party protocol.
>

Trying to turn a two-party protocol into a three party protocol is a
classical source of confused deputy vulnerabilities:

http://www.hpl.hp.com/techreports/2009/HPL-2009-20.pdf

This is why I have been such a strong proponent of using something like a
TLS extension for this sort of thing if it is to happen. At least that way
we get mutual client and server consent.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Tony Arcieri]

On Sat, Jul 8, 2017 at 11:17 AM Russ Housley <hous...@vigilsec.com> wrote:

> I want to highlight that draft-green-tls-static-dh-in-tls13-01 does not
> enable MitM.  The server does not share the signing private key, so no
> other party can perform a valid handshake.
>

This method allows a middlebox to recover the plaintext of a TLS session.
While I took issue with Stephen's attempts to shut down conversations this
line of inquiry, I have a much, much stronger objection to downplay the
fact that this is still a self-inflicted MitM attack.

Let me be very clear: full plaintext recovery by a passive middlebox
absolutely is "MitM". Just because it does not allow full impersonation of
the server does not make it MitM. It is MitM, and we should be very clear
it is MitM.

Further, the server is choosing to use a (EC)DH key that was generated by
> the key manager, so it is quite different than the mandatory key escrow used
> in the Clipper Chip.
>

It enables the same ends: recovery of session plaintexts, and as I stated
on other threads I would personally prefer a more explicit key escrow
mechanism implemented as a TLS extension, which to some degree would
actually look a bit more like LEAP.

> --
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Tony Arcieri]

On Fri, Jul 7, 2017 at 6:02 AM, Richard Barnes <r...@ipv.sx> wrote:

> You could avoid changing how the DH works altogether by simply exporting
> the DH private key, encrypted with a key shared with the monitoring device,
> in a server extension.  (Not in EncryptedExtensions, obviously.)  This
> would also have the benefit of explicitly signaling when such monitoring is
> in use.  The only real challenge here is that the client would have to
> offer the extension in order for the server to be able to send it, which I
> expect things like browsers would be unlikely to do.  However, given that
> the target of this draft seems to be intra-data-center TLS, perhaps this is
> a workable requirement?
>

I very much like the property that by using an extension, the client must
consent to being MitMed.

But in this case, why not just keywrap the session master secret with a
preshared KEK as opposed to exfiltrating the DH private key?

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Tony Arcieri]

On Sat, Jul 8, 2017 at 8:44 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie>
wrote:

> On 08/07/17 16:39, Tony Arcieri wrote:
> > Clearly there are echoes of the scary protocols of yesteryear, i.e.
> > Clipper/LEAP. I think if you visit Matt Green's Twitter page and check
> the
> > image header you will discover he is quite familiar with these things,
> and
> > my personal presumption would be he is not displaying this image to show
> > his undying love of the Clipper chip, although perhaps he's an especially
> > crafty and duplicitous NSA sleeper agent.
> >
>
> Reputations are irrelevant to how we evaluate this, though
> I guess can be affected by the drafts one co-authors.
>
> The relevant draft is proposing a wiretapping API for TLS.
>
> That's inconsistent with RFC2804 no matter who proposes it.


Perhaps you should respond to the other two paragraphs in my message?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Tony Arcieri]

I was one of the people arguing my hardest against the BITS Security
proposal to continue to (ab)use RSA static keys to allow passive MitM, even
though TLS 1.3 had already moved forward on what I would call a more modern
protocol design of the sort I believe payments companies should embrace to
improve their security.

That said, if people do want to MitM themselves, I would rather there be a
single, easily detectable and very explicit way of doing so, as opposed to
sketchy, incompatible, ad hoc mechanisms. Furthermore, it would be nice to
have a clear answer for these users, less they continue to make (bad)
arguments that there is something fundamentally wrong with the design of
TLS 1.3 that makes it incompatible with "industry requirements".

Clearly there are echoes of the scary protocols of yesteryear, i.e.
Clipper/LEAP. I think if you visit Matt Green's Twitter page and check the
image header you will discover he is quite familiar with these things, and
my personal presumption would be he is not displaying this image to show
his undying love of the Clipper chip, although perhaps he's an especially
crafty and duplicitous NSA sleeper agent.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

[Tony Arcieri]

On Mon, Feb 13, 2017 at 3:21 PM, Aaron Zauner <a...@azet.org> wrote:

> I thought the cited paper sorted this out like a year ago.
>
> In favor of option a


I am also in favor of option A.

The wording in option B is simultaneously much more unclear and much more
verbose. I consider it a regression.

Option C is more similar to option A, but not an improvement, IMO.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Tony Arcieri]

On Fri, Dec 2, 2016 at 7:57 PM, Scott Schmit <i.g...@comcast.net> wrote:

> This draft has been in development since April 2014, 2.6 years ago.
> Over that time, the wire protocol has changed multiple times and
> incompatibly.  So not even all of that 2.6 years of details is still
> applicable to the protocol we're going to publish as an RFC.  So why
> would mixing up searched for the final protocol with the draft versions
> be a good thing?
>

The wire format is one thing, but there is work that has been done at a
much higher level referencing "TLS 1.3", e.g. TRON work:

http://prosecco.gforge.inria.fr/personal/karthik/pubs/proscript-tls-tron-2016.pdf


> The volume of work that will be published in the hopefully 18 or more
> years that this draft is in deployment will dwarf the current body of
> work.  If it doesn't, then we will have completely failed.


While more security analysis against whatever-the-new-TLS-is-called will
certainly happen, I would imagine it would be split against
whatever-the-next-TLS-version-is-called. And the thing is, a lot of the
extant research about "TLS 1.3" is fantastic, so much so that I think it
will be routinely cited. Certainly there will be new research, but much of
the groundwork has already been laid.

>From what I can tell, the main argument for changing the version is to
*reduce confusion*. I am incredibly unconvinced rebranding TLS 1.3 to TLS
4/2017/9000 will actually accomplish the intended goal.

A recent example of what sort of confusion I could see arise: ECMAScript.
They moved from a numbered branding (ES6/ES7) to a year-based branding
(ES2016/ES2017). People continue to use both, so now you have to maintain a
mental mapping of which-version-to-which-year.

The optimal solution to me as far as reducing these sort of mental
gymnastics goes is to keep the version as "TLS 1.3" and drop the 1.x in the
next release. This gets the "TLS 4" advocates what they want, just not
right away, without renaming the current release at the last minute.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Tony Arcieri]

On Thu, Nov 17, 2016 at 6:12 PM, Sean Turner <s...@sn3rd.com> wrote:

> The consensus in the room was to leave it as is, i.e., TLS1.3, and to not
> rebrand it to TLS 2.0, TLS 2, or TLS 4.  We need to confirm this decision
> on the list so please let the list know your top choice between:
>
> - Leave it TLS 1.3
> - Rebrand TLS 2.0
> - Rebrand TLS 2
> - Rebrand TLS 4
>
> by 2 December 2016.


I guess we're at the deadline, but I have a compromise I think makes sense:

- Keep this version TLS 1.3
- For the next version of TLS, drop the 1.x and call it TLS 4

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Tony Arcieri]

On Fri, Dec 2, 2016 at 1:21 PM, Peter Gutmann <pgut...@cs.auckland.ac.nz>
wrote:

> The change was proposed long ago, and deferred by the chairs until now.
> This
> is just another variant of the inertia argument.


You keep dismissing this argument out of hand, but I think it has merit.

I think we can all admit the decision to rename SSL -> TLS is a mistake (to
the point people are proposing to retroactively re-rename TLS back to SSL).

There is now a huge body of work which calls the protocol "TLS 1.3" which
will be cited for years to come. You wrote this whole body of work off as
the concern of "TLS WG and a small number of people who interact with it"
as if a move to a different version number comes at zero cost almost as if
this work doesn't matter, but I have a different view: this is one more bit
of errata in exactly the same vein as the SSL -> TLS move which anyone
consulting this body of work will have to contend with.

You will no doubt disagree, so I'm simply saying it for posterity: keeping
the version TLS 1.3 is the least confusing option, IMO.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Tony Arcieri]

On Wed, Nov 30, 2016 at 8:43 PM, Viktor Dukhovni <ietf-d...@dukhovni.org>
wrote:

> > I actually completely agree with Timothy Jackson's recent posting:
> >
> >   After 15 years, everyone but us still calls it SSL. We need to
> >   admit that we lost the marketing battle and plan for a world where
> >   everyone calls “TLS X” “SSL X”. Even “new” implementations call
> >   themselves “LibreSSL” and “BoringSSL” rather than “LibreTLS” or
> >   “BoringTLS”.
>
> I'll drink to that!


I will also +1 this and add that if the goal is to reduce confusion, a last
minute renaming of TLS 1.3 to something else probably won't accomplish
that, but will rather create more confusion. There's already ample material
out there (papers, presentations, mailing list discussions, etc) which
talks about "TLS 1.3". Rebranding it now would add an additional bit of
errata everyone needs to learn if they ever encountered the "TLS 1.3"
version in any of these materials. And I think the whole SSL/TLS thing is
errata enough.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Tony Arcieri]

I am a big fan of leaving it as TLS 1.3.

It feels more like evolution than revolution, even with the addition of
0-RTT. I would like to see a future TLS 2.0, but one that makes fundamental
changes which didn't make the cut for 1.3, e.g. moving to OPTLS.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Tony Arcieri]

On Mon, Oct 3, 2016 at 2:21 PM, BITS Security <bitssecur...@fsroundtable.org
> wrote:

> If PCI has mandated upgrading TLS because of vulnerabilities, they are
> likely to do it again and in fact have provided strong hints to the market
> where they should be beyond the minimum requirement itself.


This is simply not true. In 2015 the PCI council was pushing for updating
to TLS 1.1+ in short order, but backed off out of "industry concerns"
similar to the ones you are voicing here, and have delayed the mandatory
rollout of TLS 1.1 until 2018.

That's at least two years away.

After that, they will deprecate TLS 1.1. That will probably take at least a
year. So in 2019 (again, pure speculation as to the earliest time this will
possibly happen), TLS 1.2 will be mandatory.

After that, they may deprecate TLS 1.2 if it is demonstrated to be
insecure. There is no reason to suspect at this point that that will even
happen. TLS 1.2 is generally recognized as secure, and the "LTS" profile
should fix whatever low-priority security concerns remain.


> I don't see that the timing really matters because it isn't based on the
> age of the standard, it is based on the standard becoming outdated.


That is absolutely not true. The PCI's motivation for TLS version upgrades
has been real-world security vulnerabilities, and again, it took them 15
years to deprecate TLS 1.0.

There is absolutely no evidence that the PCI council plans on making TLS
1.3 mandatory any time soon, and if we follow a version-a-year cadence
(which they're NOT presently working on, based on the one deprecation data
point we have it's ~3 years per version) it will be 2020 at the earliest
before it happens.

You are asking the IETF to make a serious compromise regarding the security
of the Internet based on *pure speculation*. A minimum degree of due
diligence here would be to first ask the PCI council what their plans for
mandating TLS 1.3 actually are, and if they *actually* give you a date that
scares you, that might be a reason to voice concern so late in the process.

I think what you're proposing is actively harmful to Internet security and
you should be working with the PCI Council, not the IETF, to address your
concerns.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Tony Arcieri]

On Wed, Sep 28, 2016 at 5:49 PM, Melinda Shore <melinda.sh...@nomountain.net
> wrote:

> I think it's quite clearly the case that that is not going to happen.
> But, that doesn't mean that these guys don't have a problem worth
> addressing, even if they're asking for a crap solution to it.  The
> IETF is an insular organization and I tend to think that leads to
> poorer outcomes in some cases than we might otherwise have produced.


Their argument is the PCI council will mandate TLS 1.3 soon. This is not
the case. A TLS *1.1* mandate by the PCI council has been delayed until
2018.

I work for a company that directly participates in the PCI council, and
have been participating in the TLS and CFRG process for several years
(again, I do not directly represent either in this discussion).

I do not think that TLS 1.3 in its current form will cause them any
practical real-world problems for these companies, rather they seem to be
attempting to futureproof their current bad practices.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Tony Arcieri]

On Wed, Sep 28, 2016 at 4:27 PM, Melinda Shore <melinda.sh...@nomountain.net
> wrote:

> We have poor participation and representation from
> enterprise networks.  So now we've got someone showing up from
> the enterprise space and saying "I have this problem related to
> protocol changes."  And yeah, he's very, very late in this
> process, although it's worth pointing out that it's in the best
> tradition of the IETF to deal with technical problems that crop
> up with documents at any point in their development.


"BITS Security" is representing *some* companies in the payments space,
namely these ones: http://fsroundtable.org/members/

Their concerns are not representative of "the enterprise", "the industry",
"the payments space", etc. In fact some of the companies in the
aforementioned link have personally contacted me to note they disagree with
"BITS Security". Even among their cabal, their opinion is contentious.

My personal opinion, as a security professional directly working on
implementing TLS for a payments company, is their last-minute proposed
changes would harm the security of our payments platform. I want to deploy
TLS 1.3 in its current form. I also think the reasoning for their proposed
changes is based on flawed premises.

There are relevant industry groups BITS Security seems actually concerned
with, such as the PCI Council. BITS Security should be voicing their
concerns there, and the PCI Council should be working with the IETF to
implement such changes if they're actually deemed necessary.

I do not think this is a case of the IETF failing to understand "industry
requirements". I strongly disagree the proposal represents "industry
requirements" at all. I think they are trying to subvert the IETF process
because they have inadequate security processes and they do not want to see
their inadequate processes disturbed by security improvements to TLS.

As a payments professional, my personal opinion is improving the security
of TLS is *paramount*. The voiced concerns are not representative of
"enterprise", "industry", or "payments" as a whole, but an last-minute
opinion of companies who haven't been paying attention to the process who
do not want to invest in upgrading their security practices.

The IETF is doing great work. This entire thread is a distraction, and I
hope it does not result in changes which weaken TLS 1.3's security.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Tony Arcieri]

On Mon, Sep 26, 2016 at 12:01 PM, BITS Security <
bitssecur...@fsroundtable.org> wrote:

> The PCI DSS is already requiring TLS 1.2 for financial institutions that
> participate in the Payment Card Industry.  .BANK (exclusive top level
> banking domain) is also planning to require TLS 1.2.   We're anticipating
> that a regulatory body like these will require TLS 1.3 at some point in the
> future.  Financial institutions then have to comply if they want to
> continue to do business with the companies represented by the regulatory
> body (like large credit card companies in the case of PCI).


Hello again,

I work firsthand enforcing these requirements at a payments company. Again,
I do not speak on behalf of my employer.

It wasn't until last year that PCI decided to deprecate TLS 1.0, at the
time a 16 year old standard. I think your sense of emergency is highly
over-exaggerated.

I find it highly unlikely that any group such as the PCI Council will begin
mandating TLS 1.3 any time soon. I would go as far as to call your concerns
"imaginary".

If you are worried about such an eventuality, the IETF is the wrong place
to complain. It is far, far too late in the TLS 1.3 process to be voicing
these concerns. Where were you 2+ years ago when it was the appropriate
time in the TLS development cycle to voice such concerns? I think the view
of more "forward thinking" payments companies is TLS 1.3 has taken too long
already, and they would like to start deploying it in its current form and
would prefer unnecessary holdups/distractions which have already occurred
throughout the process.

That said, there is still plenty of time to ensure that groups like the PCI
Council do not put in place requirements which would affect the centralized
traffic-decrypting MitM-capability on your payments stack. Perhaps you
should be voicing your concerns there? If you are worried about a TLS 1.3
mandate preventing your MitM capability, the onus is on you to convince the
relevant payments standards bodies that mandating TLS 1.3 is a bad idea for
the payments industry. I think those organizations are better poised to
judge whether such an approach reflects on necessary requirements versus
pervasive antipatterns among complacent companies unprepared for the future
and ripe for a data breach.

In the meantime, you have disclosed a veritable treasure map to a
traffic-decrypting single point of failure which ostensibly exists at all
of the companies you represent which attackers could leverage to recover
all payment credentials. That sounds like a huge security threat.

Would you mind disclosing which companies you represent, so I can ensure
for the safety of my own money that I do not use them?

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Tony Arcieri]

I work in the payments industry, but I am not speaking on behalf of my
employer.

I would like to note that if the approaches outlined in the "BITS Security"
post are the preferred ones for the companies they represent, those
companies have made a huge strategic blunder and should correct those
strategic blunders rather than requiring last-minute major design overhauls
to TLS 1.3 which would weaken its security.

+1000 Kenny Patterson's comments.

On Thu, Sep 22, 2016 at 10:19 AM, BITS Security <
bitssecur...@fsroundtable.org> wrote:

> -  End point monitoring: This technique does not replace the pervasive
> network visibility that private enterprises will lose without the RSA key
> exchange.  Ensuring that every endpoint has a monitoring agent installed
> and functioning at all times is vastly more complex than ensuring that a
> network traffic inspection appliance is present and functioning.  In the
> case of monitoring of supervised employee communications, moving the
> monitoring function to the endpoint raises new security concerns focusing
> on deliberate circumvention - because in the supervision use case the
> threat vector is the possessor of the endpoint.
>

I strongly disagree. Endpoint security is paramount, and some sort of
network MitM system is absolutely not a replacement for endpoint agents. I
would highly suggest deploying agents on your endpoints. If you don't have
endpoint security, all is lost. I would suggest performing multiple
security checks regularly on all endpoints throughout your enterprise.

Modern endpoint agents can work at a level much higher than TLS network
packets (i.e. total memory inspection with kernel-level agents). MitMing
traffic in lieu of deploying an endpoint agent only provides monitoring of
"compliant" packet streams, which are unlikely to be used by either
attackers or insider threats. I'm not saying it's bad to run NIDS or a
rolling packet capture system, these are both great, but again, neither are
a replacement for an endpoint agent.

Until the critical concerns surrounding enterprise security, employee
> supervision, and network troubleshooting are addressed as effectively as
> internet MITM and surveillance threats have been, we, on behalf of our
> members, are asking the TLS 1.3 Working Group to delay Last Call until a
> workable and scalable solution is identified and vetted, and ultimately
> adopted into the standard by the TLS 1.3 Working Group.


If you're relying on MitMing S2S traffic for debugging a payment stack, it
sounds like your payment stack is opaque to you, which is not only a
concern for security, but the general reliable operation of your payment
stack as a whole. As a general recommendation, I would suggest building out
debugging facilities for your payment stack so you know it actually works,
and don't have to lean on crutches like MitMing traffic for debugging
purposes.

While such a crutch may in the short-term make debugging appear easier, it
also assists a patient attacker with internal network access who is
passively capturing traffic before attempting to obtain a decryption key
which would expose payment credentials e.g. cardholder info/PANs, ACH
account numbers, etc.

tl;dr: your suggestions would harm the security of more "forward thinking"
payments companies. Again, my personal opinion, not that of my employer.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Tony Arcieri]

On Thu, Sep 8, 2016 at 8:01 AM, Derek Atkins  wrote:

> So they are finally up to 80-bit security?  Woohoo!
> That makes me feel so safe.
>

1024-bit RSA is certainly less than ideal, but certainly better than
nothing, which was the claim about devices in this class.

Comparisons with symmetric cryptography aren't exactly fungible like that
either: though I personally consider 1024-bit RSA keys to be weak, to my
knowledge one has not been factored successfully by the general public.

Payments are a very poor example..  Several seconds per transaction?
> That's not usable performance.  Look at all the pushback from consumers
> that have been happening since the changeover to chip cards in the US
> this past year.
>

The cryptography is not the bottleneck in this case: poor implementations
of the protocol are. Use the same card for an NFC transaction (provided
it's capable) and the delay will be considerably less.

Also, an asymmetric primitive is something you'd use to exchange keys and
sign transcripts for session initialization, after which all subsequent
communication is symmetric. Does a second of handshaking actually matter if
all subsequent communication is hardware accelerated symmetric
cryptography? (I'm sure it might for some, but won't for many others)

The real point is that if verticals within the "IoT space" were to
standardize on a particular set of asymmetric primitives and ship them en
masse like the payments industry did, economies of scale can drive the
costs down to the levels they deem acceptable. But they seem unwilling to
do the up-front development work and want to continue using the MCUs
they're already using, many of which have no crypto accelerators
whatsoever...
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Tony Arcieri]

On Tue, Sep 6, 2016 at 9:15 PM, Peter Gutmann <pgut...@cs.auckland.ac.nz>
wrote:

> When crypto hardware support is available, it's universally AES,
> occasionally
> SHA-1 and/or DES, and very rarely RSA and/or DH and/or ECDSA


EMV chip cards support RSA digital signatures. Granted earlier EMV cards
used ridiculously small key lengths (i.e. 320-bits), but they have been
gradually ratcheted up to e.g. 768 or 1024-bits.

These cards number in the billions (10s of billions?) and the chips are
priced in the penny range.

I don't think it's impractical to ship hardware accelerated asymmetric
crypto primitives on chips that meet the specifications you're describing.
The payments industry has definitely shown it's possible.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 3DES diediedie

[Tony Arcieri]

On Wed, Aug 24, 2016 at 8:28 PM, Peter Gutmann <pgut...@cs.auckland.ac.nz>
wrote:

> Only if there's an actualy issue.  3DES is still very widely supported
> (particularly in financial systems and embedded)


As someone who works professionally in the payments industry alongside
people who are directly implementing EMV protocols, let me note: those are
not IETF protocols and should not have bearing on IETF/IRTF decisions
regarding deprecations of protocols in TLS or other IETF protocols. But I'm
mainly concerned with TLS...

and provides a useful backup to AES.


So does ChaCha20.


>   An attack that recovers cookie if you can record 785GB of traffic isn't
> anything I'm losing any sleep over.


..but is not a terribly dissimilar traffic volume to recover plaintexts
from similar attacks against RC4, which received "diediedie" in RFC7465.

Perhaps notable is the RC4 attacks work across multiple session keys,
whereas SWEET32 requires the same key, but I think the practical
consequences regarding data volume limits are similar.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Tony Arcieri]

On Wed, Aug 24, 2016 at 7:41 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie>
wrote:

> On 25/08/16 03:34, Tony Arcieri wrote:
> I guess there's sometimes value in those die-die-die RFCs. Given that
> we have RFC7525/BCP195 [1] that already has a SHOULD NOT for effective
> key sizes less than 128 bits, one could argue that the IETF has covered
> that to a reasonable extent, in terms of RFCs saying to not do that.


Yes, aside from the 64-bit block size the the 112-bit (or sometimes
108-bit) key sizes are also notable for 3DES

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Tony Arcieri]

It appears 3DES is not supported in TLS 1.3.

I would still support a "diediedie" RFC banning its use in previous
versions of TLS, despite its previous MTI status.

On Wed, Aug 24, 2016 at 7:34 PM, Tony Arcieri <basc...@gmail.com> wrote:

> On Wed, Aug 24, 2016 at 7:31 PM, Benjamin Kaduk <ka...@mit.edu> wrote:
>
>> Well, there is
>> https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00
>> but it is not really what you are looking for, I think, given the
>> recipient list on the message.
>
>
> I am particularly interested in 3DES's usage in TLS, given its previous
> MTI status in TLS, and because it was until very recently included in the
> OpenSSL "DEFAULT" ciphersuite list.
>
> --
> Tony Arcieri
>



-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Tony Arcieri]

On Wed, Aug 24, 2016 at 7:31 PM, Benjamin Kaduk <ka...@mit.edu> wrote:

> Well, there is
> https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00
> but it is not really what you are looking for, I think, given the
> recipient list on the message.


I am particularly interested in 3DES's usage in TLS, given its previous MTI
status in TLS, and because it was until very recently included in the
OpenSSL "DEFAULT" ciphersuite list.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA

[Tony Arcieri]

It's also worth noting that BERserk is one of many such incidents of this
coming up in practice:
https://cryptosense.com/why-pkcs1v1-5-signature-should-also-be-put-out-of-our-misery/

On Tue, Aug 9, 2016 at 2:13 PM, Tony Arcieri <basc...@gmail.com> wrote:

> On Tue, Aug 9, 2016 at 7:16 AM, Martin Rex <m...@sap.com> wrote:
>
>> BERserk is an implementation defect, not a crypto weakness.
>>
>
> Hence why I phrased the question the way I did. Per Izu, Shimoyama, and
> Takenaka 2006, PKCS#1 v1.5 has sharp edges which implementers must avoid
> (of course, the same can be said of BER in BERserk, and it was clearly the
> bigger of the two problems).
>
> Peter Gutmann's response was the sort of thing I was looking for when I
> originally asked the question.
>
> --
> Tony Arcieri
>



-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA

[Tony Arcieri]

On Tue, Aug 9, 2016 at 7:16 AM, Martin Rex <m...@sap.com> wrote:

> BERserk is an implementation defect, not a crypto weakness.
>

Hence why I phrased the question the way I did. Per Izu, Shimoyama, and
Takenaka 2006, PKCS#1 v1.5 has sharp edges which implementers must avoid
(of course, the same can be said of BER in BERserk, and it was clearly the
bigger of the two problems).

Peter Gutmann's response was the sort of thing I was looking for when I
originally asked the question.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA

[Tony Arcieri]

On Monday, August 8, 2016, Martin Rex  wrote:
>
> The urban myth about the advantages of the RSA-PSS signature scheme
> over PKCS#1 v1.5 keep coming up.
>

Do you think we'll see real-world MitM attacks against RSA-PSS in TLS
similar to those we've seen with PKCS#1v1.5 signature forgery, such as
BERserk?
___
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]

[Tony Arcieri]

On Friday, June 10, 2016, Nikos Mavrogiannopoulos <n...@redhat.com> wrote:

> I'm actually surprised you mention the microsoft servers as being
> version negotiation tolerant. They were the most prominent examples
> of terminating the handshake if TLS 1.2 was offered to them
>

Personally I'd give that award to F5 BIG-IP devices


-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

[Tony Arcieri]

On Sun, May 15, 2016 at 6:50 AM, Aaron Zauner <a...@azet.org> wrote:

> I know that the word "nonce" does have another meaning as well (BTW I'm
> not a native english speaker, as you may have guessed). But do you think
> that is really relevant in this case? If so, could you suggest better
> wording for this specific paragraph?
>

I think "nonce" meaning number used once is fine for cryptographic
purposes.

I'd also note Adam Langley has taken to pronouncing the word nonce as
"n-once", at least at this year's RWC.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Tony Arcieri]

On Mon, Mar 28, 2016 at 3:49 PM, Ryan Hamilton <r...@google.com> wrote:

> ​We (Chrome) definitely want this (sending cookies in 0-RTT requests), and
> are doing this today with QUIC (which we can't wait to TLS 1.3-ify). ​
>

I went to RealWorldCrypto 2016 and saw the TLS track and all of the
analysis TLS 1.3 has received, and while it wasn't TRON, I can sympathize
with why you might want TLS 1.3, namely the extensive analysis it is
receiving as an up and coming cryptographic standard which is a clear
choice for academic researchers to focus on.

That said, I really don't understand Google's excitement to switch from
QUIC's crypto to TLS 1.3. QUIC crypto seems like a much simpler and cleaner
protocol which fulfills many of the same goals as TLS, and while it hasn't
received as much scrutiny as TLS 1.3, it seems like it doesn't need as much
by design due to its relative simplicity.

I also understand Facebook is adding QUIC-crypto-over-TCP support to
proxygen (there was also a talk at RWC2016) for use in their mobile apps as
a stopgap for doing 0-RTT until such a time as 0-RTT ships in TLS 1.3.

Can you speak to specific reasons why the Chrome team "can't wait to TLS
1.3-ify" over QUIC, specifically reasons different from the ones I have
already highlighted above?

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

[Tony Arcieri]

On Monday, March 21, 2016, Dave Garrett <davemgarr...@gmail.com> wrote:

> I don't exactly see a 'T' for "LTS" in "Legacy Support Profile"...  ;)
>

Haha, oops. LSP?


-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

[Tony Arcieri]

On Mon, Mar 21, 2016 at 12:42 PM, Dave Garrett <davemgarr...@gmail.com>
wrote:

> Frankly, I think this document should be renamed "Extended Support
> Profile", rather than "Long-term Support Profile" (and ESP instead of LTS).


Legacy Support Profile? Then you don't have to change the acronym

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] JPAKE

[Tony Arcieri]

On Tue, Feb 16, 2016 at 10:45 PM, Dan Harkins <dhark...@lounge.org> wrote:

> What?!? How is that "better"? Having a "keychain" that loops in some
> vague "secure enclave" that makes authorization decisions based on some
> app deriving a "strong master secret from a weak password/pin" sounds
> complicated


Microsoft:
https://technet.microsoft.com/en-us/library/mt621546(v=vs.85).aspx
Matt Green: https://twitter.com/matthew_d_green/status/699777680728842240
Apple: https://www.apple.com/business/docs/iOS_Security_Guide.pdf (see
also: Matt Green)

Hardware interlocks around authentication allow various anti-brute force,
exponential backoff, and device wiping security measures. They also allow
you to unlock a "full entropy" cryptographic key with some low entropy
mechanism like a PIN without the former being deterministically derived
from the latter.

I personally believe the future of authentication is having a weak
credential which unlocks a strong credential on something you have. This
approach to authentication is generally described as "something you have
and something you know"

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] JPAKE

[Tony Arcieri]

On Mon, Feb 15, 2016 at 4:33 PM, Robert Cragie 
wrote:

> In Thread, it is used for local device authentication and authorisation.
> These use cases clearly benefit from a PAKE, i.e. getting deriving a shared
> cryptographic from a weaker shared password.
>

The better way to solve this problem is a device-specific "keychain", which
possibly loops in some sort of secure enclave for decrypting secrets, and
can authorize secret decryption based on the requesting app, derive a
strong master secret from a weak password/pin (possibly using a PUF for
anti-tamper). This is becoming a standard feature of the OSes on most
devices humans actually physically interact with, e.g. most smartphones,
tablets, and any OS you'd find on a laptop.

If you have this sort of keychain system, you can provision secrets
on-the-fly, e.g. origin-bound certificates. Now you don't need PAKE.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] JPAKE

[Tony Arcieri]

On Mon, Feb 15, 2016 at 4:33 PM, Robert Cragie <robert.cra...@gridmerge.com>
wrote:

> The big assumption here is that SSL/TLS is used solely in browsers.
>

In literally every one of the non-browser SSL/TLS contexts I use today, I
do not use passwords (preferring client certs instead). The main place I'd
actually be interested in using a PAKE in a generalized transport context
would be an IPSEC/IKE context (in addition to a client cert as a second
factor).

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] JPAKE

[Tony Arcieri]

On Mon, Feb 15, 2016 at 11:54 AM, Watson Ladd  wrote:

> PAKE in SSL has always been a solution in search of a problem.
>
Browsers do not have UI elements compatible with PAKE (unless someone cares
to bring up the basic auth dialog, in which case I'd simply suggest please
don't)

Brian Warner's "Magic Wormhole" use case seems like something of a killer
app for PAKE, but that's clearly a non-SSL context.

PAKE in SSL seems to be in need of new browser standards which are probably
unlikely to happen. I think "passwordless" standards like FIDO UAF/U2F
which offer a better user experience are far more likely to see browser
support.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

[Tony Arcieri]

On Mon, Jan 11, 2016 at 9:32 PM, Viktor Dukhovni <ietf-d...@dukhovni.org>
wrote:

> > No MD5 function should remain in the relevant codebase;
>
> In particular the IETF does not get to tell anyone which functions
> they get to include in their codebase.  So no IETF document saying
> such a thing makes much difference.


Not being the person who called "diediedie", but being in total agreement
with the OP, "diediedie" should represent a "burn notice" from the IETF to
all implementers:

DO NOT DO THIS!!!

Clearly many TLS stacks still implement MD5, and there are no TLS police to
arrest the people who are ignoring the IETF RFCs and still shipping
diediedie-filled crypto, but if we want any modicum of security want any
sort of security guarantees from TLS, all stacks *MUST* abandon MD5 in its
entirety.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Forward secrecy with resumption, and 0-RTT security

[Tony Arcieri]

On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox <waywardg...@google.com> wrote:

> In the past, there were two cases: resumption using session IDs, and
> resumption with session tickets.  Using session IDs loses forward secrecy,
> because the server always has session keys in a session cache, which could
> be used to decrypt the prior sessions.  Using tickets did not work either,
> because the server always kept a ticket decryption key which could be used
> to decrypt all resumed sessions since the key was last rotated.
>
> My first question is: Do we care?
>

At least for session tickets, I don't care. There's a simple enough way to
solve that problem: rotate the session ticket key every few days.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dumb thoughts for hardware backed keys for AEAD

[Tony Arcieri]

On Mon, Nov 30, 2015 at 7:07 PM, Bill Cox <waywardg...@google.com> wrote:

> However, there are overhead costs for moving data in/out of these
> execution zones, and overhead when switching back and forth.  Execution
> speed is a little slower in these modes for various reasons.  For maximum
> speed, I might want a separate HMAC/HKDF key besides the read/write keys.
> That way, I keep just the HMAC/HKDF key in a secure execution zone, and
> only have to do one small operation with it per AEAD call per TLS record.
>

Have you measured the overhead of performing just the private key
operations of TLS using a key stored in an SGX enclave versus the same
operations outside an SGX enclave? I'd be curious what the actual
performance impact is.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] bikeshed: Forward Security or Secrecy?

[Tony Arcieri]

On Mon, Nov 30, 2015 at 8:09 PM, Hugo Krawczyk <h...@ee.technion.ac.il>
wrote:

> The more common term is "forward secrecy"
>

I'd second this. I'm also a fan of Dan Bernstein's recommended term: "key
erasure"

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Tony Arcieri]

On Sat, Nov 28, 2015 at 10:05 AM, Roland Zink <rol...@zinks.de> wrote:

> Am 28.11.2015 um 17:56 schrieb Henrick Hellström:
>
>> AFAIK, HTTP 1.1 browsers typically don't send a new request over an open
>> connection, before it has received the response to the previous request. If
>> that is the case, it is trivial to get the message lengths from the
>> traffic, with or without encrypted TLS record headers. IOW you gain nothing
>> by encrypting the length fields.
>>
>> I think this is what browsers do by default. For HTTP2 this should be
> different.


This is HTTP/1.1 pipelining, which is supported by most browsers but
typically disabled by default as most servers don't support pipelining
correctly.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Data limit for GCM under a given key.

[Tony Arcieri]

On Friday, November 6, 2015, Watson Ladd <watsonbl...@gmail.com> wrote:

> On Wed, Nov 4, 2015 at 3:43 PM, Dang, Quynh <quynh.d...@nist.gov
> <javascript:;>> wrote:
> > I did not talk  under indistinguishability framework. My discussion was
> about confidentiality protection and authentication.
>
> What is the definition of "confidentiality protection" being used here?
>

I too am confused by Quynh's statement. Indistinguishability is the modern
bar for confidentiality and authentication.

Quynh, are you talking about anything less than IND-CCA2? If you are, that
is less than the modern bar I would personally consider acceptable.


-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Tony Arcieri]

On Sun, Oct 4, 2015 at 10:58 AM, Jeffrey Walton <noloa...@gmail.com> wrote:

> > The takeaway for me is you can't mix compression, any fixed value an
> > attacker wishes to learn, and attacker-controlled data, or there will be
> a
> > compression side-channel.
>
> Is that necessarily true?
>
> Deflate violates semantic security by allowing the attacker to gain
> information across messages (even though any single message is
> secure). So perhaps its the mode of compression ot the way compression
> was implemented, and not compression itself.


The only property of compression that this class of side-channel attack
relies on is that the compression algorithm produces a smaller output for
message a || a than a || b (where a and b are of identical length), so
really it would seem to be a conceptual problem with mixing compression and
encryption.

If someone has produced a secure system for "compression side-channel
resistant encryption", I haven't seen it.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Tony Arcieri]

On Sat, Sep 19, 2015 at 12:04 PM, Daniel Kahn Gillmor <d...@fifthhorseman.net
> wrote:

> I think we should remove compression and we should also explicitly warn
> users of the protocol about the risks of combining compression with TLS.


+1

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Tony Arcieri]

On Tuesday, September 1, 2015, Blumenthal, Uri -- 0553 -- MITLL <
u...@ll.mit.edu> wrote:

> But IANAL (I Am Not A Lawyer)... I *can* understand vendors who would hold
> until either an explicit IPR release is posted, or the (potentially!)
> relevant patents expire.
>
> Then those hypothetical people should use RSA signatures and FFDHE key
exchange


-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Tony Arcieri]

On Friday, August 28, 2015, Dang, Quynh quynh.d...@nist.gov wrote:

 People who don't use DSA, then they don't use DSA. People who use DSA
 right, it should be fine for them to use DSA.

Can you name one of these people? If not, you seem to be arguing for
including legacy protocols with no real-world use case in mind.

In absence of real-world use cases, removing legacy baggage from TLS
reduces attack surface and makes things easier for implementers.


-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1

[Tony Arcieri]

To respond more specifically to your concerns:

On Wed, Jul 15, 2015 at 6:42 PM, Rene Struik rstruik@gmail.com wrote:

 It seems prudent to keep some diversity of the gene pool and not only have
 curves defined over prime curves. Similarly, one should perhaps have some
 diversity of gene pool criteria within the set of recommend curves and not
 only include special primes. Should some problem with a particular subclass
 show up over time, one then at least has other classes available.


Binary curves in particular are showing warning signs of potential future
security issues:

https://eprint.iacr.org/2015/310.pdf

I think even if we don't completely pare down the TLS curve portfolio to
the list I suggested, if nothing else I would like to see binary curves
removed.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls