> On Oct 11, 2015, at 3:59 PM, Dave Garrett <davemgarr...@gmail.com> wrote:
>
> On Sunday, October 11, 2015 02:17:17 pm Viktor Dukhovni wrote:
>> Please start with a sensibly minimal proposal that achieves the
>> essential goal of deprecating *trust* in SHA-1. Please do not
>> overreach by requiring not sending SHA-1 or aborting when receiving
>> SHA-1. This is adds nothing of value, just needlessly breaks
>> legitimate (yes non-primary) TLS use-cases.
>
> It's getting lost in the long replies, but again, we have already said we
> both agree with clients not aborting on receiving SHA-1 if trust doesn't rely
> on it.
Excellent, I'm ready to +1 a PR that says just that and no more for clients.
> I am merely saying that TLS 1.3 servers should consider a certificate chain
> which does not rely on obsolete hashes as a prerequisite to use certificate
> authenticated cipher suites. Sorry, but I do not think this is unreasonable.
> Allowing otherwise is, in my view, an unnecessary risk and should not be the
> default assumption.
Well, since anon_DH suites just got removed, and not all servers support them
anyway, clients that don't check certificates will still request "certificate
authenticated ciphesuites". So the server has no idea whether its certificates
are relevant or not, and must not prevent their transmission if that's all it
has.
> With regard to MD5, I think it's reasonable to allow (not require)
> implementations to distrust based solely on that. Note that this is _reduced_
> from the _current_ draft which has mandatory rejection of all MD5, as I agree
> that clarifying that ignoring it when not applicable (e.g. bonkers MD5 root)
> can be valid.
We improve nothing by restricting the content of chain elements that are not
used to build trust. This just promotes the kind of needless failures that I
see with opportunistic TLS in Schannel. Sometimes more is less and less is
more.
Pointless restrictions lead to fallback to even worse choices.
>> Soon enough the trusted CAs will stop issuing certs with SHA-1 in
>> them, and the problem goes away at that layer.
>
> Organizations can run their own CAs for private use. It's not just about the
> big public ones. Allowing TLS servers to send SHA-1-reliant chains means
> considering this to be valid forever.
Yes, but they won't be trusted per the core limitation we've already agreed on.
The remaining issue is whether to prohibit the transmission of such chains,
and the answer is an unequivocal NO. Not trusting is plainly sufficient, and
strictly better, by not breaking (downgrading) use-cases in which the
certificates are otherwise ignored.
> Someone should not be able to blindly upgrade their system to TLS 1.3 and not
> even notice that they're still sending SHA-1-reliant chains. One thing we
> should have all learned over the past couple years is that proper design
> requires making mistakes less possible, not merely labeling things as
> potentially unsafe and delegating them appropriately.
They'll notice right away if the client stops trusting them and is doing
authentication. If the client was not doing authentication it will continue to
not do authentication (ignore the certs regardless of the signature algorithm).
In your zeal to stamp out SHA-1 you're not going through the case analysis to
see that prohibiting less is strictly better.
>> Nothing of the sort. We've agreed that TLS 1.3 clients won't trust
>> SHA-1. We need to stop there. We have no choice. We might like
>> to be able to be beneficent dictators, but that's not an option.
>
> There's always a choice. Perpetuating all design assumptions in a 20 year old
> protocol ensures perpetuating all chronic flaws that it produces. Each layer
> cannot blindly trust the other and expect to work in a complex system. It's
> not that simple anymore.
Yes, we could publish a protocol that shoots itself in the foot and achieves
strictly less security than it otherwise would, and would be less
interoperable. I'm not going to sit idly by and let that happen. Expect
objections at every step of the way...
> Case in point: HTTP/2 has a messy set of TLS restrictions because this WG
> decided against creating a TLS 1.2.1 it could require. Yes, it's not the
> application layer's role to be picking security settings like that, but the
> layer it relies on abdicated its role in maintaining a current version with a
> full set of known-safe configurations. Sure, we may want to "get it right"
> with TLS 1.3 to get ideal adoption rates, but that doesn't change the fact
> that HTTP had a problem with its security layer that it needed fixing.
> Likewise, we cannot safely trust the next layer down in full, because there
> is no overriding standard to mandate only known-safe configurations, so here
> we are debating how to best sanity-check cert chains. It's even messier than
> HTTP, as TLS is the one negotiating the supported algorithms here, so it is
> not even a fully separate layer.
We're not reasoning by tenuous analogy. The proposal you make reduces
security, and needs to not move forward.
> If the WG consensus agrees with your stance, so be it, but the only safe
> thing to do is to at least attempt to prohibit servers from considering
> SHA-1-reliant chains to be safe. (again, roots can do whatever & it's the
> hash reliance or presumption thereof, not cert itself, that's the issue)
Once clients don't get to advertise SHA-1 in supported algorithms, servers will
use SHA-1 only when they have nothing else to offer. This is enough. A much
shorter PR solves the problem, the rest really is just overreach.
Clients that do the "authentication" in "certificate authenticated
ciphersuites" will object to SHA-1 if essential to the chain. Clients that
don't do the "authentication" don't get their connections broken if the server
has nothing better.
Breaking opportunistic TLS connections typically leads to cleartext fallback
(not progress). Where's the win in you're proposing beyond a "feel good"
posture that've deprecated SHA-1 "harder". (Sorry to be a bit blunt, but this
really is NOT personal, I have a lot of respect for all your hard work in many
other PRs, I'm just trying to get this one point across in some manner that
will get through).
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
