Re: [TLS] I-D Action: draft-ietf-tls-curve25519-01.txt
On Sunday 12 July 2015 16:39:37 Simon Josefsson wrote:
> Hubert Kario writes:
> > As is described in secion 5.1. of RFC 4492, and then reiterated in
> > section 2.2. of this draft - the elliptic_curves (a.k.a. supported_groups)
> > guides both the ECDH curves and curves understandable by peer for ECDSA
> > signatures.
> >
> > As Curve25519 and Curve448 can only be used for ECDHE, maybe they should
> > be
> >
> > defined/named in the registry as such, to remove any ambiguity[1]:
> > enum {
> >
> > Curve25519_ecdh(TBD1),
> > Curve448_ecdh(TBD2),
> >
> > } NamedCurve;
>
> I don't care strongly. One disadvantage with this is that if we decide
> to reuse these NamedCurve allocations to have something to do with
> Ed25519, the naming above will be confusing. However, I believe it is
> already likely that Ed25519 will have its own NamedCurve.
Given that there certainly will be implementations that support ecdh and not
the signatures, we certainly *don't* want to reuse this codepoint for anything
else.
So unless the PKIX and TLS parts are defined at the same time, in the same
document, we definitely need to keep them apart.
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
On Saturday 11 July 2015 17:09:27 Dave Garrett wrote: > On Saturday, July 11, 2015 04:48:10 pm Viktor Dukhovni wrote: > > Largely close enough. Feel free to borrow any text from the below > > that you find to be an improvement. > > > > > > > > Whenever possible, all certificates provided by the server > > SHOULD be signed by a hash/signature algorithm pair indicated > > by the client's supported algorithms extension (or the defaults > > assumed in its absence). If the server cannot produce a > > certificate chain that is signed via only the indicated supported > > pairs, then it SHOULD continue the handshake by sending the > > client a certificate chain of its choice that may include > > hash/signature algoriths that are not known to be supported by > > the client. > > > > The public key in the leaf certificate must of course be > > compatible with the chosen cipher-suite, and the subsequent > > ServerKeyExchange message must be signed via a mutually supported > > hash/signature algorithm pair. > > > > If the client cannot construct a satisfactory chain using the > > provided certificates and decides to abort the handshake, then > > it MUST send an "unsupported_certificate" alert message and > > close the connection. > > > > > > The middle bit is already in existing text above the section in question. > > New version with a little rewording and a typo fix. > > \/ > > > All certificates provided by the server SHOULD be signed by a > hash/signature algorithm pair indicated by the client's > "signature_algorithms" extension (or the defaults assumed in > its absence), where possible. If the server cannot produce a > certificate chain that is signed only via the indicated supported > pairs, then it SHOULD continue the handshake by sending the > client a certificate chain of its choice that may include algorithms > that are not known to be supported by the client. If the client > cannot construct an acceptable chain using the provided certificates > and decides to abort the handshake, then it MUST send an > "unsupported_certificate" alert message and close the connection. > What about the cert chain offered by client to server as a response to Certificate Request message? They are also under the limitation of using just the signature algorithms advertised as supported by server. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
Viktor Dukhovni wrote:
> Andrei Popov wrote:
>>
>> When old algorithms are deprecated and new algorithms replace them in
>> actual deployments (a very slow process), an opportunistic client would
>> need to be updated, just like a normal server-authenticating client does.
>> Except for the opportunistic client this update would be rather trivial.
>>
>> Alternatively, can an opportunistic client explicitly negotiate
>> anonymous connections?
>
> Postfix tries to, as hard as it can, but many servers do not offer
> anon_DH cipher suites, and under-informed auditors give system
> administrators a hard time when they are offered.
anon_DH cipher suites are a true security problem, in particular with
clients that perform server endpoint identification as a mere side-effect
of processing the server's TLS Certificate handshake message (such as
through a callback) rather than as a mandatory verification step at
the end of a successful TLS handshake.
Anonymous cipher suites are regularly not just "not offered by servers",
they might not even be implemented in the server's TLS implementation.
We don't support them, and I didn't notice any such cipher suites
on these lists, either:
https://msdn.microsoft.com/library/aa374757.aspx
https://support.microsoft.com/en-us/kb/2929781
https://technet.microsoft.com/en-us/library/dn786419.aspx
Btw., anonymous TLS ciphersuites have been officially deprecated
already in TLSv1.0 (rfc2246) in 1999, several years before deprecation
of the export-crypto cipher suites:
https://tools.ietf.org/html/rfc2246#page-55
The following cipher suites are used for completely anonymous
Diffie-Hellman communications in which neither party is
authenticated. Note that this mode is vulnerable to man-in-the-middle
attacks and is therefore deprecated.
CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
-Martin
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-curve25519-01.txt
Hubert Kario writes:
> On Sunday 12 July 2015 16:39:37 Simon Josefsson wrote:
>> Hubert Kario writes:
>> > As is described in secion 5.1. of RFC 4492, and then reiterated in
>> > section 2.2. of this draft - the elliptic_curves (a.k.a. supported_groups)
>> > guides both the ECDH curves and curves understandable by peer for ECDSA
>> > signatures.
>> >
>> > As Curve25519 and Curve448 can only be used for ECDHE, maybe they should
>> > be
>> >
>> > defined/named in the registry as such, to remove any ambiguity[1]:
>> > enum {
>> >
>> > Curve25519_ecdh(TBD1),
>> > Curve448_ecdh(TBD2),
>> >
>> > } NamedCurve;
>>
>> I don't care strongly. One disadvantage with this is that if we decide
>> to reuse these NamedCurve allocations to have something to do with
>> Ed25519, the naming above will be confusing. However, I believe it is
>> already likely that Ed25519 will have its own NamedCurve.
>
> Given that there certainly will be implementations that support ecdh
> and not the signatures, we certainly *don't* want to reuse this
> codepoint for anything else.
>
> So unless the PKIX and TLS parts are defined at the same time, in the same
> document, we definitely need to keep them apart.
It is conceivable to reuse the NamedCurve values for TLS authentication
without affecting the ECHDE use, nor delaying the Curve25519 ECDHE work.
Compare how we "reuse" the ECDHE ciphersuite values to refer to
Curve25519 (instead of defining new ciphersuites for Curve25519), and
how we are "reusing" the "uncompressed" code point to refer to
Curve25519-compressed code points (instead of defining new
ECPointFormat).
Allocating new values when that creates additional costs and no improved
clarity seems wasteful to me. This approach is what people have
suggested for most other allocations here, so I prefer to stick to that
philosophy unless it is clear that there is consensus for something
else. What do others think?
/Simon
signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
On Tue, Jul 14, 2015 at 11:31:26AM +0200, Hubert Kario wrote: > > > > All certificates provided by the server SHOULD be signed by a > > hash/signature algorithm pair indicated by the client's > > "signature_algorithms" extension (or the defaults assumed in > > its absence), where possible. If the server cannot produce a > > certificate chain that is signed only via the indicated supported > > pairs, then it SHOULD continue the handshake by sending the > > client a certificate chain of its choice that may include algorithms > > that are not known to be supported by the client. If the client > > cannot construct an acceptable chain using the provided certificates > > and decides to abort the handshake, then it MUST send an > > "unsupported_certificate" alert message and close the connection. > > > > What about the cert chain offered by client to server as a response to > Certificate Request message? > > They are also under the limitation of using just the signature algorithms > advertised as supported by server. Exactly the same strategy should apply when client certificates are in use, send compatible if possible, else send something you have. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-curve25519-01.txt
On Tue, Jul 14, 2015 at 05:23:44PM +0200, Simon Josefsson wrote: > Hubert Kario writes: > > > So unless the PKIX and TLS parts are defined at the same time, in the same > > document, we definitely need to keep them apart. > > It is conceivable to reuse the NamedCurve values for TLS authentication > without affecting the ECHDE use, nor delaying the Curve25519 ECDHE work. > > Compare how we "reuse" the ECDHE ciphersuite values to refer to > Curve25519 (instead of defining new ciphersuites for Curve25519), and > how we are "reusing" the "uncompressed" code point to refer to > Curve25519-compressed code points (instead of defining new > ECPointFormat). Well, allowing curve to set point format isn't much of a stretch (and in fact, TLS 1.3 as of currently requires this). If one does only "uncompressed" format, all current ECDHE curves work as a triple: - Keybytes: How many bytes of private key it wants. - Generate: Take in private key, output public key. - Agree: Take in private key and peer public key, output premaster secret (or ES/SS in TLS 1.3). (Instantiating that for both uncompressed NIST P-256 and Curve25519 is left as an simple excercise). > Allocating new values when that creates additional costs and no improved > clarity seems wasteful to me. This approach is what people have > suggested for most other allocations here, so I prefer to stick to that > philosophy unless it is clear that there is consensus for something > else. What do others think? Well, that would imply that implementation that supports Curve25519 and/ or Curve448 sigs has to also do ECDHE with exactly those curves. And conversely, anything that does both Curve25519 and Curve448 ECDHE and does signatures with either has to do signatures with both. In implementation, signatures are quite a bit more complicated than ECDHE. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
On Tue, Jul 14, 2015 at 03:46:12PM +0200, Martin Rex wrote:
[ There's no need to belabour the obvious, yes unauthenticated TLS
does not protect against active attacks, absent authenticated
channel binding post handshake. This does not mean that the are
no appropriate use-cases for anon_DH and anon_ECDH. ]
>https://tools.ietf.org/html/rfc2246#page-55
>
>The following cipher suites are used for completely anonymous
>Diffie-Hellman communications in which neither party is
>authenticated. Note that this mode is vulnerable to man-in-the-middle
>attacks and is therefore deprecated.
>
> CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
> CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
> CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
> CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
> CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
Which still leaves us with (sorry about the OpenSSL-specific names):
AECDH-AES256-SHASSLv3 Kx=ECDH Au=None Enc=AES(256) Mac=SHA1
ADH-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD
ADH-AES256-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(256) Mac=SHA256
ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1
ADH-CAMELLIA256-SHA SSLv3 Kx=DH Au=None Enc=Camellia(256) Mac=SHA1
AECDH-AES128-SHASSLv3 Kx=ECDH Au=None Enc=AES(128) Mac=SHA1
ADH-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=None Enc=AESGCM(128) Mac=AEAD
ADH-AES128-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(128) Mac=SHA256
ADH-AES128-SHA SSLv3 Kx=DH Au=None Enc=AES(128) Mac=SHA1
ADH-CAMELLIA128-SHA SSLv3 Kx=DH Au=None Enc=Camellia(128) Mac=SHA1
AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1
As for "ADH" and "AECDH" being "insecure", that rather depends on
the threat model, and presumption of lack of channel binding.
For opportunistic TLS in SMTP, the threat model does not include
active attacks. Active attackers can in any case suppress "STARTTLS",
use some random certificate (the client performs no authentication
anyway), ... Denying the client anon TLS is pointless, and loses
audit information on the server side.
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-1.3
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-8.2
If the recently proposed changes to cipher suite negotiation bear
fruit, perhaps there'll some day again be a reasonably complete/current
set of anon_ECDH ciphers to work with.
--
Viktor.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
Using anonymous cipher suites for opportunistic connections allows the server
operator to explicitly enable anonymous connections, and it saves bytes on the
wire.
The downside is of course that the attacker can easily distinguish
opportunistic clients from server-authenticating ones. Is this a concern for
the opportunistic TLS community?
-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Viktor Dukhovni
Sent: Tuesday, July 14, 2015 12:16 PM
To: tls@ietf.org
Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3
draft-07 sneak peek)
On Tue, Jul 14, 2015 at 03:46:12PM +0200, Martin Rex wrote:
[ There's no need to belabour the obvious, yes unauthenticated TLS
does not protect against active attacks, absent authenticated
channel binding post handshake. This does not mean that the are
no appropriate use-cases for anon_DH and anon_ECDH. ]
>https://tools.ietf.org/html/rfc2246#page-55
>
>The following cipher suites are used for completely anonymous
>Diffie-Hellman communications in which neither party is
>authenticated. Note that this mode is vulnerable to man-in-the-middle
>attacks and is therefore deprecated.
>
> CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
> CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
> CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
> CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
> CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
Which still leaves us with (sorry about the OpenSSL-specific names):
AECDH-AES256-SHASSLv3 Kx=ECDH Au=None Enc=AES(256) Mac=SHA1
ADH-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD
ADH-AES256-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(256) Mac=SHA256
ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1
ADH-CAMELLIA256-SHA SSLv3 Kx=DH Au=None Enc=Camellia(256) Mac=SHA1
AECDH-AES128-SHASSLv3 Kx=ECDH Au=None Enc=AES(128) Mac=SHA1
ADH-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=None Enc=AESGCM(128) Mac=AEAD
ADH-AES128-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(128) Mac=SHA256
ADH-AES128-SHA SSLv3 Kx=DH Au=None Enc=AES(128) Mac=SHA1
ADH-CAMELLIA128-SHA SSLv3 Kx=DH Au=None Enc=Camellia(128) Mac=SHA1
AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1
As for "ADH" and "AECDH" being "insecure", that rather depends on the threat
model, and presumption of lack of channel binding.
For opportunistic TLS in SMTP, the threat model does not include active
attacks. Active attackers can in any case suppress "STARTTLS", use some random
certificate (the client performs no authentication anyway), ... Denying the
client anon TLS is pointless, and loses audit information on the server side.
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-1.3
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-8.2
If the recently proposed changes to cipher suite negotiation bear fruit,
perhaps there'll some day again be a reasonably complete/current set of
anon_ECDH ciphers to work with.
--
Viktor.
___
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] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
On 14 July 2015 at 12:30, Andrei Popov wrote: > The downside is of course that the attacker can easily distinguish > opportunistic clients from server-authenticating ones. Is this a concern for > the opportunistic TLS community? I raised the concern about this previously. Opportunistic MitM happens, and providing a strong signal that the connection won't be (or couldn't be) authenticated somehow is a problem for that. I'd rather have opportunistic security be indistinguishable from "real" security. It also means that you don't have separate code paths to support. The anonymous modes serve a different purpose. For instance tcpinc could use them. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
If opportunistic TLS handshakes need to be indistinguishable from server-authenticated TLS handshakes, then perhaps opportunistic clients have no choice but to send the signature_algorithms extension (when offering TLS1.2). The absence of signature_algorithms in a TLS 1.2 ClientHello can be used as a signal by the MITM. -Original Message- From: Martin Thomson [mailto:martin.thom...@gmail.com] Sent: Tuesday, July 14, 2015 12:56 PM To: Andrei Popov Cc: tls@ietf.org Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) On 14 July 2015 at 12:30, Andrei Popov wrote: > The downside is of course that the attacker can easily distinguish > opportunistic clients from server-authenticating ones. Is this a concern for > the opportunistic TLS community? I raised the concern about this previously. Opportunistic MitM happens, and providing a strong signal that the connection won't be (or couldn't be) authenticated somehow is a problem for that. I'd rather have opportunistic security be indistinguishable from "real" security. It also means that you don't have separate code paths to support. The anonymous modes serve a different purpose. For instance tcpinc could use them. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
On Tue, Jul 14, 2015 at 07:30:38PM +, Andrei Popov wrote: > Using anonymous cipher suites for opportunistic connections allows the > server operator to explicitly enable anonymous connections, and it saves > bytes on the wire. Yes, and informs the server that the client is skipping authentication, which is often useful information on the server end. Is it a common mistake to suggest that servers should disable anon_DH, that advice is appropriate for most clients, but is mostly wrong for servers. Servers might in some cases want to minimize what they present to clients that connect with anon_DH ciphers, but they can't typically do that when they preclude the negotiation of anon_DH. > The downside is of course that the attacker can easily distinguish > opportunistic clients from server-authenticating ones. Is this a concern > for the opportunistic TLS community? A minor concern, but a determined adversary has many ways to figure out which client/server pairs don't involved server certificate checks. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
On Tue, Jul 14, 2015 at 08:06:19PM +, Andrei Popov wrote: > If opportunistic TLS handshakes need to be indistinguishable from > server-authenticated TLS handshakes, then perhaps opportunistic clients > have no choice but to send the signature_algorithms extension (when offering > TLS1.2). The absence of signature_algorithms in a TLS 1.2 ClientHello can > be used as a signal by the MITM. Nobody is suggesting that opportunistic clients employ the extension in question differently from other clients. The proposal under discussion is about how servers respond when their certificate chain is not unequivocally compatible. Correct server behaviour is to return some sort of chain, and let the client decide. TLS used by opportunistic TLS clients, largely looks the same as TLS used by other clients, except that anon_DH may be offered, which has little bearing on the signature algorithms extension. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
On 14 July 2015 at 13:08, Viktor Dukhovni wrote: > Yes, and informs the server that the client is skipping authentication, > which is often useful information on the server end. The problem here is that the server isn't the only recipient of that signal. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
On Tue, Jul 14, 2015 at 01:49:36PM -0700, Martin Thomson wrote: > On 14 July 2015 at 13:08, Viktor Dukhovni wrote: > > Yes, and informs the server that the client is skipping authentication, > > which is often useful information on the server end. > > The problem here is that the server isn't the only recipient of that signal. You forgot to mention that an on-path MiTM can hide the fact the client is doing it from the server. For clients doing unauthenticated TLS active attacks are not what they are defending against. None of this is news. We should stop here. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
