Re: [TLS] Enforcing Protocol Invariants

2018-11-09 Thread Eric Mill 
On Thu, Nov 8, 2018 at 9:31 PM Ryan Carboni  wrote:

> On Thursday, November 8, 2018, Eric Rescorla  wrote:
>
>>  It's also worth noting that in practice, many sites are served on
>> multiple CDNs which do not share keying material.
>>
>
> Encrypting common knowledge is cargo cult fetishism for cryptography. The
> files could be sent unencrypted, and protected using subresource integrity.
> If you are sharing the same data to multiple second parties to serve to a
> single third party, the value of encryption is less than zero.
>

This misunderstands the utility and deployability of SRI. SRI is based on
hashing data exactly, and so sites can only practically use it for files
that do not change (e.g. jQuery x.y.z) and not services that do change
(e.g. an analytics service, or really any live service). Encryption in
transit for public files, between services operated by separate entities,
is a practical necessity to preserve integrity.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

2018-07-09 Thread Eric Mill 
If we're looking for precedent and support, the Canadian government
recently (like in the last week or two) issued a policy requiring TLS 1.0
and 1.1 be disabled:

https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html

It's effective immediately for new services, and has a deadline of
September 30, 2019 for existing services.

-- Eric

On Mon, Jul 9, 2018 at 3:02 PM Loganaden Velvindron 
wrote:

> On Mon, Jul 9, 2018 at 8:54 PM, Eric Rescorla  wrote:
> > Thanks for writing this.
> >
> > I would be in favor of deprecating old versions of TLS prior to 1.2.
> Firefox
> > Telemetry shows that about 1% of our connections are TLS 1.1 (on the same
> > data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible.
> >
> > This is probably a higher number than we'd be comfortable turning off
> > immediately, but it is probably worth starting the process.
> >
>
> I'm also in favour. Many banks/instituion in developing countries are
> moving to deprecate tls v1.0 and tls v1.1.
>
> As I commented on github:
> SSLpulse shows how many top websites support tls 1.2 (92.8%) and this
> number is increasing (0.5%):
>
> https://www.ssllabs.com/ssl-pulse/
>
> KeyCDN and digicert have also announced their intentions to deprecate
> tls 1.0 and tls 1.1.
>
>
> https://github.com/sftcd/tls-oldversions-diediedie/commit/a0d6c160d922bd7f52a917884823114c90932291
>
>
>
> > -Ekr
> >
> >
> > On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty
> >  wrote:
> >>
> >> Hello,
> >>
> >> Stephen and I posted the draft below to see if the TLS working group
> >> is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
> >> been a recent drop off in usage for web applications due to the PCI
> >> Council recommendation to move off TLSv1.0, with a recommendation to
> >> go to TLSv1.2 by June 30th.  NIST has also been recommending TLSv1.2
> >> as a baseline.  Applications other than those using HTTP may not have
> >> had the same reduction in usage.  If you are responsible for services
> >> where you have a reasonable vantage point to gather and share
> >> statistics to assess usage further, that could be helpful for the
> >> discussion.  We've received some feedback that has been incorporated
> >> into the working draft and feelers in general have been positive.  It
> >> would be good to know if there are any show stoppers that have not
> >> been considered.
> >>
> >> https://github.com/sftcd/tls-oldversions-diediedie
> >>
> >> Thanks in advance,
> >> Kathleen
> >>
> >>
> >> -- Forwarded message --
> >> From:  
> >> Date: Mon, Jun 18, 2018 at 3:05 PM
> >> Subject: New Version Notification for
> >> draft-moriarty-tls-oldversions-diediedie-00.txt
> >> To: Stephen Farrell , Kathleen Moriarty
> >> 
> >>
> >>
> >>
> >> A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt
> >> has been successfully submitted by Stephen Farrell and posted to the
> >> IETF repository.
> >>
> >> Name:   draft-moriarty-tls-oldversions-diediedie
> >> Revision:   00
> >> Title:  Deprecating TLSv1.0 and TLSv1.1
> >> Document date:  2018-06-18
> >> Group:  Individual Submission
> >> Pages:  10
> >> URL:
> >>
> >> https://www.ietf.
> .org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt
> >>
> >> Status:
> >>
> https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/
> >> Htmlized:
> >> https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00
> >> Htmlized:
> >>
> >>
> https://datatracker.ietf.org/doc/html/draft-moriarty-tls-oldversions-diediedie
> >>
> >>
> >> Abstract:
> >>This document [if approved] formally deprecates Transport Layer
> >>Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves
> >>these documents to the historic state.  These versions lack support
> >>for current and recommended cipher suites, and various government and
> >>industry profiiles of applications using TLS now mandate avoiding
> >>these old TLS versions.  TLSv1.2 has been the recommended version for
> >>IETF protocols since 2008, providing sufficient time to transition
> >>away from older versions.  Products having to support older versions
> >>increase the attack surface unnecessarily and increase opportunities
> >>for misconfigurations.  Supporting these older versions also requires
> >>additional effort for library and product maintenance.
> >>
> >>This document updates the backward compatibility sections of TLS RFCs
> >>[[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1.  This
> >>document also updates RFC 7525.
> >>
> >>
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> The IETF Secretariat
> >>
> >>
> >>
> >> --
> >>
> >> Best regards,
> >> Kathleen
> >>
> >> _

Re: [TLS] Breaking into TLS to protect customers

2018-03-19 Thread Eric Mill 
On Mon, Mar 19, 2018 at 9:23 AM, Yoav Nir  wrote:
[snip]

> > On 19 Mar 2018, at 7:32, Daniel Kahn Gillmor 
> wrote:
> > So if this technology were deployed on a network where not all parties
> > are mutually trusting, it would offer network users a choice between
> > surveillance by the network on the one hand (opt-in) and censorship on
> > the other (opt-out and be blocked).  Is that right?
>
> I see it a little differently. Your computer or my computer, both of which
> are not configured to opt-in, should not be on such networks. In the
> corporate world, there could be a production network that enforces this and
> has access to corporate resources. There will usually also be a “guest”
> network with unfiltered connectivity, but no access to internal databases..
> This is where visitors go, but also where employee phones connect.
>
> Of course the government of Elbonia might require all networks to have
> this feature, and then you’ll have to decide if you want to configure your
> laptop to opt-in.  I would prefer to stay off-line while I’m in Elbonia in
> that case.
>

That seems like notably less of an option for the citizens of Elbonia.

-- Eric
-- 
konklone.com | @konklone 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Breaking into TLS to protect customers

2018-03-18 Thread Eric Mill 
On Sun, Mar 18, 2018 at 12:09 PM, Darin Pettis  wrote:

> Agreed.   I know a lot of good work has gone into TLS 1.3 and having
> visibility to the data once it hits the data center seems like a new
> capability to the good folks working that have had TLS 1.3 in mind for the
> last couple years.   But to enterprises, they have visibility to their data
> today and have become dependent on that visibility to utilize security and
> troubleshooting tools.
>
> This actually speaks to the fact the there is a different use case for the
> Internet vs the data center.  Hopefully we can agree on that point.
>

We maybe can agree that enterprises feel they have become dependent on
their current set of security and troubleshooting tools, which rely on passive
decryption for visibility. That doesn't mean that that the enterprise is
actually dependent on that current set of tools.


> Additionally, bad actors will have the ability to utilize TLS 1.3
> decryption for command and control and data exfiltration purposes.
> Security services need to see the data to combat that.
>

Passive decryption is not necessary to do this. Active
decryption/termination can also accomplish this, where all outbound network
traffic is required to pass through trusted proxies -- an active approach
is necessary anyway to actually stop data from being exfiltrated.
Presumably stopping the data is superior to just being able to see it
leaving later when looking through forensics.


> Finally, I wanted to make the clear that we utilize the term "visibility"
> because it is the correct term for the outcome that is needed - regardless
> of the technology solution that enables it.
>

Totally agree, though it's still not obvious why the tools to enable this
don't already exist.

-- Eric


>
> Thanks,
> Darin
>
> On Thu, Mar 15, 2018 at 2:50 PM, Ackermann, Michael 
> wrote:
>
>> Good point Yoav.
>>
>>
>>
>> And this positive side effect holds true in the health care and insurance
>> industries as well,  and is not an accident.  It is one of the primary
>> reasons this monitoring is performed.
>>
>>
>>
>> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Yoav Nir
>> *Sent:* Thursday, March 15, 2018 12:58 AM
>> *To:* Rich Salz 
>> *Cc:* tls@ietf.org
>> *Subject:* Re: [TLS] Breaking into TLS to protect customers
>>
>>
>>
>> Hi, Rich.
>>
>>
>>
>> You are conflating customers and users. The customer that may be
>> protected by breaking TLS in a bank’s server farm is the bank itself. An
>> IPS system with visibility into the traffic may detect bots that are there
>> to steal data or mine cryptocurrencies or whatever.
>>
>>
>>
>> If the customers of the bank are protected, it’s a happy side effect
>> (collateral benefit?). The object is to protect the system integrity and
>> the data.
>>
>>
>>
>> Yoav
>>
>>
>>
>> On 15 Mar 2018, at 5:29, Salz, Rich  wrote:
>>
>>
>>
>> Some on this list have said that they need to break into TLS in order to
>> protect customers.
>>
>>
>>
>> The thing customers seem to need the most protection is having their
>> personal data stolen.  It seems to happen with amazing and disappointing
>> regularity on astounding scales.  Some examples include
>>
>> · retailer Target, presumably subject to PCI-DSS rules
>>
>> · Anthem health insurance, presumably a regulated industry
>>
>> · Equifax, a financial-business organization (but apparently not
>> regulated)
>>
>> · Yahoo, a company created on and by and for the Internet (one
>> would think they know better)
>>
>> We could, of course, go on and on and on.
>>
>>
>>
>> NONE of those organizations are using TLS 1.3.
>>
>>
>>
>> So what kind of “protect the customer” requires breaking TLS?  And what
>> benefits and increased protection will customers see?
>>
>>
>>
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>>
>> The information contained in this communication is highly confidential
>> and is intended solely for the use of the individual(s) to whom this
>> communication is directed. If you are not the intended recipient, you are
>> hereby notified that any viewing, copying, disclosure or distribution of
>> this information is prohibited. Please notify the sender, by electronic
>> mail or telephone, of any unintended receipt and delete the original
>> message without making any copies.
>>
>> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
>> nonprofit corporations and independent licensees of the Blue Cross and Blue
>> Shield Association.
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>


-- 
konklone.com | @konklone 
___
TLS mailing li

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

2017-07-10 Thread Eric Mill 
On Mon, Jul 10, 2017 at 6:07 PM, Russ Housley  wrote:
>
> >> So, I failed to convince you.  However, you have also failed to
> >> convince me that the proposal is wiretapping under the definition in
> >> RFC 2804, Section 3.
> >
> > Consider SMTP/TLS. Where one MTA on the path supports this.
> > Say it's one operated by an anti-spam company for example.
> > That is clearly not the sender nor recipient.
> >
> > That meets all 4 points in 2804, right?
>
> You are pointing to email.  Some MTAs will use SMTP over TLS, but many
> others do not.  It would be great if they all do, especially for the
> authentication.  In your response you are talking about an email system
> that has been using plaintext for ages, and you are trying to apply
> hop-by-hop a mechanism to the delivery.  Then, you are saying that the
> sender and receiver have confidentiality expectations that are being
> violated.  I do not buy it.
>

It seems like a weak counterargument to say that because there remain areas
where mail servers don't use TLS, that senders and receivers have no
expectation of confidentiality with email at all. Are you really saying
that if an MTA used this static-DH draft version of TLS to maintain keys to
decrypt email traffic, despite it only being "intended" for enterprise use,
that it wouldn't be wiretapping?

What about if/when MTA STS[1] is implemented? Will MTA adoption have to hit
100% before it's suddenly wiretapping for any given MTA to surreptitiously
use the static DH version of TLS that was "intended" only for enterprise
use?

-- Eric

[1] https://tools.ietf.org/html/draft-ietf-uta-mta-sts-06


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



-- 
konklone.com | @konklone 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2017-07-09 Thread Eric Mill 
On Sun, Jul 9, 2017 at 2:04 AM, Colm MacCárthaigh  wrote:

>
> On Sat, Jul 8, 2017 at 9:27 AM, Watson Ladd  wrote:
>>
>> > They also don’t want to install TLS proxies all over the place.  That’s
>> a
>> > large extra expense for them.
>>
>> Nginx exists. What's the blocker?
>
>
> Here's how these networks work today:
>
> * Key servers are configured to use RSA KX, no DH.
> * In some cases, all outbound (e.g. internet) connectivity is also proxied
> via such a server. Clients are made to trust a private CA for this purpose.
> * All data is not necessarily logged or stored somewhere, and almost
> certainly not in the plain, as that would increase over-all risk.
> * Admins use port-mirrors and tools like tcpdump to investigate/scan
> suspicious flows from time to time, or as part of a targeted investigation.
> Occasionally it might also be used for debugging. The RSA keys can be used
> to render the connections plain on demand.
> * That doesn't mean that the RSA private keys are readily available, they
> are often very tightly controlled.
>
> Migrating to proxies would:
>
> * Be a very big operational change. Gotta get nginx on all of the boxes,
> is that even possible?
>

That's an oversimplification - proxying traffic should require addition of
points in the middle, but shouldn't (always) require modification of the
source and destination points.

But yes, it would be a big operational change. I don't think the folks
arguing that proxies can handle this are suggesting it's trivial to migrate
in this direction.


> * Completely change the access mechanisms, invalidate almost all of the
> operational controls.
>

Why wouldn't these be improvements? (More below.)


> * Probably more than double the basic compute costs associated with
> encryption.
>

Perhaps, but also probably more than doubles the cost to attackers, by
granting forward secret properties to internal traffic and by removing the
number of places where keys exist that are capable of decrypting this data.

* Create more sensitive environments where plaintext is floating around.
>

I don't see how that follows. In a previous message, Jacob Hoffman-Andrews
included a great description of why it should reduce the amount of access
to sensitive keys that can produce plaintext:

I would also point out that retrospectively decrypting pcaps asks TLS to do
double duty: as at-rest encryption in addition to transit encryption. If,
instead, each TLS server shares a copy of its plaintext via a TLS
connection to an encrypted storage service, the enterprise gets much better
security properties. Not only does it retain forward secrecy for
in-datacenter traffic, it can control the keys for at-rest data much more
tightly. Instead of every TLS frontend having the keys for retrospective
decryption, those keys can be limited to auditors or security team members.



> That doesn't mean that these vendors/operators are owed a solution, or an
> easy-to-insert more-or-less-compatible-with-today mechanism. But it does
> help assess whether they are really likely to adopt TLS1.3 to begin with.
>

That's quite fair. However, what's so far been unstated is that it's
plausible for regulatory pressure to eventually build to push regulated
enterprises towards TLS 1.3 and away from 1.2.

It's also quite plausible that regulatory pressure could eventually build
to push agencies to use encrypted traffic with forward secret properties
within their data centers, for the same reasons that it's unacceptable
today to send plaintext around.

This WG is responsible for making the strongest protocol possible, and it's
up to the rest of the world how to use it. TLS 1.3 looks likely to be
extremely widely used on the public internet. If enterprises end up staying
behind on TLS 1.2 inside their networks, or making their own non-standard
alternative, because they can't summon the will to get away from
network-based monitoring, they're likely to face costs for doing that
eventually, whether regulatory or just in the ongoing overhead of creating
and maintaining non-standard tools.

-- Eric


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


-- 
konklone.com | @konklone 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2017-07-08 Thread Eric Mill 
On Sat, Jul 8, 2017 at 11:31 AM, Paul Turner  wrote:
>
> The Internet Draft describes the use of static (EC)DHE for traffic
> entirely inside enterprise networks and intends to clearly state that it
> should not be used for "information passed across the Internet". If we have
> not been clear enough on that in the document, please tell us how we can be
> more clear. Assuming that the document is clear on this point, it would not
> then apply to "wiretapping" as defined in RFC 2804 (as Russ mentioned in an
> earlier email).
>

The IETF's position as expressed in 2804 is on technologies that
"facilitate" wiretapping. What the RFC says the protocol is "intended for"
in layer 8 isn't as relevant as how the technology could easily be used,
once standardized.

The burden on the proposers should be to demonstrate that the technology
can *only* be used in the manner of its stated intent, even if the humans
involved were all hostile, or compelled to be hostile.

You have stated that there are alternatives by using proxies but enterprise
> organizations have stated this is not viable due to the complexity and
> scale of their network environments.


Not all statements are created equal. Stating that proxies can technically
fulfill this function is objective, and can be backed up in clear technical
detail.

Stating that proxies are not viable for enterprise organizations due to the
scale and complexity of their network environments is subjective, generally
not well-detailed, and much more open to skepticism.

The burden on the proposers should be to address this skepticism, and to
justify to the working group why enterprises that are large enough and
well-funded enough to have such vast and complex networks cannot invest in
upgrading those networks to an approach that doesn't rely on directly
weakening their own connection security and potentially the security of
others' through the unintended consequences of formalizing this RFC.


> Our collective objective is to increase the security of the Internet at
> large. As such, we have proposed this RFC in order to ensure that TLS 1.3
> is adopted as broadly as possible inside of enterprises, which is an
> important step in increasing security.


So is increasing the use of forward secret connections within enterprise
network environments. Why should the TLS WG accept the argument that legacy
approaches to monitoring enterprise networks are worth risking the
weakening of the product of years of hard work?

-- Eric


-Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell
> Sent: Saturday, July 8, 2017 10:33
> To: Yaron Sheffer ; tls chair <
> tls-cha...@tools.ietf.org>
> Cc: tls@ietf.org
> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
>
>
>
> On 08/07/17 15:27, Yaron Sheffer wrote:
> > Hi Stephen,
> >
> > Like you, I am very unhappy with this draft, and would not support its
> > adoption as a WG draft. However I think that open discussion is in
> > general good, and that the best venue for discussion of this draft is
> > this mailing list. Even if some of this discussion devolves into
> > generic "are we pro or against wiretapping" questions.
>
> FWIW I believe that we have had that discussion about breaking tls over
> and over on this and other lists. I see no value in doing it yet again,
> even if the proximate cause is a new variation of the "here's a way to
> break tls" class of drafts. (Someday we should find someone who'd document
> all the broken break-tls ideas that have been rightly rejected over the
> years.)
>
> >
> > I don't think this is a significant distraction that could derail
> > (D)TLS, moreover, you will recall that in Chicago several new drafts
> > were adopted to the working group. So the WG does feel that TLS is in
> > good enough shape that we can spend some bandwidth on other things.
>
> Maybe I'm more easily distracted, at least by this topic;-)
>
> Anyway, I'm fine that it's for the chairs to figure that out.
>
> S.
>
>
> > Thanks,
> >
> > Yaron
> >
> >
> > On 08/07/17 12:17, Stephen Farrell wrote:
> >> Sean/Joe,
> >>
> >> This is a request that you, as chairs, shut down the distracting
> >> wiretapping discussion, at least until DTLS1.3 is done.
> >>
> >> I have planned to spend time reading draft 21 and DTLS, but that
> >> won't happen if we keep having to fight off the latest attempts to
> >> break TLS. I'd not be surprised if I weren't the only one finding
> >> that distraction an irritating waste of time. Finishing
> >> TLS1.3 and getting DTLS1.3 on the way surely needs to not be
> >> constantly de-railed by these attempts to break TLS.
> >>
> >> Therefore I'd ask that you declare this discussion closed for at
> >> least that long (i.e until DTLS1.3 is done).
> >>
> >> I'd also ask that you not allocate agenda time for wiretapping in
> >> Prague.
> >>
> >> Thanks,
> >> S.
> >>
> >>
> >>
> >> ___
> >> TLS mailing list
> >> TLS@ie

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

2017-07-07 Thread Eric Mill 
On Fri, Jul 7, 2017 at 4:04 PM, Russ Housley  wrote:
>
> The enterprise wants forward secrecy on the public Internet. Terminating
> the TLS session at the load balancer preserves forward secrecy on the
> public Internet.
>


> In your response, you ignored a fairly significant point in my previous
> post.
>
> In some industries, there are regulatory requirements that cannot
> be
> met without access to the plaintext.  Without some authorized
> access
> mechanism, the enterprise will be forced to use plaintext within
> the
> datacenter.  That seems like a worse alternative to me.
>
> From my perspective, draft-green-tls-static-dh-in-tls13 is not advocating
> outdated crypto, like RC4 or MD5.  Instead, it is using exactly the same
> crypto algorithms and key sizes as draft-ietf-tls-tls13.  Again, this seems
> like a much better way forward than plaintext throughout the datacenter.
>

Your response is also failing to address a very important point, by
presenting the choice as either static-key TLS or plaintext. That's clearly
not the case -- you can maintain traffic visibility at endpoints within
your data center, by forcing traffic through terminating trusted proxies
which log the same network traffic data you would get from passive
monitoring. You can do that with forward secret TLS today.

I'm sure it's not as easy to change your designs to incorporate proxies as
it is to just rely on the network monitoring infrastructure you already
have in place, but that's not a good enough reason to insist that the TLS
WG standardize an RFC which can plainly be used for wiretapping.

It's also passing up an opportunity to gain the benefits of forward secret
connections within your data center, which should really be a best practice
and requirement for any organization managing data that merits strict
regulatory oversight.

This comes across as asking the IETF to contort itself around its own
stated goals so that the enterprise doesn't have to do any heavy lifting to
keep up with security trends. As explained so far, this seems like
something the TLS WG should reject.

-- Eric


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



-- 
konklone.com | @konklone 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-11-20 Thread Eric Mill 
On Sun, Nov 20, 2016 at 2:17 PM, Filippo Valsorda  wrote:

> I'm definitely for 1.3.
>
> I get where 4 is coming from, but 1.2 is not going anywhere soon, and we
> spent the last 10 years training people that the high-numbered one is
> bad, and that the 1.x ones are cool.
>
> I really don't want to have the following conversation, with the exact
> same people the proponents of 4 are trying to help:
>
> "You only support 1.2, you should support 4"
> "Oh, wasn't it that weird other way around where the high one was
> broken?"
> "Ah, no, 4 is the latest and greatest"
> "Oh, ok, then I should support only 4 and 3?"
> "Nono, 3 is terribly broken."
> "Oh, so only 4? Do all clients support it?"
> "Uh, you should keep 1.2"
> "Ah, so 1.2 is better than 3 but worse than 4?"
> "Yeah... I'm sorry"
>
> "4 is great, 3 is bad, 1.2 is good" is harder than "3 is bad, 1.2 is
> good" was, and harder than "3 is bad, 1.2 is good, 1.3 is great" would
> be.
>

While this conversation might not be impossible, I think it's an unlikely
hypothetical. A change to TLS 4 wouldn't be to address confusion for those
who have already internalized the weird version history (which is mostly
people like us on-list), but for people who only think about TLS/SSL when
they're forced to think about it, once every year or few.

For those people, the real conversations I've had were based on superficial
glances and hazy memories of the protocol history that are reconstituted
every time the subject comes up. Naming it TLS 4 wouldn't fix it for
everyone, but it would be all-upside for some -- as well as providing a
helpful opportunity to drop the faux-minor version number and simplify the
numbering overall in the long term.

The near-term annoyance of renaming things by folks close to the WG, and
the chance of some confusion around the edges, seem like small issues
compared to a positive investment in bending the sanity curve of the next
20 years of lazy enterprise decisions.

-- Eric


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



-- 
konklone.com | @konklone 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-11-18 Thread Eric Mill 
It seems like TLS 2 and TLS 2.0 have very little support, so it's really
just deciding between:

TLS 1.3
TLS 4 (or maybe 4.0)

I'll just amplify Rich's and djb's points by noting that the cost of
switching away from TLS 1.3 really only affects a very small number of
people -- really just the people in and around this WG.

There is a much, much larger universe of people who will make deployment
and implementation decisions, with varying attention span and degrees of
skill, and I think they're best served with a clean start of an unambiguous
version number. Just because it feels uncomfortable to us doesn't mean it
will feel uncomfortable to the larger technical/enterprise community who
don't really *care* about the versioning scheme, they just need to make
some decisions and move on.

-- Eric

On Fri, Nov 18, 2016 at 1:07 PM, D. J. Bernstein  wrote:

> The largest number of users have the least amount of information, and
> they see version numbers as part of various user interfaces. It's clear
> how they will be inclined to guess 3>1.3>1.2>1.1>1.0 (very bad) but
> 4>3>1.2>1.1>1.0 (eliminating the problem as soon as 4 is supported).
>
> We've all heard anecdotes of 3>1.2>1.1>1.0 disasters. Even if this type
> of disaster happens to only 1% of site administrators, it strikes me as
> more important for security than any of the arguments that have been
> given for "TLS 1.3". So I would prefer "TLS 4".
>
> Yes, sure, we can try to educate people that TLS>SSL (but then we're
> fighting against tons of TLS=SSL messaging), or educate them to use
> server-testing tools (so that they can fix the problem afterwards---but
> I wonder whether anyone has analyzed the damage caused by running SSLv3
> for a little while before switching the same keys to a newer protocol),
> and hope that this education fights against 3>1.3 more effectively than
> it fought against 3>1.2. But it's better to switch to a less error-prone
> interface that doesn't require additional education in the first place.
>
> ---Dan
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
konklone.com | @konklone 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-11-18 Thread Eric Mill 
On Thu, Nov 17, 2016 at 9:12 PM, Sean Turner  wrote:

> At IETF 97, the chairs lead a discussion to resolve whether the WG should
> rebrand TLS1.3 to something else.  Slides can be found @
> https://www.ietf.org/proceedings/97/slides/slides-97-tls-
> rebranding-aka-pr612-01.pdf.
>
> 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
>

Because I have literally had the experience of a (very) major organization
insisting that HTTPS was not secure because the "most recent" version, SSL
version 3.0, had recently been broken, I support moving this out to TLS 4.

But more generally, I support getting off of the major/minor version naming
scheme. There are no "minor versions" of TLS. Every one is a huge deal for
the ecosystem to update to. I think it will be simpler for everyone in the
future if TLS always just uses whole numbers with no decimal points.

So either TLS 4 or TLS 2 would be improvements in some way. TLS 2.0
wouldn't get you improvements in either category.

As really a non-participant in the WG, I don't expect my preference to
count much, but for whatever it's worth, it would be:

TLS 4 > TLS 2 > TLS 1.3 > TLS 2.0

-- Eric

by 2 December 2016.
>
> Thanks,
> J&S
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
konklone.com | @konklone 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 -> TLS 2.0?

2016-08-31 Thread Eric Mill 
On Wed, Aug 31, 2016 at 7:05 PM, Richard Barnes  wrote:

> I am in total agreement with Nick here.  "TLS 1.3" accurately describes
> what we're doing here, and it's consistent with our past naming scheme.
>
> There is no upside to changing away from 1.3, and as Nick notes, lots of
> potential downside.
>
> --Richard
>
> On Wednesday, August 31, 2016, Nick Sullivan 
> wrote:
>
>> I am reluctant to endorse a name change from TLS 1.3 to TLS 2.0. I see a
>> few immediate issues with the proposal:
>> - it causes confusion with SSL 2.0
>> - it implies wire incompatibility with TLS 1.2
>> - it suggests there will be a forthcoming TLS 2.1 with only minor changes
>>
>> If we're dead set on bumping the major version for a mostly backwards
>> compatible protocol change, we should just drop the minor version and go
>> with TLS/2.
>>
>> Nick
>>
>
FWIW, I've definitely seen real-world confusion about SSLv3 being a more
recent protocol than TLS 1.X, by organizations that should know better. If
there's interest and consensus, this could be a good opportunity to reset
the situation with TLS/2 or TLS 4.0.

I like TLS/2 aesthetically, and represents a similar level of
progress/reset that HTTP saw when it jumped from 1.1 to /2.

-- Eric



>
>> On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz 
>> wrote:
>>
>>> We could call it TLS 3.4 which would match the internal ID. :-)
>>>
>>> BTW, I think using something other than 1.3 is a good idea.
>>>
>>> Cheers - Bill
>>>
>>> 
>>> -
>>> Bill Frantz| When it comes to the world | Periwinkle
>>> (408)356-8506  | around us, is there any choice | 16345 Englewood
>>> Ave
>>> www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA
>>> 95032
>>>
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>


-- 
konklone.com | @konklone 
___
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?

2015-12-02 Thread Eric Mill 
On Wed, Dec 2, 2015 at 7:52 PM, Jacob Appelbaum  wrote:

> On 12/2/15, Salz, Rich  wrote:
> >> it seems blindingly obvious to me that we want it
> >
> > Few things, particularly in the security arena, are blindingly obvious.
> If
> > it actually provides no true protection, then it's just as bad as the
> > security theater in US airports.
>
> It provides protection. Specifically it provides confidentially.
>
> It doesn't solve the fact that the DNS is a privacy violating
> nightmare. It doesn't change the fact that the NSA breaks the rules.
>

And what Don and Rich's analysis is trying to isolate is how much real
protection you get from that level of confidentiality, so that a decision
that weighs all available factors can be made, including the complexity
cost.

It's not just a collective action problem because DNS isn't encrypted too.
Their analysis also looks at what you get when both are encrypted. And
regardless of DNS being encrypted, rainbow-table style reverse lookups of
IP to DNS name are always possible. That doesn't mean encrypted SNI isn't
worth it -- it clearly provides a security attribute (confidentiality) to
an important piece of information.

But it's not enough to drive ahead and say that some attribute outweighs
every other consideration. For example, HSTS' persistence of memory can be
abused as a tracking device:

http://zyan.scripts.mit.edu/sniffly/

And this was known at the time the spec was finalized:

https://tools.ietf.org/html/rfc6797#section-14.9

But HSTS creates security benefits that are well worth the cost of that
tracking potential (which can also be mitigated through preloading). There
are a lot of browsers and communities which use and advocate for HSTS that
might generally balk at creating tracking devices.

I'm not advocating a strong stance on whether encrypted SNI is worth
pursuing, or whether TLS record headers should be encrypted in TLS 1.3. But
it's useful to keep the debate framed in its full context, rather than
narrowing it to a black-and-white discussion over whether a generally good
attribute is good or not.

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