Re: [TLS] PR for anti-downgrade mechanism
On Sat, Oct 10, 2015 at 4:44 AM, Dave Garrett
wrote:
> There is one problem with the current proposed sentinel value,
> 0x030403040304. It limits what can be done with future versions. It's not
> as simple as just making that use 0x030503050305, because we want 1.3
> clients to be able to recognize sentinel values from all future versions,
> not just this one. Thus, for future proofing, (just) using the version
> number isn't a great idea. It's probably safest to just pick one static
> value and be done with it forever.
>
That may be true, but then this value is as good as any other.
An alternative would be to burn N-8 bits on a sentinel and then
8 bits on the version number. E.g.,
01 02 03 04 05 34 [0]
BTW, I'm basically indifferent between 48 and 64 bits.
-Ekr
[0] I didn't use 00 00 00 00 00 as the sentinel because I have some vague
memory
that there are implementations which use 0s in the timestamp.
And now, for my proposed bikeshed color:
>
> 0x0b501e7e5e1ec7ed
> ("obsoleteselected"; 64-bit value)
>
> I'd like to say I was clever enough to come up with neat hex words, but I
> Googled for a list and found 2 to put together. ;)
>
>
> Dave
>
> ___
> 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 Sat, Oct 10, 2015 at 7:37 PM, Dave Garrett wrote: > In light of completely unsurprising recent events [0], I think it's time > to reconsider the current consensus on how to deal with SHA-1 in TLS 1.3. > Currently, it's allowed if needed by servers that have nothing better [1]. To be clear, the only thing that's allowed is SHA-1 in *certificates*. It's forbidden in CertificateVerify. -Ekr > I propose we stop playing around and just prohibit it under TLS 1.3+. > Implementations that can negotiate nothing better would be permitted to > fall back to TLS 1.2 with the security restrictions currently in the draft > [2] (which is still a concession I'd rather not make, but it's currently > needed). I have submitted a PR [3] to this effect in order to have specific > text to discuss here, though WG consensus and chair approval is of course > required to change the current status. > > Please note that TLS 1.3 is not coming out tomorrow, nor will its > deployment be instant. By the time servers even decide to consider an > upgrade, SHA-1 will be in an even less secure state than it already is. > > To answer the obvious question: Prohibiting it in new versions reduces the > risk of mistakes, draws a clear line where support is killed, and puts an > actual impetus on PKI to transition faster. TLS 1.2 is potentially > vulnerable, depending on configuration (nothing new there), but TLS 1.3 > should be known to be secure in all valid configurations. The discussion to > have with non-experts should not be about specific algorithms to pick and > choose (RC4, MD5, SHA1, EXPORT ciphers, non-AEAD, non-PFS, weak DH groups, > etc. etc.); we should be able to point at the current version and say "use > this, not the old thing", or we can't expect it to be understood and taken > seriously. > > [0] https://sites.google.com/site/itstheshappening/ > [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-60 > [2] https://tools.ietf.org/html/draft-ietf-tls-tls13-09#appendix-C.3 > [3] https://github.com/tlswg/tls13-spec/pull/287 > > > Dave > > ___ > 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 Sat, Oct 10, 2015 at 07:44:04PM +0200, Eric Rescorla wrote: > On Sat, Oct 10, 2015 at 7:37 PM, Dave Garrett > wrote: > > > In light of completely unsurprising recent events [0], I think it's time > > to reconsider the current consensus on how to deal with SHA-1 in TLS 1.3. > > Currently, it's allowed if needed by servers that have nothing better [1]. > > To be clear, the only thing that's allowed is SHA-1 in *certificates*. > It's forbidden in CertificateVerify. Isn't using it in certificates precisely more dangeous than using it in CertificateVerify (especially with TLS 1.3)? (Not that using it in CertificateVerify is a good idea). Also, AFAIK, TLS 1.3 won't be published this year, so by the time it is published, one can't get SHA-1 certs from public CAs anyway (or if you can, those don't work reliably anyway). -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 Sat, Oct 10, 2015 at 11:28:28PM +0300, Ilari Liusvaara wrote: > > To be clear, the only thing that's allowed is SHA-1 in *certificates*. > > It's forbidden in CertificateVerify. > > Isn't using it in certificates precisely more dangeous than using it in > CertificateVerify (especially with TLS 1.3)? So long as SHA-1 self-signatures are still tolerated in root or self-signed end-entity certificates, I have no objection to TLS 1.3 specifying that a certificate signed with SHA-1 is not trusted even when issued by a trusted issuer. However, we *must* be careful about what obligations we impose on a client or server that encounters a certificate chain in which some certificate which is not self-signed uses a SHA-1 signature. It would be a big mistake to mandate fatal or even warning alerts or closing the connection. Rather, the required outcome is that the chain is simply not trusted. Whether *that* in turn leads to a connection termination depends on whether verification is required. Opportunistic clients, or servers that solicit optional client certificates need to be able to continue despite the untrusted chain, and do what they do in the absence of a peer certificate or when the peer certificate has accceptable signatures, and and yet is still untrusted (or peername does not match, ...). So if the draft language for 1.3 essentially only prohibits *trusting* SHA-1, but does not prohibit the *presence* of SHA-1 in the peer's chain, I think that should be fine. I don't want to see client's or servers hanging up just because a peer presents a SHA-1 chain that would have been simply ignored had it been SHA2-256 instead. -- Viktor. ___ 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 Saturday, October 10, 2015 04:28:28 pm Ilari Liusvaara wrote: > On Sat, Oct 10, 2015 at 07:44:04PM +0200, Eric Rescorla wrote: > > To be clear, the only thing that's allowed is SHA-1 in *certificates*. > > It's forbidden in CertificateVerify. > > Isn't using it in certificates precisely more dangeous than using it in > CertificateVerify (especially with TLS 1.3)? > > (Not that using it in CertificateVerify is a good idea). You can take all the time you need to forge something in a certificate chain (before expiry time), but to forge CertificateVerify you'd need to do it on the fly. Really dangerous vs. somewhat dangerous doesn't matter much here, though. Dave ___ 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 Sat, Oct 10, 2015 at 08:59:08PM +, Viktor Dukhovni wrote: > I don't want to see client's or servers hanging up just because a > peer presents a SHA-1 chain that would have been simply ignored > had it been SHA2-256 instead. In particular pull request 287 breaks opportunistic TLS and *must* not be adopted as-is. It needs to allow SHA-1 chains to be sent when that's all that's available. The onus to not trust such chains is on the peer. Some peers may continue with the handshake despite the untrusted chain. They may, for example, have pinned the leaf certificate and not give a hoot about any of the signatures. -- Viktor. ___ 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 Saturday, October 10, 2015 04:59:09 pm Viktor Dukhovni wrote: > So long as SHA-1 self-signatures are still tolerated in root or > self-signed end-entity certificates, I have no objection to TLS > 1.3 specifying that a certificate signed with SHA-1 is not trusted > even when issued by a trusted issuer. > > However, we *must* be careful about what obligations we impose on > a client or server that encounters a certificate chain in which > some certificate which is not self-signed uses a SHA-1 signature. > It would be a big mistake to mandate fatal or even warning alerts > or closing the connection. Rather, the required outcome is that > the chain is simply not trusted. > > Whether *that* in turn leads to a connection termination depends > on whether verification is required. Opportunistic clients, or > servers that solicit optional client certificates need to be able > to continue despite the untrusted chain, and do what they do in > the absence of a peer certificate or when the peer certificate has > accceptable signatures, and and yet is still untrusted (or peername > does not match, ...). > > So if the draft language for 1.3 essentially only prohibits *trusting* > SHA-1, but does not prohibit the *presence* of SHA-1 in the peer's > chain, I think that should be fine. > > I don't want to see client's or servers hanging up just because a > peer presents a SHA-1 chain that would have been simply ignored > had it been SHA2-256 instead. Yes, to all points above. I feel like self-signed certs should have to use SHA-256 too, but mandating that doesn't get us that much. The current PR is a bit too general; will need revision to handle all cases. I'll of course change it to accommodate concerns that come up in discussion here. Note that opportunistic encryption is weird and getting the whole document to be perfect for it might not be entirely doable, as OE needs to tolerate more fuzziness than the main spec should allow. Dave ___ 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 Sat, Oct 10, 2015 at 05:11:56PM -0400, Dave Garrett wrote: > Note that opportunistic encryption is weird and getting > the whole document to be perfect for it might not be entirely doable, as > OE needs to tolerate more fuzziness than the main spec should allow. Unfortunately requirements in the base TLS document end up "set in stone" in software implementations, and then break opportunistic TLS in ways application software can't work around. So while the UTA TLS BCP can write requirements that exclude opportunistic security, the TLS specification does not have that liberty. In this case the solution is simple enough. DO NOT prohibit the exchange of certificate chains with SHA-1 in them. Just prohibit *trusting* their content. We alredy have language to allow servers and client to send "last-resort" chains that don't match the peer's advertised supported algorithms. This suffices. The necessary changes are then MUCH simpler than the current pull request 287. * Prohibit advertising SHA-1 in the supported algorithms list, (except as needed for TLS 1.2 compat, ...) * Prohibit trusting SHA-1 when found in certificates that are not self-signed. That's it. A lot less work. SHA-1 is no longer trusted, but does not impede interoperability when certificates are largely useless baggage. -- Viktor. ___ 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 Saturday, October 10, 2015 05:19:30 pm Viktor Dukhovni wrote: > On Sat, Oct 10, 2015 at 05:11:56PM -0400, Dave Garrett wrote: > > Note that opportunistic encryption is weird and getting > > the whole document to be perfect for it might not be entirely doable, as > > OE needs to tolerate more fuzziness than the main spec should allow. > > Unfortunately requirements in the base TLS document end up "set in > stone" in software implementations, and then break opportunistic > TLS in ways application software can't work around. I do agree with rewording the text in question to deal with this better, but honestly, OE & AE are directly opposed concepts. I'd much rather write almost everything assuming the goal is properly authenticated encryption, and have a separate section dedicated to opportunistic encryption stating that its implementation requires ignoring many of the hard requirements TLS has with regard to authentication. Trying to subtlety allow for AE & OE in all the same text might give us a more fragile specification where accidentally screwing up authentication is easier. OE can be useful, but it's the exception, not the rule; giving AE too much wiggle-room could be dangerous. (when it's explicitly requested, e.g. TOFU with raw public keys, that's a different discussion) Dave ___ 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 Sat, Oct 10, 2015 at 06:46:47PM -0400, Dave Garrett wrote: > > Unfortunately requirements in the base TLS document end up "set in > > stone" in software implementations, and then break opportunistic > > TLS in ways application software can't work around. > > I do agree with rewording the text in question to deal with this better, > but honestly, OE & AE are directly opposed concepts. I'd much rather write > almost everything assuming the goal is properly authenticated encryption, > and have a separate section dedicated to opportunistic encryption stating > that its implementation requires ignoring many of the hard requirements > TLS has with regard to authentication. Sorry that works for the UTA BCP, but *cannot* work the TLS protocol specification. The TLS protocol cannot and SHOULD NOT make any assumption about the client's security model, which can be: * PKIX with Web PKI public CAs * DANE-TA(2) with private CAs trusted via DNS * DANE-EE(3) (if you like server-side pinning via DNS). * RFC7250 bare public keys with DANE "3 1 1" bindings. * RFC7250 bare public keys with some other out-of-band keying * Trust on first use with leaf certificate pinning. * GSSAPI with channel binding * Unauthenticated opportunistic TLS. * ... It is not appropriate for this WG to be narrowly focused on just the first security model, which is certainly important, but not to the exclusion of the rest. > Trying to subtlety allow for AE & > OE in all the same text might give us a more fragile specification where > accidentally screwing up authentication is easier. OE can be useful, but > it's the exception, not the rule; giving AE too much wiggle-room could be > dangerous. (when it's explicitly requested, e.g. TOFU with raw public > keys, that's a different discussion) There is no subtlety getting in the way of not deprecating trust in SHA-1, with a tiny bit of care it can be done generally without breaking any of the use cases. If the base protocol is bifurcated into many different use-cases, implementations won't handle all the cases correctly. This is not difficult, it just requires not forgetting that there's more than one way to do (or not do) authentication, and that the TLS protocol needs to remain largely agnostic of the authentication model. Just deliver the available credentials to the peer, and let the peer decide what to do. -- Viktor. ___ 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 Saturday, October 10, 2015 10:35:16 pm Viktor Dukhovni wrote: > This is not difficult, it just requires not forgetting that there's > more than one way to do (or not do) authentication, and that the > TLS protocol needs to remain largely agnostic of the authentication > model. Just deliver the available credentials to the peer, and > let the peer decide what to do. It's the "or not do" that's the issue, not the other ways to do authentication that I'm concerned about. As I said, it looks like we can word this properly in a way that works for everyone. I just feel like the best way to cover the OE case fully is to address it in a separate section, explicitly, rather than (just) tweak wording to accommodate it. Even TOFU is more straightforward than OE, because at least with that it always follows basically the same pattern. OE requires you take what would normally be a blatant catastrophic error, but wave a wand and say it's OK for this separate use case. That may be true, but that doesn't make it any less of a blatant catastrophic error when that's not the case. I'm worried about having these not be completely distinct for the same reason you don't put a self-destruct button next to a light switch, no matter how well labeled. ;) Also, I want the spec to anticipate some peers being incredibly stupid and avoid making it easy to mess things up. Dave ___ 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 Sat, Oct 10, 2015 at 11:00:30PM -0400, Dave Garrett wrote: > On Saturday, October 10, 2015 10:35:16 pm Viktor Dukhovni wrote: > > This is not difficult, it just requires not forgetting that there's > > more than one way to do (or not do) authentication, and that the > > TLS protocol needs to remain largely agnostic of the authentication > > model. Just deliver the available credentials to the peer, and > > let the peer decide what to do. > > It's the "or not do" that's the issue, not the other ways to do > authentication that I'm concerned about. Concern is appropriate and healthy, and nevertheless the requirement to not focus too narrowly remains. For example a client doing GSSAPI with channel-binding and ignoring TLS certificates is essentially opportunistic viewed narrowly at the TLS layer, since it may well accept (and ignore) whatever certificate chain is sent its way. > As I said, it looks like we can word this properly in a way that works > for everyone. I just feel like the best way to cover the OE case fully is > to address it in a separate section, explicitly, rather than (just) tweak > wording to accommodate it. Separate (and thus possibly conflicting) language only as a last resort when a single specification is simply not possible. Most of TLS is trust model agnostic, so these differences should not matter in most or perhaps the entire specification. > Even TOFU is more straightforward than OE, because at least with that it > always follows basically the same pattern. Not when TOFU pins just the public key in the leaf cert. Nothing about the chain is then relevant, and the same SHA-1 questions are out of scope. > OE requires you take what would normally be a blatant catastrophic error, > but wave a wand and say it's OK for this separate use case. That may be > true, but that doesn't make it any less of a blatant catastrophic error > when that's not the case. I'm worried about having these not be completely > distinct for the same reason you don't put a self-destruct button next to > a light switch, no matter how well labeled. ;) TLS is silent on the trust model. It makes Web PKI, DANE, TOFU and OS/OE all equally possible. The peer gets the TLS credentials, the rest is up to the peer. > Also, I want the spec to anticipate some peers being incredibly stupid > and avoid making it easy to mess things up. Web PKI authentication is specified in other IETF specifications (RFC5280, RFC6125, ...). TLS just sends the rockets up, and it is not the job of TLS to care where they come down. :-) -- Viktor. ___ 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 12:33:33AM -0400, Dave Garrett wrote:
> https://github.com/tlswg/tls13-spec/pull/287
>
> PR updated with some revisions. Please take a look at some point and tell me
> what you think.
Still problematic, by changing more text than necessary. The following
is wrong and should not be added.
Just after which is largely fine (I would carve out an explicit
exception for self-signatures which are a matter of data format
necessity not trust):
"Endpoints negotiating use of TLS 1.3 MUST NOT trust any
signature that uses any of the deprecated hash algorithms
(MD5, SHA-1, & SHA-224)"
You add the incorrect:
or send any certificate relying on any deprecated hash to
its peer. (see {{server-certificate}})
This is still the same problem as before. The fix is to just as
before say no such thing, each peer sends something with a known
supported algorithm if it can, or whatever otherwise it has if it
can't. Indeed with SNI, sending the right certificate (matching
SAN) takes precedence over any considerations of algorithms. If
the none of the certificates with the right SAN have supported
algorithms, send one with an unsupported algorithm and let the peer
decide.
At which point, the next change is not needed:
-the client a certificate chain of its choice that may include algorithms
-that are not known to be supported by the client. This fallback chain MAY
-use the deprecated SHA-1 hash algorithm.
+the client a certificate chain of its choice that MAY include algorithms
+that are not known to be supported by the client.
For SHA-1 can still be sent, all that changes is that its in
signatures is no longer trusted, (but tolerated in self-signatures
which are not relevant in evaluating trust).
At which point we get to (removed original text elided, just
unchanged and new text below):
If the client cannot construct an acceptable chain using the provided
+certificates and decides to abort the handshake, then it MUST send a
+fatal alert message and close the connection. If the chain is untrustworthy
+because a certificate cannot be parsed correctly or due to use of a
+deprecated hash algorithm (MD5, SHA-1, & SHA-224), then it SHOULD produce
+a "bad_certificate" alert; otherwise it MUST produce an
+"unsupported_certificate" alert.
It is simply wrong to require any particular reaction to an untrusted
chain. Elements of the chain may expired, contain unknown (more
modern?) algorithms, and yet the handshake can continue in trust
models which don't need the problematic portion of the chain.
TLS does not mandate a trust model, it supports Web PKI trust more
directly than other models, but that's as far as it goes.
TLS can say that certificates with SHA-1 are no longer to be trusted.
Some such intermediate certificates sent by a peer may not even
end up in the (alternative) chain the verifier builds. Or the
verifier may not validate any certificate chain at all.
+Servers supporting both TLS 1.2 and TLS 1.3 MAY negotiate TLS 1.2 with
+support for SHA-1 hashes, however servers MUST NOT downgrade to use an
+older version in response to a TLS 1.3 client offering support for only
+deprecated or unsupported hashes. All clients offering TLS 1.3 are REQUIRED
+to offer support for at least one hash/signature pair which is not
deprecated
+(see {{signature-algorithms}}).
This is fine, and applies to TLS PRFs, ... but the certificate
chain can still contain (untrusted) SHA-1 signatures even with TLS
1.3.
+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 presence MUST NOT terminate the handshake, mandating
this at the TLS layer is a layer violation. Trust is an application
layer problem.
Also the below is not appropriate:
+- Have you ensured that certificate chains using SHA-1 or SHA-224
+ are only used with TLS 1.2 or older, or are prohibited completely?
+
And this:
+- When the client has requested a server certificate, but no
+ suitable certificate chain is available, do you correctly send a
+ valid fallback chain using whatever TLS 1.3 permitted algorithms
+ are necessary, instead of immediately aborting the connection?
+
The fallback chain can contain anything at all. CRC-32 if need
be. Only SHA2-256, equivalent or better is to be trusted, but
that's a decision for the next layer up.
This pull request needs to simply specify that digest algorithms
other than SHA2-256 and SHA2-384 (plus any speficified in future
RFCs as sufficiently strong) are to be trusted by default.
Some clients may accept GOST signatures, that's a local matter for
those clients. And we may yet see some subset of SHA3-256, SHAKE256,
Blake2, ... in certificates.
This draf
