Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

[Geoffrey Keating]

Joseph Salowey  writes:

> The last call has come and gone without any comment.  Please indicate if
> you have reviewed the draft even if you do not have issues to raise so the
> chairs can see who has reviewed it.  Also indicate if you have any plans to
> implement the draft.

I looked at the draft.

My understanding of the draft (and I think it would have helped if it
contained a diagram showing the resulting TLS handshake) is that it's
specifying the existing psk_dhe_ke flow, to which it adds a
certificate-based signature over the handshake, which it doesn't
specify but works the same way as in RFC 8446 when there is no PSK.

This is somewhat confusing because the draft is written as if it
starts with a certificate-based TLS flow and somehow adds a PSK; it
repeats all the RFC 8446 PSK machinery, but doesn't explain how the
certificate interacts with it, and raises questions like "are there
two DH operations or just one?".  I think the draft could have been a
lot shorter.

Conversely, one area where the draft could have been longer would be to
explain how exactly this produces quantum-resistance in the presence
of a secret shared key.  It appears that it relies on the HKDF-Expand
function being quantum-resistant.  That seems like an important thing
to document, given that we don't have fully functional quantum
cryptanalysis yet and so don't know exactly what might be
quantum-resistant or not.

However, once you're past that, the resulting protocol seems quite
simple (as an addition to psk_dhe_ke) and I have no objections to it.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

[Geoffrey Keating]

Viktor Dukhovni  writes:

> TL;DR:  Should TLS client abort DHE-RSA handshakes with a peer
> certificate that *only* lists:
> 
> X509v3 Key Usage: 
> Key Encipherment, Data Encipherment

Yes, because in DHE-RSA, the RSA key is used for signing, and this is
an encryption-only key.

It's much more important in the DHE-ECDSA case, because using an
encryption-only EC key for signing can lead to key compromise (IIRC).
As far as I know there's no similar attack on RSA, but I think this is
not a well-examined area.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-sni-encryption

[Geoffrey Keating]

m...@sap.com (Martin Rex) writes:

> If anyone really thinks that there should be a scheme where a
> server's hostname is no longer transfered in a cleartext (including
> TLS extension SNI), then first of all a *NEW* distinct URI method
> should be defined for that purpose, e.g. "httph://" as a reliable
> indicator to the client processing this URI, that the hostname from
> this URI is not supposed to be sent over the wire in the clear
> *anywhere*.

Although I can see how this, or some other mechanism, might be helpful,
I don't agree it has to happen *first*.  Why can we not start by providing
an ESNI mechanism, and then later standardize a mechanism to require it
for particular hostnames?

A limited-purpose client can just require TLS 1.3 and ESNI for all
connections, so such a mechanism would not be required for that
client.  In the future TLS 1.3 and ESNI deployment may be sufficiently
widespread that all clients could require them, making the mechanism
unnecessary.

Even if ESNI is opportunistic and so subject to active attacks, that
still eliminates passive network sniffing.  Even an active attack
would not (I think) lead to a successful connection, because of the
TLS anti-downgrade features, with consequences including user-visible
error messages or the device deciding the network is non-functional
and ceasing to use it, so although some hostnames may be revealed, the
user or device may stop before revealing all of them.  So ESNI is
still useful even if not mandatory.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] integrity only ciphersuites

[Geoffrey Keating]

"Nancy Cam-Winget \(ncamwing\)"  writes:

> In following the new IANA rules, we have posted the draft
> https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-00
> to document request for registrations of HMAC based cipher
> selections with TLS 1.3…..and are soliciting feedback from the WG on
> the draft and its path forward.

This draft needs more security analysis than is currently there, and
probably it needs to define not just a ciphersuite but an entire
profile for using TLS with this ciphersuite.  Some topics:

* Anything that relies on EncryptedExtensions should probably not be
used.

* The session ticket properties change in the absence of encryption.  In
existing TLS 1.3, they are sent only after Finished and so are
encrypted; now they are public.  I am not sure if this changes the
security model but it definitely makes it easier to attack the ticket.

* A less-obvious consequence to the lack of confidentality is that a
typical implementation, an attacker can selectively block messages
knowing their contents (by breaking the connection).  In the weather
example this might be used to manipulate average daily temperature by
blocking only higher or only lower readings.  In the robot example
this might be used to cause it to exceed its limits by allowing
movement commands only in one direction.

I wonder whether it's really helpful to call the result 'TLS' and
not something else?

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Captive portals, "access administratively disabled" and alert messages

[Geoffrey Keating]

Two problems with this proposal, that don't occur with the proposal
the capport WG is working on, are:

- What do you do if you get one of these alerts over multipath TCP?

- What happens if some site far away on the Internet sends you one of
  these alerts?  Perhaps because DNS was forged and hasn't timed out
  yet?

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS specification clarification in case of client authentication: different CA with DN different only in case

[Geoffrey Keating]

devzero2000  writes:

> Hello everyone
> 
> >From the tls 1.2 specification, speaking of client authentication,
> https://tools.ietf.org/html/rfc5246#section-7.4.4 par 7.4.4 (but it is the
> same for the last tls draft 1.3 par. 4.2.4.)
> 
> when he says:
> 
> certificate_authorities
>   A list of the distinguished names [X501] of acceptable
>   certificate_authorities, represented in DER-encoded format.
> 
> What would be the right behavior if the server has the certificates of two
> different CAs (different subject key info, public key parameter) but whose
> subject DN differs only for the case (for example
> something like this
> 
> Subject: /C=US/ST=California/L=Mountain View/O=XXX Inc/CN=mail.xxx.com
> 
> and
> 
> 
> Subject: /C=US/ST=California/L=mountain View/O=XXX Inc/CN=mail.xxx.com

These are the same distinguished name under RFC 5280 section 7.1,
although in practice implementations may treat them as different, most
notably under the older RFC 3280 rules.  I believe the correct
behaviour is to Not Do That---do not generate certificates which have
distinguished names that match under RFC 5280 and are not
byte-for-byte identical in DER format, if you must do that make sure
they are not valid at the same time, and if you must do that, try to
ensure no piece of software is aware of both of them, and if you must
do that, don't be surprised if the behaviour is inconsistent and
especially don't be surprised if the LDAP StringPrep rules are not
implemented correctly or at all.

And if you value your sanity, don't rely on anything that might change
if the Unicode standard is revised.

However, the TLS specification doesn't say that the list must contain
each DN only once.  So in this situation I would suggest the software
should list both.  Indeed I would recommend listing every distinct DER
representation that's present in any acceptable certificate.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] comments on draft-ietf-tls-tls13-19

[Geoffrey Keating]

Ilari Liusvaara  writes:
> > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos 
> > wrote:
> > 
> > > My issue with OCSP when used under TLS was how to determine the
> > > validity of the response when the nextUpdate field is missing. I've
> > > added some text for that introducing an (arbitrary) upper limit at:
> > > https://github.com/tlswg/tls13-spec/pull/974
...
> Anybody happens to know a CA that doesn't put NextUpdate in? If so,
> what's the OCSP issuance frequency?

The definition is:

   If nextUpdate is not set, the responder is indicating that newer
   revocation information is available all the time.

I think 15 days is much too long.  I would suggest wording it more like:

If the nextUpdate value is omitted, the server SHOULD refresh the
response so that the thisUpdate field is no more than 24 hours in
the past.

and not place any requirement on the client; if the client wants
fresher information than the server provides, it can go fetch it
itself.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Geoffrey Keating]

BITS Security  writes:

> Outbound TLS connections require MITM for decryption.  Inbound or
> internal TLS connections can be decrypted with an RSA private key
> under TLS 1.2.

It would be unwise to build a security or regulatory structure on the
principle that MITM will always be possible.  This is especially true
for the kinds of popular and frequently attacked services for which
DLP might be important, like Facebook, Twitter, Google, Apple,
Dropbox, Github.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Geoffrey Keating]

Ryan Carboni  writes:

> in the internet of things, DH is actually
> less secure than normal public key exchange. Servers are more likely to
> have entropy than embedded devices.

I think that's backwards; in a 'normal' public key exchange, it is the
client that generates the secret key, the server contributes no
randomness.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] CertficateRequest extension encoding

[Geoffrey Keating]

Peter Gutmann  writes:

> David Benjamin  writes:
> 
> >Either way I imagine our stack will just keep on ignoring it, so I don't feel
> >about this all too strongly. But the topic came up so I thought I'd suggest
> >this.
> 
> I ignore it too.  Client certs are so rare, and so painful to deploy, that I'm
> not going to make things harder on users by adding complex and opaque
> filtering to prevent them from working.  My approach is to specify as few
> constraints as possible, the client submits whatever certificate it has, and
> it's then decided based on a whitelist for which the server can very clearly
> report "not on the whitelist" when it rejects it.  The design seems to be
> based on the idea that each client has a smorgasbord of certs and the server
> can specify in precise detail in advance which one it wants, when in reality
> each client has approximately zero certs, and the few that do have one just
> want the one they've got to work.

A typical macOS system will have many issued certs, typically with at
most one that will work for any particular web site or web API.  So
the filter is somewhat important for client certs to work there in any
kind of user-friendly way.  In particular if the server provides no
guidance, the UI will ask the user, presenting a dialog containing
many certificates the user is not aware they have, leading to complete
user confusion.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 3DES diediedie

[Geoffrey Keating]

Tony Arcieri  writes:

> This attack was published today[*]:
> 
> https://sweet32.info/
> 
> I bring it up because I think the threat model is similar to the threats
> that lead to RC4 "diediedie"
> 
> https://www.rfc-editor.org/info/rfc7465
> 
> Should there be a 3DES "diediedie"?

I think so.

> I believe 3DES is MTI for TLS 1.0/1.1(?) but I think it would make sense
> for it to be banned from TLS 1.3.

At least one purpose of such a RFC would be to replace the MTI ciphersuite
with a different ciphersuite.

> [*] Lest anyone claim the contrary, I am not surprised by this attack, and
> have pushed to have 3DES removed from TLS prior to the publication of this
> attack, and can probably find a TLS implementer who can back me up on that.

The problem has even been described previously on this very mailing list
 (the
original is off here:
).


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

[Geoffrey Keating]

Peter Gutmann  writes:

> The problem is that 7919 doesn't say "I want to do DHE, if possible
> with these parameters", it says "I will only accept DHE if you use
> these parameters, otherwise you cannot use DHE but must drop back to
> RSA".  Talk about cutting off your nose to spite your face, you'd
> have to have rocks in your head to want to break your implementation
> like that.

Actually, my problem with the RFC is the reverse.  If you have an
implementation which won't accept certain DH groups, and those are
extremely common in legacy software (1024-bit, for example), there's
no way to stop those legacy implementations ignoring the extension and
choosing DH, which you will then have to reject, doubling connection
establishment time.

So Apple's client still has DH off.

However I don't see a helpful solution to this; the obvious thing is
to have a new ciphersuite, but it's hard to see how that would be
worth the effort if it requires new implementations and ECDHE is
already standardised and already implemented in many places.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

[Geoffrey Keating]

Peter Gutmann  writes:

> Viktor Dukhovni  writes:
> 
> >There's no guess, the client sends its full list of supported
> >groups, and the server picks the one it likes.
> 
> ... and if the client doesn't get it exactly right, the server has to fall
> back to RSA rather than use another DHE suite of its choosing.

I believe that's the intention; the assumption is that the client
using this extension doesn't want DHE parameters that it doesn't have
configured, it only wants one of a pre-validated list of
groups/generators.  It especially doesn't want the server to say
"well, I know the client listed only groups 2048-bit and higher, but I
have this 512-bit group, let's use that".

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Keeping TLS extension points working

[Geoffrey Keating]

Hubert Kario  writes:

> On Thursday, 28 July 2016 06:12:48 CEST Watson Ladd wrote:
> > On Thu, Jul 28, 2016 at 3:28 AM, Hubert Kario  wrote:
> > > On Wednesday, 27 July 2016 09:50:18 CEST Wan-Teh Chang wrote:
> > >> Another source of interop failures is the firewall devices that do
> > >> anomaly detection.
> > > 
> > > how about adding a section that explicitly says what they are allowed to
> > > do, and what they should not do?
> > 
> > This is what parsing is for.
> 
> yes, and bugs in parsing may very well be exploitable
>  
> > > in other words, how they can still provide added value without breaking
> > > TLS in the future
> > 
> > Maybe they can't, and you shouldn't buy those products.
> 
> pragmatist would say that double checking is defence in depth
> 
> and whatever we think, doesn't change the fact that people do make them 
> because people do buy them, so at least we can tell them how they can play 
> nice

I don't think 'playing nice' is the point of these devices; the
concept is that unusual is bad, and so should be blocked.  They don't
just block new or unknown features, but sometimes also known features
being used in unusual combinations.  I've seen these devices raise a
security alert because of a ciphersuite list which contained only
ciphersuites used by browsers, but not in the expected
combination/order---at least, that's what I think it was.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption of TLS-LTS

[Geoffrey Keating]

Peter Gutmann  writes:

> Hubert Kario  writes:
> 
> >to be pedantic, the RFC describes itself "a profile" while in reality it
> >modifies the protocol in a way that will make it incompatible with "vanilla"
> >TLS 1.2 implementations
> 
> Oh, right.  Well that's easily fixed, I used "profile" because I
> couldn't think of a better term, the best I could come up with is
> "plan", but it's not really a plan either.  If people think "plan"
> is better than "profile", and it deals with Russ' objection, I'll
> change it to that.  Alternatively, if you can think of a better term
> than "plan", let me know (or forever hold your peace :-).

I think an appropriate title might be

 The Transport Layer Security (TLS) Protocol
 Version 1.2.1 Update

because that's what this is, isn't it?  It's a new version of the
protocol with minor but significant changes.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

[Geoffrey Keating]

Ryan Hamilton <r...@google.com> writes:

> On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating <geo...@geoffk.org>
> wrote:
> 
> > So, I don't think HTTP is generally safe against attacker-forced
> > replay, and would suggest great caution in allowing it.
> >
> 
> It's worth keeping in mind this recent paper about Replay attacks against
> HTTPS <http://blog.valverde.me/2015/12/07/bad-life-advice/#.VucOsJMrIxN>.
> TL;DR: Attackers can already force a browser to replay requests basically
> at will. ​As a result, it's not clear that 0-RTT replay makes this
> situation worse.

The blog indicates that it's possible to cause a browser to repeat a
request exactly once, within a short timeframe (probably 60 seconds or
so) before the browser times out; and the browser must not see the
first request succeed.  That's quite different from being able to let
a client make and complete a request, and then being to repeat that
request thousands of times over a period of hours or longer; even if
the client is a browser, it might be hard to convince it to do that.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Require deterministic ECDSA

[Geoffrey Keating]

[I guess we're top-posting...]

Another benefit is that if it turns out the entropy source is broken,
then if client/server random or IV is guessable, that's something that
affects one connection and can be addressed for future connections by
fixing the entropy source.  But if k generation is broken, then that
leaks the key permanently and you need to get a new one and revoke the
old one, which may be difficult.

Perhaps the RFC should say something to that effect?  I think there's
already a section in the security considerations about random number
generators.

Joseph Birr-Pixton  writes:

> Hi,
> 
> The other benefit is being able to test that a critical code path
> produces the correct answers. With randomised k, this is not really
> possible. For instance, you can choose k with the top bit clear
> without any obvious or externally-testable effects, except effectively
> publishing your long-term private key after a large number of
> signatures[1].
> 
> Given the history of these things, I would perhaps challenge the
> assumption that all TLS stacks will have a bug-free, thread-safe,
> fork-safe, high quality, uncompromised, backdoor-free, unbiased random
> number generator :)
> 
> Cheers,
> Joe
> 
> [1]: 
> http://people.rennes.inria.fr/Jean-Christophe.Zapalowicz/papers/asiacrypt2014.pdf
> 
> On 23 January 2016 at 19:27, Jacob Maskiewicz  wrote:
> > The main argument I see from the RFC for deterministic ECDSA is computing k
> > on systems without high quality entropy sources. But any system running a
> > TLS stack is already going to have a high quality entropy source for
> > client/server randoms and IVs and such, so what's the benefit of
> > deterministic ECDSA here?
> >
> > -Jake M
> >
> > On Jan 23, 2016 11:13 AM, "Joseph Birr-Pixton"  wrote:
> >>
> >> Hi,
> >>
> >> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA.
> >>
> >> For discussion, here's a pull request with possible language:
> >>
> >> https://github.com/tlswg/tls13-spec/pull/406
> >>
> >> Cheers,
> >> Joe
> >>
> >> ___
> >> TLS mailing list
> >> TLS@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Controlling use of SHA-1

[Geoffrey Keating]

Viktor Dukhovni  writes:

> On Thu, Oct 22, 2015 at 08:42:51AM +0100, Rob Stradling wrote:
> 
> > IINM this also changes the fallback for servers that choose to include a
> > PKIX trust anchor certificate in the Server Certificate message.
> 
> The signatures of trust-anchor (i.e. self-signed) certificates MUST
> NOT be constrained by this proposal, even if the WG otherwise
> chooses to step outside the proper scope of TLS into PKIX chain
> validation.

I believe nothing is constrained by this proposal in the form you're
thinking.  That is, it's only if you have two versions of the root,
one with a requested algorithm and one without, that this proposal
comes into play.

At least, I think that's the intent.  It might help to clarify this in
the proposal.  It should be noted that the situation can become quite
complicated, for example it's possible that there might be one chain
which uses only SHA-2 which chains to one newer root, and another
chain which uses mostly SHA-1 and chains to a different older root.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Review of PR #209

[Geoffrey Keating]

Daniel Kahn Gillmor  writes:

> Consider a server has an ongoing session wrapped in TLS that uses client
> authentication to approve or deny some requests from the client.  It
> remembers what requests the client has made as some sort of relevant
> state.  Let's take an imap server working with a client that has state
> of a "currently-examined folder", but this applies to servers and
> clients with much more complex state as well.
...

I think for such a protocol, you'd want to say that authentication is
not retroactive.

For other protocols, you might want something else.  For example, in a
protocol which uses client authentication for billing, you might want
to treat an authentication half-way through the session as the account
to bill for the entire session.

Some protocols will also want to support multiple identities, and some
will not.  For some protocols a new authentication might want to in
some fashion dis-trust previous authentications, other protocols might
say that all previous authentications are valid until the end of the
session.


I think this is something that TLS should allow higher-level protocols
to specify.  The TLS model could be that each client authentication
happens at a particular point in the session, breaking it up into
segments, and TLS informs the higher-level protocols of where the
segments start and end; it's up to the higher-level protocol to work
out what that means.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-whyte-qsh-tls13-01.txt

[Geoffrey Keating]

William Whyte  writes:

> Hi all,
> 
> We've updated the TLS 1.3 Quantum Safe Handshake draft to use extensions as
> suggested by DKG in Prague. All comments welcome.
> 
> There's an interesting issue here: McEliece keys, which should be
> permissible, are larger in size (about 2^20 bytes) than the maximum
> permissible extension size (2^16-1). In order to support McEliece keys it
> might be worth increasing the maximum extension size to 2^24-1 for TLS 1.3.
> Is there a strong reason for keeping the maximum size at 2^24-1, other than
> saving one byte on all the relevant length fields?

That would affect the initial client hello, which I think we're trying
to keep backwards compatible.  It might be better to just define a
rule like "if multiple extensions with the same number are present,
their values are concatenated".

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Should we require implementations to send alerts?

[Geoffrey Keating]

Martin Thomson  writes:

> On 12 September 2015 at 13:49, Eric Rescorla  wrote:
> > "Nobody must ever be required to send an alert. Any requirement for sending
> > an alert should be SHOULD, at most."
> 
> This was a point of debate for HTTP/2 as well.  The conclusion there
> was that you had to be prepared to have the connection disappear
> without warning for various reasons, so requiring that an error be
> sent was silly.
> 
> After all, what are you going to do when the connection drops without
> a GOAWAY?  Drop the connection?

Try again, assuming the problem is a one-time glitch?

> That only applies to fatal alerts of course, but I don't see a lot of
> use of the warning level, in fact, they might be a bad thing to
> support (but that's a separate subject).  My suggestion is that we
> require that endpoints treat certain errors as fatal and maybe suggest
> a particular alert.  However, also note that they MAY drop the
> connection without sending the alert OR that even if they do send the
> alert, it might get lost.

For a lot of the alerts, two correct implementations speaking to each
other should never use them, so it's hard to standardise what to do about them.

However I would suggest that the unsupported_certificate, unknown_ca,
protocol_version or insufficient_security alerts, benefit
interoperability because the server (or client in some cases) might be
able to do something different in the negotation if it is retried (for
example present a different certificate chain), but only if it knows
what the problem was.  So I'd suggest these should be MUST.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Geoffrey Keating]

Jeffrey Walton noloa...@gmail.com writes:

 
  Also, if DSA was to be supported, one would need to specify how to
  determine the hash function (use of fixed SHA-1 doesn't fly). And
  1024-bit prime is too small.
 
 FIPS186-4 (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf)
 partially remediates the issue. DSA now includes 2048 and 3072 sizes.

This is true, but if TLS 1.3 was to specify DSA, it should require the
2048 or 3072 sizes (since 1024 is last century's crypto), and existing
implementations do not necessarily support those today.

Which really highlights the question: who would actually use it?
ECDSA can be smaller, faster, and more secure all at once; and if you
don't like ECDSA or want an alternative, there's RSA.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls