Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt
On Oct 11, 2015, at 8:53 AM, Dave Garrett wrote: > From a perspective to get it to work with the bare minimum needed, it's > excessive. From a perspective of killing SHA-1 wherever viable, it is not. I don’t think killing SHA-1 wherever viable should be a goal of this document. A certificate is a credential. It can be used in multiple protocols, standard and proprietary. Whether the certificate is trusted or not is up to the relying party regardless of what protocols that relying party uses. It is not for the TLS spec to dictate what properties a certificate should have, except when those properties make a difference for the protocol. So if we’re removing DSA from the spec, and have not yet standardized EdDSA signatures, it makes sense to require that the public key (not the signature!) in the certificate be either RSA or ECDSA. I don’t think it’s reasonable to require stuff that doesn’t enter the protocol. > Any continued legitimate allowance of a deprecated hash perpetuates other > possible continued allowances, even if the one in question is viable under > some specific circumstance. > > The goal I'm aiming for is SHA-1 being restricted to TLS 1.2 And assuming that TLS 1.3 has better security than TLS 1.2, how does this goal help security on the Internet? We are not in charge of the Internet. We are only engineering some protocols that we hope the implementers will find useful. The industry *is* moving away from signing certificates with SHA-1, but that decision is being made elsewhere. Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] I-D: CipherSuites for Kerberos + DH
Hello TLS WG, I would like to propose new CipherSuites for TLS. The cryptography is founded on Kerberos authentication and DH encryption, cryptographically bound together. The mechanism uses mutual authentication, although clients may use anonymous tickets. Any feedback that you may have (technical, or WG-procedural) is kindly welcomed. I will also send this to the Kitten WG. Thanks, Rick van Rein > *From:* internet-dra...@ietf.org > *Date:* 1 October 2015 18:54 > *To:* "Rick van Rein" , "Rick van Rein" > > *Subject:* New Version Notification for draft-vanrein-tls-kdh-00.txt > A new version of I-D, draft-vanrein-tls-kdh-00.txt > has been successfully submitted by Rick van Rein and posted to the > IETF repository. > > Name: draft-vanrein-tls-kdh > Revision: 00 > Title:TLS-KDH: Kerberos + Diffie-Hellman in TLS > Document date:2015-10-01 > Group:Individual Submission > Pages:26 > URL: > https://www.ietf.org/internet-drafts/draft-vanrein-tls-kdh-00.txt > Status: https://datatracker.ietf.org/doc/draft-vanrein-tls-kdh/ > Htmlized: https://tools.ietf.org/html/draft-vanrein-tls-kdh-00 > > > Abstract: >This specification extends TLS with a Kerberos-based method of mutual >authentication, and binds in Diffie-Hellman to achieve Perfect >Forward Secrecy for the session. > The IETF Secretariat > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D: CipherSuites for Kerberos + DH
On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote: > > *From:* internet-dra...@ietf.org > > > > Name: draft-vanrein-tls-kdh > > Revision: 00 > > Hello TLS WG, > > I would like to propose new CipherSuites for TLS. The cryptography is > founded on Kerberos authentication and DH encryption, cryptographically > bound together. The mechanism uses mutual authentication, although > clients may use anonymous tickets. > > Any feedback that you may have (technical, or WG-procedural) is kindly > welcomed. I will also send this to the Kitten WG. Some quick comments: - The signed DH share does not look to be bound to anything (crypto parameters negotiation, randoms, server key exchange, etc..). I can't offhand say what that would lead to, but it looks even worse than TLS ServerKeyExchange, which has known vulernabilities due to lack of binding to things like ciphersuite. - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2]. - Even use of DH is questionable. [1] All the current ciphersuites have SHA-256 or SHA-384 prf-hash (the prf-hash of existing ciphers was grandfathered as SHA-256, even if the name has _SHA or _MD5). [2] AFAIK, proving security properties of TLS against active attack needs assumption that prf-hash is secure. And we know SHA-1 isn't. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt
On Sun, Oct 11, 2015 at 02:01:59AM -0400, Dave Garrett wrote: > On Sunday, October 11, 2015 01:53:34 am Dave Garrett wrote: > > If the trust model doesn't need the problematic portion of the chain, > > then the chain is not trustworthy and this does not apply. > > Sorry, follow-up to fix a rather critical typo from a double negative. > The "is not trustworthy" was meant to be "is not untrustworthy". If the > trust model doesn't need a part to trust the peer, then it's not untrusted; > it's irrelevant. The overall chain can be trustworthy regardless of what's > in parts it doesn't care about. Yes, of course. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D: CipherSuites for Kerberos + DH
On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara wrote: > On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote: >> > *From:* internet-dra...@ietf.org >> > >> > Name: draft-vanrein-tls-kdh >> > Revision: 00 >> >> Hello TLS WG, >> >> I would like to propose new CipherSuites for TLS. The cryptography is >> founded on Kerberos authentication and DH encryption, cryptographically >> bound together. The mechanism uses mutual authentication, although >> clients may use anonymous tickets. >> >> Any feedback that you may have (technical, or WG-procedural) is kindly >> welcomed. I will also send this to the Kitten WG. > > Some quick comments: > - The signed DH share does not look to be bound to anything (crypto > parameters negotiation, randoms, server key exchange, etc..). I can't > offhand say what that would lead to, but it looks even worse than > TLS ServerKeyExchange, which has known vulernabilities due to > lack of binding to things like ciphersuite. > - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC > (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2]. > - Even use of DH is questionable. I would suggest piggybacking on the PSK mode, using the key Kerberos provides at both ends as the PSK key. This would address all of these issues in TLS 1.3 Sincerely, Watson ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D: CipherSuites for Kerberos + DH
This seems like a good approach. -Ekr On Sun, Oct 11, 2015 at 6:46 AM, Watson Ladd wrote: > On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara > wrote: > > On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote: > >> > *From:* internet-dra...@ietf.org > >> > > >> > Name: draft-vanrein-tls-kdh > >> > Revision: 00 > >> > >> Hello TLS WG, > >> > >> I would like to propose new CipherSuites for TLS. The cryptography is > >> founded on Kerberos authentication and DH encryption, cryptographically > >> bound together. The mechanism uses mutual authentication, although > >> clients may use anonymous tickets. > >> > >> Any feedback that you may have (technical, or WG-procedural) is kindly > >> welcomed. I will also send this to the Kitten WG. > > > > Some quick comments: > > - The signed DH share does not look to be bound to anything (crypto > > parameters negotiation, randoms, server key exchange, etc..). I can't > > offhand say what that would lead to, but it looks even worse than > > TLS ServerKeyExchange, which has known vulernabilities due to > > lack of binding to things like ciphersuite. > > - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC > > (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2]. > > - Even use of DH is questionable. > > I would suggest piggybacking on the PSK mode, using the key Kerberos > provides at both ends as the PSK key. This would address all of these > issues in TLS 1.3 > > Sincerely, > Watson > > ___ > 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
Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt
On Sun, Oct 11, 2015 at 01:53:34AM -0400, Dave Garrett wrote: > On Sunday, October 11, 2015 01:08:41 am Viktor Dukhovni wrote: > > Is this clear yet? > > It's clear, but we disagree on a few points here. It is important to keep in mind that the TLS protocol specification has a reasonably well defined scope and must not intrude on matters that lie outside that scope. In particular, the TLS 1.3 protocol, when not performing PSK resumption, carries a sequence of "certificates" whose first element (possibly in fact a bare public key) signs the protocol key exchange. The protocol tries to be helpful by providing certificates that the peer will understand. Therefore, the peer's list of supported signature algorithms, whose primary purpose is to negotiate a mutually supported PRF, is overloaded to help in certificate chain selection. When multiple choices of certificate chain are available (quite rare at present) to a peer, "the best" one can be selected. Beyond that however, it is not the TLS protocol's job to preempt a peer's decision as to whether a given sequence of "certificates" is trustworthy or even well formed. That responsibility falls on related higher-level protocols (PKIX 5280, Peer name checks RFC 6125, DANE 6698 as imminently updated by RFC 7671). > From a perspective to get it to work with the bare minimum needed, it's > excessive. From a perspective of killing SHA-1 wherever viable, it is not. Is is not appropriate mission for the TLS WG to launch a wider anti-SHA1 crusade. The TLS WG just needs to just avoid SHA-1 problems in the TLS protocol itself (PRFs, ...). Avoiding SHA-1 in PKIX is outside this group's purview. Yes, libraries that implement both TLS and PKIX and provide applications with active-attack resistant "secure channels" will should avoid trusting SHA-1 in PKIX, and I'm fine with a narrow statement that the peer chain verification code in such libraries should not trust SHA-1 issued certificates when negotiating TLS 1.3. However the TLS specification MUST NOT preempt that verifier's responsibility at the supplicant. > Any continued legitimate allowance of a deprecated hash perpetuates other > possible continued allowances, even if the one in question is viable under > some specific circumstance. See above, no crusades. > The goal I'm aiming for is SHA-1 being restricted to TLS 1.2, with the > exception of self-signed roots. A lofty goal, but one that thoroughly exceeds the scope of the TLS protocol. SHA-1 must also be allowed in non-root certs, provided the peer does not trust them (possibly does not need them at all). This is something only the peer can know. > In fact, > two endpoints exchanging certs using SHA1 with intent to directly trust > certs is allowed with this wording. Shots-in-the-dark using SHA1 from > general-purpose servers are not. I think you wish to allow this last case; > I do not. I'm afraid this wish exceeds the proper scope of what the TLS protocol can properly specify. > If the trust model doesn't need the problematic portion of the chain, then > the chain is not trustworthy and this does not apply. This decision fundamentally belongs on the verifier side, and therefore, it is NOT up to the sender to make it, nor is incumbent on the verifier to reject the handshake because the chain sent contains certificate with some algorithm it does not support if it ends up not needing (to trust or use) those certificates. > Also note that it > is merely saying that _if_ the client chooses to abort the handshake, that > _then_ it must alert and abort, and then specifies which abort should be > used. If the client does not decide to abort the handshake, then the > _entire_ portion above is not applicable (no abort, because acceptable in > its trust model, therefor no alert for the trustworthy chain), which is > exactly what you're requesting. We already know what verifiers should do when they don't trust a peer's credentials. Nothing new applies when that's due do an unsupported signature algorithm. > > This is fine, and applies to TLS PRFs, ... but the certificate > > chain can still contain (untrusted) SHA-1 signatures even with TLS > > 1.3. > > Yes. The certificate list can contain untrusted stuff, but the whatever > it builds out of that to trust cannot rely on it at any point. (e.g. can > trust a chain with a root w/ SHA1 or directly trust such a cert, but not > a link with a SHA1 sig) This is something we agree on, so the pull request needs to limit itself to *exactly* this. Any trusted chain constructed by a TLS 1.3 peer cannot contain issuer->subject links that employ SHA-1 signatures. If you narrowly say just this, without making any other changes, I'm on board. > > +MD5 hashes MUST NOT be used in any certificate in any TLS version, and > > any > > +implementation MAY reject any such certificate, without further > > inspection. > > > > Again this is simply too strong. Just like SHA-1, MD5 is not > > trusted. Its pres
Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt
On Sun, Oct 11, 2015 at 01:24:36PM -0400, Dave Garrett wrote: > > Is is not appropriate mission for the TLS WG to launch a wider > > anti-SHA1 crusade. The TLS WG just needs to just avoid SHA-1 > > problems in the TLS protocol itself (PRFs, ...). Avoiding SHA-1 > > in PKIX is outside this group's purview. > > Every time something is "someone else's problem", it is ensured that the > problem will not be properly fixed. Security is only as strong as the > weakest link in the chain, and thus I don't believe a philosophy of complete > separation of roles is realistic, especially in a world where upgrades > and fixes are still deployed slowly and badly. And yet despite your best intentions, defining the semantics of the certificates *carried* by TLS (but specified elsewhere and possibly irrelevant to the verifier) is properly outside the purview of the TLS WG. We can suggest that in TLS 1.3 SHA-1 signatures should not be trusted because they are too weak by comparison with the algorithms used elsewhere in TLS 1.3, we cannot say that peers must abort handshakes carrying certs with signature algorithms employing SHA-1, MD5 or even hypothetically CRC-32 certificates on sight. > > See above, no crusades. > > Calling the goal of phasing out known-bad features a "crusade" is not > really helpful. I'm perfectly fine with stating that SHA-1 is reasonable > to allow in areas where it needs to be for continued transition. It, > however, should require justification to keep allowance rather than to > remove. And yet what you propose is a crusade. You're no longer looking at TLS. You're suggesting we constrain choices outside of TLS, because we know better, but we don't know better, because TLS has no knowledge of the application trust model. So TLS does not get to dictate which offered certificate chains are to be rejected and which accepted. The best we can do is to specify which parameters are too weak to include in such decisions when and if processing chain elements that contain such parameters. > > SHA-1 must also be allowed in non-root certs, provided > > the peer does not trust them (possibly does not need them at all). > > This is something only the peer can know. > > If we consider the certificate authenticated cipher suite scenario within > TLS to expect this to be the common case, then that gives the false > impression that admins don't "have" to upgrade because they're "usable". 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. > > This is something we agree on, so the pull request needs to limit itself > > to *exactly* this. Any trusted chain constructed by a TLS 1.3 peer cannot > > contain issuer->subject links that employ SHA-1 signatures. > > Essentially, our disagreement is just what to do on the server side of > things. I'm saying the server should be required to send non-obsolete > certificates and not allowed to assume clients might be able to trust > non-root certs directly, as this is not the dominant way certificate > authentication is done. The difference goes further, yes the server must not unilaterally deny access to a configured SHA-1 chain, but also the client must not out of hand reject the transmission of such a chain just because SHA-1 is found. Rather the client optionally (but typically) attempts to authenticate the server's certificates, and if that requires using a SHA-1 cert it might stops there given suitable requirements in the TLS 1.3 draft, but if none of the presented SHA-1 certs were needed, then all's well that ends well. This subsumes all the use-cases in which some or all of the server's certificates go unused. > > Well, this "MAY" is in fact used incorrectly in Schannel, which > > aborts connections with opportunistic TLS SMTP clients that present > > client certs that include CAcert's MD5 self-signed root. > > Why on Earth is anyone still using an MD5 self-signed root? Regardless, > "non-root" is acceptable here, if that's sadly still a concern. Ask CAcert.org whose 4096-bit root CA is self-signed with MD5 for no good reason whatsoever. And yet there's no problem with that, the cert is slightly smaller that way, and the self-signature plays no role in security. > When talking about MD5 still being around, I'm inclined to consider it > acceptable collateral damage to avoid presenting a false sense of security, > though if the land of half-assed email transport security is still this > bad, then this may not be ideal. Your "half-assed" is my impressive success, ~80% of outbound email from Google, that used to go in clear is now encrypted. What fraction of HTTP sites have migrated from cleartext? > The correct course of action is of course > to not support this connection at all, but that requires more commitment > than developers are willing to make to security. That lack of will is > _why_ I'm argui
Re: [TLS] I-D: CipherSuites for Kerberos + DH
> On Oct 11, 2015, at 09:46, Watson Ladd wrote: > > > I would suggest piggybacking on the PSK mode, using the key Kerberos > provides at both ends as the PSK key. This would address all of these > issues in TLS 1.3 > Which would also match how Kerberos is used in IKE/IPsec Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-00.txt
Hi Yaron--
On Sun 2015-10-11 15:57:38 -0400, Yaron Sheffer wrote:
> We have a standard for certificate pinning (RFC 7469), but it is rather
> hard to use and as a result is rarely deployed. This draft proposes a
> lightweight alternative that allows TLS clients to authenticate the
> server they're connecting to, even if a rogue CA can generate fake
> certificates for that server.
>
> The draft is currently TLS 1.3-only, and is based on the previous draft
> of 1.3 so some minor details may have changed.
I've only just skimmed thus far, but i'm happy to see this proposal. A
few comments below:
TACK
As you note in the draft, it addresses a similar problem as TACK, which
never made it through the standards process:
http://tack.io/draft-tack.html
perhaps it would be useful to have a section next to the Comparison:
HPKP that included a Comparison: TACK ?
(dis)similarity to session tickets
--
In the session-ticket case, most servers (clustered or otherwise) can
afford to treat their session ticket master keys as ephemeral keys -- if
the server is restarted or dies and is re-installed, the worst that
happens is that a client doesn't get to resume their session -- they
have to open a new connection.
If the session ticket resumption master keys are used as recommended
here, it seems like the risk of master key loss is bricking the server,
so the master key becomes necessary to store non-ephemerally.
Writing the master key to disk or storing it off-site someplace can
present a risk to the forward-secrecy of ticket-resumed sessions.
tracking the master key itself seems like it also adds specific
operational overhead for server maintainers that doesn't currently
exist. Does this reduce the advantage of the scheme over TACK or HPKP?
if not, can you explain why not?
Client Privacy
--
section 6.6 says "TODO", and page 5 says:
> The main reason for refreshing the ticket on each connection is
> privacy: to avoid the ticket serving as a fixed client
> identifier. It is RECOMMENDED to include a fresh ticket with
> each response.
If the participating client wants privacy from the server (to avoid the
server using this to track the client) but also wants defense against
broken CAs, how does recomending this behavior from the server actually
allow the client to enforce privacy?
The server is trivially capable of tying together a history of
pinning_ticket objects to track specific clients, right? it just
remembers the two tickets involved every time it generates a
PinningTicket extension. If the pinning tickets returned by the server
are different each time, the client cannot know whether the server is
doing this tracking or not.
public key vs. certificate
--
In your introduction (and in the mail above), you refer to "certificate
pinning" -- but i don't think there is anything out there that is
"certificate pinning" -- HPKP is public key pinning, and it ignores the
certificates that wrap any given public key. So your tables should
really refer to "main public key" and "backup public key", not "main
certificate" or "backup certificate".
HPKP example workflow
-
Your HPKP timeline seems to assume that your "old backup certificate"
can't be used as your "new main certificate" -- what makes you say this?
I agree with you that HPKP end-entity pinning generally makes more sense
(and is more useful at defending against malicious/incompetent CAs) than
authority pinning. But I'd expect an HPKP timeline using end-entity
pinning to be more like:
lower-case letters are public keys. we presume that the site
administrator has the corresponding secret keys backed up
offsite/offline somewhere, and the associated certs and secret keys
needed to operate the web site get deployed as needed.
Initial deployment:
HPKP: { a, b } Cert: A = X.509-wrapped(a)
as A approaches expiry, we generate a new key c (storing its secret key
offline), get a new cert made over b, and switch to:
HPKP: { b, c } Cert: B = X.509-wrapped(b)
As B approaches expiry, we do the same dance, generating d and making a
cert over c:
HPKP: { c, d } Cert: C = X.509-wrapped(c)
and so on.
Does this simpler cycle change your analysis of HPKP?
I tend to think HPKP deployment has been slow because:
(a) the risk of bricking the site makes admins (justifiably) nervous
(b) having to have an additional offsite store (of your HPKP backup
secret key) to avoid site-bricking is a workflow that most admins
don't already have in place.
But i don't think your proposal addresses these issues either (though
the data stored offsite for (b) is slightly different between your
proposal and HPKP). Does it address them in some way that i'm missing?
Regards,
--dkg
signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/li
Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt
> On Oct 11, 2015, at 3:59 PM, Dave Garrett 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 sepa
Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt
On Sun, Oct 11, 2015 at 07:13:03PM -0400, Dave Garrett wrote: > A wording change might be helpful here. Instead of no sending of SHA1 certs: > 1) SHA1 signatures must not be trusted Excellent. > 2) servers must not send cert chains they do not trust Pointless overreach that breaks things. > Yes, I know you'll say that the client can of course trust things the > server might not be able to, but the core of what I'm concerned about is > servers making an attempt to get clients to accept a chain it knows very > well is not trustworthy and thus encourage implementations to accept it > anyway. You're still ignoring the fact that in many environments the client (correctly) does not validate the chain via trust-anchors of any kind, so signatures of certificates by some "issuer" are of interest to the client. There is no reason for the server to avoid sending the chain even if some "signer" in the chain happened to use SHA-1. At a minimum a leaf cert signed with SHA-1 may still be valid by means other than trust of its signature. > > They'll notice right away if the client stops trusting them and is doing > > authentication. > > "if" > If servers keep on sending SHA1 indefinitely, we risk clients keep on > accepting SHA1 indefinitely, no matter what it says in the spec. Some implementations might even ignore any misguided text telling them to not send the chain. :-) We can't design for non-conformant implementations. You sure want that cherry on top. However right it might feel, it would still be counterproductive. > > 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. > > If servers still commonly send SHA-1, then clients will never stop offering > support for it. No, that conclusion is unwarranted. TLS 1.3 clients will not trust SHA-1. All the key implementors are reading this interminable thread. They understand the issues. If we get consensus for at least the minimal version (no trust in SHA-1) we're done. There's no reason for pessimism, we're not trying to deprecated deployed functionality, there is no TLS 1.3 deployed base. We can start "clean" and keep it that way. > > Breaking opportunistic TLS connections typically leads to cleartext > > fallback (not progress). > > Prohibiting TLS 1.3 implementations from using SHA1 certs does not break > OE. It does when the SHA-1 leaf certificate is pinned, and/or the server has nothing else to send, and its clients rightly don't care. > > Where's the win in you're proposing beyond a "feel good" posture that've > > deprecated SHA-1 "harder". > > My goal is to have fewer systems using SHA1 within a reasonable timeframe. That happens automatically in the minimal version of the PR. 1. Recall that the SHA-1 certs are not trusted by TLS 1.3 clients, so the vast majority of servers will need SHA2-256 certs. 2. Recall that public CAs are phasing out SHA-1 certs sooner than a non-negligible number of systems is likely to deploy TLS 1.3 > The current TLS 1.3 draft completely delegates that issue away in a manner > which does not put any onus on servers to upgrade, instead relying entirely > on unspecified outside forces to deal with the issue (e.g. CA/Browser > Forum; clients hopefully saying no, eventually). We've agreed to require clients to not trust SHA-1 signatures. That's quite enough, and is a smaller, simpler change. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D: CipherSuites for Kerberos + DH
On Sun, Oct 11, 2015 at 9:46 AM, Watson Ladd wrote: > On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara > wrote: > > On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote: > >> > *From:* internet-dra...@ietf.org > >> > > >> > Name: draft-vanrein-tls-kdh > >> > Revision: 00 > >> > >> Hello TLS WG, > >> > >> I would like to propose new CipherSuites for TLS. The cryptography is > >> founded on Kerberos authentication and DH encryption, cryptographically > >> bound together. The mechanism uses mutual authentication, although > >> clients may use anonymous tickets. > >> > >> Any feedback that you may have (technical, or WG-procedural) is kindly > >> welcomed. I will also send this to the Kitten WG. > > > > Some quick comments: > > - The signed DH share does not look to be bound to anything (crypto > > parameters negotiation, randoms, server key exchange, etc..). I can't > > offhand say what that would lead to, but it looks even worse than > > TLS ServerKeyExchange, which has known vulernabilities due to > > lack of binding to things like ciphersuite. > > - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC > > (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2]. > > - Even use of DH is questionable. > > I would suggest piggybacking on the PSK mode, using the key Kerberos > provides at both ends as the PSK key. This would address all of these > issues in TLS 1.3 > That's the right solution and this is why we need modular designs with generic security (generic = not tailored to a specific use case). It allows you to accommodate cases you did not necessarily think about when designing the protocol. Hugo > Sincerely, > Watson > > ___ > 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
Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt
On Sunday, October 11, 2015 08:00:45 pm Viktor Dukhovni wrote: > There's no reason for pessimism Sorry, I have to laugh a bit here. :p > we're not trying to deprecated deployed > functionality, there is no TLS 1.3 deployed base. Due to the fact that the vast majority of TLS implementations that will be used are going to be existing ones, upgraded to support TLS 1.3, yes we are deprecating deployed functionality for that implementation as well as their users. > > Prohibiting TLS 1.3 implementations from using SHA1 certs does not break > > OE. > > It does when the SHA-1 leaf certificate is pinned, and/or the server > has nothing else to send, and its clients rightly don't care. In the second case, a correct course of action for the server would be to send an incomplete or outright empty certificate_list fallback, in which case the clients that don't care will be fine with it. Pinning a SHA1 end-entiy (leaf) cert rather than an intermediate just seems like a bad idea that you can't expect to work forever. In cases where the server can't handle lack of SHA1, then my response is to fix that before upgrading TLS. > > My goal is to have fewer systems using SHA1 within a reasonable timeframe. > > That happens automatically in the minimal version of the PR. We're both trying to predict possible futures with different thought processes. I'm concerned that the simpler course is too slow, _not_ because we need to rush to get rid of SHA1 certs ASAP, but because going slower requires keeping SHA-1 around in implementations in the interim. Even requiring settings and code for an algorithm at all poses an attack surface by itself (we had attacks on supposedly disabled features over the past year). Every known vulnerable feature is one which we have to be wary of getting re-enabled or left on accidentally. I consider this risk to be high enough to not rely on delegation to another layer; you think that delegation cannot be changed without excessive interop risk. I'll post a follow-up question to the WG (with a changed title, as our discussion here got long) with the options phrased as a question with 3 main choices (including the option of doing nothing new). If there's no support for a full drop in SHA-1 support under the new version, then there won't be a point in pushing for it further, unless there's yet another SHA-1 revelation in the near future. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] The SHA-1 Options (was: banning SHA-1 in TLS 1.3, a new attempt)
I'd like to get a sense of what the WG is willing to consider with regard to SHA-1, rather than only Viktor and myself discussing this. Basically, I see 3 options: Option 0: Do nothing new. SHA-1 is soft deprecated, but still a fully viable option in TLS 1.3 if nothing better is installed. Option 1: Explicitly state that TLS 1.3+ clients must not trust SHA-1 signatures (but may trust full certificates, namely roots). Option 2: Distrust (option 1) and also prohibit endpoints from sending chains that rely on SHA-1 signatures to their peers when negotiating TLS 1.3. (aka, don't upgrade to TLS 1.3 until you've upgraded your certificates; self-signed roots still exempt) No change is proposed with regard to dealing with SHA-1 under TLS 1.2 beyond the current state. TLS 1.3 already prohibits using SHA-1 in CertificateVerify. This discussion is only for TLS 1.3+ non-root certificates. The TLS 1.3 release is not yet near (assume we're talking about 2016, when others are phasing out SHA-1 more strictly as well). I am in favor of #2, as I don't think the risk of keeping it in the spec is worth continued support (SHA-1 is on its way out, and TLS 1.3 shouldn't perpetuate its use). Viktor Dukhovni is in favor of #1, and considers prohibiting servers from sending SHA-1 certs to be sufficiently out-of-scope and not worth the interop risk (opportunistic encryption and direct trust of certificates, of note). Two opinions does not a working group make, so more input is clearly needed to move forward in any way here. This is only a preliminary call for opinions, and certainly not a policy deciding vote. The new reason to consider this: https://sites.google.com/site/itstheshappening/ Current draft language: https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-60 Start of the parent thread: https://www.ietf.org/mail-archive/web/tls/current/msg17956.html Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] The SHA-1 Options (was: banning SHA-1 in TLS 1.3, a new attempt)
On Sun, October 11, 2015 7:43 pm, Dave Garrett wrote: > I'd like to get a sense of what the WG is willing to consider with regard > to SHA-1, rather than only Viktor and myself discussing this. Basically, I > see 3 options: > > Option 0: Do nothing new. SHA-1 is soft deprecated, but still a fully > viable option in TLS 1.3 if nothing better is installed. > Option 1: Explicitly state that TLS 1.3+ clients must not trust SHA-1 > signatures (but may trust full certificates, namely roots). > Option 2: Distrust (option 1) and also prohibit endpoints from sending > chains that rely on SHA-1 signatures to their peers when negotiating TLS > 1.3. (aka, don't upgrade to TLS 1.3 until you've upgraded your > certificates; self-signed roots still exempt) My personal preference, speaking on behalf of myself and neither that of my employer or colleagues (we are all individuals here, right? ;D), would be Option 0. If that's all you care to know, stop here - the rest is pontificating and poorly articulating why :) Background: It's no secret I hate SHA-1. I'm accused by a number of Chrome users as being too aggressive in the deprecation of SHA-1. I'm unquestionably accused by CAs of being too harsh on SHA-1 - my opposition towards any extension of SHA-1 signatures by CAs complying with the CA/Browser Forum Baseline Requirements is unquestionable and well known. Why would I support "do nothing"-ism, which is effectively what Option 0 is? Two reasons: - I agree with Viktor that TLS is a protocol for which many credential types can be delivered, and while I have no desire nor intent to support a number of them within Chrome (... I'm looking at you, DANE), I don't deny their utility or viability in some circumstances and environments beyond that of web browsers. It feels inconsistent to apply this to one specific type of credentials, with a particular policy. This is an ideological argument for specification purity, fundamentally, so I fully anticipate disagreement, as is expected with such arguments. - Simply one of complexity. The modern TLS stack, as used in Web browsers (thus revealing my bias, as if we didn't know it already) is already hairy and complex. HTTP/2 imposes a (much needed) profile on ciphersuite negotiations. Browsers themselves key UI off a variety of factors contributing to the connection, both direct (e.g. ciphersuite) and indirect (e.g. mixed content). If we accept that browsers are only concerned with the Web PKI (I know some wish it were otherwise), then the WebPKI is messy, and whether or not a certificate is signed by SHA-1 is... complex and complicated and invokes path building and cross certificates and many of the things outside the remit of TLS. This certificate path building and discovery depends on a variety of factors and external resources (and here's where Martin Rex would chime in about how awful such a state is, but let's accept it as the state of the world today and not argue about necessity or not), and implementing such a policy necessarily interleaves that into the connection management. The 'gross' state of my world today, which will no doubt shock and offend, is that in many cases and ways, the verification of the server identity is deferred until after the overall connection has been established, before any data is transferred over it, and before any keys, session parameters, or overall state is persisted for reuse. The alternative to this is to do something akin to Firefox, which does verification semi-synchronously during handshaking, but which doesn't fetch such external resources (and thus has a much harder time interacting with nominally 'secure' sites), and which if it did, would trigger the various 'retry' logic to deal with servers that time out if the handshakes fail to happen in a 'reasonable' time. Look, I think the deprecation of SHA-1 is a noble goal - hopefully my bonafides are established such that few would want it more - but my concern is that it would add significant implementation complexity to my world, and fundamentally offer no benefit for my existing and documented plans. Were I (and my colleagues) to ignore such a MUST, for entirely pragmatic and yet equally secure reasons, we'd end up cheesing off folks like Dave and those who treat MUSTs as inviolate (reasonably and rightfully so), and would be seen as tacitly encouraging others to ignore such MUSTs as well. I'd like to avoid that world. I think the reasons for such a proposal are laudable, but the pragmatic application and interpretation of such a requirement would be confoundingly obnoxious, and to no obvious benefit, since I (and my counterparts at various other browser organizations) am well on my way to killing SHA-1 within the commercial space. So the only party left to all this is the Enterprise folk, those who will always override a MUST with an application profile, or who will always deal with legacy in such a way that, practically speaking, such a MUST is toothless. Such a r
[TLS] closing this thread: Re: The SHA-1 Options (was: banning SHA-1 in TLS 1.3, a new attempt)
I’m going to close this thread. We discussed SHA-1 support in TLS on the list and at the interim the chairs made the consensus call that PR#231 reflects the WG’s consensus. Note that Stephen started a thread on the saag list about further work to remove SHA-1 from protocols [1]; maybe the references both Dave and Stephen cite will accelerate the demise of SHA-1 issued certs. spt [1] http://mailarchive.ietf.org/arch/msg/saag/1iiiMLJmrtEMSmghoYO6lC_xje4 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D: CipherSuites for Kerberos + DH
Hello, Thanks for the feedback. Responding to it: Ilari> - The signed DH share does not look to be bound to anything (crypto Ilari> parameters negotiation, randoms, server key exchange, etc..). This is indeed easy to miss; it relies on Kerberos infra to deliver a short-lived session key to only the proper TLS client and TLS server. The ticket is part of this key delivery, and can travel over untrusted networks. An Authenticator is built especially for each connection, and encrypted with the session key by the TLS client. The only other that can decrypt it is the TLS server. With the client DH key only known to TLS client and TLS server, only they can construct the DH shared secret. What remains is MITM on the server side. This is detected when the Finished messages are off (these have more bytes for TLS-KDH). A alternative option to fighting MITM could be to include (a hash of) the server-sent DH offer in the Authenticator. Only the Kerberos- authenticated TLS server can decrypt it, making it detect MITM. Is that considered benefial? Ilari> I can't Ilari> offhand say what that would lead to, but it looks even worse than Ilari> TLS ServerKeyExchange, which has known vulernabilities due to Ilari> lack of binding to things like ciphersuite. Have I taken away these concerns? Pointers to the known vulnerabilities are welcome, of course. I'm not sure what you would like to bind to CipherSuites. Watson> I would suggest piggybacking on the PSK mode, using the key Kerberos Watson> provides at both ends as the PSK key. This would address all of these Watson> issues in TLS 1.3 You mean to add the short-lived session key to the pre-master secret, right? I have a (weak) preference to leave that key behind the API to help it being better protected. Also, I don't think it adds much to the security explained above. It might be an idea to add protected fields from the Authenticator though, such as the usec timestamp, seq-number, client name@realm. Ilari> - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC Ilari> (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2]. Yes, this is a naive/initial list, I knew I would need to interact here to get it pruned. Thanks, your suggestions will be taken care of! Ilari> - Even use of DH is questionable. This is mod-exp DH, on account of its need for very large keys, right? I would love to take it out, and only leave ECDH; I put up mod-exp DH initially because it might be desired for backward compatibility. If I hear no warm-felt desire for mod-exp DH I will gladly remove it. Thanks! -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
