Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document

[Viktor Dukhovni]

On Sat, Apr 20, 2024 at 04:12:48AM +, Peter Gutmann wrote:

> I realise that absence of evidence != evidence of absence, but in response to
> my previous request for anyone who has such a thing to comment on it, and even
> better to send me a sample so I can see one, no-one has mentioned, or
> produced, even one example of "a legitimate CA-issued [static-epmeheral DH
> certificate] rather than something someone ran up in their basement for fun".
> 
> So is the draft busy deprecating unicorns and jackalopes?  Nothing against
> that, but it's probably worth adding a note that such certificates are
> currently not known to exist so you probably don't have to worry about it too
> much.

Can't say I've seen any static DH certificates in the wild, but
I have seen code to support these, and perhaps the point is to
bless deprecating/disabling/removing such code?

In any case, this feels like cosmetic cleanup, rather than an
effort to migrate a significant population of existing users
to better practice.

-- 
Viktor.

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

Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

[Viktor Dukhovni]

On Thu, Mar 28, 2024 at 03:22:05PM +, John Mattsson wrote:

> I looked into what RFC 8446(bis) says about Raw Public Keys. As
> correctly stated in RFC 8446, TLS 1.3 with signatures and certificates
> is an implementation of SIGMA-I:

Assuming certificates are issued with strong assurance, which, with DV
certificates, is perhaps somewhat questionable.

> SIGMA does however require that the identities of the endpoints
> (called A and B in [SIGMA]) are included in the messages. This is not
> true for TLS 1.3 with RPKs and TLS 1.3 with RPKs is therefore not
> SIGMA. TLS 1.3 with RPKs is vulnerable to what Krawczyk’s SIGMA paper
> calls misbinding attacks:

The SNI extension in TLS allows servers that are the targets of
misbinding attacks to detect that the client was trying to communicate
with a different system, and in the case of HTTPS, there is also the
required "Host:" host header, which again will alert the server to the
fact that the client is requesting an unsupported resource.

Many operators obtain wildcard certificates, again a server should take
measures to ensure that among all the hosts sharing the same DNS suffix,
the session was actually intended for it, and not another service
endpoint, though in the case of multiple application services on the
same machine, that isn't always possible, because SNI conveys just
the hostname.

> “Even more significantly we show here that the misbinding attack
> applies to this protocol in any scenario where parties can register
> public keys without proving knowledge of the corresponding signature
> key.”

Note, that, for example, with SMTP the simplest way to direct traffic to
someone else's MX host is to publish MX records for one's own domain
that specify that MX host.  So "misbinding" attacks are not
"interesting" in this context.  Furthermore, because there are no
"cross-origin" issues in SMTP, there is nothing to be gained by
misleading a client that it is connected to a service endpoint for which
one can control the expected public key binding, when in fact it is
connecting to a "victim" service endpoint.

And of course how clients learn the association between and endpoint,
and the expected raw public key is a rather separate matter from whether
public keys or certificates happen to be used.  The public key might
be pre-shared out of band over a pre-existing bilateral trusted channel
between client and server, and proof of possession could be part of
that exchange if desired and useful.

> TLS 1.3 with PRKs does not fulfill this unless the out-of-band
> mechanism to register public keys proved knowledge of the private key.
> RFC 7250 does not say anything about this either.

If the server rejects unexpected SNI (including absence of SNI), that
should close the gap.

> I think this needs to be clarified in RFC8446bis. The only reason to
> ever use an RPK is in constrained IoT environments.

This is much too narrow a use-case.  There are other valid scenarios.

> self-signed certificate is a much better choice. TLS 1.3 with
> self-signed certificates is SIGMA-I.

Assuming the client looks at the name in the certificate, which isn't
always the case. And that the certificate isn't a wildcard certificate,
and the there aren't multiple TLS service endpoints at the same
hostname, where redirection from one application service to another,
might be a concern...

> It is worrying to find comments like this:
> 
> “I'd like to be able to use wireguard/ssh-style authentication for my
> app. This is possible currently with self-signed certificates, but the
> proper solution is RFC 7250, which is also part of TLS 1.3.”
> https://github.com/openssl/openssl/issues/6929

There are legitimate use-cases for RPKs, including at least some where
UKS attacks are not applicable.

> RPKs are not the proper solution.

RPKs are a solution when obtained from a trusted party, e.g. for
connections between machines controlled by the same operator, or
SMTP (given MX indirection described above), or in applications where
cross-origin attacks don't apply, ...

> (Talking about misbinding, does RFC 8446 say anything about how to
> avoid selfie attacks where an entity using PSK authentication ends up
> talking to itself?)

PSKs are not generally symmetric.

-- 
Viktor.

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Viktor Dukhovni]

On Mon, Dec 11, 2023 at 07:51:13PM -0800, Rob Sayre wrote:

> > Absolutely clear.  I work with stuff with 20-30 year deployment and
> > life cycles.  I'm fairly certain TLS 1.2 will still be around when
> > the WebTLS world is debating the merits of TLS 1.64 vs. TLS 1.65.
> 
> I have to say, I am skeptical of this claim. The reason being that you
> don't really want 20 year old computers connected directly to local
> ethernet without a bridge.

Did Peter say anything about (general purpose) computers or connections
to the "local ethernet" (or Internet)?  Suppose you have a control
system for a ship, an factory floor, or a nuclear power plant.

How often would one want to perform major software updates that
substantially change aspects of the system design?  What is the expected
lifetime of such systems?

Since Peter has been addressing market needs in that space for some
decades, I'd be inclined to take him at his word...

Again, it may well be that he does not have a compelling case for
ongoing TLS working-group processes to enhance TLS 1.2, or he may yet.

Peter, is there anything beyond TLS-TLS that you're looking to see work
on?  Is the issue foreclosing on opportunities to do anticipated
necessary work, or is it mostly that the statement that the work can't
happen causing disruption with audits and other bureaucratic issues?

-- 
Viktor.

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Viktor Dukhovni]

On Mon, Dec 11, 2023 at 06:38:05PM -0500, David Benjamin wrote:

> Protocol changes generally require both client and server changes to take
> effect. Pre-existing deployments, by simply pre-existing, will not have
> those changes. If we add, say, post-quantum options for TLS 1.2, it will
> benefit zero existing TLS 1.2 deployments. If we add post-quantum options
> for TLS 1.3, it will benefit zero existing TLS 1.3 deployments. That's not
> why we make these changes. We make them to benefit *future* TLS
> deployments, e.g. when server operators update their software. Although it
> can be a slow progress, pre-existing deployments gradually cycle into
> updated deployments.

FWIW, I had already considered this, and in fact essentially agree with
this take on the tradeoffs.  My point is mainly that there is legitimate
room for some diversity of opinion.

As you noted in your response, the PKCS1 barrier to TLS 1.3 adoption
that might be holding back some operators will be addressed.  Another,
that likely won't is that negotiation of "psk_ke" is particularly
brittle in TLS 1.3, and in constrained environments DH on every
resumption could be problematic.

My personal list of pain points is short, others can probably think of a
few more.  I actually don't object to the draft.  Rather, perhaps
"over", reacting to Rob's apparent negative reaction to posing the
question of whether the draft was *necessary*.

-- 
Viktor.

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Viktor Dukhovni]

On Mon, Dec 11, 2023 at 02:40:41PM -0800, Rob Sayre wrote:

> > Given that TLS 1.2 will be around for quite some time
> 
> Not clear.

As a data point, I've had no luck so far with encouraging the email
operators of domain-registry.bg to upgrade their primary MX from TLS 1.0
to at least TLS 1.2. :-(

> I don't think anyone did that (including me). The question is whether the
> IETF should state that continuing work on TLS 1.2 is not worth doing.

Indeed that's the question, but there's a spectrum of choices.  One
choice is to preclude such work now.  Another is to swiftly decline
non-compelling proposals as they come up.

If there is indeed a sufficient stream of new distracting proposed TLS
1.2 tweaks then perhaps closing the gate is well motivated.  If the
volume of proposals is sufficiently low, there's no need to solve
non-problems.  Somewhere in between it can be difficult to know which is
the right choice, but we can but do our best.

-- 
Viktor.

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Viktor Dukhovni]

On Mon, Dec 11, 2023 at 12:32:36PM -0800, Rob Sayre wrote:

> PS - I have to say, not in this message, but sometimes it seems like the
> goal of TLS 1.2 advocates is weaker encryption. So, for them, the flaws in
> TLS 1.2 that the draft describes are desirable. If that's the case,
> participants are not working toward the same goal. Writing down the
> consensus seems worth it.

For what it is worth, my agenda/perspective has never been to weaken
encryption.  Rather, it has always been about making usable encryption
ubiquitous.  While we continue work on raising the ceiling, one can be
legitimately weary of raising the floor so high that encryption is
unusable, and communication happens in the clear instead.

Given that TLS 1.2 will be around for quite some time, it is not obvious
that a feature freeze will in practice improve security.  It is good
that there's ongoing effort to make TLS 1.3 better, and I accept that it
may well not be possible to deliver on required TLS 1.3 work and to also
make some occasional modest improvements to TLS 1.2, but if the goal is
to deliver secure products to users, a realist might accept that TLS 1.2
is likely to continue to be used for some time, and that those users
could be better served if some improvements continued to take place.

The contrarian possition of course assumes that such improvements
wouldn't be a significant drain on scarce resources.  That assumption is
a matter for debate, and the "right" trade-offs are not completely
obvious.  Some difference of perspectives can be expected.

Whatever else we do, we should not default to questioning the motives of
others who would make somewhat different tradeoffs.  Worry more when
everyone is in violent agreement, perhaps something is then being
missed.

-- 
Viktor.

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Viktor Dukhovni]

On Wed, Dec 06, 2023 at 12:33:52AM -0500, Deirdre Connolly wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call
> is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.

I take no issue with the WG declining to do further non-emergency work
on TLS 1.2, if that promotes best use of scarce WG cycles.

I do however wonder why this requires a draft formalising the stance?
The simplest way to not do non-emergency work on TLS 1.2 seems to me to
not do non-emergency work on TLS 1.2.  Is the draft actually necessary?

Would not working on the draft save even more cycles?

-- 
Viktor.

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

Re: [TLS] I-D Action: draft-ietf-tls-8773bis-00.txt

[Viktor Dukhovni]

On Wed, Nov 29, 2023 at 10:49:42AM -0500, Russ Housley wrote:

> People are implementing RFC 8773, so I would like to advance this to
> the standards track.  In addition, this fixes the only errata that was
> posted against RFC 8773.
> 

I am somewhat confused by an apparent conflict between:

https://datatracker.ietf.org/doc/html/draft-ietf-tls-8773bis-00#section-3.2

which speaks of external PSK in the context of resumption, versus:

https://datatracker.ietf.org/doc/html/draft-ietf-tls-8773bis-00#section-5.1

The "pre_shared_key" extension is defined in Section 4.2.11 of
[RFC8446]. The syntax is repeated below for convenience. All of the
listed PSKs MUST be external PSKs. If a resumption PSK is listed
along with the "tls_cert_with_extern_psk" extension, the server MUST
abort the handshake with an "illegal_parameter" alert.

Are external PSKs applicable with resumption, or not???

-- 
Viktor.

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

Re: [TLS] Request mTLS Flag

[Viktor Dukhovni]

On Fri, Nov 17, 2023 at 09:57:42AM +, Peter Gutmann wrote:

> Viktor Dukhovni  writes:
> 
> >Indeed, Postfix 3.9 (release estimated Q1 '2024), when compiled against
> >OpenSSL 3.2 (release estimated circa next week), will automatically signal
> >client certificate types X.509(0) and RPK(2) iff and only a client
> >certificate is configured (available).
> 
> Could this use/behaviour be referenced somewhere to provide guidance for
> implementers in general?  It'd be good to have this made an official way to do
> things rather than just being done on an ad hoc basis.

What did you have in mind?  I guess an updated "mTLS flag" draft that
recommends overloading the cert type extension to  signal the client's
willingness to provide any one of the advertised cert types on request.

> >AFAIK, today just two MTAs are doing SMTP with raw public keys, both are
> >mine.
> 
> You have to wonder about the qualifications for being a standards-track RFC
> if, after ten years, the total installed base (at least for MTAs) is one
> person.

Well, not surprising, since the supporting code in both Postfix and
OpenSSL is brand new, and not yet present in any official release of
either OpenSSL or Postfix,

I'm running a pre-release Postfix snapshot compiled against a
pre-release version of OpenSSL, because I am the author of the RPK
support code for the former, and played a major role in guiding and
reviewing the underlying TLS code in the latter.

So it isn't the case that operators shied away from using RPKs, rather
they've had no opportunity to deploy it.  Some time next year, users
running the latest/greatest releases will also start signalling and,
at times actually using RPKs.  Large-scale adoption will of course take
a few years, because for that, the new code has to be bundled with some
operating system that users upgrade to.

The same of course would apply to hypothetical software supporting any
new "mTLS flag" extension, so it plausibly looks like the existing cert
type extension may be fit for purpose.  Unless we discover a popular TLS
stack that sends the cert type extension by default, even in the absence
of a client cert it is willing to send, or worse, also then aborts the
handshake if a cert is subsequently requested.

-- 
Viktor.

P.S.  Gory details re RFC7250 RPK specifically:

Enabling use of cert type RPK(2) involves 4 separate signals:

   1. Client's CTOS (client to server) cert types, listing the cert
  types the client is willing to send.  This is what we're
  discussing to potentially overload as an "mTLS flag".

  It should be able to function as a client-to-server mTLS signal,
  even when neither end has any interest in RPKs as such.

   2. Client's STOC (server to client) cert types, this lists the types
  of server certificates the client is willing to accept.

   3. Server's CTOS (client to server) cert types, this indicates the
  certificate types the server is willing to accept from the client.

   4. Server's STOC (just application's TLS stack configuration, never
  sent on the wire as an extension) cert types, listing the types
  server certificates the server is potentially willing to send to
  client.  The server just sends the preferred mutually supported
  cert type, no need for a prior signal.

In Postfix RPKs are enabled in 1 and 4 by default, either end is always
willing to *send* RPKs when supported by the other.

For "2", the client is always willing to accept RPKs, when
authenticating a server with exclusively DANE-EE(3) TLSA records.  It
will optionally, subject to a non-default boolean configuration:

http://www.postfix.org/postconf.5.html#smtp_tls_enable_rpk

also accept RPKs from the server when doing unauthenticated
opportunistic TLS (a lerge fraction of SMTP message tranmission falls
into this bucket), mandatory unauthenticated encryption or the
"fingerprint" security level, when all fingerprints are public key
fingerprints, which the operator "promises" by setting the parameter
to "yes".

For "4", the server is only willing to accept client RPKs when

http://www.postfix.org/postconf.5.html#smtpd_tls_enable_rpk

the operator indicates that all certificate-based access controls
(or other uses of the requested client cert) need only the public key,
and not the full certificate:

http://www.postfix.org/postconf.5.html#smtpd_tls_enable_rpk

this setting is also off by default.

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

Re: [TLS] Request mTLS Flag

[Viktor Dukhovni]

On Thu, Nov 16, 2023 at 09:00:52PM +0200, Mohit Sethi wrote:

> Unless I am mistaken, it has probably slipped under the radar of the
> WG that this indication is already achievable by using the
> client_certificate_type extension defined in RFC 7250:
> https://datatracker.ietf.org/doc/html/rfc7250 with certificate type
> value = 0:
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3.

Indeed, Postfix 3.9 (release estimated Q1 '2024), when compiled against
OpenSSL 3.2 (release estimated circa next week), will automatically
signal client certificate types X.509(0) and RPK(2) iff and only a
client certificate is configured (available).

So in at least one case, the signal that the client is inclined and able
to offer a certificate is already implemented in at least one stack.

So servers could request client certificates conditioned on this signal
(and support for at least one of the offered types).

There isn't pesently (in Postfix) a way to configure offering just X.509
or just RPK, but perhaps there'll be a compelling use case to make that
possible some day.  To user either, the client configures a key and
cert, and the RPK is extracted from the cert if use of RPKs is
negotiated.

AFAIK, today just two MTAs are doing SMTP with raw public keys, both are
mine.  Server authenication by the client is via DANE-EE(3) public key
digests.

Nov 12 17:28:27 ... Verified TLS connection established to ...:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange 
X25519
server-signature RSA-PSS (2048 bit raw public key) server-digest SHA256

Nov 16 20:27:04 ...  Anonymous TLS connection established from ...:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange 
X25519
server-signature RSA-PSS (2048 bit raw public key) server-digest SHA256

I am not presently using client certs on either end, so the client
remains "anonymous" from the perspective of TLS.

-- 
Viktor.

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

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

[Viktor Dukhovni]

On Wed, Nov 08, 2023 at 03:54:05AM +, Andrei Popov wrote:

> A few concerns I have with this extension:
> 
>   1.  Privacy: clients broadcasting intent to identify themselves to
>   anyone who asks. I know, this is intended for crawler bots, but the
>   TLS stack does not know whether our caller is a bot, so we will have
>   to implement API support, which will be used by various
>   apps/services.

Unclear how that's worse than today, with clients offering the certs
when asked.

>   2.  Broadcasting intent to send a client cert before knowing the
>   CerrtificateRequest parameters is contrary to the design of TLS
>   client auth. What if the available client cert does not match the
>   future CertificateRequest?  3.  The stated goal is to use this
>   extension to selectively interrogate crawler bots. This extension
>   will only be useful for this purpose until general Web apps start
>   using it. Which they will do, once TLS stacks are updated to support
>   the new extension.

Unclear how that's worse than today, with servers asking for certs
regardless of whether the client promised to not break when asked.

Note that the extension is not a hard commitment to send a client cert,
rather a promise to gracefully tolerate a request.  So the client still
decides after receiving the request, just like it does now.

All that changes, is that servers get the opportunity to be more
selective about when to ask.

> Doesn't the proposed extension facilitate surveillance by letting an
> unauthenticated TLS sever know that the client is willing to divulge
> its identity, and that querying client identity won't disrupt the flow
> or cause any notification to the user?

Not more than today, for servers that are willing to solicit the cert.
Note that for an MiTM scenario, injecting the request mutates the
session transcript, so authenticated impersonation is not available.

Again nothing changes, other than servers being able to be a bit more
selective about whom they'll ask.  Everything else is the same,
including various scenarios where "bad guys" can already ask the client.

-- 
Viktor.

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

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

[Viktor Dukhovni]

On Wed, Oct 25, 2023 at 02:34:08AM +, Peter Gutmann wrote:

> Andrei Popov  writes:
> 
> >An "I really mean it" flag. We can add these for every TLS message, not just
> >authentication-related ones. Just to make sure the peer truly is serious
> >about the TLS handshake.
> 
> It really depends on how servers react when they see client-cert-auth when
> they're not expecting it.  Some time ago I tested one of the always-requests-
> client-auth servers to see what happened when it actually did get client-cert-
> auth and the result was a Handshake Failure alert.  For J.Random messages it
> won't matter, but if the server is requesting client auth without knowing it's
> doing it then some "I really mean it" indication back to the client might be
> useful.

I think what you're really saying, is that it may be time replace the
extant client certificate request message with a completely new one,
because the old one is ossified.

That could mean "I really mean it", until some server code turns it on
by default again...  We can't win that battle.

I work on Postfix, I always recomment that users don't enable client
cert requests for no good reason.  And yet, we provide the feature to
make it possible, and some users then truly believe that it is necessary
to ask for certs they can't/won't use.

Postfix fortunately does not misbehave when useless certs arrive, but
the basic seed of doom is in the user behaviour.

https://marc.info/?l=postfix-users=169565176912422=2

> If you also have TLS client certs configured (typically without just
> cause) to be sent to servers that happen to request them (also typically
> without just cause), then a failure to load the client certs breaks TLS
> support in tlsproxy(8), which makes all attempts at "STARTTLS" fail.

Yes, list.sys4.de also uses TLS client certs and I'm not really sure
I like you writing "typically without just cause". I'd rather have
it the other way around and be irritated if clients do not identify
themselves in TLS sessions as well.

For some quixotic reason, this is particularly common in Germany.

-- 
Viktor.

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

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

[Viktor Dukhovni]

On Tue, Oct 24, 2023 at 04:13:48PM +, Andrei Popov wrote:

> > So it may be necessary to have the server respond with its own flag
> > to indicate that it really does want client cert auth and isn't just
> > asking for a client cert on autopilot.
>
> An "I really mean it" flag. We can add these for every TLS message,
> not just authentication-related ones. Just to make sure the peer truly
> is serious about the TLS handshake.

I hope Peter wasn't entirely serious... If the client offers and the
server asks, there's nothing to be gained from yet another extension,
the server operators who unwittingly enabled (or left defaults
unchanged) server requests for client auth, will similarly unwitingly
enable the new flag.

The proposed "I'm a bot with a cert, please ask me for my bot driver's
license", flag could I think be helpful to server operator who want
to request certs from just that population of bots.

This isn't a burning issue however, just a nice to have.  We've somehow
gotten by without it so far, and indeed if all clients that had no
a priori reason to volunteer a cert, simply ignored all requests, the
flag would not be needed.

-- 
Viktor.

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

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

[Viktor Dukhovni]

On Tue, Oct 24, 2023 at 12:54:08PM -0400, David Benjamin wrote:

> Is the concern here errors or prompting? From the original email, it
> sounded like the issue was that requesting client certificates showed
> undesirable UI to human-backed clients.

My concern is errors, browser UX concerts are not my bailiwick.  I
typically look at TLS from the perspective of SMTP, where all the
communication is bot-to-bot (MTA to MTA).

But, you're right that prompting could also be an issue, since in this
case the use-case was MUA to MSA, so it would apply to Thunderbird,
Outlook, ... where there's a user behind the keyboard.

I don't recall seeing prompting as an issue reported by MUA users, since
the MUA authentication method is typically pre-configured as part of the
"server settings".  MUAs have the luxury of a static set of servers they
talk to, where pre-configuration is the norm.

-- 
Viktor.

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

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

[Viktor Dukhovni]

On Tue, Oct 24, 2023 at 04:11:53PM +, Andrei Popov wrote:

> > At least as a client, you can't read anything into seeing a cert request 
> > from the server, it's just a standard part of the handshake, like a keyex 
> > or a finished.
>
> This is exactly my argument: when a client receives a cert request the
> client cannot satisfy, the RFC says send an empty Certificate and
> continue with the handshake...

Sadly, that's not what actually reliably happens in practice, or at
least that was the case when I last looked.

Perhaps all the guilty TLS stacks were fixed in the meantime?  I am not
well placed to determine how much "friction" remains.

-- 
Viktor.

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

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

[Viktor Dukhovni]

On Tue, Oct 24, 2023 at 02:40:35AM +, Peter Gutmann wrote:

> >Yes, but, arguably, such broken clients won't be fixed by adding new
> >extensions/flags/etc. If they do not comply with the simple RFC language that
> >exists, can we expect them to implement the new flag correctly?
> 
> I would argue that it's the server that's broken, not the client.  An awful
> lot of (non-WWW) servers automatically request a client cert without anyone
> running the server being aware of it, or when asked, how to disable it.  The
> clients then sleepwalk their way past it with a zero-length reply and things
> continue as normal with neither the server admin nor the client-side user
> being aware that certificate auth was requested and denied.

The breakage being, I assume, the pointless asking.  I assume that you
wouldn't object to servers *conditionally* asking if:

- The client explicitly signalled willingness
- The server actually has a use for some client certs, but does
  not always require them.

I don't see in your comment anything to suggest that the flag is a
no-go. 

To David's point, I don't expect browsers to ever set it, at least not
without some advanced user configuration that almost nobody would set,
though you never know what "enterprise" customers will ask for...

-- 
Viktor.

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

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

[Viktor Dukhovni]

On Mon, Oct 23, 2023 at 05:49:47PM +, Andrei Popov wrote:

> >> They could just proceed without a certificate, or return a default
>   one, but they don't.
> 
> Yes, but, arguably, such broken clients won't be fixed by adding new
> extensions/flags/etc. If they do not comply with the simple RFC
> language that exists, can we expect them to implement the new flag
> correctly?

You misunderstood.  If they don't send the flag, the servers in question
simply won't request certificates.  Requests will only when when the
cert request is *explicitly*  solicited.  So the broken clients *will*
be fixed by (lack of) the extension.

--
VIktor.

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

Re: [TLS] Request mTLS Flag

[Viktor Dukhovni]

On Mon, Oct 23, 2023 at 11:36:10AM -0400, David Benjamin wrote:

> Would you expect a browser user to send this flag? On the browser side, we
> don't know until the CertificateRequest whether a client certificate is
> configured. We have to do a moderately expensive query, dependent on
> information on the CertificateRequest of the OS's cert and key stores to
> get this information. This query may even call into things like 3p
> smartcard drivers, which may do arbitrarily disruptive things like showing
> UI.

One sensible use-case for such a signal is in mail user agent (MUA) to
mail submission agent (MSA) communication.

- When the submission client is a bot, a client cert is a fairly
  natural choice of credential.

- Some Java TLS libraries (used to?) fail the handshake when the
  client has no configured certs, or the list of issuer CA DN hints
  does include any of its available (typically just zero or one)
  certificates.

  They could just proceed without a certificate, or return a default
  one, but they don't.

- Most MTAs and MSAs don't request certificates, avoiding the
  potential interoperability issue.

It would be useful to be able to request certificates conditioned on the
client promising to not fail just because it is unable or unwilling to
offer one.

Hence, I would like to see this flag move forward, though I'd also,
perhaps separately, like to see an extension, that either combined with
this flag, or alone, conveys an additional DNS name, where the server
might find the client's TLSA records, allowing the client to establish
a binding to that name.  Something like, given:

_smtp-client.example.com. IN TLSA 3 1 1 ...

send a hint of "example.com", with the "_smtp-client" prefix implied by
the application protocol (prepended by the server).

https://datatracker.ietf.org/doc/html/draft-huque-tls-dane-clientid

-- 
Viktor.

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

Re: [TLS] [Technical Errata Reported] RFC8446 (7620)

[Viktor Dukhovni]

On Tue, Aug 29, 2023 at 10:55:56AM +0200, Ben Smyth wrote:

> TLS 1.2 dictates: Either party may initiate a close by sending a
> close_notify alert...The other party MUST respond with a close_notify
> alert of its own and close down the connection immediately, discarding
> any pending writes.
> 
> RFC 8446-bis could simply forbid that behaviour, e.g., This does not have
> any effect on the read side of the sender's connection; a party receiving a
> "close_notify" alert MUST NOT respond with a "close_notify" alert of its
> own. Note that this is a change from versions of TLS prior to TLS 1.3 in
> which receivers were required to react to a "close_notify" by discarding
> pending writes and sending an immediate "close_notify" alert of their own.

I think what's being said here is not "MUST NOT", but "need not".  In
other words, TLS 1.3 supports (at least to some extent) half-closed TLS
connections, in which the side that did not send a "close_notify" can
attempt to continue to send data.

I don't think there's anything here to "forbid", rather the intent of
the present text could perhaps be more clearly expressed.

-- 
Viktor.

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

Re: [TLS] [Technical Errata Reported] RFC8446 (7620)

[Viktor Dukhovni]

On Mon, Aug 28, 2023 at 04:02:18AM -0700, RFC Errata System wrote:

> Both parties need not wait to receive a "close_notify" alert before
> closing their read side of the connection, though doing so would
> introduce the possibility of truncation.

While the paragraph text is under the microscope, its last sentence
looks particularly unclear to me.  Could it get a more clear rewrite?

Perhaps:

Neither party needs to wait to receive a "close_notify" alert from
the peer before closing its read side of the connection.  Note that
tolerating connection closure by the peer without a "close_notify"
can introduce opportunities for truncation attacks.

The above suggested wording change serves two purposes:

- Replaces the (to me at least) confusing "both need not" with
  "neithe needsr".

- Clears up the truncation attack language.  The issue, as I
  understand it, is not choosing to close the read side before
  "close_notify", but rather accepting EOF (peer's closure of his
  write side) without a "close_notify".

-- 
Viktor.

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

Re: [TLS] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Viktor Dukhovni]

On Fri, Jul 14, 2023 at 04:03:25PM +, Peter Gutmann wrote:

> Interesting, so you're saying that essentially no-one uses custom groups?  My
> code currently fast-tracks the known groups (RFC 3526 and RFC 7919) but also
> allows custom groups (with additional checking) to be on the safe side because
> you never know what weirdness is out there, do you have an idea of what sort
> of magnitude "hardly any" represents?

The "almost no one" is likely technology-sector specific.  Postfix prior
to 3.7 (released Q1 2022) or linked with OpenSSL 1.1.1 (rather than 3.0)
uses a compiled-in 2048-bit safe-prime DH group by default, or a locally
generated group if configured.

With Postfix 3.7 or later linked with OpenSSL 3.0 or later, the group
selection defaults to the the OpenSSL "auto" list, which is based on
the security bits of the server certificate or cipher with anonDH:

if (dh_secbits >= 192)
p = BN_get_rfc3526_prime_8192(NULL);
else if (dh_secbits >= 152)
p = BN_get_rfc3526_prime_4096(NULL);
else if (dh_secbits >= 128)
p = BN_get_rfc3526_prime_3072(NULL);
else if (dh_secbits >= 112)
p = BN_get_rfc3526_prime_2048(NULL);
else
p = BN_get_rfc2409_prime_1024(NULL);

The most common result will be the rfc3526 2048-bit group.  It is not
clear that these are actually better, but they are perhaps more likely
interoperable for being widely-used 'standard' groups.

-- 
Viktor.

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

Re: [TLS] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Viktor Dukhovni]

On Fri, Jul 14, 2023 at 04:53:42PM +0300, Nimrod Aviram wrote:

> There are a few valid arguments, from yourself and others here, to soften
> the prescription regarding FFDHE from MUST NOT to SHOULD NOT, or similar.

The formulation I would choose would be:

 - MUST prefer ECDHE key exchange, when supported, over FFDHE key exchange.
 - MUST prefer FFDHE key exchange, when supported, over RSA key exchange.

> That's a reasonable position to take, but at this stage I guess the
> discussion is mostly around the presentation and structure of the document.

That's a shame, because the goal surely isn't to punish the users of
legacy systems, but rather to encourage the use of preferred
alternatives.

A narrow section of the user base may well want to refuse to communicate
with the aid of any of the legacy algorithms, they already have that
option.  For the rest, I think rfc7435's emphasis on raising the ceiling
is better aligned with security goals than efforts to raise the floor.

Yes, I am well aware that sometimes we also need to raise the floor
(e.g. drop support for SSLv2).  I am not convinced this is such a
situation.

-- 
Viktor.

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

Re: [TLS] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Viktor Dukhovni]

On Thu, Jul 13, 2023 at 03:03:15PM +0200, Hubert Kario wrote:

> And in general, it's far better to use FFDHE kex with legacy client
> than RSA.  Getting RSA right is very hard, using ephemeral secrets for
> FFDHE is trivial and recommended practice already.

Indeed, though I agree that TLS applications should prefer ECDHE key
exchange over FFDHE key exchange, I hold that requiring non-support
is counterproductive.

As a data point, here's a negotiated cipher suite breakdown from SMTP
servers that have DANE TLSA records:

  30746 TLS 1.3 with AES256GCM-SHA384
   2192 TLS 1.2 with ECDHE-RSA-AES256GCM-SHA384
426 TLS 1.2 with ECDHE-ECDSA-AES256GCM-SHA384
153 TLS 1.2 with ECDHE-RSA-AES128GCM-SHA256
115 TLS 1.2 with ECDHE-ECDSA-AES128GCM-SHA256
 96 TLS 1.3 with AES128GCM-SHA256
 71 TLS 1.3 with CHACHA20POLY1305-SHA256
 71 TLS 1.2 with DHE-RSA-AES256GCM-SHA384
 25 TLS 1.2 with DHE-RSA-CHACHA20POLY1305-SHA256
 15 TLS 1.2 with ECDHE-RSA-AES256CBC-SHA384
  5 TLS 1.0 with DHE-RSA-AES256-SHA1
  4 TLS 1.2 with ECDHE-RSA-AES256CBC-SHA
  3 TLS 1.2 with RSA-AES256GCM-SHA384
  3 TLS 1.2 with DHE-RSA-AES128GCM-SHA256
  2 TLS 1.2 with ECDHE-RSA-CHACHA20POLY1305-SHA256
  1 TLS 1.2 with DHE-RSA-AES256-SHA1

Without any "MUST NOT"s, already TLS 1.3 dominates, and by far the bulk
of TLS 1.2 connections are using ECDHE.

What benefit do we expect from forcing weaker security (RSA key exchange
or cleartext in the case of SMTP) on the residual servers that don't do
either TLS 1.3 or ECDHE?

So long as we "raise the ceiling" we reap most of the benefit, and if
the handshake is downgrade resistant, raising the floor isn't always a
win.

-- 
Viktor.

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

Re: [TLS] WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Viktor Dukhovni]

On Wed, Jul 12, 2023 at 12:40:13PM -0400, Sean Turner wrote:

> > On Jul 11, 2023, at 13:52, Salz, Rich  wrote:
> > 
> >> This email starts the working group last call for "Deprecating Obsolete 
> >> Key Exchange Methods in TLS 1.2” I-D, located here:
> > 
> >> .  https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex
> > 
> > Three minor issues and a question.
> > 
> > Consider saying once, early.in the document, that this does not
> > address TLS 1.0 and TLS 1.1 as they were already deprecated.
> 
> This appears in s2:
> 
> Note that TLS 1.0 and 1.1 are deprecated by [RFC8996]
> and TLS 1.3 does not support FFDH [RFC8446].

And section 3:


https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-02.html#section-3

Clients MUST NOT offer and servers MUST NOT select FFDHE cipher
suites in TLS 1.2 connections. This includes all cipher suites
listed in the table in Appendix C. (Note that TLS 1.0 and 1.1 are
deprecated by [RFC8996].) FFDHE cipher suites in TLS 1.3 do not
suffer from the problems presented in Section 1; see [RFC8446].
Therefore, clients and servers MAY offer FFDHE cipher suites in TLS
1.3 connections.

Note that at least in Postfix (opportunistic STARTTLS), this advice will
be ignored.  FFDHE will remain supported in TLS 1.2, with ECDHE
preferred when offered by the client:

https://tools.ietf.org/html/rfc7435

The default group used by the server is either a compiled-in 2048-bit
group or one of the groups from appendix of RFC7919 built-in to OpenSSL.
There are zero reports of clients that can't handle 2048-bit groups (as
opposed to 1024).  Point "3" in the introduction may be outdated w.r.t.
to current practice.

-- 
Viktor.

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

Re: [TLS] [EXTERNAL] Re: Servers sending CA names

[Viktor Dukhovni]

On Tue, Apr 18, 2023 at 09:06:40PM -0300, Soni L. wrote:


> That seems particularly useful for federated networks (XMPP, etc). Why 
> not call these server-to-server certs?

That's basically it.  At least in OpenSSL, when a EKU extension is
present in the client certificate, it must allow client authentication
for the certificate check to pass validation.

However, some applications don't "validate" client certificates relative
to any trust anchor, and instead maintain explicit access control lists
of suitably authorised public keys (or enclosing certificates).

One low-volume, but actually employed use-case is
nullclient-to-smarthost MTA-to-MTA authentication, hence Postfix support
for relay access via client public key or cerificate fingerprints.

https://www.postfix.org/postconf.5.html#relay_clientcerts
https://www.postfix.org/postconf.5.html#check_ccert_access

The client certificate EKU is then irrelevant, but IIRC basicConstraints
may be enforced at the TLS layer (the certificate may need to be valid
for keyAgreement, the problem goes away with raw public keys :-).

-- 
Viktor.

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

Re: [TLS] Servers sending CA names

[Viktor Dukhovni]

On Wed, Apr 12, 2023 at 08:41:31PM +, Salz, Rich wrote:

> Is this generally used?  Would things go badly if we stopped sending them?

I take you mean sending CA names as part of a certificate request.

https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.2
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.4

Yes, many servers send a non-empty list of CA names as part of
certificate request, and some clients (notably some Java-based clients)
fail to complete the handshake if the request does not list an issuer
associated with any of the client's available certificates.

So servers historically have been able to get away with an empty list,
hoping that the client will then send the only/default certificate it
typically has on hand (or not send any, but still continue the
handshake).

It looks perhaps like CA name lists are "more optional" in TLS 1.3 than
they were in TLS 1.2, but this impression may be just an artefact of the
separation of the CA names to a separate extension, rather than an
actual change of expected client behaviour.

-- 
Viktor.

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

Re: [TLS] potential security concern regarding the exchange of client certificates during the TLS handshake process

[Viktor Dukhovni]

On Sun, Mar 26, 2023 at 02:18:58AM +, Yannick LaRue wrote:

> [...] This means that information such as the client's name, email
> address, and other identifying details are transmitted in cleartext,
> potentially allowing for interception and exploitation by malicious
> actors.

This is true for TLS versions 1.0–1.2, but not TLS 1.3.

> I propose that a solution to this issue would be to separate the
> exchange of client certificates from the initial handshake process,
> and instead require the client to present their certificate only after
> the secure channel has been established. This would allow for mutual
> authentication without exposing sensitive information to potential
> interception.

In TLS 1.3, the client certificate is in the encrypted part of the
handshake.  TLS 1.3 also supports post-handshake-authentication.

> I urge you to consider this proposal and take action to address this
> potential security vulnerability. Thank you for your attention to this
> matter.

It seems you've rediscovered one of the concerns addressed in TLS 1.3.

-- 
Viktor.

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

Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

[Viktor Dukhovni]

On Wed, Mar 08, 2023 at 05:11:27AM +, Peter Gutmann wrote:

> I think a safer option moving forward is "scrap it and order a new one", just
> do an RFC with a new, single extension with unambiguous semantics that
> reintroduces the TLS classic session resumption, but done with TLS 1.3
> mechanisms.  In other words just a standalone psk_ke in a new extension with
> a description of "if the client sends this, use it".

Right, basically support for "psk_dhe_ke" is an implicit default
requiring no negotiation, and support for "psk_ke" is requested by the
client and generally accepted by servers barring specialised security
requirements.

Sure that would have been great.  But won't the usual objections (it
isn't turned up to 11) mean that unless you and I are the implementors
and it is my implementation talking to your implementation, the new
extension will have even thinner support?

I am tacitly assuming that the implementation community might be
somewhat more pragmatic than the WG, and be willing to improve the
behaviour of the current extension, or perhaps the "silent majority" of
the WG would in fact be willing be more pragmatic on resumption, but
haven't chosen to engage in this thread, and we could ideally even reach
some language in an update that recommends more liberal settings in
general, with punishment set aside only for the faithful who believe
they're sure to never stray, in case they do.

-- 
Viktor.

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

Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

[Viktor Dukhovni]

On Tue, Mar 07, 2023 at 03:49:13PM -0800, Nick Harper wrote:

> It is interoperable by default, if the implementations follow the spec. If
> implementations don't follow the spec, no amount of spec language will fix
> their behavior.

What specific changes would you recommend in say the OpenSSL
implementation?  Just not sending the useless tickets?  Fine, we've
saved a bit of bandwidth, but haven't really solved the problem.

We have somewhat different interoperability expectations, because I
expect resumption to work under typical conditions, which would include
clients sending just "psk_ke".  Unless the server has a good reason to
expect all clients to always request "psk_dhe_ke", it should support
"psk_ke", leaving the client the option to negotiate "psk_dhe_ke" or use
"psk_ke" if preferred.

> Having both PSK modes MTI is a bad idea. Resumption is an optimization:
> psk_dhe_ke removes an asymmetric cryptographic operation to verify the
> certificate chain, while retaining forward secrecy.

Resumption is an important optimisation, it can make the difference
between a scalable service and a degraded or unusable service.

> psk_ke further optimizes the handshake by removing all asymmetric
> crypto, at the cost of forward secrecy.

Only if the server's ticket key (which should be a *short-term* secret
on the scale of minutes to hours) is compromised.  Once the ticket key
is discarded, psk_ke is no less forward_secret than psk_dhe_ke.  The
latter is also compromised if the server's DHE private key leaks (yes
it is supposed to be single use, and securely erased from memory, ...
but reality may differ).

> An implementation could decide that it wants the certificate verified
> on every connection (and support no resumption), or could decide that
> it only wants to support connections with forward secrecy (and not
> support psk_ke). Making any PSK modes MTI reduces security.

There's no downgrade attack, if both sides want psk_dhe_ke, they get it.
If some application or private deployment never needs psk_ke resumption,
fine.  But in the absence of specific knowledge a generic client using
TLS to reach some random server should be able to perform resumption
without the sort of friction that turning up forward-secrecy to 11
introduces.  The client *should* still offer psk_dhe_ke where it makes
sense, and servers *should* then use DHE resumption, but if the client
has good reason to choose "psk_ke" it should not be punished for its
choice to optimise for performance.

> This isn't a protocol issue. This is an implementation issue (buggy
> implementations sending psk_dhe_ke NSTs in response to psk_ke ClientHellos)
> and an ecosystem issue.

But sending the unusable tickets isn't the problem, the problem is that
non-DHE resumption is unavailable by default.  Is that an implementation
bug or not?  And when client therefore offers both modes to avoid not
getting any resumption, it always gets DHE resumption.  So why is
"psk_ke" even defined, if it is in practice almost never usable.

Right now it requires prior consent on both sides to enable "psk_ke",
and prior knowledge by the client that the server will do so.  That
reall does not scale.

-- 
Viktor.

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

Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

[Viktor Dukhovni]

On Mon, Mar 06, 2023 at 11:18:50PM -0800, Nick Harper wrote:

> > Basically, one way or another, PSK key exchange mode negotiation needs
> > to be interoperable by default.
> 
> Based on your first message, it sounds like you have identified an
> implementation where it is not interoperable. All of the spec language in
> the world won’t fix implementation bugs.

It isn't the only one.

> PSK only key exchange lacks forward secrecy.

That's not quite accurate.  Resumption via PSK-only key exchange is not
compromised by disclosure of the server's long-term private keys.  Yes,
disclosure of the short-term ticket encryption key can compromise a set
of sessions, and so clients are free to not offer "psk_ke".

> For general purpose libraries, defaulting to PSK-DHE with forward
> secrecy is the right choice for security.

Defaulting, sure, provided both sides offer it.  But defaulting
(interoperable) is different from exclusively offering only psk_dhe_ke
(not interoperable with clients offeringl only "psk_ke").

> (As you point out, a server that only supports DHE PSKs shouldn’t send
> new session tickets to a client that doesn’t support psk_dhe_ke, but
> that doesn’t contradict psk_dhe_ke only as being a sane default.)

Yes, but the more serious issue is that resumption is impossible,
sending an unusable ticket is only a minor nuisance.

> RFC 8446 provides the right building blocks, and delegates the choice of
> which to use to an application profile standard. There’s no need for any
> additional language in the TLS 1.3 spec to encourage or mandate the use of
> non-FS PSK modes.

I disagree, protocols need to be interoperable by default.  Features
that fragment clients and servers into non-interoperable islands of
compatibility are poorly designed.  This is why we have MTI code points,
and mechanisms to negotiate more preferred options.  We need both PSK
modes to be MTI and enabled by default, with the stronger chosen when
mutually supported and enabled.

> For applications where forward secrecy isn’t needed or the computation
> costs outweigh the security benefits, the application profiles for
> those use cases can encourage or mandate psk_ke.

This is not well understood or likely to happen.  For example, ADoT in
DNS (from iterative resolver to authoritative server, not user to
resolver) is a good candidate for psk_ke, but it is not possible to to
enable it, so as a non-trivial fraction of servers are psk_dhe_ke-only,
negotiating "psk_ke" based on the client's preferred mode does not work.
This is a protocol issue first, and implementation issue second.

> > Meanwhile, when there's no other choice, keep using TLS 1.2.

[ See thread on TLS 1.2 deprecation, it is much too early to consider. ]

--
Viktor.

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

Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

[Viktor Dukhovni]

On 6 Mar 2023, at 8:13 pm, Peter Gutmann  wrote:

> Not really sure how to fix this, although at the moment "stay with TLS
> classic" seems to be the preferred option.

There are three stages of fixes:

1. Update the protocol specification.
2. Fix the implementations.
3. Keep using TLS 1.2 until the fixed implementations are broadly adopted.

Keeping in mind that LTS enterprise editions of Linux are lately supported
for ~13 years, step 3 may take a while.  Which is not to say that we should
not start doing 1. and 2., but it is like planting an olive tree, the fruit
will be enjoyed by future generations.

The protocol specification needs to say something along the lines of:

   - Implementations MUST support both psk_ke and psk_dhe_ke.

   - Server operators SHOULD leave both modes enabled.
   
   - In closed environments, or specific applications where *all*
 clients are expected to and required to support psk_dhe_ke
 the required to enable psk_ke is relaxed to MAY.

   - Conversely, where no clients are expected to support psk_dhe_ke,
 the requirement to leave it enabled changes to MAY.

   - psk_dhe_ke is negotiated when supported by both sides, otherwise
 psk_ke is negotiated.

   - Clients SHOULD generally offer both modes in the client HELLO.

   - Clients MAY offer just one or the other when appropriate for the
 application in question, and can expect to interoperate with a
 "general purpose" server.

Basically, one way or another, PSK key exchange mode negotiation needs
to be interoperable by default.

As for implementations, the code changes are not that difficult, but will
take time to release, and then there's step 3...

Meanwhile, when there's no other choice, keep using TLS 1.2.

-- 
Viktor.

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

Re: [TLS] How are we planning to deprecate TLS 1.2?

[Viktor Dukhovni]

On Fri, Mar 03, 2023 at 03:49:28PM -0800, Watson Ladd wrote:

> > 20 years is a long time.  We can only reason about shorter timelines.
> > In the next ~5 years, I don't yet see a defensible reason to deprecate
> > TLS 1.2.
> 
> 20 years from today we'll be dealing with products shipped out today.
> Doesn't it make sense to start saying TLS 1.2 will sunset at some day?

Products shipped today will typically support and prefer to negotiate
TLS 1.3, the ones that choose to not implement TLS 1.2 probably have a
reason for that choice.

The more positive message is encourage adoption of TLS 1.3 in all market
segments where it is applicable.  TLS 1.2 does not look so broken that
we need to apply a stick rather than offer a carrot.

-- 
Viktor.

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

Re: [TLS] How are we planning to deprecate TLS 1.2?

[Viktor Dukhovni]

On Fri, Mar 03, 2023 at 08:17:55PM +0200, Nimrod Aviram wrote:

> Specifically, we will have to decide when/if to deprecate version 1.2 of
> TLS within, say, the next 20 years.

20 years is a long time.  We can only reason about shorter timelines.
In the next ~5 years, I don't yet see a defensible reason to deprecate
TLS 1.2.

There are still to this day supported LTS enterprise operating systems
that support only TLS 1.2.  Yes, they're nearing EOL, but are not there
yet.

Also, TLS 1.3 is not a simple evolutionary update, it is a major new
protocol, be it one that largely manages to masquerades as TLS 1.2 to
middleboxes, and supports version negotiation with TLS 1.2 peers.

Migration to TLS 1.3 is not always straightforward, and, especially in
terms of resumption behaviour, troubleshooting (largely encrypted
handshakes) and maturity of supporting software in specialised
application sectors, TLS 1.3 is still too young to talk about imminent
deprecation of TLS 1.2.

Yes, once TLS 1.3 is closer to 20 years old, we'll know whether TLS 1.2
can or should be retired, but until such time, TLS 1.2 is likely to
still be with us (embedded in home routers, printers, refrigerators,
...).

Even among (presumably security minded) SMTP server operators who've
deployed DANE, ~10% negotiate TLS 1.2.  The numbers are likely higher in
the broader SMTP ecosystem.  DANE survey SMTP endpoint counts by TLS
version:

  27,985 -  TLS 1.3
   2,927 -  TLS 1.2
   5 -  TLS 1.0

-- 
Viktor.

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

[TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

[Viktor Dukhovni]

I took a look at whether it is practically possible for a client to
"opt-in" to (ostensibly cheaper) non-DHE TLS 1.3 resumption by sending a
"psk_key_exchange_modes" extension consisting of just "psk_ke".

Turns out that at least when the server is OpenSSL, the client is likely
to be sad.

Details below, but my question based on the details is whether, when the
client offers just [psk_ke], servers should generally be willing to go
along and support non-DHE resumption?  For otherwise, clients that
don't also offer "psk_dhe_ke" are punished for their non-conformity.

It seems to me that in many cases, and perhaps by default, servers
should be liberal in this regard, and accept the client's security
posture.  In server-to-server communications (say DNS resolver via ADoT
to DNS authoritative) where "hogging" idle connections is "rude", but
CPU cost and latency are also a concern on both ends, one might want
to use "psk_ke" with PSK lifetimes of up to an hour, but this turns
out to be impractical, either by design, or lack of clarity on default
expected server behaviour.

Comments welcome.  [ The issue is likely to also carry over into QUIC,
but there perhaps keeping somewhat idle "connections" "open" is less of
a concern, and resumption may be less frequent??? ]

Details:

- Unless the server is *explicitly* configured with a non-default
  option to support psk_ke resumption, an OpenSSL server will
  (incorrectly I believe) still issue NewSessionTickets (2 by
  default):

https://mailarchive.ietf.org/arch/msg/tls/ACqre4e9-CWiwJrvdOCIDw0rdl4/

What this text is supposed to mean is that the server
shouldn't send tickets if it doesn't like the client's
psk_ke modes. So, say that the client only supports
psk_dhe_ke and the server only supports psk_ke, then the
server shouldn't advertise tickets, because future
resumption will be useless.

- And of course, they will then be useless for resumption, which
  results in a full handshake, which again (by default) sends two
  useless tickets...  So sending only [psk_ke] to reduce the cost
  of resumption, actually has the opposite effect of completely
  defeating resumption.

- If the client sends both "psk_ke" and "psk_dhe_ke", OpenSSL
  servers will always choose to do DHE.

So, unless an, e.g. OpenSSL, server is specifically known (oracular
local configuration?) to support "psk_ke", the client must avoid that
choice, making just [psk_ke] essentially impractical.  The client simply
has to accept the CPU cost of asymmetric key agreement on every
resumption, and hope to amortise the cost by keeping connections open
long enough to perform multiple operations, and not do resumption too
often.

-- 
Viktor.

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

Re: [TLS] Packet number encryption negotiation

[Viktor Dukhovni]

On Tue, Feb 14, 2023 at 04:22:48PM +1300, Marten Seemann wrote:

> It hides certain bits of the header, as well as the packet number,
> from an on-path observer. This is crucial to prevent middleboxes from
> being "helpful" and acting upon (observed) gaps in packet numbers.  As
> such, it's hard to define what a reasonable tradeoff would be. Giving
> up on an anti-ossification measure always seems fine at first, until
> at some point it isn't any more.

If the proposed feature is negotiated via a default-off extension, and
used in high-speed internal datacentre networks, then its use is at the
internal discretion of the datacentre network designers.  Presumably, in
such networks middleboxes of the sort you mention are a no-go just on
performance grounds.

Yes, especially if not on by default, the feature is liable to run into
barriers on networks with random middlebox crud.  Is sufficient reason
to preclude well-motivated negotiated use elsewhere?

-- 
Viktor.

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

Re: [TLS] Packet number encryption negotiation

[Viktor Dukhovni]

On Mon, Feb 13, 2023 at 06:13:36PM -0800, Christian Huitema wrote:

> The process for any proposal is to submit a draft to the relevant 
> working group. I have no idea whether you will find a better reception 
> in QUIC or in TLS. Your proposal amounts to lowering security in order 
> to improve performance. The working groups may very well find that this 
> is not a good idea.

That said, we do want TLS and/or QUIC to perform sufficiently well to be
used in high-performance network applications, better that they be used,
rather than cleartext.  So if the tradeoff is reasonable (solid
performance gain at marginal security cost), it should at least be
considered seriously.

-- 
Viktor.

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

Re: [TLS] TLS 1.2, RFC7250 RPK and (not sending) client certificates?

[Viktor Dukhovni]

On Sat, Feb 04, 2023 at 07:25:31PM +0100, Achim Kraus wrote:

> My interpretation of RFC5246, 7.4.6 Client Certificate
> 
> https://www.rfc-editor.org/rfc/rfc5246.html#section-7.4.6
> 
> "If no suitable certificate is available, the client MUST send a
> certificate message containing no certificates. That is, the
> certificate_list structure has a length of zero."
> 
> covers RFC7250 as well. That section doesn't say something about
> the certificate type and so in my interpretation it applies general
> to all certificate types, including RPK.
> 
> So, even if RPK is negotiated for the client, the client complies
> to RFC5246, 7.4.6 sending a empty list in order to indicate, that
> "no suitable certificate is available".

The apparent issue with that interpretation, is that strictly speaking,
when the certificate type is RPK, there is no list length (it lives only
in the X.509 variant of the structure), all we have is an RPK length.
There's a conflict between TLS 1.2 and RFC7250, that is only properly
resolved in TLS 1.3.  What is the sensible/interoperable strategy for
TLS 1.2?

FWIW, here's what "tshark" thinks of an empty RPK in the client
Certificate message:

Transport Layer Security
  TLSv1.2 Record Layer: Handshake Protocol: Certificate
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 7
Handshake Protocol: Certificate
  Handshake Type: Certificate (11)
  Length: 3
  Certificate Length: 0
[Expert Info (Warning/Protocol): Vector length 0 is smaller than 
minimum 1]
  [Vector length 0 is smaller than minimum 1]
  [Severity level: Warning]
  [Group: Protocol]
  Certificate: 1603030025
BER Error: Sequence expected but class:UNIVERSAL(0) Primitive 
tag:22 was unexpected
  [Expert Info (Warning/Malformed): BER Error: Sequence expected 
but class:UNIVERSAL(0) Primitive tag:22 was unexpected]
[BER Error: Sequence expected but class:UNIVERSAL(0) Primitive 
tag:22 was unexpected]
[Severity level: Warning]

I'd, of course, prefer if 0-length were generally interpreted as RPK
absence even in TLS 1.2, but I am not sure that'll interoperate well,
or what if anything can/should be done about that.

-- 
Viktor.

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

[TLS] TLS 1.2, RFC7250 RPK and (not sending) client certificates?

[Viktor Dukhovni]

On Sun, Jan 22, 2023 at 03:41:06PM -0500, Viktor Dukhovni wrote:

> Thanks to Todd Short, RFC7250 raw public keys should be available in
> OpenSSL ~3.2.  Applications that use unauthenticated opportunistic TLS,
> employ DANE or have other ways to avoid X.509 certificates and make do
> with raw peer public keys can avoid the overhead of receiving and
> processing certificate chains.

In TLS 1.2, in response to a CertificateRequest, and with X.509 as the
(typically implicit) client certificate type, a client can decline to
authenticate itself by sending a zero length certificate list.

The ability for the client to opt-out of client authentication is quite
useful, it allows servers to request optional client certs, that give
some clients additional capabilities, while allowing other clients
to connect anonymously, and either not authenticate, or use some
other mechanism (SASL, ...) after the handshake.

RFC7250 introduces a polymorphic TLS Certificate message that admits raw
public keys.  The message contains a possibly empty certificate list, or
(crux of the problem detailed below) exactly one non-empty raw public key:

https://datatracker.ietf.org/doc/html/rfc7250#section-3

  opaque ASN.1Cert<1..2^24-1>;

  struct {
  select(certificate_type){

   // certificate type defined in this document.
   case RawPublicKey:
 opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>;

  // X.509 certificate defined in RFC 5246
  case X.509:
ASN.1Cert certificate_list<0..2^24-1>;

  // Additional certificate type based on
  // "TLS Certificate Types" subregistry
  };
  } Certificate;

The certificate_type is implicit, from the client_certificate_type
extension in the Server Hello, which carries exactly the subsequently
implicit type.  Therefore, with TLS 1.2, it appears that if the server
sends RPK as the client certificate type, the client has no means for
*not* sending a raw public key.

Not being able to opt-out leads to usability barriers:

- A naive client application may have signalled support for RPK
  as a supported protocol feature, expecting to be able to opt-out
  in the absence of a configured key, just as with X.509.

- The client's RPK algorithm may not be among the server's
  ClientCertificateType Identifiers:

  https://www.rfc-editor.org/rfc/rfc5246.html#section-7.4.4
  
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-2

  As a result, the client may discover late that it has no
  compatible key to send.

TLS 1.3 addresses this by wrapping even RPK client crendentials in
a list (that can be zero length).

What is the right way to handle this in TLS 1.2?

- Never offer to use client RPKs with TLS 1.2?

- Advertise client RPK support only in very narrow contexts
  where the client knows in advance that it has a key that
  will be acceptable to the server, and the server doesn't
  just solicit, but in fact requires client auth?

- Add a variant of the client_certificate_type extension
  that that allows the client to opt-out in its Certificate
  message (send length 0 to signal lack of an RPK)?

- Just send a length 0 RPK, and expect that to be taken as
  "no RPK"?

It would certainly be possible to make the upcoming OpenSSL RPK support
at least tolerate the last choice on the server side, and allow clients
to send 0-length TLS 1.2 RPKs.  Sending such 0-length RPKs in the
absence of suitable keys, will run into interoperability issues with 
implemntations that don't take the same liberal reading the RFC7250
message format.

In the mean time, it seems that TLS 1.2 servers should only enable
support for client RPKs when client authentication is *mandatory*,
and clients should only advertise RPK support if they have keys that
they have good reason to expect the server to support (either RSA
expected to be generally supported by servers, or specific knowledge
of the capabilities of the particular server).

Any thoughts, comments, or advice?

-- 
Viktor.

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

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

[Viktor Dukhovni]

On Sat, Jan 28, 2023 at 02:18:01PM -0500, Viktor Dukhovni wrote:
> On Mon, Oct 24, 2022 at 06:25:39PM +, Salz, Rich wrote:
> 
> > This draft looks good.
> > 
> > One nit, omitted "TLS" before SignatureAlgorithm in two places in
> > https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-02.html#section-15-3
> 
> Would it be appropriate to clarify the status of Ed25519 in DTLS?
> 
> https://mta.openssl.org/pipermail/openssl-users/2019-November/011582.html
> 
> and if so, where should such clarification happen?  The registry already
> marks Ed25519 as "DTLS-OK", but unclear on what basis...

See also:


https://mailarchive.ietf.org/arch/browse/tls/?gbt=1=7Mjmu7mANU5l5mcJQKd3BAY0_3A

-- 
Viktor.

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

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

[Viktor Dukhovni]

On Mon, Oct 24, 2022 at 06:25:39PM +, Salz, Rich wrote:

> This draft looks good.
> 
> One nit, omitted "TLS" before SignatureAlgorithm in two places in
> https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-02.html#section-15-3

Would it be appropriate to clarify the status of Ed25519 in DTLS?

https://mta.openssl.org/pipermail/openssl-users/2019-November/011582.html

and if so, where should such clarification happen?  The registry already
marks Ed25519 as "DTLS-OK", but unclear on what basis...

-- 
Viktor.

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

Re: [TLS] Security of using same cert for TLS client and server

[Viktor Dukhovni]

On Sat, Jan 28, 2023 at 03:03:54PM +0200, Ilari Liusvaara wrote:

> On Sat, Jan 28, 2023 at 08:35:40AM +, John Mattsson wrote:
> > Thanks Ilari for that very fast and detailed answer. I a made a PR to
> > RFC8446bis to suggest adding “A node MAY use the same certificate as
> > both server and client certificate.”, I don’t know if there should be
> > more restrictions. The real practical problems seem to be cross-
> > protocol attacks on the application layer where TLS is used for
> > several application layer protocols.
> 
> I had idea (but I never got to writing I-D) of PKIX certificate
> extension that constrained the certificate to specific set of
> explicit TLS Application Layer Protocols.
> 
> E.g., constrain to {"http/1.1","h2","h3"} for HTTP certificate,
> or something like {"imap","submission"} (might need to register
> extra ALPNs) for user mailserver.

I don't think such an extension would gain much traction.  To be useful,
the extension would need to be "critical", but since it would be thinly
supported, its use case would be in narrow walled-garden environments.

DANE addresses lack of specificity in certificate names by binding the
validity to a single layer 4 end-point:

  $ dig +noall +ans +nosplit +multi +nottl -t tlsa 
_25._tcp.dnssec-stats.ant.isi.edu
  _25._tcp.dnssec-stats.ant.isi.edu. IN TLSA 3 1 1 (
  B1E7FAAF6E482E2AFBC653C8E3B6BEF0E3352424AEBD24D2B480092951BC6097 )

And then, it often becomes possible to entirely dispense with the certificate:

$ posttls-finger -c -Lsummary,certmatch dnssec-stats.ant.isi.edu
posttls-finger: dnssec-stats.ant.isi.edu[128.9.29.254]:25:
raw public key fingerprint=...
posttls-finger: dnssec-stats.ant.isi.edu[128.9.29.254]:25:
Matched DANE raw public key:
3 1 1 
B1E7FAAF6E482E2AFBC653C8E3B6BEF0E3352424AEBD24D2B480092951BC6097
posttls-finger: Verified TLS connection established to to
dnssec-stats.ant.isi.edu[128.9.29.254]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519
server-signature RSA-PSS (2048 bit raw public key)
server-digest SHA256

-- 
Viktor.

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

Re: [TLS] Regulations for EKU validation for CA certificates in the certificate chain

[Viktor Dukhovni]

On Sat, Jan 28, 2023 at 11:57:46AM +0200, Oleg Pekar wrote:

>   "If the extension is present, then the certificate MUST only be used
>for one of the purposes indicated.  If multiple purposes are
>indicated the application need not recognize all purposes indicated,
>as long as the intended purpose is present.  Certificate using
>applications MAY require that a particular purpose be indicated in
>order for the certificate to be acceptable to that application.

Note, for the record, that OpenSSL does not require EKUs in CA
certificates, but *if* they're present, *then* the EKUs in the CA
certificate need to be compatible with the purpose to which the EE
certificate is used (e.g. TLS client or TLS server).

With Let's Encrypt DV TLS certificates the chain (sans root) looks like,
for example:

Issuer: C=US, O=Let's Encrypt, CN=R3
Subject: CN=dnssec-stats.ant.isi.edu
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication

Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1
Subject: C=US, O=Let's Encrypt, CN=R3
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication

The EKUs on the "R3" intermediate (some prefer "subsidiary") CA are
clearly intended to express the purposes to which certificates it issues
can be put.  The "R3" certificate itself is not used for TLS connection
establishment.

In some configurations there's also a cross certificate from DST, which
has no EKUs:

Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Subject: C=US, O=Internet Security Research Group, CN=ISRG Root X1

-- 
Viktor.

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

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Viktor Dukhovni]

On Mon, Jan 23, 2023 at 09:04:40PM +, John Mattsson wrote:

> RFC 7250 states that "The SubjectPublicKeyInfo structure is defined in
> Section 4.1 of RFC 5280".
> 
> The encoding of secp256r1 public keys in X.509 is defined in RFC 5480
> which says that: "MUST support the uncompressed form and MAY support
> the compressed form".
> 
> My reading is that point compressed X.509 and RPK are allowed in TLS
> and that this follows from X.509. I don't think RFC 8422 applies here.

I find that reading surprising, because at least when the point formats
extension is used:

https://www.rfc-editor.org/rfc/rfc4492#section-5.3 (bottom of page 16)

   ...   If the client has used
   a Supported Point Formats Extension, both the server's public key
   point and (in the case of an explicit curve) the curve's base point
   MUST respect the client's choice of point formats.  (A server that
   cannot satisfy these requirements MUST NOT choose an ECC cipher suite
   in its ServerHello message.)

which rather indicates that in *TLS* supported point formats is supposed
to cover not just the key exchange, but also the certificates.

With point formats other than "uncompressed" (or default for curve in
TLS 1.3) now deprecated, it sure seems like RPK would need to comply.

Any comments from the usual suspects (ekr, et. al.)?

Of course on the receiving side, of some implementation is more liberal
and accepts compressed there's probably little harm (provided TLSA
records or whatever the peer uses to match the expected key when/if
validating also match the compressed SPKI).

On the sending side, my reading is that the sender should probably
ensure that the transmitted form is "uncompressed" (default for
curve).  In practice, the sender's private key is likely already
in the default point format, so the "right thing" happens most
of the time, but perhaps implementations should be prepared to
DTRT in the rare case that the configured key material is in
some non-default point form.

-- 
Viktor.

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

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Viktor Dukhovni]

On Mon, Jan 23, 2023 at 07:01:38AM +, John Mattsson wrote:
> Hi Viktor,
> 
> Are point compressed secp256r1 RPKs supported?
> 
> - Uncompressed secp256r1 RPKs are 91 bytes.
> - Point compressed secp256r1 RPKs are 59 bytes
> - Ed25519 RPKs are 58 bytes

It looks to me like EC keys will be sent in their default point format,
which is set when the key pair is loaded.

I don't see any text in RFC7250 that describes how the TLS supported
point formats extension relates to EC raw public keys.  On the other
hand:

https://www.rfc-editor.org/rfc/rfc8422.html#section-5.1.2

seems to say that only the uncompressed format is to be used in TLS.

If so what is the right question now?  Should there be some code to make
sure that the uncompressed format is used?  (Rather than rely on the
private key passed through i2d_PUBKEY() to output that form by default).

-- 
Viktor.

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

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Viktor Dukhovni]

On Mon, Jan 23, 2023 at 09:56:05AM -0500, Viktor Dukhovni wrote:

> On Mon, Jan 23, 2023 at 02:51:45PM +, Salz, Rich wrote:
> 
> > > Assuming OpenSSL's d2i_PUBKEY(3) can decode these, they'll be
> > > accepted. I don't recall seeing any code to transmit point
> > > compressed public keys *to* the peer, but may have missed it,
> > > wasn't looking at the codec that closely.
> > 
> > Looking at the file tls`.h, it appears RFC 4492 point formats are supported.
> 
> It seems the sending side will does not presently send compressed forms:
> 
> 
> https://github.com/tmshort/openssl/blob/master-rpk/ssl/statem/extensions.c#L1802-L1812
> 

I may have confused compressed EC point formats with certificate
compression...  Sorry about the noise.

-- 
Viktor.

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

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Viktor Dukhovni]

On Mon, Jan 23, 2023 at 02:51:45PM +, Salz, Rich wrote:

> > Assuming OpenSSL's d2i_PUBKEY(3) can decode these, they'll be
> > accepted. I don't recall seeing any code to transmit point
> > compressed public keys *to* the peer, but may have missed it,
> > wasn't looking at the codec that closely.
> 
> Looking at the file tls`.h, it appears RFC 4492 point formats are supported.

It seems the sending side will does not presently send compressed forms:


https://github.com/tmshort/openssl/blob/master-rpk/ssl/statem/extensions.c#L1802-L1812

If support for compressed public key forms is a common feature of other
implementations, perhaps it should be included...

-- 
Viktor.

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

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Viktor Dukhovni]

On Mon, Jan 23, 2023 at 07:01:38AM +, John Mattsson wrote:

> Are point compressed secp256r1 RPKs supported?

There is no RPK-specific code that either accepts or rejects point
compression in ECDSA public keys received from the peer:

https://www.rfc-editor.org/rfc/rfc5480#section-2.2

Assuming OpenSSL's d2i_PUBKEY(3) can decode these, they'll be
accepted.  I don't recall seeing any code to transmit point
compressed public keys *to* the peer, but may have missed it,
wasn't looking at the codec that closely.

> - Uncompressed secp256r1 RPKs are 91 bytes.
> - Point compressed secp256r1 RPKs are 59 bytes
> - Ed25519 RPKs are 58 bytes

The

-- 
Viktor.

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

[TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Viktor Dukhovni]

Thanks to Todd Short, RFC7250 raw public keys should be available in
OpenSSL ~3.2.  Applications that use unauthenticated opportunistic TLS,
employ DANE or have other ways to avoid X.509 certificates and make do
with raw peer public keys can avoid the overhead of receiving and
processing certificate chains.

The pull request  is
still a work in progress, but complete enough for application
integration testing.  Likely too late for OpenSSL 3.1 (in beta now), but
seems likely to land by 3.2.  The TODO items on the OpenSSL side are
at this point IMHO minor.  Review eyeballs of course always appreciated.

I have a Postfix branch with a reasonably complete implementation:

# posttls-finger -c 
posttls-finger: [192.0.2.1]:25: raw public key fingerprint=<...>
posttls-finger: [192.0.2.1]:25: Matched DANE raw public key: 3 1 1 
<...>
posttls-finger: Verified TLS connection established to 
[192.0.2.1]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519
server-signature RSA-PSS (2048 bits)
server-digest SHA256

based on the the current state of the pull request.

-- 
Viktor.

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

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

[Viktor Dukhovni]

On Mon, Jan 02, 2023 at 06:32:26PM +0200, Nimrod Aviram wrote:

> (To concede a point in advance: It is obviously possible to _assume_ that
> if the server presents a modulus, then it "must" be a safe prime, or it
> meets some desired security notion that the server operator has deemed
> sufficient for the connection.

The server's choice of FFDHE groups is signed with the server's private
key (matching the public key in its certificate).  If that server is so
poorly operated as to sign a weak FFDHE group, why would one expect its
ECDHE private key to be strong (https://dilbert.com/strip/2001-10-25)?

What's the actual threat model here?  Sure server operators SHOULD NOT
configure weak FFDHE groups (export-grade, small subgroups, ...), but
if they do (despite all advice to the contrary, and much effort in
various tools and libraries to ensure safe defaults), then that's the
best security you can expect if you want to connect to *that* server.

My take remains that progress would be to make ECDHE MTI for TLS 1.2 (if
not already) and mandatory to choose over FFDHE when supported at both
ends.  This entirely achieves all the benefits of the proposed
deprecation, without causing needless auditor grief for FFDHE-only
deployments, knee-jerk switches to RSA key exchange, ...

It would also be helpful if at least one widely-available browser left
FFDHE support available (if not by default, then with a runtime config
setting) so that legacy servers with perfectly good safe DH parameters
remain reachable.

-- 
Viktor.

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

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

[Viktor Dukhovni]

On Thu, Dec 22, 2022 at 05:56:50AM +, Peter Gutmann wrote:

> John Mattsson  writes:
> 
> >A more reasonable approach would be to deprecate all cipher suites without
> >_ECDHE_.
> >
> >While the WG is in deprecation mode, please deprecate all non-AEAD cipher
> >suites as well. RFC 7540 did this 7.5 years ago...
> 
> An even more reasonable approach would be to mandate EMS, EtM, and (and I
> realise I'm biased here) LTS, which solve all of the above problems without
> having to throw away a bunch of long-standing cipher suites with massive
> existing deployed base.  That's a simple, backwards-compatible tweak to the
> deployed base to fix existing problems rather than scrap-it-and-order-a-new-
> one to replace existing problems with a new set.

Indeed, and, more generally we get much better security outcomes by
making it clear whith new things are MTI and must be preferred by
updated implementations so that they're negotiated whenever supported by
both ends.

The products that already don't want to use the old ciphers don't need
deprecations to convince them to drop support for FFDHE.  Products that
need to remain long-term interoperable, can still continue to offer
FFDHE when the peer does not support ECDHE.

Is there a compelling reason to intervene?

-- 
Viktor.

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

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

[Viktor Dukhovni]

On Tue, Dec 13, 2022 at 09:46:29AM -0500, Sean Turner wrote:

> This message starts the process to judge whether there is consensus to
> deprecate all FFDHE cipher suites including those well-known groups.
> Please indicate whether you do or do not support deprecation of FFDHE
> cipher suites by 2359UTC on 6 January 2023. If do not support
> deprecation, please indicate why.

My take is that an RFC deprecating TLS 1.2 FFDHE ciphersuites will not
have a positive impact on the ecosystem.  Most security improvements
result from raising the ceiling, not the floor, implementing the
preferred algorithms, and making sure that algorithm negotiation resists
downgrades.

If the protocol's algorithm negotiation fails to protect against
downgrade attacks, then either the protocol needs to be replaced, or
else indeed parameters that make downgrade attacks possible need to be
deprecated.

Otherwise, less-preferred, but widely used (at least in some industry
sectors) parameter choices should be marked as less preferred than
other parameter choices (i.e., in this case, implementations SHOULD
support ECDHE, SHOULD use ECDHE whenever mutually supported), but
should not be "deprecated" (as in marked "DO NOT USE").

If I've not paid enough attention, and missed an important reason
why leaving FFDHE available, while preferring ECDHE opens the door
to downgrade attacks or other critical problems, then of course
deprecation would be appropriate.

Otherwise, as a data point, looking at SMTP IP endpoints that support
DANE (presumably bleeding-edge enough to take non-default security
measures), I see:

TLS 1.3:
 20187 AES256GCM
  7115 CHACHA20POLY1305
12 AES128GCM

TLS 1.2:
  3283 ECDHE
   103 DHE
 3 RSA

TLS 1.0:
 5 DHE
 1 RSA

This supports the idea that raising the ceiling is in fact sufficiently
effective:

* The majorify of servers support and use TLS 1.3.
* The majority of TLS 1.2 servers negotiate ECDHE

In this population of servers I see 108 DHE-preferring/only endpoints
out of ~30k (and 4 RSA endpoints).

The numbers will continue to improve organically, but laggards could
be encouraged by publishing a document that strongly recommends use
of ECDHE (or X25519/X448) whenever possible, rather than DHE.

The scope of any proposed "deprecation" should also be clarified, in
response to David Benjamin's question, as to whether this is just TLS
1.2, or also TLS 1.3.

-- 
Viktor.

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

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Viktor Dukhovni]

On Fri, Dec 02, 2022 at 08:20:58PM +, Ollie wrote:

> That said, in reply to your points, I understand DANE to a level that I know
> PKIX isn't applicable to my original intention/query, so perhaps I haven't
> been clear with what I'm looking to achieve.

DANE has 4 certificate usages, and 2 of them PKIX-TA(0) and PKIX-EE(1)
are a combination of local trust-anchors (RFC 5280 PKIX) and DANE
certificate constraints (server-side DNS CA or EE certificate or public
key constraint). 

The security of PKIX-EE(1) is at least as strong as DANE-EE
(self-signed), and already supports CT via the existing CAs.  CT is
already a centralised model, so your allergic reaction to public CAs
while seeking mandatory CT is puzzling.  Perhaps you can explain on
ACME, or perhaps the (mostly inactive) d...@ietf.org list.

With a PKIX-EE(1) server key "pin", no CA can unilaterally convince a
DANE-enabled client that a misissued certificate is valid.  If the
client requires PKIX-EE(1) and does not support DANE-EE(3), then
just compromising DNSSEC is also ineffective.

Of course this is also the most operationally fragile model, offering
two ways to have an outage.  I don't see it gaining much popularity,
but you can try to convince people otherwise.

Good luck.

-- 
Viktor.

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

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Viktor Dukhovni]

On Fri, Dec 02, 2022 at 06:40:25AM +, Ollie wrote:
> > There's nothing to be gained by publishing SCTs in self-issued DANE-EE
> > validated certificates. Are you proposing to make SCTs mandatory in
> > DANE? Which user agents would insist on such SCTs and why? If not,
> > what problem would optionally including them solve?
> 
> Yes, primarily for browser user agents.  See below on use
> cases/problems.

In that case, why not just require the PKIX-EE and PKIX-TA usages, and
forgo "self-signed" certificates.  With PKIX-EE you still get to
explicitly identify a particular certificate in the TLSA records, but
it must now also follow all the WebPKI rules (including CT support if
applicable).

> > Note also that the "expiration" date of DANE-EE certificates is ignored,
> > the freshness of the key binding is attested via the TLSA record RRSIG,
> > rather than the dates in the certificate. The proposed 90-day limits on
> > "certificate lifetime" are antithetical to DANE-EE.
> 
> Noted and understood, although not sure I agree the certificate expiry
> should be ignored. What happens if I put a TLSA record for a CA
> certificate that then traditionally expires? Would user agents be
> expected to fall-back to using the RRSIG freshness?

A TLSA record for a "CA" certificate would be DANE-TA (usage 2) not
DANE-EE (usage 3), and in that case dates are not ignored in the issued
certificates.  Whether trust-anchors expire or not is not even explicit
in PKIX (a trust anchor is just a public key), and if the CA is matched
via its public key alone (say "TLSA 2 1 1 ...") then mutations of the
date are not covered by the TLSA record.

Again, and perhaps this should end this thread on the TLS WG list, where
it is not exactly on topic, it seems you're really looking for the
PKIX-TA(0) and PKIX-EE(1) certificate usages, and haven't analysed DANE
closely enough to see why those are already what you suggesting.

> I hadn't come across DNSSEC-Transparency so that probably covers a
> lot/all of the following, however I think it's worth considering CT
> log incorporation as that ecosystem is well established and the
> adoption of self-signed certificates (SSCs) would likely require
> little revision by monitors/user agents etc.

There is no DNSSEC transparency, it is just somewhat plausible
vapour-ware I've made up...

> 1.H: If presented with an SSC the user agent would require TLSA
> records and a complete DNSSEC chain and for the presence of an SCT for
> checking a CT log, doing those increases the level of assurance that
> the presented SSC is valid for the given website. If only one is
> valid, then some misissuance could have occured and a block or warning
> could be displayed to the user.

PKIX-EE with a certificate issued by a CA that participates in CT meet
your needs.  Along with browsers insisting on SCT (if that's what they
do when doing WebPKI).

Of course browser support for TLSA lookup does not look likely in the
mainstream browsers particularly soon.

If you can persuade your users to use a specialised browser with DANE
support (and I guess DoH or DoT required for DNS, else last mile
breakage is rather a barrier to DNSSEC), then perhaps you'd be able to
require PKIX-EE have your "self-signed" (really end-entity server-side
pinned) certificates.

Actually minting the certificates yourself vs. getting them from Let's
Encrypt hardly makes any difference with PKIX-EE, they're free either
way, and Let's Encrypt takes care of the CT side of things.

Sure LE doesn't presently check DNSSEC-signed TLSA records before
issuance.  But a DNSSEC-signed EE public key hash could well be a
supported ACME challenge type, that would in fact be stronger than the
current TOFU "proofs" of domain control.

So if there's an IETF group to nudge along the lines you suggest, it
might be ACME, rather than TLS, with a suitable directive in
DNSSEC-signed CAA records.  This could could be the only acceptable
domain control proof.  Solving also the problem of getting certificates
issued for various services that are not web servers.

smtp.example.com. IN CAA ...
smtp.example.com. IN CAA 128 spkialg=SHA2-256
smtp.example.com. IN CAA 128 spkival=...

would require the CA to support the above critical attributes, and match
the spki value against against the requested public key.

-- 
Viktor.

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

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Viktor Dukhovni]

On Wed, Nov 30, 2022 at 11:35:09PM +, Ollie wrote:

> It increases the barrier of entry to someone having ownership of a
> valid domain, configuring a full DNSSEC chain and configuring a valid
> certificate with an appropriate DANE record. Everyone of those
> trillion requests would need to be a real domain, with full DNSSEC and
> signatures added to TLSA records. CTs could rate limit based on the
> domain and/or common public keys from DNSSEC etc.

There's nothing to be gained by publishing SCTs in self-issued DANE-EE
validated certificates.  Are you proposing to make SCTs mandatory in
DANE?  Which user agents would insist on such SCTs and why?  If not,
what problem would optionally including them solve?

Note also that the "expiration" date of DANE-EE certificates is ignored,
the freshness of the key binding is attested via the TLSA record RRSIG,
rather than the dates in the certificate.  The proposed 90-day limits on
"certificate lifetime" are antithetical to DANE-EE.

In principle (I am not tracking whether there are extant
implementations), DANE-EE even supports TLS with RFC 7250 "raw public
keys", where there are no certificate at all!

-- 
Viktor.

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

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Viktor Dukhovni]

On Tue, Nov 29, 2022 at 04:04:58PM +0100, Bas Westerbaan wrote:

> > On the other hand, the actual certificates are not what one
> > would want to log anyway.  Instead one would only want to log DS RRsets
> > or NODATA proofs from eTLD registries (gTLDs, ccTLDs and also various
> > 2LD, 3LD, ...  suffixes operated by TLD registries).
> 
> This is the case if you run your own authoritative DNS server. Most do not.
> So you'd want transparency on the TLSA records as well.

Your DNS operator is not some random 3rd party (like a public CA, with
which you have no business relationship, and which can unilaterally
issue certificates you never asked for).  If you don't trust your DNS
operator, use them only as a secondary, and run a hidden master where
you do all the signing.

Logging all TLSA RRsets (and denial thereof!) is impractical.  The
design does not have to perfect, it just has to be sufficiently useful
and realisable.

-- 
Viktor.

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

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Viktor Dukhovni]

On Mon, Nov 28, 2022 at 06:23:36PM -0800, Eric Rescorla wrote:
> Thanks for the elaboration, Viktor.
> 
> I think the TL;DR here is that this isn't TLS-relevant work at present.
> Either you get the certs directly or you get them via RFC 9102 but in
> either case, TLS has the appropriate support.
> 
> If you don't need CT--I'm not entirely persuaded by Viktor's argument but I
> agree that the need is probably less than with WebPKI--then it seems like
> the technical work is done. If you do need CT, then probably your next stop
> is secdispatch, what with trans being closed.

Agreed, with the already mentioned clarification that the "CT" in
question would be DNSSEC-Transparency not X.509 CT, except when the DANE
usages are PKIX-{TA,EE} where the usual WebPKI rules also apply.

The "DNSSEC-Transparency" would log eTLD delegation security and any
delegations above that (root to TLD, TLD to 2LD eTLD public suffix,
...).  The viability or a such a system has not been established, nor is
there even a sufficiently detailed potential design for evaluation.

It is not clear between wider DNSSEC adoption and availability of a CT
analogue which is the cart and which is the horse.  I don't think that
lack such an analogue is presently a real obstacle to wider deployment
of DNSSEC.  If I'm mistaken, perhaps this is something that could be
explored sooner.

-- 
Viktor.

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

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Viktor Dukhovni]

On Tue, Nov 29, 2022 at 01:04:14AM +0100, Bas Westerbaan wrote:

> > In essence, I'm proposing that user agents should trust a fully DNSSEC
> > domain with a TLS certificate set up using DANE, along with changes to CT
> > log submission process to allow self-signed certificates (looking to
> > suggest via rfc9162).
> 
> How do you propose we prevent CT from being DoSed by a deluge of
> self-signed certificates?

There isn't a known viable approach to combine the existing CT system
with DANE.  On the other hand, the actual certificates are not what one
would want to log anyway.  Instead one would only want to log DS RRsets
or NODATA proofs from eTLD registries (gTLDs, ccTLDs and also various
2LD, 3LD, ...  suffixes operated by TLD registries).  Clients that
contribute to CT logs would need to run validating resolvers and
log signed delegations.

Once a NODATA proof is recorded, no more such proofs are logged until
the delegation is again signed.

So spamming can only happen as a result of repeated changes to a zones
DS RRset, including its deletion.  Similar spamming would be possible by
obtaining certificates from many CAs and rolling them over as frequently
as possible.

So long as a domain's DS RRset is not forged by the parent eTLD, what
(self-signed) certificates its TLSA records vouch for is an internal
matter, that is easily audited internally.  Monitor your DNS, and don't
sign rogue TLSA records.

-- 
Viktor.

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

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Viktor Dukhovni]

On Mon, Nov 28, 2022 at 12:27:07PM -0800, Eric Rescorla wrote:

> How much of the TLS part of this objective is achieved by RFC 9102?

Well, RFC9102 is at a different layer.  It provides a mechanism for
clients to obtain a TLSA RRset by other means than direct DNS lookup,
because that often runs into last mile barriers (as you reported at
IETF114 IIRC, is there now a paper you can link to?).

Once the client has TLSA records be it directly from DNS, or
server-facilitated via a TLS extension, at that point what's trusted
should not depend materially on how the TLSA records were obtained.

So back to the OP's question, what appears to be missing here?  It seems
to me that "3 1 1" TLSA records are sufficient to allow self-signed
certificates to validate, indeed this is already quite common in TLS for
SMTP.  The only known nit is that for an HTTP browser one needs to heed
a potential UKS issue, and so the advice in RFC7671 to ignore the
hostname in certificates validated via a TLSA "3 1 1" record is not
appropriate for "https" in browsers that support following remotely
supplied links, redirects, care about cross-origin issues, ...

In simpler protocols that just move data between a client and server,
the RFC7671 semantics for "3 1 1" records reduce the potential for
operator error (seen with low, but non-zero frequency for "2 1 1"
records, where some MX hosts now and then sport certificates that don't
match their names).

-- 
Viktor.

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

Re: [TLS] [lamps] [EXTERNAL] Re: Q: Creating CSR for encryption-only cert?

[Viktor Dukhovni]

On Fri, Oct 07, 2022 at 06:19:15PM +, Blumenthal, Uri - 0553 - MITLL wrote:

> Then publish the certificate. Then the victim is unable to read email
> encrypted to her. A DoS that costs the attacker very little,
> practically nothing.

What victim is that?

All the PoP does is make it harder to convince your CA to attest that
someone else's key is yours.  It plays no role in the most critical role
of your CA, which is to not attest that your key is someone else's.  

The scenario you suggest seems to me to require the latter.

-- 
Viktor.

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

Re: [TLS] OCSP and browsers

[Viktor Dukhovni]

On Sat, Oct 01, 2022 at 09:33:30PM -0400, Phillip Hallam-Baker wrote:

> Now we have ACME, why not move to 3 day certs issued daily and avoid the
> need for revocation entirely?

This could put rather a strain on certificate transparency.  30x times
the renewal cadence.  Not that I personally place much value on CT, but
some consider it important...

-- 
Viktor.

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

Re: [TLS] RFC 5746 applicable for session resumption?

[Viktor Dukhovni]

On Thu, Sep 15, 2022 at 01:16:33PM +, Fries, Steffen wrote:

> I was just double checking if there was an answer to the question of
> using the TLS renegotiation extension from RFC 5746 in the context of
> TLS session resumption. As stated below, based on the RFC it is not
> crystal clear if it applies. In general I would think yes, but only
> for session resumption based on the sessionID, not based on tickets.

There should be no difference between (server-side) stateful and
stateless resumption.  The server should serialise into the session
ticket sufficient information to allow it to fully recover the session,
as though it were cached locally to facilitate stateful resumption.

This is the case at least with OpenSSL, the session ticket contains and
encrypted and MACed serialised SSL_SESSION object, in exactly the same
form as it would have in a server-side session cache.

-- 
Viktor.

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

Re: [TLS] ECH not protect SNI

[Viktor Dukhovni]

On Thu, Aug 25, 2022 at 05:12:43PM -0400, Ben Schwartz wrote:

> > Here is my another undisclosed ambition, a PSI free Internet.
> 
> I think you would be better off starting with DANE (RFC 7671), rather than
> ECH.  If you're willing to accept DNSSEC as a requirement, all sorts of
> strange things become possible.  For example, with DANE-EE and the SPKI
> selector, it is possible for the client to connect without sending SNI, and
> for the server to reply without revealing its own hostname!

Well, even with DANE the client needs to elicit the correct server
certificate, by sending the matching SNI.  It is the certificate
that can (in some application protocols) omit the servername, but
not the TLS layer.  In the case of web browsers even that is not
the case as noted by Richard Barnes:

https://datatracker.ietf.org/doc/html/draft-barnes-dane-uks-00

If the client knows in advance that the server has the same underlying
EE key for all its certificates, then sure it could omit SNI and
validate the default certificate (which has the same key promised
in the _port._tcp DANE-EE TLSA record for the desired domain).

> I do not support changes to the ECH specification to pursue this goal.  ECH
> is designed specifically to avoid any dependency on DNSSEC, and this is
> clearly the correct choice given the low usage of DNSSEC.

This is now ~5% of registered domains, and growing.  DNSSEC would of
course grow faster if we didn't stay so reluctant to put it to use.

That said, FWIW, I also don't presently see a need to change ECH.

-- 
Viktor.

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

Re: [TLS] Representing IP addresses in SNI -- proposed draft

[Viktor Dukhovni]

On Fri, Jul 29, 2022 at 09:50:56AM -0400, Erik Nygren wrote:

> Also including an Extended SNI option for "Certificate Fingerprint"
> would solve a bunch of issues that have come up from time-to-time.
> For example, it might help with DANE.

DANE does not need and must not carry a client-side expected fingerprint
signal:

* DANE adequately signals the expected server identity by sending the
  "TLSA base domain" in SNI.

* The server's TLSA records are generally multi-valued (otherwise
  breakage-free key rollover becomes impossible).  There is no
  single "expected certificate fingerprint", and DANE-TA(2) records
  only signal the issuing CA.

* The server's public key may not infrequently be the same across
  multiple candidate EE certificates, and its digest may not
  clearly identify the right certificate to vend to the client.

...

> We've also talked in the past about being able to include a
> certificate fingerprint in URIs, and being able to signal that in
> Extended SNI would likely make that work better.  (A use-case for this
> is for using TLS in local/private network environments such as to home
> network devices or even localhost processes where being able to have a
> URI with an {IP,cert_fingerprint(s)} pairing would have better
> security properties than trying to use some global PKIX framework.)

There are surely better ways than client-side public key pinning to deal
with that use case.  For that (home) users will need to be able to
practically manage their own roots of trust and name resolution.  Either
PHB's Mathematical Mesh or something related could be the way forward.

-- 
Viktor.

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

Re: [TLS] Why TLSA RR and not CERT RR?

[Viktor Dukhovni]

On Sun, Jun 26, 2022 at 04:29:38PM -0400, Robert Moskowitz wrote:

> I will use them in draft-ietf-drip-registries for our X.509 certs and 
> our 'custom' attestation certs (private OID will be needed). And then 
> the powers-that-be can sort it out as we move forward.

Why do the certificates need to be delivered via DNS?  Are TLS or DTLS
not suitable as protocols between the subject and relying party?

What is the management model for these certificates?  How will key
rollover at the subject be coördinated with changes in the DNS?

TLSA records are flexible in that they can specify trust-anchor keys or
certificates (typically their digests) as well as EE keys or
certificates.  Multiple TLSA records can be published at the same RRset,
and rollover is facilitated by requiring only one to match.

The need to tightly synchronise regular certificate rollovers with DNS
changes can be avoided by keeping EE keys stable, or publishing a stable
issuer trust-anchor key.  Alternatively, one can pre-publish future
EE public keys and then use that key in a later certificate rollover
if observed in DNS for a sufficient number of TTLs, or else renew the
certificate with the extant key.

So there are well-understood (if not yet universally practiced)
operational practices that enable robust deployments of DANE TLSA.

Is there something similar for the proposed use of CERT?  Is publication
of (often multi-kilobyte) full certificates in DNS a good idea?

-- 
Viktor.

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

Re: [TLS] SPKI Fingerprints

[Viktor Dukhovni]

On Mon, Jun 13, 2022 at 02:16:03PM -0400, Daniel Migault wrote:

> Thanks for the detailed response, that is very much appreciated. When I
> wrote the initial email, I had more in mind some sort of configuration - as
> opposed to DANE. I agree that the use of PSKI should not cause any of the
> headaches associated with pinning.

Yes, and this why I explained that in OpenSSL the DANE API actually also
supports locally-configured SPKI data, via synthetic TLSA records
supplied by the application, because OpenSSL has no idea where the "TLSA
records" came from.  The "TLSA 3 1 1" records purported by the
application may actually be local SPKI pins.

This makes for a more flexible and uniform interface that is agnostic
as to the source of the data, and can also pin trust-anchor (CA)
fingerprints, not just EE fingerprints.

-- 
Viktor.

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

Re: [TLS] SPKI Fingerprints

[Viktor Dukhovni]

On Mon, Jun 13, 2022 at 10:42:51AM -0400, Daniel Migault wrote:

> I sent this question regarding the use of SPKI Fingerprints to the
> add mailing list, but I am also eventually interested to feed backs not
> necessarily restricted to encrypted resolvers.
> 
> RFC 7858 (DNS over TLS) indicates the use of SPKI Fingerprints in an
> analogous manner to that described in RFC7469 (public KEy Pinning extension
> for HTTP). I am wondering if anyone is aware of implementation considering
> SPKI Fingerprints for or if such usage is not something we would like to
> recommend/deprecate.

SPKI fingerprints are used in DANE, specifically either:

* DANE-EE(3) SPKI(1) SHA2-256(1)/SHA2-512(2) records
* PKIX-EE(1) SPKI(1) SHA2-256(1)/SHA2-512(2) records

Since the TLSA records are published by the service operator, questions
about stale data largely go away, modulo a small fraction of negligent
operators (in SMTP stale TLSA records are seen for ~1% of MX hosts, but
more importantly, only 0.0053% of DANE-enabled domains).

Also, OpenSSL supports use of SPKI fingerprints for peer certificate
verification, because "TLSA record" lookups are left up to the
application, which feeds these into the SSL handle prior to the
handshake.  This makes it possible to synthesise TLSA "[31] 1 [12]"
records corresponding to an SPKI fingerprint, and use these in
peer certificatre chain verification.

Postfix, for example, has a "fingerprint" TLS "security level", in which
the peer is authentication via a locally specified SPKI fingerprint, and
this actually implemented on top of the OpenSSL DANE API via the above
mentioned synthetic TLSA records.

-- 
VIktor.

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

Re: [TLS] Would removal of upper bounds of common certificate attributes break TLS?

[Viktor Dukhovni]

On Tue, Feb 01, 2022 at 08:55:02PM +0100, Stefan Santesson wrote:

> However, I'm curious about the facts of the case, and would appreciate
> if people here could help me answer a key question:
> 
> - Would removal of such upper bounds (e.g. common name max 64
> characters) break TLS in any way such as:
> 
>     a) Breaking current implementations
> 
>     b) Require any changes or updates to the TLS standard.

To the extent that most certificates have SANs these days, and
implementations are expected to ignore the subject DN when a supported
SAN is present, changes in the limits on CommonName should be of little
consequence.

It should perhaps be noted that best practice is to not bother with a
subject DN at all (setting it to an empty sequence) when an appropriate
SAN is included in the certificate.

Thus, while the low limits are a bit of a nuisance, in a way they're
a feature not a bug, in that they encourage avoiding the subject DN
entirely.

Yes, I have implemented signers that set the CommonName if short enough,
and leave the subject DN empty otherwise, but it would have been even
better to just always leave it empty.

CommonName aside, what are the other use-cases of interest for revising
limits?

One place I'd search for interoperability issues would be in various
MiTM gateway proxies that resign the externally presented certificate
largely verbatim, after replacing the public key (and ideally setting a
short expiration).  These might fail if presented with out of spec
CommonName values.

That is, I'd expect more friction in code that creates certificates than
in code that cosumes them.

-- 
Viktor.

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

Re: [TLS] OCSP in RFC7525bis - summary of the discussion

[Viktor Dukhovni]

> On 27 Jan 2022, at 4:45 pm, Yaron Sheffer  wrote:
> 
> So our plan moving forward is to essentially keep the new text on OCSP [1] 
> and add a reference to RFC 7633 (the certificate must-staple extension). But 
> only as a MAY. In addition, we will add a MUST requirement to perform (some 
> kind of) revocation checking.

Usual lack of Internet Police noted, I feel I should mention that this "MUST" 
*will*
be ignored in various quarters.  I still have no plans to implement any 
revocation
checks in Postfix, too much pain for too little (or no) gain.

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

Re: [TLS] [Uta] OCSP in RFC7525bis

[Viktor Dukhovni]

On Fri, Jan 21, 2022 at 01:30:38PM -0500, Ryan Sleevi wrote:

> > > Do you think that DNSSEC should be soft-fail for CAA checks, or should
> > > we urge the CAs to be more strict here?  Perhaps that would be another
> > > recommendation.
> >
> > CAA lookups must not softfail.  This needs to be the case whether the
> > domain is signed or not.  For signed domains this means that validation
> > of the response (positive or denial of existence) must succeed.  Bogus
> > replies, lame delegations, timeouts, REFUSED, SERVFAIL, ... need to all
> > be hard errors (for signed and unsigned domains alike).
> 
> Yes, and OCSP lookups must not softfail either, in order for them to be
> useful.

>From where I sit, issuance is a much more critical process than
revocation, and sloppy practices should not be acceptable.  Postfix does
not ignore DNS lookup errors, and the sky has not fallen.  I don't see
why a CA should be at liberty to do so.

If some domain has broken DNS preventing certificate issuance, then they
need to fix that first.  Both the nameservers and the CA can be expected
to be on a better than hotel captive portal network, where DNS is
sufficiently reliable to return a valid answer, or be attended to if
there's a problem.

If CA/B Forum CAs are ignoring CAA lookup errors then the WebPKI is even
weaker than I thought it was.

-- 
Viktor.

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

Re: [TLS] [Uta] OCSP in RFC7525bis

[Viktor Dukhovni]

> On 21 Jan 2022, at 9:48 am, Daniel Kahn Gillmor  
> wrote:
> 
>> Without wanting to detract too much from the core question of the thread,
>> how does this address the routing gap? The adversary at the routing layer
>> just redirects the host being validated to control the key that way, and
>> simply interrupts the nameserver during the CAA check. In the threat model
>> you're concerned about (Web PKI), DNSSEC is soft-fail, particularly for CAA
>> checks.
> 
> If DNSSEC is soft-fail for the CA verifying CAA checks, then i agree
> this is insufficient.  The letsencrypt implementation is apparently at
> least logging the info about DNSSEC signatures.
> 
>   https://github.com/letsencrypt/boulder/issues/2700
> 
> Do you think that DNSSEC should be soft-fail for CAA checks, or should
> we urge the CAs to be more strict here?  Perhaps that would be another
> recommendation.

CAA lookups must not softfail.  This needs to be the case whether the
domain is signed or not.  For signed domains this means that validation
of the response (positive or denial of existence) must succeed.  Bogus
replies, lame delegations, timeouts, REFUSED, SERVFAIL, ... need to all
be hard errors (for signed and unsigned domains alike).

-- 
Viktor.

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

Re: [TLS] [Uta] OCSP in RFC7525bis

[Viktor Dukhovni]

> On 19 Jan 2022, at 9:57 am, Yaron Sheffer  wrote:
> 
> But this raises a larger question: many client-side implementations soft-fail 
> if they don’t get an OCSP response within the handshake, i.e. they just 
> ignore the problem. As far as we understand, this makes OCSP stapling 
> completely ineffective for what it’s trying to solve.
>  
> So for the new BCP, we have three options:
>   • Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly 
> also TLS 1.2 implementations) to fail the handshake if the OCSP response is 
> missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)

IMHO unrealistic and self-defeating.

>   • Remove the whole discussion of OCSP, saying that in its current form 
> it’s not adding value.

Largely this.

>   • Maintain the status quo, where many people implement OCSP on the 
> server side, but clients rarely benefit.

Or this.

> We would be grateful for feedback based on implementation experience. In 
> particular if you have quantitative data on the use or quality of OCSP that’s 
> more recent than Chung18 [3], that would be very useful.

For example "Let's Encrypt" supports issuing certificates with "must staple",
but this an opt-in feature.  So as an attacker who can impersonate the subject,
I won't ask for "must staple", and so this is just security theatre.

In Postfix, I have elected to not waste time supporting either CRLs or OCSP.
If one wants TLS-authenticated SMTP one can use DANE, where there's no need
for "revocation", just publish a fresh TLSA RRset that does not match any
compromised keys or unauthorised certificates.

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

Re: [TLS] Question regarding RFC 7366

[Viktor Dukhovni]

On Tue, Nov 02, 2021 at 01:18:22PM +0100, alex.sch...@gmx.de wrote:

> my question addresses the negotiation of the "encrypt_then_mac" extension
> proposed in RFC 7366 and, specifically, two possible interpretations of such
> negotiation when using AEAD ciphers.

I think the source of the confusion is that AEAD ciphers are *neither*
encrypt then MAC, nor MAC then encrypt (as two separate operations).
They perform both as a single one-pass operation.  The extension in
question simply has no meaning with AEAD, and must not be sent by the
server when an AEAD cipher selected, in which case the client and server
just do AEAD.

-- 
Viktor.

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

Re: [TLS] A side meeting on OpenSSL's plans about QUIC

[Viktor Dukhovni]

On Wed, Nov 03, 2021 at 11:12:00AM +0100, Robin MARX wrote:

> I'm wondering if you could give a bit more details about the expected
> outcome of this meeting?

Indeed it is hard to see how OpenSSL project governance and development
priorities are a subject matter for the IETF TLS and/or QUIC working
groups.

-- 
Viktor.

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

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Viktor Dukhovni]

> On 6 Aug 2021, at 3:31 pm, Benjamin Kaduk 
>  wrote:
> 
>> That said, I've given up fighting potentially counter-productive "raising 
>> the floor"
>> rather than "the celing" on all fronts, and now try to focus on just the 
>> most important
>> cases.  Thus have accepted the fact that sadly no anon (EC)DH ciphers are 
>> available with
>> TLS 1.3.
> 
> Well, yes, because TLS 1.3 ciphers only indicate the hash function and AEAD.

Yes, correct on a technicality: for anon_DH I'd need a null signature scheme,
but the intended point was that TLS without server certificates is presently
not supported in TLS 1.3.  I have not chose to campain to bring it back at
this time...

-- 
Viktor.

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

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Viktor Dukhovni]

> On 6 Aug 2021, at 2:51 pm, Ilari Liusvaara  wrote:
> 
> As note: the DH_anon and ECDH_anon names are a bit misleading: Those
> two are actually ephemeral (but are still rarely a good idea to use)

For what it is worth, anon DH, and anon ECDH ciphers are used by default
in Postfix when doing unauthenticated opportunistic TLS.  Since the server
certificate is ignored, we don't bother to solicit one, or offer one if the
client does not care.

See also:

  https://datatracker.ietf.org/doc/html/rfc7672#section-8.2

where I explained that I see security advantages to making transparent the
client's non-use of a server certificate.

That said, I've given up fighting potentially counter-productive "raising the 
floor"
rather than "the celing" on all fronts, and now try to focus on just the most 
important
cases.  Thus have accepted the fact that sadly no anon (EC)DH ciphers are 
available with
TLS 1.3.

-- 
Viktor.

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

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

[Viktor Dukhovni]

On Sun, Aug 01, 2021 at 02:27:22PM +0300, Nimrod Aviram wrote:

> Looks like we have consensus for the following:

IIRC we're not looking for consensus on the substance of the draft at
this point, this just a WG adoption call.  So the issues below do not
need to be resolved at this time...  We just happen to be taking the
opportunity to discuss them...

> - Clients may choose to not support FFDHE, a la Chrome. I don't see
>   consensus for full deprecation of FFDHE, please correct me if I'm wrong.
> - Clients must not connect when the server uses a group of less than 2048 
> bits.
> - Clients may connect when the server uses a well-known, safe prime group
>   of at least 2048 bits (well-known might mean "from RFC 7919 plus the
>   built-in Postfix group", or other reasonable definitions).
> - Clients may connect when the server uses a custom safe prime group of at
>   least 2048 bits, if the client verifies that the prime is safe.
> 
> The only point where we don't have consensus seems to be:
> - For clients who choose to support FFDHE, when the server uses a custom
>   group of at least 2048 bits, and the client isn't willing to check
>   safe-primality, what should the client do?

And so, with confirmation from Peter Gutmann below that any custom
groups we're likely to encounter are almost certainly safe (given a
sufficiently large prime), I see no need to do anything beyond:

- Client should set a floor on the FFDHE group size that is appropriate
  for its application ecosystem.  Typically 2048, in ecosystems where
  smaller groups are sufficiently rare to non-existent.

- A few specific, previously recommended, "standard" groups might now be
  explicitly refused.

- Given that neither of the above can be negotiated in TLS 1.2, some
  clients and servers might choose to drop support for FFDHE either
  in TLS 1.2 or across the board.

I don't see a realistic scenario in which sufficiently large ad-hoc
server DH parameters are a problem.  Only some specific "standard"
groups (from outdated informational RFCs, ...) of suspect provenance
might reasonably be blacklisted.

On Sun, Aug 01, 2021 at 11:42:22AM +, Peter Gutmann wrote:
> Viktor Dukhovni  writes:
> 
> >OK, who goes around bothering to actually generate custom DH parameters, and
> >with what tools, but then does not use a "strong" (Sophie Germain) prime?
> 
> That's better :-).  That was my thought too, every DH/DLP keygen I've seen
> generates either Sophie Germain or FIPS 186 primes/parameters, so on the off
> chance that your server feels like generating custom primes you'd need to go
> out of your way to generate unsuitable ones, i.e. you'd probably need to write
> custom code specifically for bad prime generation, and if you're going to do
> that then all bets are off anyway.

-- 
Viktor.

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

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

[Viktor Dukhovni]

On Sat, Jul 31, 2021 at 12:57:39PM +, Peter Gutmann wrote:
> Viktor Dukhovni  writes:
> 
> >I strongly doubt there's a non-negligible server population with weak locally
> >generated groups.
> 
> Would you care to rephrase that so we can make sure you're saying what we
> think you're saying in order to disagree with it?

OK, who goes around bothering to actually generate custom DH parameters,
and with what tools, but then does not use a "strong" (Sophie Germain)
prime?

The only weakness I expect to encounter is a deprecated size of e.g.
512, 768 or 1024 bits.  Clients can easily detect that and enforce a
floor, but of course still don't get to negotiate a minimum.

Clients also don't get to negotiate the size of the server's RSA public
key, or as you mentioned various other ways for the server to not screw
up.

-- 
Viktor.

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

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

[Viktor Dukhovni]

On Fri, Jul 30, 2021 at 07:30:31PM +, Scott Fluhrer (sfluhrer) wrote:

> > Was it wrong to generate server-side DH parameters?
> 
> The problem is that it is hard for the client to distinguish between a
> well designed server vs a server that isn't as well written, and
> selects the DH group in a naïve way.

I am well aware that verifying the safety of the server's choice is
computationally taxing.

> Now, as I mentioned in the WG meeting, it would be possible to detect
> if the server proposes a safe prime (it's not especially cheap, being
> several times as expensive as the rest of the DH operations, but it's
> possible), and that would prevent most of the problems that can happen

I don't think it is realistic for the client to go to that much trouble.
The server's choice of parameters is signed by the server's public key.
What is the threat model here?  Is the client trying to avoid servers
that shoot themselves in the foot by verifiably choosing bad parameters?

The server could also have a strong DH group, but a terrible RNG with a
well known RSA private key:

http://dnssec-stats.ant.isi.edu/~viktor/mailcow.html

If the server is not one of these or similar, and attests to its choice
of DH parameters, and they happen to be less than ideal, so be it.
Server operators should be encouraged to choose strong parameters, but I
see little reason for clients to second-guess that choice.

If the DH parameter size is below a reasonable threshold (Logjam), a
client might balk, but otherwise I am not sure what practical problem
we're actually solving.

> Of course, this works only if the legacy servers you are talking about
> actually do use safe primes...

All the ones I know of use "openssl dhparam", which defaults to Sophie
Germain strong primes with generator 2.

I strongly doubt there's a non-negligible server population with weak
locally generated groups.  The only likely source of weak groups is
servers that used one the older now deemed weak groups published in
deprecated RFCs.

So it might suffice to refuse specific known weak "standard" groups,
which would have a much lower impact than requiring particular standard
groups with no mechanism to negotiate these.

-- 
Viktor.

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

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

[Viktor Dukhovni]

On Fri, Jul 30, 2021 at 05:14:08AM +, Peter Gutmann wrote:

> >The only other alternative is to define brand new TLS 1.2 FFDHE cipher code
> >points that use negotiated groups from the group list.  But it is far from
> >clear that this is worth doing given that we now have ECDHE, X25519 and X448.
> 
> There's still an awful lot of SCADA gear that does FFDHE, and that's never
> going to change from that.  The current draft as it stands is fine, in fact it
> seems kinda redundant since all it's saying is "don't do things that you
> should never have been doing in the first place", but I assume someone needs
> to explicitly say that.  No need to go beyond that.

Can you explain what you mean by "don't do things that you should never
have been doing in the first place"?

There are quite a few deployments that generate local strong (Sophie
Germain prime) DH parameters.  These would break if the draft sails
through as-is, and there's no mechanism for the client to inform the
legacy server that its would be choice of DH parameters is not
acceptable.

Was it wrong to generate server-side DH parameters?

-- 
Viktor.

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

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

[Viktor Dukhovni]

On Fri, Jul 30, 2021 at 10:34:55AM +1000, Martin Thomson wrote:

> On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote:
> > This is a working group call for adoption of Deprecating Obsolete Key 
> > Exchange Methods in TLS  (draft-aviram-tls-deprecate-obsolete-kex-00 
> > ).
> >   There was support for adopting this draft at the IETF 111 meeting.  
> > Please review the draft and post your comments to the list by Friday, 
> > August 13, 2021.  
> 
> Yep, let's do it.  There were comments suggesting that this wasn't
> going to work for some deployments yet.  That's OK, that's how this
> works: we decide to deprecate, discuss and publish a document, then
> people get to work out how they change their deployments.  If we don't
> take that first step, then in many ways things don't get better.
> Adopting this is that first step and a good idea.

I support adoption of the draft and deprecation of RSA key exchange.

For FFDHE, I'd much rather see outright deprecation a la Chrome, than a
silent restriction by client (with no mechanism to negotiate otherwise0
to parameters that the server may not be prepared to support.

The only other alternative is to define brand new TLS 1.2 FFDHE cipher
code points that use negotiated groups from the group list.  But it is
far from clear that this is worth doing given that we now have ECDHE,
X25519 and X448.

There is far less risk of interoperability failure if the client or
drops support for FFDHE, rather than silently chooses to reject
previously working parameters.

-- 
Viktor.

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

Re: [TLS] WGLC for draft-ietf-tls-flags

[Viktor Dukhovni]

On Fri, Jul 16, 2021 at 04:55:49PM -0700, Christopher Wood wrote:

> This is the second working group last call for the "A Flags Extension for TLS 
> 1.3" draft, available here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
> 
> Please review this document and send your comments to the list by July 30, 
> 2021. The GitHub repository for this draft is available here:
> 
> https://github.com/tlswg/tls-flags

Just one editorial comment, I think that the initial registration code
point of 0x8 (hex) is potentially confusing, is it the 8th bit, or the
or bit 3?  The bit positions range from 0 to 2047 and are easier to
understand in decimal, especially with the registration ranges given
in decimal.  So in this document, and in the IANA registry, the code
points should be decimal.

-- 
Viktor.

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

Re: [TLS] [EXTERNAL] Re: Narrowing allowed characters in ALPN ?

[Viktor Dukhovni]

On Thu, May 20, 2021 at 04:15:27PM -0700, Nick Harper wrote:

> > But, it makes for a fairly terrible user interface for the human
> > operator.  Compare:
> >
> > * managesieve
> > * 6d616e6167657369657665
> >
> > Typos in hex values are easy to make and hard to recognise.
>
> I agree that it's not a great user interface for the human. A good
> solution to that is to let the user define a constant with the hex value
> (or build the ALPN constant into the config language), like how with
> OpenSSL one can specify "ECDHE-ECDSA-AES128-GCM-SHA256" instead of 0xC02B.
> Using your example, one could define a constant ManageSieve = {0x6d 0x61
> 0x6e 0x61 0x67 0x65 0x73 0x69 0x65 0x76 0x65} and reference that constant,
> and if a typo were made (e.g. one put ManageSeive in the config), the
> config would fail fast, vs if one configured "manageseive" as the ALPN
> directly, the typo would propagate further through a deployment before
> being detected/fixed.

The constants would work fine in programming APIs, but they're of no use
in filling in DNS records in web forms, master copies of zone files, ...
or any other configuration file syntax where the context supports only
literals.

> There are good solutions to solve the human factors of managing/configuring
> ALPN that don't require imposing restrictions on what ALPN can go on the
> wire in TLS.

Note, I am NOT promising restricting what can go on the wire TLS, only
what can go in the IANA ALPN registry as a standard interoperable ALPN
value.

> Those solutions should be favored over restricting the wire
> protocol/code point allocation.

None come to mind for the alpn field of the proposed HTTPS/SVCB records.
What would you suggest?  (I hope not hex).

The current proposal, even with the rather compex quoting/escaping rules
is better than hex, but is rather fragile.  Developers will get it
badly wrong.

-- 
Viktor.

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

Re: [TLS] [EXTERNAL] Re: Narrowing allowed characters in ALPN ?

[Viktor Dukhovni]

On Thu, May 20, 2021 at 11:52:50AM -0700, Nick Harper wrote:

> > Since the likelihood of actually adding exotic ALPN values to the
> > registry appears slim, why not say so.  That would leave the exotic
> > values for private on-the-wire use, while allowing DNS and other
> > configuration serialisation forms to avail themselves of more
> > straight-forward parsers.
> 
> Encoding ALPN identifiers in hex for these configuration files sounds like
> a very straightforward way to support all valid ALPN identifiers. We
> already have "exotic" ALPN identifiers in the registry (for GREASE). Any
> new scheme that handles ALPN should be designed to handle all possible
> values. Not doing so will lead to interoperability issues that others have
> already mentioned.

I agree it is a straight-forwarding encoding for machines, and it is
well suited for the GREASE code points.

But, it makes for a fairly terrible user interface for the human
operator.  Compare:

* managesieve
* 6d616e6167657369657665

Typos in hex values are easy to make and hard to recognise.

-- 
Viktor.

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

Re: [TLS] [EXTERNAL] Re: Narrowing allowed characters in ALPN ?

[Viktor Dukhovni]

On Thu, May 20, 2021 at 01:46:38PM -0400, Ryan Sleevi wrote:

> > It is fine for the TLS protocol to not care, but the *standard* ALPN
> > values in the IANA registry (that might then also appear in DNS
> > zone files, configuration files, ...) a more restricted character
> > set would actually be helpful.
> 
> I'm a little torn here, because you've again mentioned usability and
> interoperability suffer, but it's unclear if you're seeing that as a
> generic statement or simply "with respect to configuring DNS zone files".

At present, more the latter, but not exclusively so, since there are
likely other places where operators might be recording choices of
supported ALPN values in configuration files.

> Saying BIDI, LTR/RTL or NFKC/NFKD are issues here is like saying TLS
> wireprotocol version field itself suffers from left-to-right issues. Such a
> statement makes no sense, because the version, like the ALPN, is a byte
> string.

And indeed at present also in the DNS wire format.  What's new, is that
those values are now also going to be manipulated by operators in their
presentation form, which gets rather unwieldy when the values happen to
contain commas, double-quotes, control characters, ... let alone strings
that in UTF-8 appear to be NFKD, BIDI, ...

> We don't say that the TLS version is "COMBINING TILDE" (U+0303), we
> say it's 0x03 0x03, or, if we want to make the string human readable, we
> convert it to a value that has no relation to its wire representation -
> such as "TLS 1.3"

Of course, we all understand they're plain octet-strings.  But that does
not help the poor operator trying to enter them into a config file or
a web form.

> The suggestion here, of restricting the registered set, seems like it
> should equally be obvious as creating and amplifying interoperability
> issues, rather than resolving them, because of the assumption again that
> values will be ASCII, even though that's not what the wire protocol
> assumes.

I don't see a substantial risk that TLS stacks will start to not treat
the ALPN string as an opaque byte string, it would take more code to do
otherwise.

> APIs, from the TLS implementation itself to those that expose or
> rely on the TLS information (such as the Web APIs previously mentioned)
> would, if such a path as you suggest here were adopted, no doubt assume
> that despite the spec saying it's a byte string, it's in fact an ASCII
> string.

This is of course possible, but does not look like a substantial risk.
And there's always GREASE.

> This issue is, functionally, an example of that. It seems like the issue is
> not at all related to the DNS wire format, which is perfectly happy with
> this, but rather the configuration text syntax used with DNS, and not
> wanting to do things like escape byte sequences.

Correct, but more than just DNS, basically any data-at-rest
serialisation of ALPN values in configuration files, or use
with interactive data entry, ...

> This is why it seems like it's simply a matter of being inconvenient,
> but have I misunderstood and there's a deeper issue I've missed?

The incovenience means that applications that process SVCB/HTTPS data
entered by users need much more complex and easier to mess up parsers.

Since the likelihood of actually adding exotic ALPN values to the
registry appears slim, why not say so.  That would leave the exotic
values for private on-the-wire use, while allowing DNS and other
configuration serialisation forms to avail themselves of more
straight-forward parsers.

-- 
Viktor.

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

Re: [TLS] [EXTERNAL] Re: Narrowing allowed characters in ALPN ?

[Viktor Dukhovni]

On Thu, May 20, 2021 at 04:45:23PM +, Andrei Popov wrote:

> ALPN IDs are byte strings; the fact that some of them can be displayed
> as ASCII character strings merely reflects the fact that those ALPN
> IDs were chosen by humans.

That's fine when they're just private signalling between a homebrew
client and homebrew server, but for ALNP values registered with IANA,
used in DNS HTTPS/SVCB records, ... the byte strings do need to be
broadly usable, so that any site operator can add them into their DNS
zone, type them into a web form, ...

If ALPN values are BIDI strings, with mixed left-to-right and
right-to-left fragments, comtain accented characters that may have
different NFKC vs. NFKD forms... usability and interoperability suffer.

It is fine for the TLS protocol to not care, but the *standard* ALPN
values in the IANA registry (that might then also appear in DNS
zone files, configuration files, ...) a more restricted character
set would actually be helpful.

-- 
Viktor.

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

Re: [TLS] Narrowing allowed characters in ALPN ?

[Viktor Dukhovni]

On Thu, May 20, 2021 at 11:23:15AM -0400, David Benjamin wrote:

> SVCB's syntax would need us to not only exclude non-ASCII characters but
> also avoid random delimiters like commas, right? I think that's going a bit
> too far. As Ryan notes, complex definitions for allowed strings result in
> ambiguities around who is responsible for validating what and subtle
> variations in different implementations. That ambiguity can lead to
> injection attacks when one component of a system expects some validation,
> but the other component disagrees.

Just the registry needs to be restricted.  TLS implementations would
support all possible inputs.  HTTPS/SVCB would no longer need to parse
complex quoted input formats.

-- 
Viktor.

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

Re: [TLS] Narrowing allowed characters in ALPN ?

[Viktor Dukhovni]

On Thu, May 20, 2021 at 03:06:06AM -0400, Ryan Sleevi wrote:

> On Thu, May 20, 2021 at 1:56 AM Viktor Dukhovni  
> wrote:
> 
> > On Wed, May 19, 2021 at 10:29:43PM +, Salz, Rich wrote:
> >
> > > I support limiting it.
> >
> > I concur.  These are not strings used between users to communicate in
> > their native language.  They are machine-to-machine protocol
> > identifiers, and use of the narrowest reasonable character set promotes
> > interoperability.
> >
> 
> I'm not sure I understand this. Could you expand further how adding more
> normative restrictions promotes, rather than harms, interoperability?

See below.  The idea is not to ask TLS implementations to reject
non-ASCII ALPN values, but rather for non-ASCII values to not be
defined, facilitating better interoperability among systems that
exchange ALPN values outside of TLS in various serialisation contexts.

> The fact that, as you highlight, they are machine-to-machine, seems like
> the greatest path to interoperability, because they shouldn't be assumed to
> be "human-readable", and because as specified, no other validation needs to
> be performed by either party. They should simply be treated as they're
> specified: an opaque series of bytes.

Yes, in TLS, but once they end up in DNS zones, configuration files,
pasted into web forms (to update DNS HTTPS/SVCB records...) various
pain points arise.

On Thu, May 20, 2021 at 07:39:59AM -0700, Ben Schwartz wrote:
> On Thu, May 20, 2021 at 6:30 AM Salz, Rich  40akamai@dmarc.ietf.org> wrote:
> 
> > Look at RFC 701, it says: the precise set of octet values that identifies
> > the protocol. This could be the UTF-8 encoding of the protocol name.
> >
> > So I changed my mind and think it's okay to leave as-is but wouldn't mind
> > if it became less general or more specific. For example, what if a protocol
> > string matches a truncated UTF8 string?  It makes me think of SNI which
> > could have any format, but really is "any format as long as it's a DNS name"
> 
> One intermediate option might be to keep the ALPN TLS extension 8-bit
> clean, but change the IANA instructions for the ALPN registry to tighten
> the registration requirements.

Yes, this, but also a commmitment to keep it that way, so that e.g.
HTTPS/SVCB can rely on not needing to encoding ALPN values that are
non-ASCII, have control characters, commas, double-quotes, ...

So the below should suffice:

* lower-case ASCII letters a-z
* ASCII digits 0-9
* "+", "-", ".", "/" and "_"

-- 
Viktor.

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

Re: [TLS] Narrowing allowed characters in ALPN ?

[Viktor Dukhovni]

On Wed, May 19, 2021 at 10:29:43PM +, Salz, Rich wrote:

> I support limiting it.

I concur.  These are not strings used between users to communicate in
their native language.  They are machine-to-machine protocol
identifiers, and use of the narrowest reasonable character set promotes
interoperability.

We don't want to embed ASCII NUL bytes in these, worry about potential
corruption when they get embedded in text strings and undergo transforms
from ISO-Latin to UTF-8 or back, ...

The more vanilla the character set the better.  The HTTPS record
constructs comma-separated lists of these in quotes, so it has to
deal with escaping quotes and commas, and other needless pain.

We're not helping anyone by insisting that the original definition was
wise.  It can and should be revised.

-- 
Viktor.

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

Re: [TLS] TLS1.3 clarification request

[Viktor Dukhovni]

On Wed, Mar 17, 2021 at 08:15:53AM +0100, Ben Smyth wrote:

> > Do I understand that right?  And if so, what is the point of the
> > language in the RFC that appears to permit a half-close?
> 
> Specifications don't define systems, they guide design. The specification
> does not "requir[e] an end to hold off sending a Close alert until after if
> has received all data that the far end is expected to send," the
> specification merely allows such behaviour. Perhaps one scenario where that
> behaviour is useful: An endpoint is about to be comprimised and raises an
> alert to avoid secrets being leaked.

FWIW, I largely part ways with Ben's assessment, and particularly the
strawman scenario above.  TLS 1.3 does in fact make it possible to
support half-close in mutually cooperative applications, and there
is no expectation that a close-notify on one side must immediately
be accompanied by a similar action on the other, the other side
can continue to send applicatoin data traffic.

However, what I don't read into 8446 is an obligation or expectation
that applications will routinely support half close.  Some probably
should (e.g. an HTTPS server should probably continue with its response
even after a half-close on the client-side following the request).

However, if applications don't support half-close, and fail to respond
to prior requests upon receipt of close-notify, I don't think they're
violating the specification, they're merely not half-close compatible.

If some application protocol is expected to support half-close, that
should be specified in some relevant application-specific standard.

-- 
Viktor.

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

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

[Viktor Dukhovni]

On Tue, Mar 09, 2021 at 11:29:40AM -0800, Carrick Bartle wrote:

> > Because there are still many TLS (non-web) implementations that don't
> > do ECDHE.
> 
> I'm confused: if those implementations don't do ECDHE, what's wrong
> with prohibiting the way it's used?

The proposal on the table is to deprecate FFDHE.  If the software stack
has no ECDHE, and only has FFDHE, it would then have to resort to RSA
key exchange.

> >* In practice security improves more when you raise the ceiling,
> >  rather the floor.
> 
> This sort of suggests that we should never deprecate anything, ever, no?

No, rather it suggests that *before* we deprecate, we first work to get
everyone to use stronger options, and then, crisis situations aside,
wait for the long tail to effectively peter out.  Then deprecate, once
it is clear that it is mostly a formality.

The difficult question is how to handle situations where the long tail
is mostly invisible to the IETF community, i.e. happens on isolated
networks, that use (and may be audited against) our standards, but don't
show up in Internet surveys, ...  It may then be hard to know when to
declare to declare victory.  I don't have a good answer for that.
This is where Peter Gutmann et. al., may be able to help.

Deprecation is not always easy, and we don't always the desired outcome.

I hear that in Germany operators of some services are expected to
operate their systems in accordance with "state of the art" practices
(I guess BCP).  This may allow a distinction between "tolerable" and
"best practice", where things we might deprecate would no longer be
"best practice", but are still within the standard, and expected
to interoperate if implemented by both (all relevant) parties.

So short of deprecation, one might say that the legacy algorithms:

* Are not recommended.
* Can't be expected to be widely implemented
* Should only be used when the preferred choices
  are not available.

Which is not nearly as strong as "MUST NOT", which is what I take
deprecation to mean.  Am I wrong about the intended meaning of
"deprecation"?

-- 
   Viktor.

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

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Viktor Dukhovni]

On Tue, Mar 09, 2021 at 07:28:26AM +, Fries, Steffen wrote:

> > My take is such measures are much too complicated.  Just keep the connection
> > lifetime short, and make a new one from time to time.  Also keep certificate
> > lifetimes short.  Where DNSSEC is an option on both ends, you can also use
> > DANE TLSA records instead of CRLs, just publish a
> > "1 1 1" (PKIX + DANE) or "3 1 1" (DANE only) record that validates the 
> > server's
> > public key, and give it a short-enough TTL that it can be replaced quickly.
> > Presto-magic, no need for OCSP, CRLs, ...
>
> While this may be a solution in general, it may not fit for power systems 
> (like a substation). 
> The application of DNSSEC or DANE is not very common and may not be used. 
> Also due to 
> Existing deployments, which do not feature these services (yet). 

I am not trying to suggest that DANE is currently a mainstream option
outside of SMTP (primarily in Northern and Central Europe for now, with
some signs of life in the USA, Canada and Brazil).  The above was more
of an aside for the record.  DANE may be a more realistic choice a few
years from now.  DNSSEC adoption is starting to grow faster, and if this
continues and accelerates, DANE may become more common, time will tell.

Early adopters can of course choose to use it now, but it is far from
mainstream today.

-- 
Viktor.

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

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

[Viktor Dukhovni]

On Mon, Mar 08, 2021 at 10:25:29PM -0800, Rob Sayre wrote:

> On Mon, Mar 8, 2021 at 10:16 PM John Mattsson wrote:
> >
> > Viktor Dukhovni wrote:
> > >In practice security improves more when you raise the ceiling, rather the
> > >floor.
> >
> > Let’s start with mandating support of
> > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for the remaining TLS 1.2
> > implementations. RFC 7540 did this 6 years ago, and it was not a day
> > too late.
> 
> I don't understand the motivation. Why not deprecate all of the RSA cipher
> suites?

If you mean all the RSA key exchange suites, sure where that's a viable
choice.  It was already argued upthread that this needs to be done
before or as part of deprecating FFDHE, lest the latter just lead to
reversion to RSA key exchange.

This would be a rather drastic floor-raising exercise, possibly in
excess of the present ceiling in some market niches.  The results
are not always what we want or expect.

As suggested above, it may first be prudent to specify some MTI
ECDHE ciphers, and check that these are being widely and correctly
implemented and deployed in some of the less familiar places that
have not done so already.

If there are major code size or other resource limits that preclude
support for both FFDHE and ECDHE, or even ECDHE alone, little is likely
to be gained by specifying that the floor is now 2 feet above the
ceiling.

I realise that my focus primarily on the ceiling and not the floor is
not universally shared, and may even be heretical in some circles, but
whether or not it should be the dominant concern, it surely warrants
some thought, because otherwise you do eventually run out of room in
between.

So my take is that barring emergencies, deprecations mostly take care of
themselves, because the better options are compelling and preferred by
default.  Such emergencies aside, deprecation can happen once "nobody"
is using an algorithm, not only on the web, but more broadly across all
the market sectors that consume IETF technologies.

Today, I sent Wietse a patch set that disables "medium" ciphers in
Postfix by default and requires TLS 1.2 (rather than 1.0) when TLS is
"mandatory" (submission, DANE, or other destination-specific policy).
I hope it will be merged in time for Postfix 3.6.

At this point, systems using TLS 1.0, SEED, RC4, IDEA or 3DES in SMTP
TLS are rare, and not expected to peers for mandatory TLS.  The ceiling
has been high for quite some time, and the floor raising is just a
formality.  Also, I'm just changing default settings, not removing
functionality.  If someone still needs the legacy crypto in some
dusty corner of their network, I'm not going to stop them.

-- 
Viktor.

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

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

[Viktor Dukhovni]

On Mon, Mar 08, 2021 at 07:08:31PM -0800, Carrick Bartle wrote:

> > I think the blanket prohibition of reuse of ECDHE keys is maybe not
> > really justified.
> 
> Why is that?

Because there are still many TLS (non-web) implementations that don't
do ECDHE.

Is there a credible active MiTM attack that can cause a server and
client both capable of ECDHE to use FFDHE or RSA key exchange?

If so, a properly scoped (to the web or the public Internet, ...)
deprecation of FFDHE and RSA key exchange is then justified.

If not, then I am cursed to ever repeat a key message of RFC7435:

* In practice security improves more when you raise the ceiling,
  rather the floor.

* If you set the bar too high, users will resort to less secure,
  but more accessible technologies.

If your basic protocol is basically sound (has downgrade-resistant
feature negotiation) then deprecation can be counter-productive in
the short to medium term, so long as a non-negligible fraction of
the installed base is then no longer tall enough to take the ride.

Therefore, a better approach may be to recommend that for key
exchange ECDHE should be prioritised ahead of EDH and RSA.

The effort may also be largely redundant, affecting only the
deployments that are likely to end up resorting to suboptimal
choices.

Below, for example, is the default TLS 1.2 ordered cipherlist for
OpenSSL 1.1.1.  All other parameters being equal, in each group
the order is kECDHE+aECDSA, kECDHE+aRSA and finally kDHE+aRSA:

  ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH   Au=ECDSA Enc=AESGCM(256) 
Mac=AEAD
  ECDHE-RSA-AES256-GCM-SHA384   TLSv1.2 Kx=ECDH   Au=RSA  Enc=AESGCM(256) 
Mac=AEAD
  DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA  Enc=AESGCM(256) 
Mac=AEAD

  ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH   Au=ECDSA 
Enc=CHACHA20/POLY1305(256) Mac=AEAD
  ECDHE-RSA-CHACHA20-POLY1305   TLSv1.2 Kx=ECDH   Au=RSA  
Enc=CHACHA20/POLY1305(256) Mac=AEAD
  DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA  
Enc=CHACHA20/POLY1305(256) Mac=AEAD

  ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH   Au=ECDSA Enc=AESGCM(128) 
Mac=AEAD
  ECDHE-RSA-AES128-GCM-SHA256   TLSv1.2 Kx=ECDH   Au=RSA  Enc=AESGCM(128) 
Mac=AEAD
  DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA  Enc=AESGCM(128) 
Mac=AEAD

  ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH   Au=ECDSA Enc=AES(256)  
Mac=SHA384
  ECDHE-RSA-AES256-SHA384   TLSv1.2 Kx=ECDH   Au=RSA  Enc=AES(256)  
Mac=SHA384
  DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA  Enc=AES(256)  
Mac=SHA256

  ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH   Au=ECDSA Enc=AES(128)  
Mac=SHA256
  ECDHE-RSA-AES128-SHA256   TLSv1.2 Kx=ECDH   Au=RSA  Enc=AES(128)  
Mac=SHA256
  DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA  Enc=AES(128)  
Mac=SHA256

  ECDHE-ECDSA-AES256-SHATLSv1 Kx=ECDH Au=ECDSA Enc=AES(256)  
Mac=SHA1
  ECDHE-RSA-AES256-SHA  TLSv1 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA1
  DHE-RSA-AES256-SHASSLv3 Kx=DH   Au=RSA  Enc=AES(256)  Mac=SHA1

  ECDHE-ECDSA-AES128-SHATLSv1 Kx=ECDH Au=ECDSA Enc=AES(128)  
Mac=SHA1
  ECDHE-RSA-AES128-SHA  TLSv1 Kx=ECDH Au=RSA  Enc=AES(128)  Mac=SHA1
  DHE-RSA-AES128-SHASSLv3 Kx=DH   Au=RSA  Enc=AES(128)  Mac=SHA1

  -- Finally, last resort kRSA
  AES256-GCM-SHA384 TLSv1.2 Kx=RSAAu=RSA  Enc=AESGCM(256) 
Mac=AEAD
  AES128-GCM-SHA256 TLSv1.2 Kx=RSAAu=RSA  Enc=AESGCM(128) 
Mac=AEAD
  AES256-SHA256 TLSv1.2 Kx=RSAAu=RSA  Enc=AES(256)  
Mac=SHA256
  AES128-SHA256 TLSv1.2 Kx=RSAAu=RSA  Enc=AES(128)  
Mac=SHA256
  AES256-SHASSLv3 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA1
  AES128-SHASSLv3 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA1

There's hardly any need to goad the ecosystem to prefer ECDHE when
available, that's already done.

> > IMO that's the part that should have deprecation of RSA cipher
> > suites done at the same time.

Here of course RSA means RSA key exchange, not RSA signatures.

> RSA seems to me to be too off-topic for this draft. (It also seems to
> me that RSA is still too widely used and not broken enough to merit
> deprecation.) If you think this draft requires that RSA key exchange
> also be deprecated, that could be done in a parallel draft.

I think there's a valid point here, either deprecate "kRSA" first
or both together.  Making it clear that no auditor's checklist
should become "green" by disabling DHE and leaving just RSA
key exchange standing.

-- 
Viktor.

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

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Viktor Dukhovni]

On Mon, Mar 08, 2021 at 08:51:31AM +, Fries, Steffen wrote:

> The problem that was addressed so far with the session renegotiation in TLS 
> 1.2 was motivated by different points. 
>
> - Recommendation in RFC 5246 regarding the use of the SessionID  lifetime
> - Regular session key update for the ongoing TLS Session
> - Trigger to verify the certificates used by both sides on a regular
>   base, ideally in relation to the update of locally available
>   revocation information
> 
> For the latter, the assumption was that some of the processes, when a
> long term key is compromised, may not be perfectly synchronized,
> meaning that the entity with a potentially compromised
> certificate/private key (long term key) is not immediately taken from
> the network.

So it sounds like the concern is that the key may have already been
compromised at the time the session was established, but was not yet
published on a CRL?  And so you want to keep checking the CRL
periodically, in case the client is talking to an MiTM attacker,
and it isn't too late to undo the damage.

Now of course the client can just check its CRL any time it wants,
without redoing the handshake.  It typically has (or can arrange to
retain) the server's certificate chain from the initial handshake.

So the only case that comes to mind where a new handshake is needed to
refresh the certificate validity is with stapled OCSP, where the server
is the source of the certificate freshness data.

My take is such measures are much too complicated.  Just keep the
connection lifetime short, and make a new one from time to time.  Also
keep certificate lifetimes short.  Where DNSSEC is an option on both
ends, you can also use DANE TLSA records instead of CRLs, just publish a
"1 1 1" (PKIX + DANE) or "3 1 1" (DANE only) record that validates the
server's public key, and give it a short-enough TTL that it can be
replaced quickly.  Presto-magic, no need for OCSP, CRLs, ...

-- 
Viktor.

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

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Viktor Dukhovni]

> On Mar 8, 2021, at 1:45 AM, Peter Gutmann  wrote:
> 
> Not that "never" since it would break a lot of things, but some time far
> enough in the future that you don't have to worry about it.

The cert generator I cobbled together for the OpenSSL test-suite
generates 100-year certs.  These work well, and should outlast
the lifetime of the library...  Lord help civilization, if it
is still using C for critical software in ~100 years.

(Before that, some older certs used in the build had in fact expired).

-- 
Viktor.

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

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Viktor Dukhovni]

On Sun, Mar 07, 2021 at 07:31:24PM -0800, Benjamin Kaduk wrote:

> Just to confirm: the scenario you're using to contrast to the one described
> by Viktor (and Nico) is a scenarios in which the certificates expire at 
> "never"
> (1231235959Z)?
> 
> I think that at least some people are contrasting against something other
> than that...

Correct, I'm contrasting with N-year certs for N <= 30 (longer if
expected lifetime of device is larger, e.g. switches in the NYC subway
system, though their actual deployed lifetime has well exceeded anything
"planned").  In other words, with certs that will actually need to be
replaced now and then.

Peter's "never" scenario has its place, it's the cases that fall between
"never" and short-lived that I find suboptimal.  Do it well, or don't
do it at all.

-- 
Viktor.

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

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Viktor Dukhovni]

On Sun, Mar 07, 2021 at 11:19:49PM +, Blumenthal, Uri - 0553 - MITLL wrote:

> > > So instead of getting one chance a year for your control system to break
> > > itself if the renewal fails, you get hundreds of them?
> >
> >Yes.  Exactly.  It's a human factors problem.  And this solution works.
> 
> With all due respect, *absolutely not*.

Well, it works when fragile manual processes (likely to be entirely
forgotten until things break) that are almost good enough to get by
on every year or two, become plainly unreasonable when exercised every
month or every week.  In other words, short-lived certs force:

- Active monitoring

- Automation of preëmptive renewals (with sufficient time
  to retry more than once on failure).

The tools to make this possible need to be available before we ask
people to invent this for themselves, but the effect on operational
discipline is real.

If either monitoring or automation are skipped, then sure, you have
a recipe for failure.  But if the signal is not ignored, and proper
automation is applied, reliability actually improves.

I see this effect in the stability of DANE deployments at domains that
are using Let's Encrypt with "mailinabox.email" which automates the
lifecycle including TLSA record updates, ..., v.s. DYI MTAs with certs
are only renewed every year or two (often wildcard shared by all MTAs
for the domain).

The mailinabox systems do a far better job of keeping their certs valid.
Despite the fact that they make up 1/3 of the deployed MXs, they make up
a much smaller fraction of the domains I ping when the DANE survey finds
poorly managed cert chains that fail authentication.

Does this mean that a nuclear reactor's cooling system should shut down
when a cert expires?  Probably not, ... but if one is going to manage
certificates that do expire, my bet is that the short-lived ones are
better managed, and will exhibit fewer total hours of downtime, despite
the more frequent expirations.

-- 
Viktor.

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

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Viktor Dukhovni]

On Sat, Mar 06, 2021 at 12:11:25AM -0600, Nico Williams wrote:

> On Fri, Mar 05, 2021 at 04:46:15PM -0800, Eric Rescorla wrote:
> > This leaves us with the case where Bob's certificate is no longer valid but
> > Bob has a new certificate [0]. In this case, just re-validating does not
> > help. Does that happen so often that we need protocol machinery other than
> > just tearing down the connection and starting over?
> 
> Probably not.  I've seen 5 day server certificates in use.  And while
> it's possible to keep connections open that long or longer, as Viktor
> points out, if you do keep a connection open and active longer than that
> and the server is still there (i.e., some node has its address and the
> connection's traffic keys), then that's probably good enough evidence
> that the server is still valid and still would have a fresh cert if you
> were to reconnect to it.

In general, I think breaking an established connection just to
reauthenticate the server only needlessly risks occasionally finding an
expired certificate that someone forgot to renew.  Server certificates
good at time of connection establishment should, barring extraordinary
circumstances be good for the life of the connection.

I suspect that in at least some cases the motivation to revalidate the
server certificate is only requested because it could be done in
principle, and ticks some checkbox about using CRLs, because they
exist, rather than from a clear threat this addresses.

However, it is possible that there actually exist use-cases where this
makes some sense, and that case, If connection lifetimes would otherwise
last unacceptably long, make a new connection, and close the old (in
some appropriate order).

-- 
Viktor.

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

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Viktor Dukhovni]

On Fri, Mar 05, 2021 at 02:01:52PM +, Fries, Steffen wrote:

> I've got a question regarding application of TLS 1.3 to protect long
> lasting  connections. Specifically on the trigger to perform a
> revocation check for the utilized certificates in the handshake. 
> 
> The background is that for the securing TCP based communication in
> power system automation we defined the application of TLS in IEC
> 62351-3. The document specifies how to use TLS v1.2 in this
> environment. As some of the connections are rather long lasting
> connections, the document defines the usage of TLS session
> renegotiation at least every 24 hours to update the session key
> material on one hand and to enforce the certificate verification from
> both sides (TLS is always used with mutual authentication) including
> the revocation check. The 24 hours were motivated by an expected CRL
> update once a day. 

This harks back to another recent thread where it was noted that one
needs to make a distinction between authentication and authorisation.

The integrity of a TLS 1.3 session (which always performs ephemeral key
agreement that offers forward-secrecy) is not compromised if later the
signing keys of one of the parties is compromised.  So there is no need
to check CRLs or renegotiate to just to maintain a secure connection.

On the server side, if the client's identity is used as a key into an
authorisation table, one just needs to periodically (or even at each
logical request) to revalidate the client's authorisation, there is
generally no need to "re-authenticate" the client.

If the client is presenting bearer-tokens for entitlement, the client
may periodically need to obtain fresh tokens.

If there is a concern that a server may somehow mid-session cease to be
a legitimate application endpoint for clients that are still connected
to it, and an expectation that timely CRLs and periodic revalidation
of the server certificate would help to avoid that, then perhaps
something should be done.

This feels to me like rather a very distant risk.  When a server is
taken out of rotation, the operator should typically terminate all
client connections at that time.  How often would one expect to
lose operational control of a running server, such that the only
way to protect active clients is via certificate revocation, with
clients finding out soon enough for this to be useful?

If loss of operational control of servers is a real concern, then I
guess clients should avoid long-lived sessions, and open new connections
frequently, limiting connection reuse and TLS session resumption to just
minutes (just to amortise the cost of the initial handshake over a short
sequence of back-to-back requests).

Once there's a new TLS session every ~5 minutes, there's no need for
CRLs, renegotiation, ... but a quick sequence of requests is still
handled efficiently.

So, in summary, avoid CRLs, OCSP, ... they're obsolete crutches.  Use
short-lived certificates (possibly just days or hours), reconnect often
if that's appropriate.  Demand fresh authorisation tokens from clients
if authorisation is encoded in the tokens, rather than checked out
of band by the server on a request-by-request basis.

-- 
Viktor.

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

Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

[Viktor Dukhovni]

> On Feb 10, 2021, at 11:57 PM, Jack Visoky 
>  wrote:
> 
> I would just like to recognize that there are some situations where it isn't 
> needed.

One classic case where Postfix supports TLS 1.[0-2] NULL ciphers
is loopback TLS (process to process communication via [127.0.0.1]
or a unix-domain socket).  Here, one would generally not use TLS
at all, but it can be useful for client authentication.

The use-case is far from common, and encrypting anyway is typically
a viable alternative, but there is a sound case that encryption adds
little value, if you can capture the traffic on [127.0.0.1] you can
also capture the same content prior to encryption (just trace the
sending process reading cleartext data from disk, or the receiving
process writing it to disk).

I am not saying there is or is not a compelling case for NULL ciphers,
but just noting a use-case where encryption does not add much value.

Performance-wise, indeed on many a CPU AESGCM is cheaper than SHA2.
So turning off encryption is not always a performance win.  It rather
depends...

If client and server conditionally support NULL ciphers in a debugging
configuration, one might also be able to debug some TLS-related problems
that are otherwise difficult to debug.  This too is a rare situation, and
comes with a risk of accidental misuse.

There is merit in keeping the combinatorial complexity of TLS 1.3
as small as possible, reducing implementation attack surface, ...

The key question, that is difficult to answer is whether the right
balance is adequately accomplished with "N" in the recommended column,
with most implementations then either not supporting said ciphersuites
at all, or disabling them by default.  If so, perhaps some specialised
implementations could use them appropriately.  On the other hand the
"specialised" applications might get used outside their originally
intended use-cases, in ways the designers never anticipated.

Do we leave the choice to use TLS wisely to the developers and users,
or we judge that misuse is inevitable, and the use-case not sufficiently
compelling?  I am somewhat inclined to do the latter.  Despite the fact
that'd I'd otherwise be inclined to argue for anonDH ciphers, which have
reasonable applications in unauthenticated opportunistic TLS, where any
presented certificates are just ignored bloat that increase the attack
surface.  I would have liked to see support for these retained in TLS 1.3,
but accept their omission as a legitimate tradeoff.  If NULL ciphers are
added (which IMHO are the greater risk), then perhaps I'd have a good
case to make to have anonDH/anonECDH ciphers re-introduced...

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