Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 1 Jul 2015 15:15:26 +0300

On Tue, Jun 30, 2015 at 10:33:23PM -0700, Eric Rescorla wrote:
> On Tue, Jun 30, 2015 at 10:22 PM, Ilari Liusvaara <
> [email-masked]> wrote:
> 
> > On Tue, Jun 30, 2015 at 03:23:18PM -0700, Eric Rescorla wrote:
> > >
> > > OPEN ISSUES
> > > There are still a number of known open issues to discuss:
> > >
> > > 1. The present known_configuration mechanism allows the client to
> > > resurrect the handshake parameters (though not the keys) which were
> > > negotiated in a previous handshake, but this is done implicitly,
> > > i.e., the server provides a label and the client returns it on
> > > the next connection. This has the advantage of keeping things short
> > > but the disadvantage the it means that you can't have a static
> > > configuration ID for everyone (instead, the server has to somehow
> > > embed the properties in the configuration ID). There are (at least)
> > > three potential alternative designs:
> > >
> > >    (a) Have the client indicate in his first flight "these are the
> > >        parameters I expect you to negotiate", along with the
> > >        configuration identifier, based on what the server
> > >        negotiated the previous time. [Optionally, the server
> > >        can run the same negotiation locally and abort on mismatch.]
> > >
> > >    (b) As in (a) but with no indication of the expected parameters,
> > >        just the configuration ID, and the client just preemptively
> > >        uses the parameters from the last time and if the negotiation
> > >        ends up differently, all the data is undecryptable
> > >        (ugh) and you somehow fall back.
> > >
> > >    (c) Have the server provide a preference list in his
> > >        ServerConfiguration (this can be the same as in the
> > >        ClientHello) and have the client do the negotiation based on
> > >        that rather than the server (as in QUIC). This is a little odd
> > >        in that it means that sometimes the server selects the
> > >        parameters and sometimes the client does, but it's not that
> > >        hard to make this code symmetrical.
> > >
> > > As I think this through, I am leaning towards (a) but other people's
> > > opinions on this topic would be welcome.
> >
> > I think that there should be capability for server to fail decrypting
> > the 0RTT data but still proceed with handshake (informing client of
> > this fact).
> >
> 
> What I had in mind here was that you would be able to fail to decrypt
> the 0-RTT data and you fell back to an ordinary 1-RTT handshake
> (i.e., if there was client auth, it went in the second flight).

Without a retry, right? 

> Are parameters here things like symmetric ciphersuite used for 0RTT
> > encryption? Or something else? I think that even if one uses supported
> > symmetric ciphers, one could still get decrypt failures.
> >
> > Or is this the "PSK + 0RTT" vs "DHE + 0RTT" problem (the one remaked
> > in #3)?
> >
> 
> Sorry, I'm not quite following this. Can you rephrase?

Say, one has DHE-CERT (for full handshake) and pure-PSK (for resumption)
key exchanges signaled. Which one provodes the key to decrypt the 0-RTT
data (because the keys sure won't be the same)? 
 
> > Undecryptable 0RTT becomes practicularly fun when considering how
> > that would interact with handshake transcripts.
> 
> That's why I'm thinking that the above is the simpler approach.

Well, if handshake is not retried and 0RTT is rejected (i.e. server
replies with Finished in its reply), it shouldn't matter very much what
is in 0RTT data.

Then there's the more fun case of where handshake that has 0RTT data is
retried (e.g. missing group key). One needs to ensure transport
consistency[1] on retry as well as preferably defending against clients
and servers doing dumb things (experience has shown that all kinds of
dumb bugs creep in, despite MUST specifically against the behaviour in
question).

> > > 2. Should we require that PSK cipher suites where the PSK is used for
> > > resumption use compatible ciphers? This is the way it was in TLS 1.2
> > > and below for resumption and tickets, but once you have a PSK, that's
> > > not really necessary [0]. So, for instance, if you had the following
> > > cipher list order:
> > >
> > >     ECDHE + AES-GCM
> > >     ECDHE + ChaCha/Poly
> > >     PSK + ChaCha/Poly
> > >     PSK + AES-GCM
> > >
> > > You could potentially negotiate one connection with GCM, use it
> > > to establish a shared key, and then reconnect with ChaCha/Poly.
> > > This seems like it probably should be something we avoid, though
> > > I'm not sure we have a concrete reason why, and it means a
> > > weird special case for PSK. Note that this issue might be
> > > ameliorated some (though not completely) with a la carte negotiation.
> >
> > I would place stuff like this into "client sending odd stuff and
> > getting odd behaviour in response". And with the negotiation the
> > way it is, I don't see security problem here.
> 
> Thanks.

More specifically, if there's a problem here, pure-PSK also has that
problem (and more severe one). And due to THS fix, it is not possible
to perform dangerous actions like keying two different ciphers with the
same key.

[1] Renego bug actually involved inconsistent transport state, as well
as two different things looking confusingly similar.

-Ilari

---

From: Hanno Böck <[email-masked]>
Date: Thu, 2 Jul 2015 16:45:36 +0200

Hi,

We recently had discussions about DSA and RSA padding modi. The draft
still contains DSA and wants RSA in the old PKCS #1 1.5 padding
mode.

I think there was broad consensus to remove DSA, it's still in the
draft. Would a Pull Request to remove it be welcome?

On RSA there was only limited discussion, but I had the impression
there is hardly an argument for not going with PSS

cu, Hanno
-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 2 Jul 2015 09:41:26 -0700

> still contains DSA and wants RSA in the old PKCS #1 1.5 padding

Yes, these are orthogonal changes, I think.

> draft. Would a Pull Request to remove it be welcome?

I'll defer to the chairs on this point. If they declare consensus, I'll
merge a PR.

> there is hardly an argument for not going with PSS

We clearly can't go entirely to PSS as certificates have already been
signed.
We could require that the CertificateVerify be signed with PSS.

-Ekr

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Hubert Kario <[email-masked]>
Date: Fri, 03 Jul 2015 19:23:19 +0200

On Tuesday 30 June 2015 15:23:18 Eric Rescorla wrote:
> Folks,
> 
> Yesterday, I posted the -06 draft which snapshots the consensus changes
> made since -05, specifically:
> 
> - Prohibit RC4 negotiation for backwards compatibility.
> - Freeze & deprecate record layer version field.
> - Update format of signatures with context.
> - Remove explicit IV.

I've noticed that the default values in case the client didn't use signature 
algorithms extensions is to use SHA1+RSA, SHA1+DSA and SHA1+ECDSA.

As we all know, those are not considered secure now.

Maybe we should update it to SHA256 for all three?

-- 
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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Jul 2015 10:34:41 -0700

> Maybe we should update it to SHA256 for all three?

I would welcome a PR for that.

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Fri, 3 Jul 2015 13:34:44 -0400

> Maybe we should update it to SHA256 for all three?

No point; usage of the extension is probably going to be mandatory. If so, we can just remove the defaults bit.

Dave

---

From: Hubert Kario <[email-masked]>
Date: Fri, 03 Jul 2015 19:43:08 +0200

On Friday 03 July 2015 13:34:44 Dave Garrett wrote:
> > I've noticed that the default values in case the client didn't use
> > signature algorithms extensions is to use SHA1+RSA, SHA1+DSA and
> > SHA1+ECDSA.
> > 

It will be better to have it updated and then removed than not updated, 
forgotten and published, don't you think?

---

From: Hubert Kario <[email-masked]>
Date: Fri, 03 Jul 2015 19:53:45 +0200

On Friday 03 July 2015 10:34:41 Eric Rescorla wrote:
> > signature

Done:
https://github.com/ekr/tls13-spec/pull/12

---

From: Dave Garrett <[email-masked]>
Date: Fri, 3 Jul 2015 15:16:10 -0400

> forgotten and published, don't you think?

Sure, that's fine too.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Jul 2015 15:22:21 -0700

> https://github.com/ekr/tls13-spec/pull/12
 [Make {sha256, xxx} the default signature algorithm extension value
when the extension is absent]

There is a problem with this, and I think that you need to highlight
that in the text.

The reason that this doesn't work particularly well, though it
probably isn't strictly problematic, is that now you have an extension
that means one thing {sha1, rsa} when you negotiate TLS <= 1.2 and
another thing {sha256, rsa} when you negotiate TLS 1.3.  Maybe that's
OK, but it narrows the utility of having a default.

Please add the following (or similar):
A TLS 1.3 client that is willing to do TLS <= 1.2 MUST include the
extension unless it supports SHA-256 for TLS 1.3 and SHA-1 for TLS <=
1.2.

---

From: Hubert Kario <[email-masked]>
Date: Sat, 04 Jul 2015 00:29:28 +0200

> extension unless it supports SHA-256 for TLS 1.3 and SHA-1 for TLS <=

Hmm, true, I'll fix it.

And while we're at it, maybe a security recommendation stating that 
advertising support for sha-1 and md-5 is not recommended?
-- 
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

---

From: Dave Garrett <[email-masked]>
Date: Fri, 3 Jul 2015 19:07:13 -0400

> advertising support for sha-1 and md-5 is not recommended?

I'm already handling some of this topic over here:
https://github.com/tlswg/tls13-spec/pull/188/files
see also:
https://github.com/tlswg/tls13-spec/issues/186

That deals with MD5 but I don't have anything for SHA1 being not recommended, yet. I was thinking that we should probably come up with a deprecation timeline to write in the spec that lines up with what vendors are already doing. That PR was just for completely removed capabilities, though. Eric said he'd have review of this PR on his todo list soon, so a new PR for the SHA1 stuff is probably best. I might work on writing up something for that next.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Jul 2015 16:13:15 -0700

I think we probably need to have WG consensus for the SHA-1 thing.
Sean?

-Ekr

On Fri, Jul 3, 2015 at 4:07 PM, Dave Garrett <[email-masked]> wrote:

> That deals with MD5 but I don't have anything for SHA1 being not
> recommended, yet. I was thinking that we should probably come up with a
> deprecation timeline to write in the spec that lines up with what vendors
> are already doing. That PR was just for completely removed capabilities,
> though. Eric said he'd have review of this PR on his todo list soon, so a
> new PR for the SHA1 stuff is probably best. I might work on writing up
> something for that next.
>
>
> Dave
>

---

From: Dave Garrett <[email-masked]>
Date: Fri, 3 Jul 2015 19:25:04 -0400

> I think we probably need to have WG consensus for the SHA-1 thing.

Yes, that's why I left it out of that changeset. I don't think the topic of what to do in the TLS 1.3 spec with SHA1 has been discussed on this list. (if it has, please point me to the thread if someone can)

The simplest thing would be to have a MUST NOT offer or negotiate in 2017 or later and a NOT RECOMMENDED to use until then. Or, we could go deeper into the weeds and talk about expiration dates. Banning it totally for TLS 1.3+ is also an option, but probably not wanted yet.

Regardless of the exact details, the signatures extension needs to be mandatory, so adding an MTI extensions section (as previously discussed) first is probably a good idea. As noted earlier in this thread, this would fix the issue of SHA1 as defaults.

Dave

---

From: [email-masked] (Martin Rex)
Date: Sat, 4 Jul 2015 01:54:27 +0200 (CEST)

> there is hardly an argument for not going with PSS

You seem to believe that RSA-PSS is better than PKCS#1 v1.5 signature
padding.  Could you elaborate why you believe this to be?

It was my impression that RSA-PSS adds complexity and slows down
things and very close to nothing else -- unless you have direct low-level
access to an RSA crypto hardware token and want to extract the RSA
private key from it through the software interface.

A significant amount of TLS usage scenarios do not use dedicated
RSA crypto hardware, and those who don't, will have to pay for RSA-PSS,
but not see any benefit.  And even those that do have the RSA crypto
hardware -- allowing PKCS#1 v1.5 access will be necessary as long
as interop based on TLSv1.0 through TLSv1.2 is still necessary,
which may be quite some time.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Sat, 4 Jul 2015 02:16:38 +0200 (CEST)

Martin Thomson wrote:
> Hubert Kario <[email-masked]> wrote:
> 

The two weak RSA signature algorithms {md5,rsa} and {sha1,rsa} were
security vulnerability that were deliberately ADDED to TLSv1.2.

All prior protocol versions, including SSLv3, are using RSA signatures
with a 278-bit hash (a concatenation of sha1+md5), which is a reasonable
and conservative design.  Given that this TLS-specific signature
scheme had been used successfully for more than a decade when TLSv1.2
was specified, it is difficult to understand why this was deliberately
weakened in TLSv1.2, rather than using the straight forward safe
solution to define a codepoint for { sha1+md5, rsa } to identify
the SSLv3->TLSv1.1 RSA signature transform for use in TLSv1.2
rather than newly adding and allowing the well-known weak signature
schemes {md5,rsa} and {sha1,rsa} (and de-facto mandating support
for the latter).

-Martin

---

From: Dave Garrett <[email-masked]>
Date: Fri, 3 Jul 2015 20:38:38 -0400

> schemes {md5,rsa} and {sha1,rsa} (and de-facto mandating support

Yeah, that was a weird choice.

I'm curious; how much more secure can SHA1+MD5 be considered in comparison to SHA1? For that matter, how strong is it in comparison to SHA256? Its strength would theoretically be stronger than the sum of its parts, though I don't know by how much. I'm wondering if there's a study on this topic somewhere that someone might be able to point me to.

Dave

---

From: Quynh Dang <[email-masked]>
Date: Fri, 3 Jul 2015 20:58:30 -0400

The ineffectiveness issue of cascading hashes has been widely known for a
long time ago.

Find block X and block X' which have collided hash for SHA1 which takes
around 2^70 operations or possibly less.

Finding a block N for which X|| N and X' || N have collided hash for MD5
which is expected to have very low complexity (finding collision for MD5).

Therefore, finding collisions for SHA1 and collisions for SHA1 || MD5
require about the same computational complexity.

Quynh.

On Fri, Jul 3, 2015 at 8:38 PM, Dave Garrett <[email-masked]> wrote:

> I'm curious; how much more secure can SHA1+MD5 be considered in comparison
> to SHA1? For that matter, how strong is it in comparison to SHA256? Its
> strength would theoretically be stronger than the sum of its parts, though
> I don't know by how much. I'm wondering if there's a study on this topic
> somewhere that someone might be able to point me to.
>
>
> Dave
>

---

From: [email-masked] (Martin Rex)
Date: Sat, 4 Jul 2015 05:11:01 +0200 (CEST)

> The ineffectiveness issue of cascading hashes has been widely known for a

Are you thinking of research like this:

http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf

> require about the same computational complexity.

I'm not a cryptographer.  I have just found the above paper with google
and just skimmed over it, and it looks a little misleading to me.

Collision attacks and preimage attacks are not the same.
finding a practial collision attack will not give you an
equivalent practical preimage attack for free.
Practical collision attacks against MD5 have been demonstrated.
Did I miss the publication of a practical MD5 preimage attack?

The reason why I prefer the conservative design of the concatenated
hashes is _not_ because their security adds up as if it were a
single hash algorithm of the combined bitsize (because it doesn't),
but because the attacks against individual algorithms will not add up
as if it was a single algorithm (because it isn't). 

-Martin

---

From: [email-masked] (Martin Rex)
Date: Sat, 4 Jul 2015 05:42:18 +0200 (CEST)

> require about the same computational complexity.

The previously mentioned paper 

describes the issue for two arbitrary hash algorithms F and G
with bit sizes nF and nG and you say this applies to

  F= md5  nF=128 bit
  G= sha1 nG=160 bit

  and that the security of F||G would be no stronger than the larger
  of the two (G alone, nG=160).

OK, lets take two other hash algorithms F and G, and even use
a weaker algorithm F with nF=96 and G with nG=160.
The assertion is, that he security of F||G would still be only 160.

OK, here are my algorithms F and G:

  F= sha-256, truncated to bits 0..95 of the output
  G= sha-256, truncated to bits 96..256 of the output

Now if your original assertion is true, then the strength of
F(m)||G(m) which curiously happens to be identical to the output of
sha256 for the message (m) has a security of only 160 bits?

Or lets look at a concatenation of 8 hashes of 32-bits each.

 F=sha-256, truncated to bits 0..31 of the output
 ... 

-Martin

---

From: "Dang, Quynh" <[email-masked]>
Date: Sat, 4 Jul 2015 12:30:19 +0000

Hi Martin,

I talked about this issue at the interim meeting in Denver last year. A lot of people there who were very good at crypto, but were not aware of this issue.  In another word, nobody knows all. So, being not aware of something is common to everyone.

Let me explain one of your examples and I hope that will help to make the issue clear.

"OK, here are my algorithms F and G:

  F= sha-256, truncated to bits 0..95 of the output
  G= sha-256, truncated to bits 96..256 of the output"

It takes approximately 2^48 operations to find a block X and X' (X and X' can be any blocks) as long as their 96-bit hash values ( F) are the same.

It takes approximately 2^80 operations to find a block N (N can be any block) so that 160-bit hash values (G) of X|| N and X'|| N are the same.

So, the work required to find a collision for G is  2^80 and the work required to find a collision for F || G is 2^48 + 2^80 and 2^48 is like nothing when being compared to 2^80.

Happy the 4th of July!

Quynh.

________________________________________
From: TLS <[email-masked]> on behalf of Martin Rex <[email-masked]>
Sent: Friday, July 3, 2015 11:42 PM
To: Quynh Dang
Cc: [email-masked]
Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek

  F= md5  nF=128 bit
  G= sha1 nG=160 bit

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Sat, 4 Jul 2015 06:31:15 -0700

But these assertions below are not what the paper actually claims!
It's important to actually read the paper, and see that the claims
apply to hash functions of a particular form, namely iterated ones.
The functions mentioned in your counterexample are not iterated hash
functions in the sense of the paper.

Nor, if you believe that the designers of TLS got ciphersuite
negotiation correct, is the claimed "vulnerability" a vulnerability.
If the security of the scheme used by A and B was the strongest in the
intersection, having MD5 based schemes would be fine so long as
everyone had SHA-256 based ones. But we know now that this result
isn't true. (There is an added wrinkle, where a scheme based on a
sufficiently weak hash function will break the negotiation)

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Quynh Dang <[email-masked]>
Date: Sat, 4 Jul 2015 14:34:21 -0400

Hi Martin,

Right. The attack does not work for truncated hashes (or wide-pipe hashes)
where hash outputs are smaller than their internal chaining hash values.

Quynh.

---

From: Dave Garrett <[email-masked]>
Date: Sat, 4 Jul 2015 15:50:34 -0400

A draft for MTI extensions, as was initially discussed a while ago:

https://github.com/davegarrett/tls13-spec/compare/pruning...davegarrett:mandatoryextensions?diff=split

This adds a "missing_extension" fatal alert to properly handle the error cases. I also copied the note against using the Truncated HMAC extension from the BCP (in the backwards compatibility section, as it's not applicable to TLS 1.3+).

Dave

---

From: William Whyte <[email-masked]>
Date: Sat, 4 Jul 2015 09:19:48 -0400

So it seems this attack applies if the output size and the chaining value
size are the same, but not if they're different. The assumption you're
making is that if F(X) = F(X') then F(X|N) = F(X'|N) but that's not true if
the output of F is truncated.

William

On Sat, Jul 4, 2015 at 8:30 AM, Dang, Quynh <[email-masked]> wrote:

>
> Hi Martin,
>
> I talked about this issue at the interim meeting in Denver last year. A
> lot of people there who were very good at crypto, but were not aware of
> this issue.  In another word, nobody knows all. So, being not aware of
> something is common to everyone.
>
> It takes approximately 2^48 operations to find a block X and X' (X and X'
> can be any blocks) as long as their 96-bit hash values ( F) are the same.
>
> It takes approximately 2^80 operations to find a block N (N can be any
> block) so that 160-bit hash values (G) of X|| N and X'|| N are the same.
>
> So, the work required to find a collision for G is  2^80 and the work
> required to find a collision for F || G is 2^48 + 2^80 and 2^48 is like
> nothing when being compared to 2^80.
>
>  Happy the 4th of July!
>
>  Quynh.
>

---

From: "Dang, Quynh" <[email-masked]>
Date: Sun, 5 Jul 2015 12:15:04 +0000

In order for the attack to work, I will have to find a collision for the whole output of the compression function of the first hash function.

The attack works for MD5 || SHA1, SHA1 || SHA-256 etc...But, it does not work for the construction Martin described which provides the same security level of SHA-256.

Quynh.

________________________________
From: TLS <[email-masked]> on behalf of Quynh Dang <[email-masked]>
Sent: Saturday, July 4, 2015 2:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] TLS 1.3 draft-07 sneak peek

Hi Martin,

Right. The attack does not work for truncated hashes (or wide-pipe hashes) where hash outputs are smaller than their internal chaining hash values.

Quynh.

On Sat, Jul 4, 2015 at 9:31 AM, Watson Ladd <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Jul 3, 2015 at 8:42 PM, Martin Rex <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>

---

From: Hanno Böck <[email-masked]>
Date: Sun, 5 Jul 2015 20:19:44 +0200

> padding.  Could you elaborate why you believe this to be?

The most obvious reason is the Bleichenbacher signature forgery attack
and related issues like BERserk. I can hardly think how anything
similar could happen with PSS.
BERserk especially highlights a new problem of the old PKCS: Having a
complex encoding (ASN.1) directly inside a cryptographic function seems
like a bad idea.
I know that it is possible to implement PKCS #1 1.5 without these
issues. But the past has shown that these mistakes happen.

There's also the theoretic argument (it has a "security proof" with a
certain definition of proof), but imho the practical implications - PSS
is harder to get wrong - are more relevant.

> things

The added complexity is limited. The performance probably is hardly
measurable. It's a couple of added hash calculations. But if this is a
real concern I can try to create some benchmarks.

-- 
Hanno Böck
http://hboeck.de/

---

From: Jeffrey Walton <[email-masked]>
Date: Sun, 5 Jul 2015 23:06:13 -0400

> - Update format of signatures with context.
I think the record layer parameters need to be cryptographically bound
in the protocol. Without a binding, a bad guy can tamper with the
initial stages of the exchange an make it appear another party is
responsible for the failure. For example, a bad guy can make it
appears a particular protocol version is unsupported by a server. At
minimum, I believe it causes a hard failure in auditing.

In Krawczyk's Cryptographic Extraction and Key Derivation: The HKDF
Scheme (https://eprint.iacr.org/2010/264.pdf), here's what he says
about contextual information like record layer versions (from page 2):

    the latter is an important parameter for the KDF intended to
    include key-related information that needs to be uniquely and
    cryptographically bound to the produced key material (e.g., a
    protocol identi er, identities of principals, timestamps, etc.).

And going back to Wagner and Schneier's Analysis of the SSL 3.0
Protocol (https://www.schneier.com/paper-ssl-revised.pdf), omitting
the record layer versions violates semantic authentication (from page
):

    ... call this the Horton principle" (with apologies to Dr. Seuss)
of semantic
    authentication: roughly speaking

        "we want SSL to authenticate what was meant, not what
        was said."

    To phrase it another way,

        Eschew unauthenticated security-critical context

I know the protocol wants to avoid a hard coupling of the record layer
from the data it carries, but its a security parameter and it needs to
be tended to.

Jeff

---

From: [email-masked] (Martin Rex)
Date: Tue, 7 Jul 2015 15:01:59 +0200 (CEST)

> similar could happen with PSS.

Both are pure implementation issues, and the solution to both have been
well-known and specified several years before TLSv1.2:

http://tools.ietf.org/html/rfc3447#section-9.2

   This encoding method is deterministic and only has an encoding
   operation.

But the designers of TLSv1.2, who _newly_ added support for
BERserk-susceptible PKCS#1 v1.5 signatures failed to require
the known-safe approach.

> complex encoding (ASN.1) directly inside a cryptographic function seems

No, BERserk highlights two other issues.  Reckless spec writers
in combination with superficial implementers.

> real concern I can try to create some benchmarks.

As I've previously wrote about RSA-PSS, the real issue is not about
the transform specified in rfc3447, but about the PKIX policy crap
expected / associated with RSA-PSS, such as what rfc4055 says.

You typically have to change low-level crypto functions to be
able to pass along the crazy (and superflous) RSA-PSS algorithm
parameters around (and the parameters necessary to be able to
perform the expected policy checks).

ECDSA signatures are much easier to accomodate with existing APIs
(they have other problems).

-Martin

---

From: "Dang, Quynh" <[email-masked]>
Date: Tue, 7 Jul 2015 14:04:40 +0000

Hi Eric,

Since the key derivation method is the HKDF method, I think the current PRF (in TLS 1.2) should be removed/changed. The key-expansion step in the HKDF should be used to generate keying materials.

For resumptions, will you re-run the resumption master secrets through the extraction step again or just run them through the key expansion step? I don't think the extraction step is necessary here.

Quynh.

________________________________
From: TLS <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Sent: Tuesday, June 30, 2015 6:23 PM
To: [email-masked]
Subject: [TLS] TLS 1.3 draft-07 sneak peek

Folks,

In the background, I've also been working with Hugo, Hoeteck, Karthik,
and others to develop a new draft using semi-ephemeral DH based on
Hugo's ideas as discussed in Dallas. I'm planning to merge this into
master soon and submit it as draft-07 next week, but I wanted to
e-mail the list and give people a chance to comment before I do
that. I've provided a summary of the major changes and open issues
below. Remember, this is a WIP so if you see something wrong, don't
panic, but do let me know.

CHANGES
1. Move ClientKeyShare into an extension so that the ClientHello
   is the only message in the client's first flight. This removes
   a bunch of ugliness around the "early_data" extension which
   could encapsulate handshake and application data.

2. Added a mechanism for the server to indicate a known (EC)DHE
   key/configuration which the client can then use in subsequent
   handshakes (via the known_configuration extension). The net
   effect here is that the client and server can skip over the
   signature in subsequent handshakes, which provides benefit
   when signatures are much slower than key exchange, as with
   RSA; it also enables 0-RTT.

3. Added support for 0-RTT data, both with and without
   client authentication.

4. Removed most of the support for resumption in favor of
   a mechanism proposed by Karthik where you just establish
   a PSK in connection N which you then use to key a PSK
   cipher suite in connection N+1.

All of these keying mechanisms use a unified key schedule based on two
keys the "Ephemeral Secret" (ES) and the "Static Secret"
(SS). Depending on the exact handshake type, these may be equal, but
the logic is the same regardless. In the process, I also converted
the key schedule to use HKDF (per WG consensus).

OPEN ISSUES

    ECDHE + AES-GCM
    ECDHE + ChaCha/Poly
    PSK + ChaCha/Poly
    PSK + AES-GCM

3. I don't currently have PSK/Resumption + 0-RTT working, because you
need a way to indicate the expected parameters (see point #1 above).

4. I plan to rewrite the Handshake Protocol Overview (S 6.2)
to be clearer. I hope to do this before submitting -07.

5. Security Considerations is badly out of date, so I plan to
rewrite that soon, but probably not before Prague. I also intend
to do a pretty substantial editorial cleanup pass and potentially
some restructuring after Prague.

As indicated above, this is still a WIP, so no doubt contains
a number of errors, potentially serious ones. Comments and PRs
welcome.

Thanks,
-Ekr

[0] With the exception of cryptographic concerns about the use
of the same IKM with different hash functions for HKDF, but this
is a problem that applies to any use of PSK, not just this one.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 7 Jul 2015 17:34:31 +0300

On Fri, Jul 03, 2015 at 07:25:04PM -0400, Dave Garrett wrote:
> Yes, that's why I left it out of that changeset. I don't think the
> topic of what to do in the TLS 1.3 spec with SHA1 has been discussed
> on this list. (if it has, please point me to the thread if someone
> can)
> 
> The simplest thing would be to have a MUST NOT offer or negotiate
> in 2017 or later and a NOT RECOMMENDED to use until then. Or, we
> could go deeper into the weeds and talk about expiration dates.
> Banning it totally for TLS 1.3+ is also an option, but probably not
> wanted yet.

No, the simplest thing would be to ban it entierely:
- MUST ignore entries with MD5 or SHA1 hash in
  supported_signature_algorithms, even if those are the only
  ones (which will cause handshake failure).
- MUST terminate connection with insufficient_security if MD5 or
  SHA1 is seen in DigitallySigned.algorithm.

SHA-1 is known to be seriously broken. That is way more than
enough reason to completely remove it. Especially from new
standards.

If one wants those to also apply to TLS 1.2, plus:
- MUST send signature_algorithms extension in TLS 1.2+,
  server MUST terminate connections without it.
- MUST NOT send MD5 or SHA1 entries in
  supported_signature_algorithms.

Effective immeidately for MD5, and in 1.1.2017 for SHA1
(including signature_algorithms) is separate matter
(and separate draft).

-Ilari

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Tue, 7 Jul 2015 10:54:09 -0400

Putting aside the timeline for retiring SHA-1 from certificates, which will happen
sooner than later, I think we should ban MD5 and SHA1 from client and server 
signatures in TLS 1.3. 

Recent events show that TLS servers get updated too slowly to hope
for graceful deprecation. Using the version change to remove these 
(like we removed RSA encryption and RC4) would be right thing to do

-Karthik

> On 07 Jul 2015, at 10:34, Ilari Liusvaara <[email-masked]> wrote:
>

---

From: Dave Garrett <[email-masked]>
Date: Tue, 7 Jul 2015 10:54:56 -0400

>   supported_signature_algorithms.

I very much agree that banning it entirely is the ideal route, but there were indications given that we didn't want to do this, unfortunately.

Again I'll state: by the time TLS 1.3 is done and actually being adopted, an assumption of no SHA1 will be even more expected. Servers that are playing chicken with browsers planning on dropping support for them in a matter of months can stick to TLS 1.2.

Dave

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 7 Jul 2015 14:57:24 +0000

> Putting aside the timeline for retiring SHA-1 from certificates, which will
> happen sooner than later, I think we should ban MD5 and SHA1 from client
> and server signatures in TLS 1.3.

Strongly in favor.  I see no reason why a new protocol should ever use SHA1.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Dave Garrett <[email-masked]>
Date: Tue, 7 Jul 2015 11:35:00 -0400

> Strongly in favor.  I see no reason why a new protocol should ever use SHA1.

Good. There seems to be strong support all around for this. I've updated the PR to drop SHA1 too.

PR:
Issue:

I also have a mandatory extensions patch here:
https://github.com/davegarrett/tls13-spec/compare/pruning...davegarrett:mandatoryextensions

I'll probably just submit a PR for that too in a bit.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Jul 2015 09:04:45 -0700

On Tue, Jul 7, 2015 at 7:04 AM, Dang, Quynh <[email-masked]> wrote:

>
>  Hi Eric,
>
>  Since the key derivation method is the HKDF method, I think the current
> PRF (in TLS 1.2) should be removed/changed. The key-expansion step in the
> HKDF should be used to generate keying materials.
>

Yes, that's how it's supposed to look. If I missed some PRF instances,
please point
them out.

For resumptions, will you re-run the resumption master secrets through the
> extraction step again or just run them through the key expansion step? I
> don't think the extraction step is necessary here.
>

Since we're trying to model resumption as PSK, I want to run the entire key
schedule for consistency.

-Ekr

> Quynh.
>
>  ------------------------------
> *From:* TLS <[email-masked]> on behalf of Eric Rescorla <
> [email-masked]>
> *Sent:* Tuesday, June 30, 2015 6:23 PM
> *To:* [email-masked]
> *Subject:* [TLS] TLS 1.3 draft-07 sneak peek
>
>   Folks,
>

---

From: Dave Garrett <[email-masked]>
Date: Tue, 7 Jul 2015 12:08:11 -0400

> schedule for consistency.

On that topic, it looks like you have:
"{::comment} Describe key schedule {:/comment}"

On the end of the file in the current draft.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Jul 2015 09:08:30 -0700

Let's distinguish between two different uses of SHA-1:

1. In certificates.
2. In TLS signatures.

I have no problem with insisting that TLS 1.3 not do SHA-1 for signatures in
the protocol. However, given that there are lots of SHA-1 certificates in
the
field and the world is bigger than browsers, it seems like forbidding use of
SHA-1 in certificates for TLS 1.3 (while it's still available to TLS 1.2)
acts
mostly as a disincentive to adoption for TLS 1.3, so I'm currently not in
favor of that.

-Ekr

On Tue, Jul 7, 2015 at 7:54 AM, Dave Garrett <[email-masked]> wrote:

> I very much agree that banning it entirely is the ideal route, but there
> were indications given that we didn't want to do this, unfortunately.
>
> Again I'll state: by the time TLS 1.3 is done and actually being adopted,
> an assumption of no SHA1 will be even more expected. Servers that are
> playing chicken with browsers planning on dropping support for them in a
> matter of months can stick to TLS 1.2.
>
>
> Dave
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Jul 2015 09:10:15 -0700

> https://github.com/tlswg/tls13-spec/issues/186

This PR seems to prohibit use of SHA-1 for certificates as well, which I'm
not sure
is wise. I suggest we put this on the agenda for Prague.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 7 Jul 2015 16:13:57 +0000

> This PR seems to prohibit use of SHA-1 for certificates as well, which I'm not sure

Yes, I didn't intend to outlaw SHA1 certs; perhaps a bit more finesse is required.:)

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Tue, 7 Jul 2015 12:16:04 -0400

> Let's distinguish between two different uses of SHA-1:

I was recommending getting rid of (2).
Getting rid of (1) would be nice, but I gather it relies on developments outside TLS.

> On 07 Jul 2015, at 12:13, Salz, Rich <[email-masked]> wrote:
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 7 Jul 2015 19:31:47 +0300

> developments outside TLS.

Well, for "public" CA system, one can't get SHA-1 certs after
this year, neither Chrome nor Firefox accept those and Chrome
reacts rather badly to SHA-1 certs with expiration in 2017 or
later.

(Of course, this is just WebPKI, and there is plenty of other
stuff too).

And I don't think it is at all clear which of (1) or (2) is
actually worse for security (I think (1)).

-Ilari

---

From: Dave Garrett <[email-masked]>
Date: Tue, 7 Jul 2015 12:42:22 -0400

On Tuesday, July 07, 2015 12:08:30 pm Eric Rescorla wrote:
> the protocol. However, given that there are lots of SHA-1 certificates in the
> SHA-1 in certificates for TLS 1.3 (while it's still available to TLS 1.2) acts

On Tuesday, July 07, 2015 12:10:15 pm Eric Rescorla wrote:
> not sure is wise. I suggest we put this on the agenda for Prague.

How does it prohibit SHA1 in certs? The commit message might be unclear, but it only modifies the signature algorithms extension.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Tue, 7 Jul 2015 12:57:25 -0400

> How does it prohibit SHA1 in certs? The commit message might be unclear, but it only modifies the signature algorithms extension.

The relevant commit with a fixed message:

https://github.com/davegarrett/tls13-spec/commit/56e481f19ed4d2ed374a6fb6e24a66637eb07b3c

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Jul 2015 10:45:25 -0700

On Tue, Jul 7, 2015 at 9:57 AM, Dave Garrett <[email-masked]> wrote:

> > How does it prohibit SHA1 in certs? The commit message might be unclear,
> but it only modifies the signature algorithms extension.
>

http://tlswg.github.io/tls13-spec/#server-certificate:

If the client provided a “signature_algorithms” extension, then all
certificates provided by the server MUST be signed by a hash/signature
algorithm pair that appears in that extension. Note that this implies that
a certificate containing a key for one signature algorithm MAY be signed
using a different signature algorithm (for instance, an RSA key signed with
a DSA key).
So if you can't express SHA1 in signature_algorithms, then the server can't
send you a certificate signed with SHA-1.

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Tue, 7 Jul 2015 14:22:46 -0400

> send you a certificate signed with SHA-1.

Hmm... well, we could state a special case that SHA-1 within some restricted use-case is permitted in certs, but this could quickly become messy. Just axing it all would be better, but yeah, that's a larger change than originally intended.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 7 Jul 2015 20:58:59 +0000

> send you a certificate signed with SHA-1.

This is a very unfamiliar use of the word "can't".  In practice
most servers will send whatever (fixed) certificate chain they're
configured with, no matter the content of the signature_algorithm
extension.  Servers that possess otherwise equivalent chains that
differ only in the signature algorithm are rather rare beasts AFAIK.

Which SSL libraries allow server administrators to configure multiple
chains based on the signature algorithm?

Which SSL libraries allow clients to configure multiple chains and
present the appropriate one to the server based on signature
algorithm?

My impression is that chain selection based on the extension is
largely wishful thinking.

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Jul 2015 16:01:07 -0700

> chains based on the signature algorithm?

I just investigated this earlier today.  NSS maintains separate
certificates keyed on the signature algorithm and selects based on the
cipher suite, though this does not consider the hash part of the
signature algorithm pair.  That's the server end; the client side is
far less capable (though I have a patch in progress that would enable
what you describe).

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 8 Jul 2015 01:55:35 +0000

> I just investigated this earlier today.  NSS maintains separate certificates

boringSSL does it, too.  They have an early callback that presents the entire parsed clientHello message, and allows the server to unify SNI, cipher-suite, and cert assignment all at once.  I'm going to bring that feature into the next OpenSSL release, along with unified extension handling.

Agreed, nobody cares much about the client side.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Jul 2015 09:02:44 -0700

> Agreed, nobody cares much about the client side.

I do, but only a little (we do mutual authentication for WebRTC and we
want to migrate from RSA to ECDSA certs).

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 8 Jul 2015 16:04:24 +0000

I do too - we do mutual certificate-based authentication.
-- 
Regards,
Uri Blumenthal

On 7/8/15, 12:02 , "TLS on behalf of Martin Thomson" <[email-masked]

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 8 Jul 2015 16:05:35 +0000

>I do too - we do mutual certificate-based authentication.

Having said that, we do not care much for SHA1.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 8 Jul 2015 16:06:33 +0000

> I do too - we do mutual certificate-based authentication.

So let me rephrase Viktor's question:  do many client-side TLS apps care need to care about which certificate to present?  Or is it a choose from a list of one type of thing?

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 8 Jul 2015 16:12:04 +0000

On 7/8/15, 12:06 , "Salz, Rich" <[email-masked]> wrote:

>So let me rephrase Viktor's question:  do many client-side TLS apps care
>need to care about which certificate to present?

Probably not, at least not now. Usually our clients have one cert per
purpose, and are well-aware of what cert to use when (if one client has
more than one purpose and therefore more than one credential). Maybe it’s
because our usage model is still young and unsophisticated…?

>  Or is it a choose from a list of one type of thing?

<puzzled look> :-)

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Jul 2015 09:16:20 -0700

> So let me rephrase Viktor's question:  do many client-side TLS apps care need to care about which certificate to present?  Or is it a choose from a list of one type of thing?

I was grappling with this exact problem yesterday.

---

From: [email-masked] (Martin Rex)
Date: Wed, 8 Jul 2015 19:45:49 +0200 (CEST)

> chains based on the signature algorithm?

Unfortunately, a non-marginal installed base is exhibiting this self-imposed
(mis)behaviour of connection failure: Microsoft SChannel beginning 
with Windows 7 / 2008R2 (aka WinNT 6.1), and Windows 8 / 2012 and
Windows 8.1 / 2012R2 exhibit the same (mis)behaviour.

When you install a server certificate with a sha256WithRsaEncryption signature
on a Microsoft IIS on one of these platforms, enable TLSv1.2 on the server
and try to connect with an extension-free ClientHello that offers
client_version= (3,3), you will face a connection failure (IIS simply closes
the network connection--IIS is notorious in failing to put fatal alerts
on the wire).

The handshake succeeds (with TLSv1.1) if the client offers at most TLSv1.1,
or if the client offers TLSv1.2 in a SSL Version2 CLIENT-HELLO rather than
an extensionless TLS ClientHello, if TLSv1.2 is disabled on IIS, or if
a server certificate with only sha1WithRsaEncryption ist used.

> largely wishful thinking.

To me, it looks more like a lack of thinking on part of the spec writers
and the implementors.  Just how dumb the idea is should become obvious
if you compare the handshake result for TLSv1.1 and for TLSv1.2.
Essentially, this is a TLS protocol version intolerance created by 
the TLSv1.2 protocol specification itself.

-Martin

---

From: Dave Garrett <[email-masked]>
Date: Wed, 8 Jul 2015 13:50:39 -0400

> a server certificate with only sha1WithRsaEncryption ist used.

To clarify, how does this scenario respond with a TLS 1.2 ClientHello with at least one extension? Does it matter what extension(s)? (e.g. does IIS have to know what it is?)

Dave

---

From: [email-masked] (Martin Rex)
Date: Wed, 8 Jul 2015 20:07:47 +0200 (CEST)

Dave Garrett wrote:
> Martin Rex wrote:
> To clarify, how does this scenario respond with a TLS 1.2 ClientHello
> with at least one extension? Does it matter what extension(s)?
> (e.g. does IIS have to know what it is?)

The issue here is the (lack of the) TLSv1.2 signature_algorithms extension.

Windows SChannel appears to treat the absence of this extension
the same as the presence of an extension with (md5,rsa) (sha1,rsa) (sha1,dsa)

If you send the TLSv1.2 signature_algorithms extension with the
algorithm matching the signature of the server certificate,
e.g. (sha256,rsa) in the above example, then a TLSv1.2 handshake will succeed.

Correcting a slight inaccuracy above:  when the server certificate is signed
with sha1WithRsaEncryption, the handshake will succeed with TLSv1.2.

When an SSLv2 ClientHello offering TLSv1.2 is sent, the TLS handshake
will succeed independent of the signature on the IIS server certificate,
but the server will pick only TLSv1.1 rather than TLSv1.2.

-Martin

---

From: Hubert Kario <[email-masked]>
Date: Wed, 08 Jul 2015 20:08:27 +0200

> extension unless it supports SHA-256 for TLS 1.3 and SHA-1 for TLS <=

Done and done.

Also submitted a pull request directly to tlswg/tls13-spec repo:
https://github.com/tlswg/tls13-spec/pull/196

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Jul 2015 21:08:39 +0300

> On Jul 8, 2015, at 7:06 PM, Salz, Rich <[email-masked]> wrote:
> 

I believe it is never an issue. The use case I care about is “SSL VPNs” and corporate portals. In both of them the organization running the web server rolls out a CA. They hardly ever use a public CA. It’s either a CA that comes bundled with the portal software or a corporate CA. Such a CA will issue the user exactly one certificate, because that certificate is meant to be used to access the portal or the SSL VPN, and the portals are meant to look up the identity in the certificate in the corporate LDAP server or RADIUS or DIAMETER.

It’s possible that a single user might be issued multiple certificates, but they will be from different CAs, and choosing a client certificate based on CA will work. I don’t see any use case for a corporate CA to issue multiple certificates to the same user or device with different algorithms. This is at least true for my use cases.

Yoav

---

From: Andrei Popov <[email-masked]>
Date: Wed, 8 Jul 2015 18:08:53 +0000

For context: on multiple threads, Martin has repeatedly brought up the fact that schannel complies with section 7.4.1.4.1 "Signature Algorithms" of RFC 5246, which says:

"   If the client does not send the signature_algorithms extension, the
   server MUST do the following:

   -  If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
      DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
      sent the value {sha1,rsa}.

   -  If the negotiated key exchange algorithm is one of (DHE_DSS,
      DH_DSS), behave as if the client had sent the value {sha1,dsa}.

   -  If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
      ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}."

This means that e.g. if IIS only has a SHA256 cert, and the client offers TLS1.2 and no signature_algorithms extension, IIS will indeed fail the handshake.

It is possible that we might improve the product by not complying with section 7.4.1.4.1 of RFC 5246 in a future release, but currently schannel does comply.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Wednesday, July 8, 2015 11:08 AM
To: Dave Garrett
Cc: [email-masked]
Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

Dave Garrett wrote:
> Martin Rex wrote:
>> Unfortunately, a non-marginal installed base is exhibiting this 
>> self-imposed (mis)behaviour of connection failure: Microsoft SChannel 
>> beginning with Windows 7 / 2008R2 (aka WinNT 6.1), and Windows 8 / 
>> 2012 and Windows 8.1 / 2012R2 exhibit the same (mis)behaviour.
>> 
>> When you install a server certificate with a sha256WithRsaEncryption 
>> signature on a Microsoft IIS on one of these platforms, enable 
>> TLSv1.2 on the server and try to connect with an extension-free 
>> ClientHello that offers client_version= (3,3), you will face a 
>> connection failure (IIS simply closes the network connection--IIS is 
>> notorious in failing to put fatal alerts on the wire).
>> 
>> The handshake succeeds (with TLSv1.1) if the client offers at most 
>> TLSv1.1, or if the client offers TLSv1.2 in a SSL Version2 
>> CLIENT-HELLO rather than an extensionless TLS ClientHello, if TLSv1.2 
>> is disabled on IIS, or if a server certificate with only sha1WithRsaEncryption ist used.
> 

Windows SChannel appears to treat the absence of this extension the same as the presence of an extension with (md5,rsa) (sha1,rsa) (sha1,dsa)

If you send the TLSv1.2 signature_algorithms extension with the algorithm matching the signature of the server certificate, e.g. (sha256,rsa) in the above example, then a TLSv1.2 handshake will succeed.

Correcting a slight inaccuracy above:  when the server certificate is signed with sha1WithRsaEncryption, the handshake will succeed with TLSv1.2.

When an SSLv2 ClientHello offering TLSv1.2 is sent, the TLS handshake will succeed independent of the signature on the IIS server certificate, but the server will pick only TLSv1.1 rather than TLSv1.2.

-Martin

---

From: Hubert Kario <[email-masked]>
Date: Wed, 08 Jul 2015 20:15:40 +0200

On Wednesday 08 July 2015 13:50:39 Dave Garrett wrote:
> > beginning with Windows 7 / 2008R2 (aka WinNT 6.1), and Windows 8 / 2012
> > and
> > signature on a Microsoft IIS on one of these platforms, enable TLSv1.2 on
> > the server and try to connect with an extension-free ClientHello that
> > offers
> > client_version= (3,3), you will face a connection failure (IIS simply
> > closes the network connection--IIS is notorious in failing to put fatal
> > alerts on the wire).
> > 
> > TLSv1.1,
> To clarify, how does this scenario respond with a TLS 1.2 ClientHello with
> at least one extension? Does it matter what extension(s)? (e.g. does IIS
> have to know what it is?)

The IIS is behaving as the RFC requires it to (with the exception of TLS 
alerts) - according to section 7.4.2 of RFC 5246 - bottom of page 48.

If you send a TLS 1.2 Client Hello, include signature algorithms with (sha1, 
sha256)*(rsa, ecdsa, dsa) it will abort connection if the installed 
certificate has SHA512 signature.
-- 
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

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 8 Jul 2015 14:21:41 -0400

>   SHA1 is seen in DigitallySigned.algorithm.

The browsers have already independently moved to do the same:

* https://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html
* https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
* http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

Other user agents could probably get on a similar schedule with little
to no hardship. I've noticed the OS (like Windows) and Frameworks
(like .Net) seem to be driven by the web security model, so its not a
leap at all. Its kind of like the tail wagging the dog - folks get the
weaker security model by default, and have to do extra work to close
gaps.

Jeff

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 8 Jul 2015 18:27:37 +0000

On Wed, Jul 08, 2015 at 09:08:39PM +0300, Yoav Nir wrote:

> It's possible that a single user might be issued multiple certificates,
> but they will be from different CAs, and choosing a client certificate
> based on CA will work. I don't see any use case for a corporate CA to
> issue multiple certificates to the same user or device with different
> algorithms. This is at least true for my use cases.

Are root-CA self-signatures subject to the algorithm compatibility
requirements on intermediate and leaf certificates?  I was under
the impression that root-CA self-signatures were exempted from such
a constraint.

My impression was that it is not uncommon to use the same (say
SHA-1 self-signed) root CA to issue both a SHA-1 and a SHA2-256
intermediate CA, each of which then issues chains signed with the
corresponding algorithm all the way down to the leaf.  

In the above scenario, the server's signal of which root-CA to
choose does not help the client to interoperate with the server by
using a certificate that matches the agreed algorithm.  And I still
expect that most servers and clients will have just one certificate
chain to offer.

Therefore, the requirement to return a chain that uses a shared
algorithm or fail seems too strong.  Returning what you have seems
a lot more reasonable to me.  The peer can reject the chain if so
desired.

-- 
	Viktor.

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 8 Jul 2015 14:28:50 -0400

> Let's distinguish between two different uses of SHA-1:
Marc Steven is engineering collisions on SHA-1 in 2^61. See the
HashClash homepage at https://marc-stevens.nl/p/hashclash/. That's
well within reach of many attackers given how cheaply one can purchase
compute time on EC2 or Nova.

1024-bit RSA has been basically been deprecated, and it provided about
80-bits of security. I'm not sure what economic models those
speculating on attacks are following, but adversaries usually perform
the most economical attack first, not last.

It kind of reminds me of the CAs ignoring the warnings about MD5. And
then this happened: https://www.win.tue.nl/hashclash/rogue-ca/.

Jeff

---

From: Dave Garrett <[email-masked]>
Date: Wed, 8 Jul 2015 15:23:03 -0400

> alerts) - according to section 7.4.2 of RFC 5246 - bottom of page 48.

I was just about to respond to this with the obvious joke: "It works perfectly fine except for the part that is broken" ... and then I read the spec and actually have to defend them here. There isn't actually a requirement of throwing an error alert in the spec, currently. There of course ~should~ be an alert, and it should be in the spec, but it isn't yet.

Note, BTW, that my current WIP for MTI extensions already does have hard error cases added in, including a new alert:
https://github.com/davegarrett/tls13-spec/compare/pruning...davegarrett:mandatoryextensions

There have already been a few spots that got clarifications on what errors should be expected, and I think this is an area that really should be given proper focus for TLS 1.3. We shouldn't have any spots where anyone can say: "huh, what should it do now?".

In fact, I think a catch-all requirement that a server MUST always return ~something~ in response to a (mostly) valid client message might be helpful here. Radio silence in response to any error is a really bad scenario that makes dealing with things annoyingly difficult. Servers should only stealth block/drop connections when it's likely to be junk its receiving (e.g. DoS or explicitly invalid/unauthorized attempt).

Dave

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Jul 2015 22:25:31 +0300

> On Jul 8, 2015, at 9:27 PM, Viktor Dukhovni <[email-masked]> wrote:
> 

Root CAs are not subject to any restrictions.  What I meant was that the same user (or more to the point - the same device) can have multiple certificates from multiple CAs for multiple applications. For example, the user’s employer might have a corporate portal with user certificates issued by the corporate CAs. Her employer may have also deployed an SSL VPN solution that uses its own bundled CA to issue certificates, and maybe the user’s bank also issues certificates (there were a few of those in the 90s and early 00s, but they have mostly given up on that).  

Choosing which of these certificates to use is easy - the CA DN is in the certificate request, and each portal asks for exactly one CA. 

If instead we lived in a world where client certificates were provided from commercial CAs, we would have trouble - perhaps the same CA issued both the bank certificates and the SSL VPN certificate. How would the browser know to send the correct identity? I don’t know the answer to this hypothetical question about a hypothetical problem in a hypothetical situation, but I’m pretty sure the answer is not to hope that the CA issues certificates with different algorithms.

Yoav

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 8 Jul 2015 19:36:49 +0000

On Wed, Jul 08, 2015 at 10:25:31PM +0300, Yoav Nir wrote:

> If instead we lived in a world where client certificates were provided
> from commercial CAs, we would have trouble - perhaps the same CA issued
> both the bank certificates and the SSL VPN certificate. How would the
> browser know to send the correct identity? I don?t know the answer to this
> hypothetical question about a hypothetical problem in a hypothetical
> situation, but I?m pretty sure the answer is not to hope that the CA issues
> certificates with different algorithms.

Which I think supports my view, that signature algorithm constraints
ought not strictly apply to client certificates.

However, in the DANE WG we're going to be discussing an extension
of DANE TLSA to client authentication, where "client" will typically
not mean "user with a browser", but  rather will likely be another
server that initiates a connection.  Such "clients" are just as
likely to have multiple chains (varying by algorithm) as the servers
they connect to (that is unlikely in both cases, but not never).

Such clients are very likely to completely ignore the server's CA
hints, and use whatever cert chain they have (modulo signature
algorithm selection).

So the question still stands, is sending what you have prohibited,
or is the supported algorithms extension (in the context of
certificate signatures) a hint to maximize interoperability, and
not a prohibition of the algorithms not listed.

I rather think that the "hint" perspective makes a lot more sense,
because certificate chains are not generally built on the fly to
comport with the negotiated parameters.  So "send what you have"
and let the peer accept/reject makes more sense to me.

-- 
	Viktor.

---

From: Hubert Kario <[email-masked]>
Date: Thu, 09 Jul 2015 12:43:09 +0200

On Wednesday 08 July 2015 15:23:03 Dave Garrett wrote:
> I was just about to respond to this with the obvious joke: "It works
> perfectly fine except for the part that is broken" ... and then I read the
> spec and actually have to defend them here. There isn't actually a
> requirement of throwing an error alert in the spec, currently. There of
> course ~should~ be an alert, and it should be in the spec, but it isn't
> yet.

this is general behaviour of schannel implementation, as far as I've read
 
> Note, BTW, that my current WIP for MTI extensions already does have hard
> error cases added in, including a new alert:
> There have already been a few spots that got clarifications on what errors
> should be expected, and I think this is an area that really should be given
> proper focus for TLS 1.3. We shouldn't have any spots where anyone can say:
> "huh, what should it do now?".

definitely agree, what action to take on an error state should be clearly 
defined by the spec

I'm quite sure that by differences in error handling you can fingerprint the 
implementations very specifically - not catastrophic, but hardly ideal

that being said, I don't think this part of spec is, let's say... "fortunate".
It should be left up to the client to decide if it likes the certificate or 
not - not the server withholding it as a "you won't like it anyway".

> In fact, I think a catch-all requirement that a server MUST always return
> ~something~ in response to a (mostly) valid client message might be helpful
> here. Radio silence in response to any error is a really bad scenario that
> makes dealing with things annoyingly difficult. Servers should only stealth
> block/drop connections when it's likely to be junk its receiving (e.g. DoS
> or explicitly invalid/unauthorized attempt).

that was my general understanding for the TLS specs, given that we have such 
general alerts as "internal_error" and "handshake_failure" - but I can't point 
to any specific part of RFC that says that.

+1 for adding it to the TLS 1.3 spec
-- 
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

---

From: Henrik Grubbström <[email-masked]>
Date: Thu, 9 Jul 2015 16:14:42 +0200

> e.g. (sha256,rsa) in the above example, then a TLSv1.2 handshake will succeed.

Sounds like it is complying with the TLS v1.2 RFC. Fix your client.

-- 
Henrik Grubbström                                       [email-masked]
Roxen Internet Software AB                              [email-masked]

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 9 Jul 2015 19:15:17 +0000

Clearly we need to discuss this more, but you're right about the browsers , and we're okay with SHA-1 being dropped from TLS 1.3

---

From: [email-masked] (Martin Rex)
Date: Fri, 10 Jul 2015 16:29:44 +0200 (CEST)

Henrik Grubbström wrote:
>  Martin Rex <[email-masked]> wrote:
>> algorithm matching the signature of the server certificate, e.g.
>> (sha256,rsa) in the above example, then a TLSv1.2 handshake will succeed.
> 

Nope, _our_ client is perfectly compliant by _not_ sending TLS extensions.
SCHannel is violating a MUST requirement, failing to properly process
a ServerHello without a TLS extension.

https://tools.ietf.org/html/rfc5246#section-7.4.1.2

  7.4.1.2  ClientHello

   extensions
      Clients MAY request extended functionality from servers by sending
      data in the extensions field.  The actual "Extension" format is
      defined in Section 7.4.1.4.

                                      A server MUST accept ClientHello
   messages both with and without the extensions field,

The interpretation of rfc5246 that Microsoft is using to explain the
broken behaviour is in clear conflict with rfc2119 section 6

https://tools.ietf.org/html/rfc2119#section-6

   6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

Requiring a server admin to continue using a sha1WithRsaEncryption
signed certificate and failing the handshake when a sha256WithRsaEncryption
signed certificate is installed, or alternatively requiring the server
admin to disable TLSv1.2 (which happens to be the default in Win7/2008R2)
is a dumb idea and actively causing harm.

So the alleged requirement they're looking at is either not meant
the way they're reading it, or that requirement is simply VOID because
it is clearly incompatible with rfc2119 section 6.

What the implementor did not take into account is the warning sign
on the front of rfc5246, where it says "Proposed Standard",
which is explained by rfc2026:

http://tools.ietf.org/html/rfc2026#section-4.1.1

   Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Fri, 10 Jul 2015 07:44:35 -0700

> a ServerHello without a TLS extension.

Specific overrules general.

> broken behaviour is in clear conflict with rfc2119 section 6

This interpretation is so obviously wrong. ECDHE support requires
sending extensions. A server configured to only support ECDHE
ciphersuites will fail any handshake that doesn't contain the
necessary extensions. You cannot expect psychic servers to negotiate
unadvertised features.

Why can't you advertise support for the signatures you in fact
support, if you want to advertise support?

> is a dumb idea and actively causing harm.

If clients don't support sha256WithRsaEncryption, they won't work with
that server. The problem is clients failing to advertise features,
then their authors complaining about lack of psychic abilities on the
behalf of servers.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 10 Jul 2015 15:05:15 +0000

> Specific overrules general.

While I don't agree with the line of argument that Martin takes to
support his position, I still agree with the conclusion that the
Schannel behaviour is unfortunate.  

If the client does not signal the signature algorithms extension,
and the server's chain is not SHA-1, it should use whatever chain
it has.  Withholding the chain the server has is counterproductive.

Yes, extensions are needed to negotiate the use of SHA2-256 for
TLS MAC computations, but forcing the certificate chain signatures
issued by arms-length CAs to agree with the client's preference for
message MAC algorithms is I think needless restrictive.  

Yes, when possible servers should provide a chain that is more
likely to be understood by the client.  But refusing to provide
the chain they have, just because the client did not disclose every
signature algorithm it supports (or simply did not send any) is a
mistake in the implementation and likely a design error in the
specification.

I encourage implementations to ignore the MUST in question, and
respond with some default chain even if it does not match the
client's signature algorithms extension.  The client may well be
able to handle the new chain, or may not even care about the CA
signatures at all (e.g. opportunistic TLS or DANE-EE(3)).

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 10 Jul 2015 11:37:44 -0400

> mistake in the implementation and likely a design error in the

A TLS 1.2 client is not capable of not indicating at least some set of support. (unless it sends an invalid empty extension)

https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1

   If the client supports only the default hash and signature algorithms
   (listed in this section), it MAY omit the signature_algorithms
   extension.  If the client does not support the default algorithms, or
   supports other hash and signature algorithms (and it is willing to
   use them for verifying messages sent by the server, i.e., server
   certificates and server key exchange), it MUST send the
   signature_algorithms extension, listing the algorithms it is willing
   to accept.

   If the client does not send the signature_algorithms extension, the
   server MUST do the following:
   [use SHA1 defaults]

The only instance a TLS 1.2 client is allowed to omit the extension is when it only support the defaults. If it doesn't support the default or supports something else (or both) then it MUST send the extension. The server MUST interpret the lack of an extension as equivalent to sending SHA1 support. A client not sending the extension is telling the server not to send it anything other than SHA1.

Yes, it doesn't explicitly say what the server should do when the client has not indicated support for anything it has, but a client is in the wrong for not indicating it. The client side is a spec error; the server side is just problematic.

Dave

---

From: [email-masked] (Martin Rex)
Date: Fri, 10 Jul 2015 17:48:33 +0200 (CEST)

Watson Ladd wrote:
> ECDHE support requires sending extensions.

This claim is also clearly invalid.

Btw. rfc4492 is *NOT* a standard, and implementing TLSv1.2 does not
require support for ECC (and neither does TLSv1.2 require support
for any AES-GCM cipher suites).

Our TLSv1.2 client, where we noticed the Microsoft SChannel goof,
does neither implement ECC nor AES-GCM.

rfc4492 says:

4.  TLS Extensions for ECC

   Two new TLS extensions are defined in this specification: (i) the
   Supported Elliptic Curves Extension, and (ii) the Supported Point
   Formats Extension.  These allow negotiating the use of specific
   curves and point formats (e.g., compressed vs. uncompressed,
   respectively) during a handshake starting a new session.  These
   extensions are especially relevant for constrained clients that may
   only support a limited number of curves or point formats.

   A TLS client that proposes ECC cipher suites in its ClientHello
   message SHOULD include these extensions.

                                                        A client that
   proposes ECC cipher suites may choose not to include these
   extensions. 

rfc4492 is a little inconsistent here, because it uses both
"SHOULD" and "may" for the very same client behaviour.

> A server configured to only support ECDHE

Because sending TLS extensions is backwards incompatible behaviour when
you have never sent TLS extensions before, and it will cause some
interop scenarios to fail.  We are not allowed to ship backwards-incompatible
behaviour that breaks existing usage scenarios as patch into the installed
base.  For the very same reason, the use of protocol version > TLSv1.0
on outgoing connections is a pure opt-in.

> then their authors complaining about lack of psychic abilities on the

So what.  Leave the matter of dealing with a sha256WithRsaEncryption
certificate to the client.  This is particularly true for the extremely
unhelpful SSL Alert that is meant to be used here (handshake_failure),
and doubly so for Microsoft IIS -- which does not put any alerts
on the wire before closing the connection.

The latter might not be a problem of SChannel, which seems to create
the alerts and potentially offers them at the SSPI interface, but might
a flaw of the SChannel SSP application callers (Microsoft IIS, MSIE),
to process a token that is returned from a context iterator
(InitializeSecurityContext / AcceptSecurityContex) along with
an SSPI error code.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 10 Jul 2015 15:49:12 +0000

On Fri, Jul 10, 2015 at 11:37:44AM -0400, Dave Garrett wrote:

> > ... refusing to provide
> The only instance a TLS 1.2 client is allowed to omit the extension is
> when it only support the defaults. If it doesn't support the default or
> supports something else (or both) then it MUST send the extension. The
> server MUST interpret the lack of an extension as equivalent to sending
> SHA1 support. A client not sending the extension is telling the server
> not to send it anything other than SHA1.

Suppose the server's certificate is signed with SHAKE256, but the
client has no idea that SHA256 exists.  Suppose also the client is
doing opportunistic (unauthenticated TLS) or using DANE TLSA with
the server's certificate binding published in a DANE-EE(3) digest.

Then the client does not care what signatures may or may not be
present in the server certificate.  And yet the specification
demands that the server abort the handshake.  The specification is
wrong, and implementations that follow it are not well thought out.

With time we learn to ignore some elements of specifications that
don't make sense.  This is one such element.

Perhaps it is not too late to fix this in 1.3, so that the
specification does not demand unreasonable server behaviour.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 10 Jul 2015 11:54:53 -0400

> don't make sense.  This is one such element.

Which will lead to problems like this because not everyone will agree on what parts to ignore. If you want it to actually work reliably, you're going to need to follow or amend the spec.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 10 Jul 2015 16:08:48 +0000

On Fri, Jul 10, 2015 at 11:54:53AM -0400, Dave Garrett wrote:

> Which will lead to problems like this because not everyone will agree on
> what parts to ignore. If you want it to actually work reliably, you're
> going to need to follow or amend the spec.

I am proposing that the specification bug be fixed in TLS 1.3.

Indeed specification bugs are suboptimal.  In cases such as this
one, not implementing the specification bug leads to unconditionally
improved behaviour.  In some other cases, one has no choice but to
implement the bug.

For example, Postfix ignores a bug in RFC 5321 that suggests treating
a 552 response to "RCPT TO" as though it were a 452 response.
Following this causes more problems in practice than the mostly
theoretical problem it solves.

So if Andrey Poppv is still following this thread, I would like to
suggest that Schannel be revised to be more tolerant of clients
that don't offer a signature algorithm that matches the server's
chain and use the server chain anyway.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Fri, 10 Jul 2015 18:17:05 +0200 (CEST)

Dave Garrett wrote:
> The only instance a TLS 1.2 client is allowed to omit the extension
> is when it only support the defaults. If it doesn't support the default
> or supports something else (or both) then it MUST send the extension.

This is the result of an incorrect reading of rfc5246.

If the TLSv1.2 client uses the *PERMITTED* option in
section 7.4.1.2 ClientHello:

   extensions

Then the entire Section 7.4.1.4 HelloExtensions and all of its SubSections
are completely irrelevant to that client.

There is no (valid) prohibition of TLSv1.0 and TLSv1.1 clients and servers
to use server certificate that is signed by sha256WithRsaEncryption, and
as you can test yourself, Microsoft SChannel will properly handshake
with these protocol versions and a server certificate that has a
(sha256,rsa) signature.  The only situation where Microsoft SChannel
crashes and burns is when an extension-less ClientHello arrives with
ClientHello.client_version = (3,3).

Was TLSv1.2 really meant to be backwards-incompatible to TLSv1.0 and TLSv1.1
and create new problems for the migration from sha1-signed server certs
to sha256-signed server certificates, considering that sha1-signed certs
had already been officially been deprecated (e.g. by NIST) more than a
year before TLSv1.2 (rfc5246) was published.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 10 Jul 2015 16:39:38 +0000

> year before TLSv1.2 (rfc5246) was published.

Martin, I think that focusing on a fine-grained scholarly analysis
of the specification is a distraction.  Even if the specification
unequivocally requires servers to do as Schannel does (and there
is some evidence that it does even if not univerally convincing),
the specification is wrong.

There are many situations where the server has little choice of
what chains it can present, and the client is perfectly happy with
chains that bear signatures it does not recognize.

There is no reason for the server to abort the handshake on the
unjustified presumption that the chains it has are unacceptable to
the client.  

Lawyering the RFCs is not worth the effort, concede the law
and go for jury nullification.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 10 Jul 2015 13:05:23 -0400

> and go for jury nullification.

I will take this as the thread ender. :p

Dave

---

From: Andrei Popov <[email-masked]>
Date: Fri, 10 Jul 2015 17:31:01 +0000

Hi Viktor,

Quoting my previous response to this thread: 
"It is possible that we might improve the product by not complying with section 7.4.1.4.1 of RFC 5246 in a future release, but currently schannel does comply."

This thread has shown that it is hard to argue that schannel is RFC non-compliant WRT this particular problem. However, indeed it can be argued that in this case the product does not benefit from being RFC-compliant.
 
Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
Sent: Friday, July 10, 2015 9:09 AM
To: [email-masked]
Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

On Fri, Jul 10, 2015 at 11:54:53AM -0400, Dave Garrett wrote:

> Which will lead to problems like this because not everyone will agree 
> on what parts to ignore. If you want it to actually work reliably, 
> you're going to need to follow or amend the spec.

Indeed specification bugs are suboptimal.  In cases such as this one, not implementing the specification bug leads to unconditionally improved behaviour.  In some other cases, one has no choice but to implement the bug.

For example, Postfix ignores a bug in RFC 5321 that suggests treating a 552 response to "RCPT TO" as though it were a 452 response.
Following this causes more problems in practice than the mostly theoretical problem it solves.

So if Andrey Poppv is still following this thread, I would like to suggest that Schannel be revised to be more tolerant of clients that don't offer a signature algorithm that matches the server's chain and use the server chain anyway.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Sat, 11 Jul 2015 00:56:07 -0400

Due to discussion here, I've started a branch to add some better expectations or errors to deal with things more clearly. Just a WIP at this point:

https://github.com/davegarrett/tls13-spec/compare/seanfixesredux...davegarrett:morealerts

I've also expanded the alerts list to include all standardized as I needed one from another RFC, and SNI will be required, so the full current registry really needs to be listed here for reference.

I already have another WIP branch for MTI extensions over here:

(showing branch diffs because each of these is based on PRs still pending review by ekr)

If anyone has any more "MUST NOT" requirements that really should have a corresponding alert specified to go with it, please send me a PR onto my "morealerts" branch. (I haven't completely scoured the spec for them all yet) See also:
https://github.com/tlswg/tls13-spec/issues/156

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 11 Jul 2015 05:09:11 +0000

On Sat, Jul 11, 2015 at 12:56:07AM -0400, Dave Garrett wrote:

> Due to discussion here, I've started a branch to add some better
> expectations or errors to deal with things more clearly. Just a WIP at
> this point:
> 

Thanks for collecting these.  Is there a reason to "perpetuate"
the TLS 1.2 specification anomaly under discussion in this thread
in lines 2207-2211:

    If a server receives a ClientHello, but the server cannot produce a valid
    certificate chain using the hash/signature pairs known to be supported by
    the client (via this extension or the defaults assumed in its absence),
    then the server MUST send an "unsupported_certificate" alert message and
    close the connection.

Or are you just summarizing current state, with any proposed changes
to be discussed separately?  I still maintain that is clearly
incorrect server behaviour, any specifications to the contrary
notwithstanding.  The decision of whether the chain is or is not
supported by the client MUST be left to the client.  The server
does not have sufficient information to make this decision unilaterally
(even if knows all the signature algorithms the client appears to
support).

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Sat, 11 Jul 2015 02:44:58 -0400

On Saturday, July 11, 2015 01:09:11 am Viktor Dukhovni wrote:
> to be discussed separately?

Yes.

> The decision of whether the chain is or is not

Just an idea, but maybe a way for the client to state that desire should be added? Maybe add "any(255)" values to the enums so clients could request, e.g. {any,rsa}+{any,ecdsa} or {any,any}, etc.? (there might be a better way to do this, though)

I'm not against the idea that the server should be required to always send a valid cert chain, even if it believes the client can't handle it. At a minimum, this could be useful for debugging as the client would be sent something for you to figure out why it's not working.

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 11 Jul 2015 10:25:47 +0300

On Sat, Jul 11, 2015 at 02:44:58AM -0400, Dave Garrett wrote:
> Just an idea, but maybe a way for the client to state that desire
> should be added? Maybe add "any(255)" values to the enums so clients
> could request, e.g. {any,rsa}+{any,ecdsa} or {any,any}, etc.? (there
> might be a better way to do this, though)

It is not about clients that can process any hash or signature
algorithm, it is about if chain processing will terminate (reached
"trust anchor") before the client runs into the unsupported hash/
signature and chokes.

And that trust anchor might even be the public key in the end-
entity certificate, which would cause every signature except the
one EE public key itself makes[1] to be skipped (so even if
the EE cert itself was signed by Foo/Bar, both of which are
unknown to client, it would still work).

[1] Obviously the client must know the signature algorithm
the key uses or things just plain won't work. Additionally
if the key forces hash algorithm (at least some CFRG signature
proposals work that way), that hash needs to be known too.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 11 Jul 2015 08:52:27 -0400

I'm not necessarily opposed to relaxing this requirement on the server,
but given that:

1. SHA-1 is on its way out.
2. Future versions of TLS seem very likely to explicitly indicate which
hash algorithms the clients support.

I'm kind of confused about the principle being espoused here. In general,
when the client has told the server what's acceptable and the server
doesn't have it, we abort the handshake. What makes this case different
from (say) the client only supporting P256 and the server only supporting
Curve25519 but deciding to send Curve25519 anyway?

-Ekr

On Fri, Jul 10, 2015 at 1:31 PM, Andrei Popov <[email-masked]>
wrote:

> "It is possible that we might improve the product by not complying with
> section 7.4.1.4.1 of RFC 5246 in a future release, but currently schannel
> does comply."
>
> This thread has shown that it is hard to argue that schannel is RFC
> non-compliant WRT this particular problem. However, indeed it can be argued
> that in this case the product does not benefit from being RFC-compliant.
>
> Cheers,
>
> Andrei
>
> Indeed specification bugs are suboptimal.  In cases such as this one, not
> implementing the specification bug leads to unconditionally improved
> behaviour.  In some other cases, one has no choice but to implement the bug.
>
> For example, Postfix ignores a bug in RFC 5321 that suggests treating a
> 552 response to "RCPT TO" as though it were a 452 response.
> So if Andrey Poppv is still following this thread, I would like to suggest
> that Schannel be revised to be more tolerant of clients that don't offer a
> signature algorithm that matches the server's chain and use the server
> chain anyway.
>
> --
>         Viktor.
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 11 Jul 2015 16:45:16 +0300

> Curve25519 but deciding to send Curve25519 anyway?

The ECDH example involves something that will certainly blow up. Same with
the server signature itself being made with unsupported algorithm.

But with sending non-compliant certificates, the further up the chain the
non-complance is, the more likely client processing will terminate before
the client hits the "bad" signature and chokes. In some cases the last
thing client processes might even be the public key of the end-entity
certificate (never reaching the issuer signature of any certificate
in chain).

So if server wants to make last-ditch hail mary attempt, it would be
picking certificate chain that contains accepted algorithms as far
as possible (if it doesn't have EE certificate that can sign using
the indicated algorithms, it can abort right away because it is
not going to work[1]). It may or may not work, but at least it has
the greatest probability of working.

[1] Unless the client is buggy.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 11 Jul 2015 09:55:45 -0400

This makes a certain amount of sense (though I wonder how often it's really
an issue that a server declines to send a certificate that would otherwise
have worked to a compliant client [0]).

Perhaps the right text here is that if you have a conformant certificate,
you
MUST send it, but if not, you MAY send a nonconformant one?

-Ekr

[0] As you say, with a buggy client all bets are off.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 11 Jul 2015 15:17:29 +0000

> have worked to a compliant client [0]).

Every time with Schannel, Exchange SMTP servers, and opportunistic
TLS SMTP clients.

> you MUST send it, but if not, you MAY send a nonconformant one?

Correct.  It is important to try to match a supported algorithm,
but failing that, send what you have.  It may well work just fine
for the client, since the signatures in question are not made in
real-time by the server, but rather at some previous time by some
CA, which the client may not care about (pinned leaf cert, DANE
leaf cert, opportunistic TLS, ...).

And the point about debugging also makes sense.  The client
administrator can much more easily determine which additional
algorithm is required to interoperate with the server.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Sat, 11 Jul 2015 14:32:29 -0400

> algorithm is required to interoperate with the server.

Ok, draft language for new behavior here:

==============================
If a server receives a ClientHello, but the server cannot produce a valid
end-entity certificate using the hash/signature pairs known to be supported by
the client (via this extension or the defaults assumed in its absence),
then the server MUST send an "unsupported_certificate" alert message and
close the connection. In the event that a server can produce a valid end-entity
certificate known to be supported by the client, however the known supported
hash/signature pairs are insufficient to produce a known valid certificate
chain, the server is RECOMMENDED to send a complete valid certificate chain
which attempts to use supported hash/signature pairs where possible yet
includes certificates with unknown client support. If the client cannot build
a trusted chain using these certificates and any other trusted information it
has access to, then it MUST send an "unsupported_certificate" alert message
and close the connection. The server MAY instead choose to simply send an
"unsupported_certificate" alert message and close the connection.
==============================

Sound viable?

(this might be a bit too wordy, though; the wording throughout the document about fatal alerts could probably be simplified a bit)

I pushed the above to the morealerts WIP branch.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 11 Jul 2015 19:00:40 +0000

> Ok, draft language for new behavior here:

[ Reordered, feedback question before draft language ]

> Sound viable?
> 
> (this might be a bit too wordy, though; the wording throughout the document
> about fatal alerts could probably be simplified a bit)

The signature of the leaf certificate is just as irrelevant as
signatures up the chain.  With pinned leaf certificates, DANE-EE(3),
opportunistic TLS, ... even the leaf (end-entity) certificate
signature algorithm is of no consequence and is ignored by the
client.

Therefore, this qualification is not needed, and the server SHOULD
NOT send any alert or close the connection even when the client's
supported signature algorithms do not include the signature algorithm
used for some certificate in the chain (regardless of depth).
Instead the server MUST send whatever chain it has whose leaf public
key is compatible with the agreed cipher-suite.  (The server of course
chooses the agreed cipher-suite to make the last condition true). 

If at all possible, the server SHOULD choose a chain all of whose
signatures (excluding any self-signed root CAs) match the client's
signature algorith list.  If that's not possible, it SHOULD send
a default chain (often the only chain it has) with a compatible
public key.

[ Of course, perhaps worth mentioning, none of this applies with
RFC 7250 raw-public-keys, because there is no chain or signatures
to send, the server just sends its SPKI public key per RFC 7250. ]

> In the event that a server can produce a valid end-entity
> includes certificates with unknown client support.

As above: s/RECOMMENDED/SHOULD/.  It is NOT up to the server to decide
which chains the client can accept.  The server has insufficient
information, and therefore SHOULD NOT preempt the client's decision
of whether the chain works or not.

> If the client cannot build
> and close the connection.

If the client chooses to authenticate the server's chain (i.e.
not unauthenticated opportunistic TLS) and fails to do so because
it does not support  the signature algorithm in one or more
certificates that are needed for said authentication, then it
MUST send ...

> The server MAY instead choose to simply send an

No, the server SHOULD NOT preempt the client's decision.  I'd
personally prefer MUST NOT, but there are arguably servers whose
clients are all known to never use trust on first use certificate
pinning, DANE, unauthenticated opportunistic TLS, ...

If we need to weasel out and give some servers the choice to lock
out all clients that do anything remotely unorthodox, then SHOULD
NOT provides some rope.  I think such weaseling out is likely to
do more harm than good, but I'm open to concede the rope if need
be.

On the public Internet, such servers will be few and far between,
and the choice to preempt the client should not be a default choice
made by the TLS library.  If some particular application wants to
limit client support, that choice needs to be explicitly signalled
to the TLS library.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Sat, 11 Jul 2015 15:36:49 -0400

> signature algorithm is of no consequence and is ignored by the

I was going based on Ilari's comments here:
https://www.ietf.org/mail-archive/web/tls/current/msg17022.html

The only scenario where having an EE cert that can't sign anything would be useful is opportunistic encryption. Using anon ciphers sounds better, but I guess attempting auth allows trust on first use so I agree that transmitting certs could be useful here.

> a default chain (often the only chain it has) with a compatible

We don't really have an official definition of what constitutes a "default" chain here.

> of whether the chain works or not.

I was also going with RECOMMENDED/MAY language based on ekr's recent comments.

> On the public Internet, such servers will be few and far between,

I think the rope, as you put it, needs to be there in some form. On the public Internet, yes, I can see your point. In a more tightly controlled system with a potentially constrained environment, I don't see the point in forcing the server to send down certs that the admin can 100% know will just waste bandwidth and processing. So, SHOULD/RECOMMENDED is the level that I think this'll need to be at.

I think I understand all of your argued reasons better now. I'll come up with some replacement language that takes them into account.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Sat, 11 Jul 2015 16:05:01 -0400

Ok, revised:

========================================
If the client provided a "signature_algorithms" extension, then all
certificates provided by the server SHOULD be signed by a hash/signature
algorithm pair indicated by the extension (or defaults assumed in its
absence). If the server cannot produce a valid certificate chain using
these known supported pairs, then it SHOULD send the client a complete
valid chain which attempts to match known support where possible, yet
including certificates that are not known to be supported. If the
client cannot build a trusted chain using these certificates and any
other trusted information it has access to, then it MUST send an
"unsupported_certificate" alert message and close the connection.
========================================

Comments?

Note that for the purposes of discussion here, opportunistic encryption can "trust" whatever it wants; anything or nothing, depending on implemented strategy.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 11 Jul 2015 20:36:17 +0000

On Sat, Jul 11, 2015 at 03:36:49PM -0400, Dave Garrett wrote:

> The only scenario where having an EE cert that can't sign anything would
> be useful is opportunistic encryption. Using anon ciphers sounds better,
> but I guess attempting auth allows trust on first use so I agree that
> transmitting certs could be useful here.

Not, not "can't signed anything" rather "is signed *by* its issuer
via an unsupported signature".  The server's public key is not
constrained to use the same signature algorithm that signed its
certificate.  Indeed it must, for example, sign EDH/EECDH parameters
with an algorithm that is supported by the client.

> We don't really have an official definition of what constitutes a "default" chain here.

Whatever the server cares to use.  Implementation dependent.  Using something
minimally exotic would be wise, but I don't the standar can or should specify
how to choose.

> I was also going with RECOMMENDED/MAY language based on ekr's recent comments.

That would be wrong.  It really MUST or at least SHOULD continue
the handshake.

> I think the rope, as you put it, needs to be there in some form. On the
> public Internet, yes, I can see your point. In a more tightly controlled
> system with a potentially constrained environment, I don't see the point
> in forcing the server to send down certs that the admin can 100% know will
> just waste bandwidth and processing. So, SHOULD/RECOMMENDED is the level
> that I think this'll need to be at.
> 
> I think I understand all of your argued reasons better now. I'll come up
> with some replacement language that takes them into account.

I'll settle for SHOULD.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 11 Jul 2015 20:48:10 +0000

On Sat, Jul 11, 2015 at 04:05:01PM -0400, Dave Garrett wrote:

> Note that for the purposes of discussion here, opportunistic encryption
> can "trust" whatever it wants; anything or nothing, depending on implemented
> strategy.

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.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 11 Jul 2015 16:51:53 -0400

On Sat, Jul 11, 2015 at 11:17 AM, Viktor Dukhovni <[email-masked]>
wrote:

> TLS SMTP clients

Well, I assume you mean every time you have a pair with the right
properties.
But my question is how often that happens on the live Internet.

 -Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 11 Jul 2015 20:57:54 +0000

> But my question is how often that happens on the live Internet.

Well, the client would have to not offer SHA256, most do.  Schannel
issues with SMTP tend to be mostly in other corners of the spec.

For example, Schannel opportunistic clients hang-up when the server
certificate is "expired", even when they don't otherwise authenticate
the certificate, and accept self-signed  or wrong server name, ...
That is also pointlessly strict.

The breakage in this thread would require a client that offers
TLSv1.2, but not SHA256, and those are at present rare.  That
does not mean that the specification should stay wrong.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Sat, 11 Jul 2015 17:09:27 -0400

> that you find to be an improvement.

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.
========================================

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 11 Jul 2015 21:13:45 +0000

> New version with a little rewording and a typo fix.

I find this version much improved, in fact very clear and concise.
Excellent, works for me.  Thanks.

-- 
	Viktor.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 12 Jul 2015 00:14:03 +0300

>     hash/signature algorithm pair.

Actually, it only needs to be compatible with ciphersuite if client
did not send signature_algorithms. If it did, then it needs to be
compatible with any algorithm pair signaled in that.

It also worked this way in TLS 1.2.

E.g. if client advertised {sha256, ecdsa} + <others> in its
signature_algorithms and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
+ others in its ciphersuites, then the server MAY pick
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and then proceed to
sign the handshake with ECDSA/SHA-256. Despite there being
no DHE_ECDSA ciphersuites.

Also, it occurs to me that analogous situation occurs with client
certificates. But there the rules are much less clear to me:

There are two fields that control supported certificate algorithms:
certificate_types and supported_signature_algorithms, both in
CertificateRequest.

Here's what TLS 1.2 says about interplay of those fields (and
TLS 1.3 wg-07 has very similar language, quite possibly exactly
the same):

"The end-entity certificate provided by the client MUST contain a
key that is compatible with certificate_types. If the key is a
signature key, it MUST be usable with some hash/signature
algorithm pair in supported_signature_algorithms."

Is say ECDSA key "compatible" with rsa_sign?

Also, it seems like TLS 1.3 draft allows fixed_dh certificate_types.
How would those even work? I thought only signature-capable ones
do. Which would mean that certificate_types could be deprecated
entierely. 

-Ilari

---

From: Dave Garrett <[email-masked]>
Date: Sat, 11 Jul 2015 17:23:58 -0400

> Excellent, works for me.  Thanks.

Great. :)

To actually get back to the title of this thread, the change under current discussion could actually help us drop SHA1 from the spec a little more easily. SHA1 can be prohibited to be offered for TLS 1.3+, the defaults can be changed to SHA256 (and eventually to mandatory to send), and nothing else is really needed. The new text allows for unspecified hashes to be used if forced to, which would apply to SHA1. SHA1 would be MUST NOT offer & implicitly SHOULD NOT be sent by server. Thus, the official stance would be that SHA1 is only ever permitted in a fallback chain, which is pretty much what we want.

Note that clients willing to negotiate TLS 1.2 (e.g. the vast majority) would still probably want to offer SHA1 in the short term, so the 1.3 spec would need to state that this is not prohibited for them, but TLS 1.3 servers would have to ignore it.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 11 Jul 2015 19:18:01 -0400

On Sat, Jul 11, 2015 at 5:09 PM, Dave Garrett <[email-masked]>
wrote:

> =======================================
>

I'm not happy with this. There should be a MUST-level requirement to provide
a conformant chain if possible.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 11 Jul 2015 19:19:02 -0400

On Sat, Jul 11, 2015 at 5:14 PM, Ilari Liusvaara <
[email-masked]> wrote:

> How would those even work?

This is just editor error.

> I thought only signature-capable ones

Yes, I think i observed this before but just haven't gotten around to
updating
the spec to remove it.

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Sat, 11 Jul 2015 19:29:02 -0400

> a conformant chain if possible.

Yeah. "SHOULD" & "where possible" aren't both needed. We only really want one or the other. I'll change it to "MUST" & "where possible".

Dave

---

From: Andrei Popov <[email-masked]>
Date: Mon, 13 Jul 2015 04:11:04 +0000

I'm not happy with this either. The spec already says:

"If the client supports only the default hash and signature algorithms
   to accept."

This seems to be pretty clear: if the client properly advertises the algorithms it supports, then the handshake has a deterministic outcome.
 
Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Dave Garrett
Sent: Saturday, July 11, 2015 4:29 PM
To: Eric Rescorla
Cc: [email-masked]
Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

On Saturday, July 11, 2015 07:18:01 pm Eric Rescorla wrote:
> I'm not happy with this. There should be a MUST-level requirement to 
> provide a conformant chain if possible.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Jul 2015 04:41:04 +0000

On Mon, Jul 13, 2015 at 04:11:04AM +0000, Andrei Popov wrote:

> This seems to be pretty clear: if the client properly advertises the
> algorithms it supports, then the handshake has a deterministic outcome.

That's all fine, we're talking about what the server should do when
it is certificate chain does not (in its entirety) match those
algorithms.  And in the context of TLS 1.3 which is not yet set in
stone.  

Which part are you objecting to?  The subsequent proposal to suppress
SHA-1 advertisements (if the client supports only TLS 1.3 or later)
when even when the client is willing to accept a SHA-1 chain when
all else fails?  That too seems sensible, and it was already noted
that clients will need to send the SHA-1 codepoint when willing to
accept TLS 1.2, since that spec does not contain the proposed new
language for server-side behaviour.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Mon, 13 Jul 2015 16:12:46 +0200 (CEST)

Andrei Popov wrote:
> I'm not happy with this either.

I liked that proposal.

> algorithms it supports, then the handshake has a deterministic outcome.

While this may seem true, the problem that you're ignoring here is
that it changes the original meaning&semantics of ClientHello in
a backwards-incompatible and undesirable fashion, which creates either
an interop failure or a security problem or both.

In TLS up to TLSv1.1, the absence of a TLS signature_algorithms
extensions indicates *ONLY* the algorithm that has to be used
a the TLS protocol layer (for digitally-signed), and it says
*NOTHING* at all about the algorithms that may be used within
certificates.

As you might know, support for server certificates signed with
sha256WithRsaEncryption was added to Windows XP with Service Pack 3
(21-Apr-2008) and into Windows 2003 with KB938397.

So the lack of a TLS signature_algorithm extension ought to apply
semantics exclusively to "digitally-signed".  Applying any restrictive
semantics to server certifcates is a backwards-incompatible dumb idea
(in rfc5246) that needs to be fixed.

-Martin

---

From: Henrik Grubbström <[email-masked]>
Date: Mon, 13 Jul 2015 16:21:53 +0200

>    messages both with and without the extensions field,

Yes, and section 7.4.1.4.1 says that that means:

| If the client does not send the signature_algorithms extension, the
| server MUST do the following:
|
|   -  If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
|      DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
|      sent the value {sha1,rsa}.
|
|   -  If the negotiated key exchange algorithm is one of (DHE_DSS,
|      DH_DSS), behave as if the client had sent the value {sha1,dsa}.
|
|   -  If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
|      ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.

Which indicates that the server in effect MUST behave as if there was
an implicit signature_algorithms value of
{{sha1,rsa},{sha1,dsa},{sha1,ecdsa}}.

Section 7.4.2 then says that the certificate chain either MUST or
SHOULD (depending on the interpretation of the "behave as if" above)
be validated against the implicit signature_algorithms extension.

---

From: [email-masked] (Martin Rex)
Date: Mon, 13 Jul 2015 16:30:06 +0200 (CEST)

> Yes, and section 7.4.1.4.1 says that that means:

Section 7.4.1.4 Hello Extensions and its subsections are clearly IRRELEVANT
for a client that does not use Hello Extensions.

You are looking at a defect of the rfc5246 document.  As rfc2026 says,
defects in "proposed standards" are to be expected -- and implementors
with a clue about formal correctness proofing recognize specification
defects and compensate for it while implementing.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Jul 2015 14:37:29 +0000

> for a client that does not use Hello Extensions.

Let's not go back to lawyering the RFCs.  We've been there already,
with not much success.  I think we can reach consensus around the
proposed new language that fixes the specification defect for TLS 1.3.

Once that's done, where necessary, we can suggest to implementors
of TLS 1.2 to "improve the product by not complying with section
7.4.1.4.1 of RFC 5246 in a future release".

I am confident this has a much better chance of success than trying
to convince folks that their reading of the RFC is incorrect.

And in any case, when the client *does* send a supported algorithms
extension, that should *still* not rigidly constrain the server to
a certificate chain with just those algorithms,  Rather, as proposed,
the server should strive to vend a chain with just the supported
algorithms if at all possible, but failing that it should continue
the handshake with some suitable chain it has at its disposal.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Mon, 13 Jul 2015 10:40:34 -0400

> for a client that does not use Hello Extensions.

If you want to put it that way, sure, however they are NOT irrelevant for a _server_ that does use hello extensions. This is a direct part of the TLS 1.2 spec, therefore it is very well established that not sending the extension is a direct request for SHA1, and the server supporting this extension is required to interpret it that way. The expectations on what to do in lieu of that working are bad; that's what we want to fix here.

Dave

---

From: [email-masked] (Martin Rex)
Date: Mon, 13 Jul 2015 18:10:52 +0200 (CEST)

Dave Garrett wrote:
>> Section 7.4.1.4 Hello Extensions and its subsections are clearly
>> IRRELEVANT for a client that does not use Hello Extensions.
> 
> If you want to put it that way, sure, however they are NOT irrelevant
> for a _server_ that does use hello extensions. This is a direct part
> of the TLS 1.2 spec,

That particular MUST in 7.4.1.4.1 is *VOID* because it is incompatible with
rfc2119 section 6.  As it can be easily verified, the behaviour
described in rfc5246 is detrimental to interoperability and security.

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 13 Jul 2015 19:28:10 +0300

> described in rfc5246 is detrimental to interoperability and security.

I don't see such conflict (except with TLS 1.0/1.1 client with TLS 1.2
server). The scenarios where that sort of behaviour would cause actual
interop trouble (meaning it could have worked otherwise, assuming non-
buggy client/server) are:

- TLS 1.0/1.1 client (ClientVersion 3.1 or 3.2) connecting to TLS 1.2
  server. Or
- Server cert chain contains certificates TLS 1.2+ client does not care
  about (e.g. TLSA or excess certificates).

The proposed changes for TLS 1.3 are for the latter case.

(Then there is whole separate question on how compatible inter-
operability and security are, and the answer seems to be not very).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Jul 2015 10:05:07 -0700

> - TLS 1.0/1.1 client (ClientVersion 3.1 or 3.2) connecting to TLS 1.2

Hmm... TLS 1.2 servers shouldn't be following this section if the client
is claiming to be TLS 1.0 or 1.1. I don't think that this section says
that you should (since in that case the TLS 1.1 or TLS 1.0 spec would
control) but in any case, it shouldn't say that and I never interpreted
it that way.

-Ekr

---

From: [email-masked] (Martin Rex)
Date: Mon, 13 Jul 2015 19:06:15 +0200 (CEST)

> no DHE_ECDSA ciphersuites.

Which part of which RFC makes you believe that such weird
behaviour would be allowed?

The key exchange algorithm in the TLS cipher suites requires
a specific kind of asymmetric key in the server certificate.

A DHE_RSA key exchange requires a server certificate with an RSA key.

The key of the CA that signed the server certificate ought to be
irrelevant -- it *WAS* irrelevant in SSLv3, and the words in rfc2246
that suggest otherwise are a defect in rfc2246 (a defect, for which
I haven't yet seen an implementor who got it wrong and implemented
it in the obviously bogus fashion that rfc2246 suggests).

-Martin

---

From: Andrei Popov <[email-masked]>
Date: Mon, 13 Jul 2015 17:11:29 +0000

I think a good design is to have the client explicitly advertise any algorithms the client is willing/able to support, and for the server to honor the client's capabilities.

IMHO the existing specs already meet the above goal, with an unfortunate quirk that SHA1/MD5-only clients don't have to be explicit about their supported signature/hash combinations. This quirk has caused some confusion, but this should be easy to fix in 1.3 by requiring that all algorithms are advertised.

> SHA-1 advertisements (if the client supports only TLS 1.3 or later) when even when the client is willing to accept a SHA-1 chain when all else fails?  
No, I don't care for SHA1; let's deprecate it ASAP. I do care for a straightforward and deterministic handshake where the client MUST advertise supported algorithms and the server MUST honor the client's capabilities.

Having shipped a product that implements the strict interpretation of the current specs (WRT signature_algorithms) for a number of years now, I remember exactly 3 related problem reports. Without pointing fingers (as much as possible), here they are:
1. A version of a popular Web browser failed to interoperate because it did not include all of its supported algorithms in the signature_algorithms extension. Unfortunately, the browser had already been fixed by the time I reported the issue to them, so I could not use this incident as an opportunity to promote IE. :)
2. An open-source TLS stack that had just added TLS1.2 support, but did not implement extensions. I pointed them at the signature_algorithms section of the RFC and they quickly implemented this extension.
3. A vocal participant of this mailing list who seems to be opposed to the idea of making certain TLS extensions MTI, as a matter of principle.

My preference would be to keep the client explicitly advertising its capabilities, and the server strictly honoring the client-advertised capabilities. And since the concept of "default algorithms" confuses people, let's just get rid of it in 1.3. Conveniently, most of this WG no longer wants SHA1 or MD5. Why not just make signature_algorithms (even more) clearly and unambiguously MTI in 1.3?

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
Sent: Sunday, July 12, 2015 9:41 PM
To: [email-masked]
Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

> algorithms it supports, then the handshake has a deterministic outcome.

That's all fine, we're talking about what the server should do when it is certificate chain does not (in its entirety) match those algorithms.  And in the context of TLS 1.3 which is not yet set in stone.  

Which part are you objecting to?  The subsequent proposal to suppress
SHA-1 advertisements (if the client supports only TLS 1.3 or later) when even when the client is willing to accept a SHA-1 chain when all else fails?  That too seems sensible, and it was already noted that clients will need to send the SHA-1 codepoint when willing to accept TLS 1.2, since that spec does not contain the proposed new language for server-side behaviour.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Mon, 13 Jul 2015 19:45:03 +0200 (CEST)

Andrei Popov wrote:
>
> I think a good design is to have the client explicitly advertise any
> algorithms the client is willing/able to support, and for the server
> to honor the client's capabilities.

A good design provides robust interop and good backwards-interoperability,
and a reasonble default set of algorithms to be unconditionally available.
Why TLSv1.2 did imply availability of sha256WithRsaEncryption by default,
is beyond my understanding.

The rfc5246 PDU Definition for ClientHello clearly makes HelloExtensions
and optional (MAY) feature for clients and the acceptance of extension-less
ClientHellos a mandatory (MUST) feature for Servers.  Similarily,
Appendix E allows the use of a SSL Version 2 CLIENT-HELLO instead of
and extension-less TLS ClientHello,

It has already been observed by others, a server can not make up
signatures with client-requested signature schemes at will during
the TLS handshake, but can only pick from the set of existing
server certificates that have been preconfigured by the server admin
-- and often this may be just one single server certificate.

The server responding with an ambiguous "handshake_failure" if the
admin-configured server cert does not fit the silly "implicit" algs
that a server boldly assumes based on the design-flawed wording
in rfc5246 7.4.1.4.1 in absence of ClientHelloExtensions is
is a bad idea, and if the client-visible behaviour is a silent
connection closure (this is what Microsoft IIS does) it is the
worst possible outcome.  This behaviour is completely indistinguishable
from that of defective extensions-intolerant and TLS-version
intolerant servers!

Would the server respond with the next best fit (the way this has been
and still is being done, even by Microsoft SChannel, for SSLv3, TLSv1.0
and TLSv1.1), then the client can at least produce a meaningful
error message and show the certificates that it can not process.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Jul 2015 18:01:53 +0000

On Mon, Jul 13, 2015 at 05:11:29PM +0000, Andrei Popov wrote:

> algorithms the client is willing/able to support, and for the server to
> honor the client's capabilities.

To the extent possible.  However, the server SHOULD NOT refuse to
continue the handshake merely because it believes that some
certificates in its chain might have signatures the client can't
check.  The point being that the client may not need or attempt to
check those signatures.

> IMHO the existing specs already meet the above goal,

No, the language about the certificate chain is needlessly restrictive.
The decision as to whether the chain works for the client or not,
SHOULD be left to the client.  The server's job is to *try* to avoid
problems by sending a known-compatible chain when available.

> No, I don't care for SHA1; let's deprecate it ASAP. I do care for a
> straightforward and deterministic handshake where the client MUST advertise
> supported algorithms and the server MUST honor the client's capabilities.

The MUST honour bit cleanly applies to choices of algorithms in
signature the server makes during and after the handshake.  However,
honouring the algorithms for the chain signatures is more subtle.
Yes, send a compatible chain when possible, HOWEVER, DO NOT prejudge
the client's inability to handle an alternative chain if that's
all you have.  As explained before, opportunistic TLS, DANE, pinning,
...  may mean that the client does not in fact examine the signatures
in the chain and the handshake would succeed, if only the server
were not needlessly pedantic.

Let's not be needlessly pedantic.

> Having shipped a product that implements the strict interpretation of the
> current specs (WRT signature_algorithms) for a number of years now, I
> remember exactly 3 related problem reports. Without pointing fingers (as
> much as possible), here they are:

Past performance is not a guarantee of future returns.

Today, TLS 1.2 clients generally support all the defined hash
algorithms, so problems are rare.  In the future, there will be
new hash algorithms that not all clients will support, and there
will servers with chains that are signed with bleeding-edge
algorithms, there's no need to reject connections from clients that
don't need to verify said signatures.

> My preference would be to keep the client explicitly advertising its
> capabilities, and the server strictly honoring the client-advertised
> capabilities. And since the concept of "default algorithms" confuses
> people, let's just get rid of it in 1.3. Conveniently, most of this WG no
> longer wants SHA1 or MD5. Why not just make signature_algorithms (even
> more) clearly and unambiguously MTI in 1.3?

An opportunistic TLS or DANE TLSA client cannot advertise the
capability of supporting algorithms it was aware existed (by ignoring
all signatures in the chain).

We surely don't want to muddy the waters by adding "wildcard"
algorithm code-points, and new APIs for clients to request that
the TLS stack send those.

The proposal on the table is simply sensible.  The server lacks
sufficient information to make an informed decision as to whether
its chain is unacceptable, and therefore should send whatever chain
it has if it lacks a known compatible chain.  This is simply sound
engineering.  The alternative is needless incompatibility. 

That this also fixes the problem for some folks who don't want to
make sending the extension mandatory (and happen to get back a
chain they can accept) is a harmless accident.

-- 
	Viktor.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 13 Jul 2015 18:18:36 +0000

To keep it short, +1 to Viktor’s point.
-- 
Regards,
Uri Blumenthal

---

From: Dave Garrett <[email-masked]>
Date: Mon, 13 Jul 2015 14:52:09 -0400

> My preference would be to keep the client explicitly advertising its capabilities, and the server strictly honoring the client-advertised capabilities. And since the concept of "default algorithms"…

Yep. I already have that in a WIP branch at the moment. I'm merging together all my WIPs from WG discussion on the topics of alerts and certs here:

https://github.com/davegarrett/tls13-spec/compare/seanfixesredux...davegarrett:alertsandcerts

There's a backlog of PRs on main, so diffing on top of Sean Turner's fixes branch to reduce noise in the diff.

Dave

---

From: Andrei Popov <[email-masked]>
Date: Mon, 13 Jul 2015 19:45:30 +0000

> An opportunistic TLS or DANE TLSA client cannot advertise the capability of supporting algorithms it was aware existed (by ignoring all signatures in the chain).
> We surely don't want to muddy the waters by adding "wildcard" algorithm code-points, and new APIs for clients to request that the TLS stack send those.

Would it make sense for an opportunistic client to advertise all algorithms commonly supported in the server certs? After all, there are relatively few signature/hash pairs in use, and they are changing very slowly over time.

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
Sent: Monday, July 13, 2015 11:02 AM
To: [email-masked]
Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

> to honor the client's capabilities.

To the extent possible.  However, the server SHOULD NOT refuse to continue the handshake merely because it believes that some certificates in its chain might have signatures the client can't check.  The point being that the client may not need or attempt to check those signatures.

No, the language about the certificate chain is needlessly restrictive.
The decision as to whether the chain works for the client or not, SHOULD be left to the client.  The server's job is to *try* to avoid problems by sending a known-compatible chain when available.

> straightforward and deterministic handshake where the client MUST 
> advertise supported algorithms and the server MUST honor the client's capabilities.

The MUST honour bit cleanly applies to choices of algorithms in signature the server makes during and after the handshake.  However, honouring the algorithms for the chain signatures is more subtle.
Yes, send a compatible chain when possible, HOWEVER, DO NOT prejudge the client's inability to handle an alternative chain if that's all you have.  As explained before, opportunistic TLS, DANE, pinning, ...  may mean that the client does not in fact examine the signatures in the chain and the handshake would succeed, if only the server were not needlessly pedantic.

> Having shipped a product that implements the strict interpretation of 
> the current specs (WRT signature_algorithms) for a number of years 
> now, I remember exactly 3 related problem reports. Without pointing 
> fingers (as much as possible), here they are:

Today, TLS 1.2 clients generally support all the defined hash algorithms, so problems are rare.  In the future, there will be new hash algorithms that not all clients will support, and there will servers with chains that are signed with bleeding-edge algorithms, there's no need to reject connections from clients that don't need to verify said signatures.

> people, let's just get rid of it in 1.3. Conveniently, most of this WG 
> no longer wants SHA1 or MD5. Why not just make signature_algorithms 
> (even

An opportunistic TLS or DANE TLSA client cannot advertise the capability of supporting algorithms it was aware existed (by ignoring all signatures in the chain).

We surely don't want to muddy the waters by adding "wildcard"
algorithm code-points, and new APIs for clients to request that the TLS stack send those.

The proposal on the table is simply sensible.  The server lacks sufficient information to make an informed decision as to whether its chain is unacceptable, and therefore should send whatever chain it has if it lacks a known compatible chain.  This is simply sound engineering.  The alternative is needless incompatibility. 

That this also fixes the problem for some folks who don't want to make sending the extension mandatory (and happen to get back a chain they can accept) is a harmless accident.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Mon, 13 Jul 2015 23:20:59 +0200 (CEST)

> Curve25519 but deciding to send Curve25519 anyway?

The choice of Curve25519 for an ECDHE_RSA or ECDHE_DSA key exchange is a
transform at the _TLS_ protocol level that a client's _TLS_ implementation
must support in order to perform the TLS handshake.

Algorithms for the signature on the server certifcate or signatures
higher up the certificate path conveyed by the server are

  -   *NOT* part of the TLS handshake, they're instead performed
      by what is usally a totally different software module (PKIX)
      from the TLS protocol implementation

  -   *NOT* predictable to be used to get used (and verified) by the
      client's certificate path validation function after whatever
      fancy "certificate path discovery" the client might be performing
      before validating the server's certificate.  The client might
      also be directly trusting the server's key (cert pinning,
      DANE usage 3 and other possibilities), where it is not clear
      whether the the signature on the certificate presented by the
      server needs to be verified at all.

So the difference here is HUGE.

Btw., TLSv1.2 implementations that do not support multiple server
certificates that differ only by algorithms, are probably skipping the
entire TLSv1.2 cert signature algorithms fandango and exhibit a highly
interoperable behaviour quite naturally.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Jul 2015 22:08:20 +0000

On Mon, Jul 13, 2015 at 07:45:30PM +0000, Andrei Popov wrote:

> Would it make sense for an opportunistic client to advertise all algorithms
> commonly supported in the server certs? After all, there are relatively
> few signature/hash pairs in use, and they are changing very slowly over
> time.

This does not work when new algorithms are introduced, since you
can't advertise algorithms you don't know exist.

-- 
	Viktor.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 13 Jul 2015 22:31:16 +0000

> This does not work when new algorithms are introduced, since you can't advertise algorithms you don't know exist.
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?

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
Sent: Monday, July 13, 2015 3:08 PM
To: [email-masked]
Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

On Mon, Jul 13, 2015 at 07:45:30PM +0000, Andrei Popov wrote:

> Would it make sense for an opportunistic client to advertise all 
> algorithms commonly supported in the server certs? After all, there 
> are relatively few signature/hash pairs in use, and they are changing 
> very slowly over time.

This does not work when new algorithms are introduced, since you can't advertise algorithms you don't know exist.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Tue, 14 Jul 2015 01:08:11 +0200 (CEST)

> can't advertise algorithms you don't know exist.

Pretty much *ALL* TLS implementations in the installed base implement
TLSv1.1 _and_ do the right thing when negotiating a server certificate
for a client that proposes at most TLSv1.1.

So if the TLSv1.2 server certificate selection fails, just do the
TLSv1.1 server certificate selection.  It is really that easy,
and produces a very backwards-compatible behaviour that will be
highly appreciated by all TLS client, users and helpdesks.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Jul 2015 02:47:11 +0000

On Mon, Jul 13, 2015 at 10:31:16PM +0000, 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.
> 

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.

Furthermore, DANE-EE(3) clients and certificate pinning clients
cannot use anon_DH, they still a recognizable certificate from the
server, they just often don't need a recognizable signature.  Even
DANE-TA(2) clients might be able to stop part-way up the chain
before the objectionable signature appears.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 14 Jul 2015 00:38:51 -0400

> before the objectionable signature appears.

Generic open-ended question: Is there anything else with regard to getting DANE working more smoothly that needs addressing?

The current CA-based system generally sucks, and whilst not everyone agrees that DANE is currently the ideal alternative, fixing issues inhibiting it could improve things here. It really would be nice if TLS 1.3 was as DANE-friendly as possible so we can start getting support built into more clients and be less reliant on the current mess.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Jul 2015 05:22:29 +0000

On Tue, Jul 14, 2015 at 12:38:51AM -0400, Dave Garrett wrote:

> Generic open-ended question: Is there anything else with regard to getting
> DANE working more smoothly that needs addressing?

>From a TLS standards perspective, we're in reasonably good shape.

The main remaining friction point is server software that is
incapable of including self-signed root CAs in the server's wire
certificate chain.

With DANE-TA(2), the trust-anchor certificate MUST be in the
server's certificate message (wire chain) even if it is a
self-signed "root".  So if a site wants to designate a self-signed
DANE trust anchor, it must find a way to include it in server
chains.

This is not a protocol problem as such.  Rather, the fact that the
specification says that server MAY omit root CA certs with a
"traditional" X.509 PKI means that some software stacks provide no
means for the server administrator to force inclusion.

With TLS 1.3, perhaps updated text could reference the imminent
RFC 6698 update (draft-ietf-dane-ops, scheduled for the IESG telechat
on Aug 6th) and mention that a mechanism needs to exist for servers
to request inclusion of root trust anchor certificates (when the
library constructs the chain on the fly by augmenting the application
provided leaf certificate with the requisite intermediate CA certs,
but at present by default leaves out the root CA cert).

In addition, with DANE-EE(3) TLS libraries are expected to accept
end-entity certificates that are expired or bear the wrong server
name, provided the certificate or enclosed public key matches the
TLSA record.  Thus (again not a protocol issue), it would be nice
if TLS libraries did not get in the way of that, but presumably
this gets fixed when the library adds DANE support.

Speaking of DANE support in libraries, there are as yet no mainstream
libraries that offer correct and complete DANE support.  I expect
to remediate this for one or two open source libraries.

Last I looked GnuTLS DANE support was rather incomplete, "ldns"
was insecure and libval was fragile.  Neither OpenSSL nor mTLS (aka
PolarSSL) at present support DANE.

In general don't trust DANE "addons" that are not core parts of
the underlying TLS library, this is very difficult to get right.
DANE support needs to be "baked in" as part of the core chain
construction and validation logic of the TLS library.  The application
can provide the validated TLSA RRset, the TLSA base domain and zero
or more additional reference identifiers (with DANE there can be
multiple valid hostnames for the server end of a client's TLS
connection), and the library should then do the rest.

I'd like to see DANE support in the not too distant future in at
least:

	* OpenSSL
	* mTLS
	* GnuTLS
	* NSS
	* Schannel
	* Java

-- 
	Viktor.

---

From: Hubert Kario <[email-masked]>
Date: Tue, 14 Jul 2015 11:31:26 +0200

> New version with a little rewording and a typo fix.

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

---

From: [email-masked] (Martin Rex)
Date: Tue, 14 Jul 2015 15:46:12 +0200 (CEST)

> 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Jul 2015 15:38:51 +0000

> 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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Jul 2015 19:16:13 +0000

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. ]

>     CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };

Which still leaves us with (sorry about the OpenSSL-specific names):

    AECDH-AES256-SHA        SSLv3 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-SHA        SSLv3 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.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 14 Jul 2015 19:30:38 +0000

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:[email-masked]] On Behalf Of Viktor Dukhovni
Sent: Tuesday, July 14, 2015 12:16 PM
To: [email-masked]
Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

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.

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.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Jul 2015 12:55:52 -0700

> 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.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 14 Jul 2015 20:06:19 +0000

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:[email-masked]] 
Sent: Tuesday, July 14, 2015 12:56 PM
To: Andrei Popov
Cc: [email-masked]
Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

> 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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Jul 2015 20:08:39 +0000

On Tue, Jul 14, 2015 at 07:30:38PM +0000, 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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Jul 2015 20:11:57 +0000

On Tue, Jul 14, 2015 at 08:06:19PM +0000, 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.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Jul 2015 13:49:36 -0700

On 14 July 2015 at 13:08, Viktor Dukhovni <[email-masked]> wrote:
> which is often useful information on the server end.

The problem here is that the server isn't the only recipient of that signal.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Jul 2015 21:35:34 +0000

> 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.