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] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Fries, Steffen]

> -Original Message-
> From: TLS  On Behalf Of Viktor Dukhovni, Sent: Montag, 
> 8. März 2021 19:05
> > 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.
Yes, that would be one scenario. 

> 
> 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.
True, which requires either a timer to do the checks periodically (either using 
CRL or OCSP) or a trigger when a new CRL is locally available.
So I already gathered, that this may be the solution.

> 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.
Agree. This would be the case, in which the receiver may have no access to an 
OCSP responder.


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

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

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

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

[Rob Sayre]

On Mon, Mar 8, 2021 at 10:16 PM John Mattsson  wrote:

> Brian Smith wrote:
> >Deprecating FFDHE key exchange without deprecating RSA key exchange will
> substantially increase the usage >of RSA key exchange and thus make server
> key compromise more dangerous. At a minimum, RSA key >exchange should be
> deprecated at the same time, in the same document.
>
> Deprecating static RSA and everything else that does not have PFS is long
> overdue. RFC 7540 did this 6 years ago, and it was not a day too late.
> Strange that the best TLS profiling was/is done by HTTPBIS.
>

That is strange.


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

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

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

[John Mattsson]

Brian Smith wrote:
>Deprecating FFDHE key exchange without deprecating RSA key exchange will 
>substantially increase the usage >of RSA key exchange and thus make server key 
>compromise more dangerous. At a minimum, RSA key >exchange should be 
>deprecated at the same time, in the same document. 

Deprecating static RSA and everything else that does not have PFS is long 
overdue. RFC 7540 did this 6 years ago, and it was not a day too late. Strange 
that the best TLS profiling was/is done by HTTPBIS.

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.

Cheers,
John

From: TLS  on behalf of Brian Smith 
Date: Tuesday, 9 March 2021 at 01:13
To: Martin Thomson 
Cc: "TLS@ietf.org" 
Subject: Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

It is sad that nobody is willing to discuss the obvious downsides of this 
proposal as written, which should at least be mentioned in the security 
considerations. Without discussing the downsides we're reducing engineering to 
politics. If we discuss the downsides then we can substantially improve the 
proposal.

Deprecating FFDHE key exchange without deprecating RSA key exchange will 
substantially increase the usage of RSA key exchange and thus make server key 
compromise more dangerous. At a minimum, RSA key exchange should be deprecated 
at the same time, in the same document. 

Look at Windows Server 2012 and similar legacy products that are in widespread 
use, which don't support any PFS cipher suites except FFDHE. Please deprecate 
RSA key exchange at the same time so that there is enough motivation for 
vendors of these legacy products to add safe alternatives and/or for users of 
these legacy implementations to upgrade to something new that implements a safe 
alternative. (Note that Windows Server 2012 did add a patch to enable 
increasing its FFDHE key size to safe sizes.)

It would be useful for the browser vendors that recently dropped FFDHE support 
to share their measurements for how much RSA key exchange usage increased after 
their changes. That would help us quantify the real-world impact of this change.

RSA key exchange uses flawed and error-prone cryptography that is prone to side 
channels as well, PKCS#1 encryption/decryption. Previous studies have found 
widespread flaws in implementations that are (AFAICT) even more easily 
exploitable than the Racoon attack is.

It is easy to imagine a perfect implementation of RSA key exchange that also 
perfectly protects the server's private key. It is unrealistic to expect 
implementations to actually live up to that ideal. When RSA key exchange is 
used, then a government that can effectively undo all the past encryption of a 
server if it can force the server operator to disclose the key, even for a 
perfect implementation of RSA key exchange.

Deprecating RSA key exchange at the same time as FFDHE will encourage adoption 
of newer products that also often support TLS 1.3.

Without creating a new, correct, way to use FFDHE key exchange, we're left with 
elliptic curve (ECDHE) key exchange as the only reasonable and 
widely-implemented key exchange mechanism.

Cheers,
Brian
(Speaking only for myself)

___
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] Regarding draft-bartle-tls-deprecate-ffdhe

[Peter Gutmann]

Brian Smith  writes:

>It would be useful for the browser vendors that recently dropped FFDHE
>support to share their measurements for how much RSA key exchange usage
>increased after their changes. That would help us quantify the real-world
>impact of this change.

... in mice.

Peter.


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

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

[Peter Gutmann]

David Benjamin  writes:

>[*] From the conclusion of the paper: "The most straightforward mitigation
>against the attack is to remove support for TLS-DH(E) entirely, as most major
>client implementations have already stopped supporting them"

Just as you need to automatically add "in mice" to the end of any announcement
of a new medical result, so you also need to add "on the web" to the end of
any pronouncement about TLS.  This only applies to the special bubble of the
web.  For other situations, the effect of banning DHE will be to force
everyone to move to RSA.  I've already seen this in payments processing
applications, instead of using the secure-unless-you-implement-it-really-badly
DHE they use the almost-impossible-to-do-securely RSA, because someone has
told them not to use DHE.

So a blanket ban of DHE will lead to a net loss in security.

Peter.


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

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

[Carrick Bartle]

> I think the blanket prohibition of reuse of ECDHE keys is maybe not really 
> justified.

Why is that?

> IMO that's the part that should have deprecation of RSA cipher suites done at 
> the same time.

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.


> On Mar 8, 2021, at 4:23 PM, Brian Smith  wrote:
> 
> Brian Smith mailto:br...@briansmith.org>> wrote:
> It is sad that nobody is willing to discuss the obvious downsides of this 
> proposal as written, which should at least be mentioned in the security 
> considerations. Without discussing the downsides we're reducing engineering 
> to politics. If we discuss the downsides then we can substantially improve 
> the proposal.
> 
> To clarify: the RFC is about deprecating non-ephemeral cipher suites and 
> reusing keys in implementing the ephemeral cipher suites. I don't know of any 
> practical issues with the RFC as written, although I think the blanket 
> prohibition of reuse of ECDHE keys is maybe not really justified.
> 
> The proposal that I'm saying needs to be improved is the proposal of 
> deprecating the ephemeral FFDHE cipher suites at the same time. IMO that's 
> the part that should have deprecation of RSA cipher suites done at the same 
> time.
> 
> Cheers,
> Brian
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

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

[David Benjamin]

Chrome dropped TLS 1.2 DHE nearly five years ago now. I don't have data on
the current DHE-to-RSA conversion, but I can tell you what it was then.
When we put it under a fallback for measurement, only 2% of connections
negotiated DHE. Of that 2%, 95% used 1024-bit DHE. That means we really
only had 2% * 5% = 0.1% of connections that actually used it effectively.
https://groups.google.com/a/chromium.org/g/security-dev/c/dYyhKHPnrI0/m/pNxx8vTKBAA

At 95% with no group negotiation, clearing DHE-1024 was implausible without
a *dramatic* shift in the server population. Moreover, there is a TLS
client with a *maximum* DHE group size of 1024-bit, so servers risked
interop problems if they switched to larger group sizes. (To say nothing of
DoS risks because DHE is pretty slow.) The code points are basically stuck.
It's a pity we didn't have RFC7919 from the start, but anyone implementing
it can already implement ECDHE and now TLS 1.3. It also doesn't help here
because, by reusing the old TLS 1.2 DHE code points, it's not possible for
a client to offer RFC7919 TLS 1.2 DHE without simultaneously offering
legacy TLS 1.2 DHE.

All those numbers were five years ago. ECDHE deployment has increased
substantially, so DHE's value has only gone down. Looks like Firefox
dropped it more recently, so perhaps they'll have more recent numbers.

David


On Mon, Mar 8, 2021 at 7:30 PM Andrei Popov  wrote:

> Hi Brian,
>
>
>
>- Look at Windows Server 2012 and similar legacy products that are in
>widespread use, which don't support any PFS cipher suites except FFDHE.
>
> Windows Server 2012/Windows 8 support both TLS_ECDHE_ECDSA and
> TLS_ECDHE_RSA cipher suites: TLS Cipher Suites in Windows 8 - Win32 apps
> | Microsoft Docs
> 
>
>
>
> Our telemetry shows extremely low usage of TLS_DHE cipher suites and I’m
> in favor of deprecating them.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS  *On Behalf Of * Brian Smith
> *Sent:* Monday, March 8, 2021 4:13 PM
> *To:* Martin Thomson 
> *Cc:*  
> *Subject:* [EXTERNAL] Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe
>
>
>
> It is sad that nobody is willing to discuss the obvious downsides of this
> proposal as written, which should at least be mentioned in the security
> considerations. Without discussing the downsides we're reducing engineering
> to politics. If we discuss the downsides then we can substantially improve
> the proposal.
>
>
>
> Deprecating FFDHE key exchange without deprecating RSA key exchange will
> substantially increase the usage of RSA key exchange and thus make server
> key compromise more dangerous. At a minimum, RSA key exchange should be
> deprecated at the same time, in the same document.
>
>
>
> Look at Windows Server 2012 and similar legacy products that are in
> widespread use, which don't support any PFS cipher suites except FFDHE.
> Please deprecate RSA key exchange at the same time so that there is enough
> motivation for vendors of these legacy products to add safe alternatives
> and/or for users of these legacy implementations to upgrade to something
> new that implements a safe alternative. (Note that Windows Server 2012 did
> add a patch to enable increasing its FFDHE key size to safe sizes.)
>
>
>
> It would be useful for the browser vendors that recently dropped FFDHE
> support to share their measurements for how much RSA key exchange usage
> increased after their changes. That would help us quantify the real-world
> impact of this change.
>
>
>
> RSA key exchange uses flawed and error-prone cryptography that is prone to
> side channels as well, PKCS#1 encryption/decryption. Previous studies have
> found widespread flaws in implementations that are (AFAICT) even more
> easily exploitable than the Racoon attack is.
>
>
>
> It is easy to imagine a perfect implementation of RSA key exchange that
> also perfectly protects the server's private key. It is unrealistic to
> expect implementations to actually live up to that ideal. When RSA key
> exchange is used, then a government that can effectively undo all the past
> encryption of a server if it can force the server operator to disclose the
> key, even for a perfect implementation of RSA key exchange.
>
>
>
> Deprecating RSA key exchange at the same time as FFDHE will encourage
> adoption of newer products that also often support TLS 1.3.
>
>
>
> Without creating a new, correct, way to use FFDHE key exchange, we're left
> with elliptic curve (ECDHE) key exchange as the only reasonable and
> widely-implemented key exchange mechanism.
>
>
>
> Cheers,
>
> Brian
>
> (Speaking only for myself)
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Andrei Popov]

Hi Brian,


  *   Look at Windows Server 2012 and similar legacy products that are in 
widespread use, which don't support any PFS cipher suites except FFDHE.
Windows Server 2012/Windows 8 support both TLS_ECDHE_ECDSA and TLS_ECDHE_RSA 
cipher suites: TLS Cipher Suites in Windows 8 - Win32 apps | Microsoft 
Docs

Our telemetry shows extremely low usage of TLS_DHE cipher suites and I’m in 
favor of deprecating them.

Cheers,

Andrei

From: TLS  On Behalf Of Brian Smith
Sent: Monday, March 8, 2021 4:13 PM
To: Martin Thomson 
Cc:  
Subject: [EXTERNAL] Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

It is sad that nobody is willing to discuss the obvious downsides of this 
proposal as written, which should at least be mentioned in the security 
considerations. Without discussing the downsides we're reducing engineering to 
politics. If we discuss the downsides then we can substantially improve the 
proposal.

Deprecating FFDHE key exchange without deprecating RSA key exchange will 
substantially increase the usage of RSA key exchange and thus make server key 
compromise more dangerous. At a minimum, RSA key exchange should be deprecated 
at the same time, in the same document.

Look at Windows Server 2012 and similar legacy products that are in widespread 
use, which don't support any PFS cipher suites except FFDHE. Please deprecate 
RSA key exchange at the same time so that there is enough motivation for 
vendors of these legacy products to add safe alternatives and/or for users of 
these legacy implementations to upgrade to something new that implements a safe 
alternative. (Note that Windows Server 2012 did add a patch to enable 
increasing its FFDHE key size to safe sizes.)

It would be useful for the browser vendors that recently dropped FFDHE support 
to share their measurements for how much RSA key exchange usage increased after 
their changes. That would help us quantify the real-world impact of this change.

RSA key exchange uses flawed and error-prone cryptography that is prone to side 
channels as well, PKCS#1 encryption/decryption. Previous studies have found 
widespread flaws in implementations that are (AFAICT) even more easily 
exploitable than the Racoon attack is.

It is easy to imagine a perfect implementation of RSA key exchange that also 
perfectly protects the server's private key. It is unrealistic to expect 
implementations to actually live up to that ideal. When RSA key exchange is 
used, then a government that can effectively undo all the past encryption of a 
server if it can force the server operator to disclose the key, even for a 
perfect implementation of RSA key exchange.

Deprecating RSA key exchange at the same time as FFDHE will encourage adoption 
of newer products that also often support TLS 1.3.

Without creating a new, correct, way to use FFDHE key exchange, we're left with 
elliptic curve (ECDHE) key exchange as the only reasonable and 
widely-implemented key exchange mechanism.

Cheers,
Brian
(Speaking only for myself)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Brian Smith]

Brian Smith  wrote:

> It is sad that nobody is willing to discuss the obvious downsides of this
> proposal as written, which should at least be mentioned in the security
> considerations. Without discussing the downsides we're reducing engineering
> to politics. If we discuss the downsides then we can substantially improve
> the proposal.
>

To clarify: the RFC is about deprecating non-ephemeral cipher suites and
reusing keys in implementing the ephemeral cipher suites. I don't know of
any practical issues with the RFC as written, although I think the blanket
prohibition of reuse of ECDHE keys is maybe not really justified.

The proposal that I'm saying needs to be improved is the proposal of
deprecating the ephemeral FFDHE cipher suites at the same time. IMO that's
the part that should have deprecation of RSA cipher suites done at the same
time.

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

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

[Brian Smith]

It is sad that nobody is willing to discuss the obvious downsides of this
proposal as written, which should at least be mentioned in the security
considerations. Without discussing the downsides we're reducing engineering
to politics. If we discuss the downsides then we can substantially improve
the proposal.

Deprecating FFDHE key exchange without deprecating RSA key exchange will
substantially increase the usage of RSA key exchange and thus make server
key compromise more dangerous. At a minimum, RSA key exchange should be
deprecated at the same time, in the same document.

Look at Windows Server 2012 and similar legacy products that are in
widespread use, which don't support any PFS cipher suites except FFDHE.
Please deprecate RSA key exchange at the same time so that there is enough
motivation for vendors of these legacy products to add safe alternatives
and/or for users of these legacy implementations to upgrade to something
new that implements a safe alternative. (Note that Windows Server 2012 did
add a patch to enable increasing its FFDHE key size to safe sizes.)

It would be useful for the browser vendors that recently dropped FFDHE
support to share their measurements for how much RSA key exchange usage
increased after their changes. That would help us quantify the real-world
impact of this change.

RSA key exchange uses flawed and error-prone cryptography that is prone to
side channels as well, PKCS#1 encryption/decryption. Previous studies have
found widespread flaws in implementations that are (AFAICT) even more
easily exploitable than the Racoon attack is.

It is easy to imagine a perfect implementation of RSA key exchange that
also perfectly protects the server's private key. It is unrealistic to
expect implementations to actually live up to that ideal. When RSA key
exchange is used, then a government that can effectively undo all the past
encryption of a server if it can force the server operator to disclose the
key, even for a perfect implementation of RSA key exchange.

Deprecating RSA key exchange at the same time as FFDHE will encourage
adoption of newer products that also often support TLS 1.3.

Without creating a new, correct, way to use FFDHE key exchange, we're left
with elliptic curve (ECDHE) key exchange as the only reasonable and
widely-implemented key exchange mechanism.

Cheers,
Brian
(Speaking only for myself)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Comments on draft-friel-tls-eap-dpp-01

[Eric Rescorla]

On Mon, Mar 8, 2021 at 1:18 PM Dan Harkins  wrote:

>
>   Hi Eric,
>
> On 3/8/21 8:00 AM, Eric Rescorla wrote:
>
> Taking a step back from the crypto, I'm trying to make sure I
> understand the desired security properties. As I understand the
> situation:
>
> - the client has a preconfigured key pair (X_c, Y_c)
> - the server is anonymous (i.e., doesn't have a valid TLS cert).
> - the server is preconfigured with information about each
>   client (in this case, Y_c).
>
> And the desired property you are looking for is that:
>
> 1. The client authenticates to the server using X_c
> 2. The client will only connect to servers that know the
>per-client information
>
> Is this correct?
>
>
>   Yes.
>
>
> Assuming it is, it seems like we could accomplish this with
> less change to TLS. Here is one proposal (warning: not
> at all analyzed so may be totally broken).
>
> - Have the client take on the TLS server role, and use RFC 7250 raw
>   public keys. This addresses requirement 1.
>
>
>   This breaks the use of (T)EAP. In the case of EAP, the server is the
> one that grants access to the network and the client is the one that
> asks for access (which is why it's known as the "supplicant"). The
> EAP roles match the TLS roles so it wouldn't be possible for an EAP
> client to act as a TLS server in the EAP method.
>

Thanks for the clarification. This is party of why it's helpful to
understand the requirements.


> - Store a separate per-client value K_c (this can be derived from the
>   X_c to ease the burden on the client) and use RFC 8773 external PSK
>   with cert authentication to inject K_c into the key schedule.
>
>
>   There's no certs involved here. There is trust by the server in a
> raw public key and there's an assurance (not quite authentication) of
> the client based on who knows that public key
>

To clarify, what I was proposing was that that you replace knowledge of the
pubkey
with knowledge of the PSK and have the client (acting as the server)
present its
public key in the RFC 7250 Raw Public Key mode. The reason certs come
into play is that TLS 1.3 prohibits the use of certificate based exchanges
(which
should include Raw Public Key) with PSKs, and 8773 relaxes that.

However, if you can't have the client act as the server, then we'll need to
find
another approach. As I indicated on the call, what would be helpful to me
would
be a description of the externally visible invariants that we need to
satisfy.

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

Re: [TLS] Comments on draft-friel-tls-eap-dpp-01

[Dan Harkins]

  Hi Christian,

On 3/8/21 11:49 AM, Christian Huitema wrote:


The list of requirement reminds me of two scenarios: the Anima problem 
of "bringing a clean device into the new owner's network"; and the 
corporate Wi-Fi problem of "connecting a device to the corporate 
Wi-Fi". In the Anima problem, the server can verify that the device 
identity corresponds to something that the owner bought, but the 
device has no knowledge of where it is connecting to. Anima proposed 
to close the security loop by having the device connect to the 
enterprise first, then check a certificate issued by the manufacturer 
to device owner. The Wi-Fi scenario uses EAP over TLS and the classic 
solution is a variation of TOFU: ask the device user to verify that 
the key is what it expects for the SSID, then remember that for the 
following connections. In this scenario, the Wi-Fi server is always 
entitled to verify the client's identity and authorization.


  Yes, this is the scenario. Although there is no "expects for the 
SSID". The client
has no knowledge of anything, no provisioning, no credentials, and in 
many cases no
UI by which someone would provision an SSID and some credential. It's a 
classic
catch-22-- I need a credential to get on the network but I need to get 
on the network

to get a credential.

  Wi-fi solves this problem by doing DPP over special 802.11 frames 
which are sent
pre-association. So the client doesn't need to know an SSID or connect 
to anything
in order to engage in a handshake. The network entity authenticates the 
client based
on the bootstrapped public key and the client gets an assurance that 
this is the
right network because the network entity knew its public key (based on 
the resurrecting

duckling model from [1]).

  For the wired case, which is what TLS-pok is addressing, the network 
is whatever
port the device is plugged into and it wants to get an assurance that 
the entity on

the other side of that port knows its public key. It's a bit more than TOFU
because if the other end doesn't know its public key (if it's not the 
legitimate

network) then it won't complete the TLS handshake.



I don't think that these scenarios lend themselves easily to 
"reversing the roles". At least, not easily.


  You're right, they don't.

  regards,

  Dan.

[1] https://link.springer.com/chapter/10.1007/10720107_24

--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

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

Re: [TLS] Comments on draft-friel-tls-eap-dpp-01

[Dan Harkins]

  Hi Eric,

On 3/8/21 8:00 AM, Eric Rescorla wrote:

Taking a step back from the crypto, I'm trying to make sure I
understand the desired security properties. As I understand the
situation:

- the client has a preconfigured key pair (X_c, Y_c)
- the server is anonymous (i.e., doesn't have a valid TLS cert).
- the server is preconfigured with information about each
  client (in this case, Y_c).

And the desired property you are looking for is that:

1. The client authenticates to the server using X_c
2. The client will only connect to servers that know the
   per-client information

Is this correct?


  Yes.



Assuming it is, it seems like we could accomplish this with
less change to TLS. Here is one proposal (warning: not
at all analyzed so may be totally broken).

- Have the client take on the TLS server role, and use RFC 7250 raw
  public keys. This addresses requirement 1.


  This breaks the use of (T)EAP. In the case of EAP, the server is the
one that grants access to the network and the client is the one that
asks for access (which is why it's known as the "supplicant"). The
EAP roles match the TLS roles so it wouldn't be possible for an EAP
client to act as a TLS server in the EAP method.


- Store a separate per-client value K_c (this can be derived from the
  X_c to ease the burden on the client) and use RFC 8773 external PSK
  with cert authentication to inject K_c into the key schedule.


  There's no certs involved here. There is trust by the server in a
raw public key and there's an assurance (not quite authentication) of
the client based on who knows that public key (this is modeled on the
"Resurrecting Duckling" paper).

  regards,

  Dan.


-Ekr

On Mon, Mar 8, 2021 at 7:09 AM Scott Fluhrer (sfluhrer) 
> wrote:


Again, last minute reviews…

It would appear that the exact computations that both the client
and the server need to perform needs to be explicitly spelled out,
as there are several possibilities.

Here is the one I could see that appear to have the security
properties that you appear to be looking for:

Variable names:

    g – Well known group generator

    h – The secret generator that is private to the
client and the server

    z – The secret value known to the client; g^z = h

    x – The client’s ephemeral DH private value

    y – The server’s ephemeral DH private value:

Client keyshare:

    This is the value g^x

When the server receives this, he selects y (and retrieves the
value h); he then transmits (as his keyshare) the value:

    h^y

and stirs the value (g^x)^y into his KDF

When the client receives this (h^y), he computes:

    (h^y) ^ (x z^-1)

(where z^-1 is the modular inverse of z modulo the group order),
and stirs that value into his KDF.

With this protocol, it appears that the client needs to know not
only h, but also the value z.  However, this really needs to be
spelled out (and run past the CFRG to check for subtle issues)

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


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


--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

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

Re: [TLS] Comments on draft-friel-tls-eap-dpp-01

[Dan Harkins]

  Hi Scott,

On 3/8/21 7:09 AM, Scott Fluhrer (sfluhrer) wrote:


Again, last minute reviews…

It would appear that the exact computations that both the client and 
the server need to perform needs to be explicitly spelled out, as 
there are several possibilities.


Here is the one I could see that appear to have the security 
properties that you appear to be looking for:


Variable names:

    g – Well known group generator

    h – The secret generator that is private to the client 
and the server


    z – The secret value known to the client; g^z = h

    x – The client’s ephemeral DH private value

    y – The server’s ephemeral DH private value:

Client keyshare:

    This is the value g^x

When the server receives this, he selects y (and retrieves the value 
h); he then transmits (as his keyshare) the value:


    h^y

and stirs the value (g^x)^y into his KDF

When the client receives this (h^y), he computes:

    (h^y) ^ (x z^-1)

(where z^-1 is the modular inverse of z modulo the group order), and 
stirs that value into his KDF.


With this protocol, it appears that the client needs to know not only 
h, but also the value z. However, this really needs to be spelled out 
(and run past the CFRG to check for subtle issues)




  That is an interesting exchange but it is not DPP and it is not TLS-pok.

  regards,

  Dan.

--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

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

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

[Carrick Bartle]

Great, sounds good to me then.

> On Mar 8, 2021, at 11:24 AM, David Benjamin  wrote:
> 
> I guess it's a question of what the goal of this draft is. I don't 
> particularly care as long as it's self-consistent. :-)
> 
> We've got the title, "FFDH(E)", which would suggest targeting TLS_DH_*, 
> TLS_DHE_*, and even NamedGroup.ffdhe*, and not anything around ECDH(E).
> We've got the contents, which are targeting non-PFS flows, EC or FF. That is, 
> TLS_DH_*, TLS_ECDH_*, and uses of (EC)DHE that aren't actually ephemeral.
> We've got the Raccoon citation, which would suggest[*] targeting TLS_DH_* and 
> TLS_DHE_*, due to the buggy construction, and possibly also the non-PFS modes 
> of both 1.3 FFDHE and 1.2/1.3 ECDHE because key reuse is more fragile.
> 
> [*] From the conclusion of the paper: "The most straightforward mitigation 
> against the attack is to remove support for TLS-DH(E) entirely, as most major 
> client implementations have already stopped supporting them"
> 
> On Mon, Mar 8, 2021 at 2:06 PM Carrick Bartle  > wrote:
> I'm not opposed to expanding the scope of this document to include 
> deprecating DHE. Is there a major advantage to that being its own draft?
> 
> 
> > On Mar 8, 2021, at 10:09 AM, Martin Thomson  > > wrote:
> > 
> > One thing at a time?
> > 
> > On Tue, Mar 9, 2021, at 05:05, David Benjamin wrote:
> >> I'd suggest we also deprecate TLS 1.2 TLS_DHE_*, even when ephemeral:
> >> 
> >> - The construction is broken. The leak itself in the Raccoon attack 
> >> comes from TLS 1.2 removing leading zeros. We can't change the meaning 
> >> of the existing code points, so any fix there would involve dropping 
> >> them.
> >> 
> >> - It lacks group negotiation, which makes it very difficult to migrate 
> >> away from small groups. At least in the web, it's already no longer 
> >> supported by most implementations.
> >> https://groups.google.com/a/chromium.org/g/blink-dev/c/AAdv838-koo/m/bJv17voIBAAJ
> >>  
> >> 
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1496639 
> >> 
> >> https://weakdh.org/ 
> >> 
> >> On Mon, Mar 8, 2021 at 12:52 PM Carrick Bartle 
> >>  >> > wrote:
> >>> Agreed. I'll change the title to reflect that.
> >>> 
>  On Mar 8, 2021, at 7:33 AM, Martin Thomson   > wrote:
>  
>  Well overdue.  We should do this.
>  
>  The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to 
>  match the document content.  I only see static or semi-static DH and 
>  ECDH key exchange being deprecated (in the document as non-ephemeral).
>  
>  ___
>  TLS mailing list
>  TLS@ietf.org 
>  https://www.ietf.org/mailman/listinfo/tls 
>  
> >>> 
> >>> ___
> >>> TLS mailing list
> >>> TLS@ietf.org 
> >>> https://www.ietf.org/mailman/listinfo/tls 
> >>> 
> > 
> > ___
> > TLS mailing list
> > TLS@ietf.org 
> > https://www.ietf.org/mailman/listinfo/tls 
> > 
> 

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

Re: [TLS] Comments on draft-friel-tls-eap-dpp-01

[Christian Huitema]

On 3/8/2021 8:00 AM, Eric Rescorla wrote:

Taking a step back from the crypto, I'm trying to make sure I
understand the desired security properties. As I understand the
situation:

- the client has a preconfigured key pair (X_c, Y_c)
- the server is anonymous (i.e., doesn't have a valid TLS cert).
- the server is preconfigured with information about each
  client (in this case, Y_c).

And the desired property you are looking for is that:

1. The client authenticates to the server using X_c
2. The client will only connect to servers that know the
   per-client information

Is this correct?


Assuming it is, it seems like we could accomplish this with
less change to TLS. Here is one proposal (warning: not
at all analyzed so may be totally broken).

- Have the client take on the TLS server role, and use RFC 7250 raw
  public keys. This addresses requirement 1.

- Store a separate per-client value K_c (this can be derived from the
  X_c to ease the burden on the client) and use RFC 8773 external PSK
  with cert authentication to inject K_c into the key schedule.



The list of requirement reminds me of two scenarios: the Anima problem 
of "bringing a clean device into the new owner's network"; and the 
corporate Wi-Fi problem of "connecting a device to the corporate Wi-Fi". 
In the Anima problem, the server can verify that the device identity 
corresponds to something that the owner bought, but the device has no 
knowledge of where it is connecting to. Anima proposed to close the 
security loop by having the device connect to the enterprise first, then 
check a certificate issued by the manufacturer to device owner. The 
Wi-Fi scenario uses EAP over TLS and the classic solution is a variation 
of TOFU: ask the device user to verify that the key is what it expects 
for the SSID, then remember that for the following connections. In this 
scenario, the Wi-Fi server is always entitled to verify the client's 
identity and authorization.


I don't think that these scenarios lend themselves easily to "reversing 
the roles". At least, not easily.


-- Christian Huitema

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

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

[David Benjamin]

I guess it's a question of what the goal of this draft is. I don't
particularly care as long as it's self-consistent. :-)

We've got the title, "FFDH(E)", which would suggest targeting TLS_DH_*,
TLS_DHE_*, and even NamedGroup.ffdhe*, and not anything around ECDH(E).
We've got the contents, which are targeting non-PFS flows, EC or FF. That
is, TLS_DH_*, TLS_ECDH_*, and uses of (EC)DHE that aren't actually
ephemeral.
We've got the Raccoon citation, which would suggest[*] targeting TLS_DH_*
and TLS_DHE_*, due to the buggy construction, and possibly also the non-PFS
modes of both 1.3 FFDHE and 1.2/1.3 ECDHE because key reuse is more fragile.

[*] From the conclusion of the paper: "The most straightforward mitigation
against the attack is to remove support for TLS-DH(E) entirely, as most
major client implementations have already stopped supporting them"

On Mon, Mar 8, 2021 at 2:06 PM Carrick Bartle  wrote:

> I'm not opposed to expanding the scope of this document to include
> deprecating DHE. Is there a major advantage to that being its own draft?
>
>
> > On Mar 8, 2021, at 10:09 AM, Martin Thomson  wrote:
> >
> > One thing at a time?
> >
> > On Tue, Mar 9, 2021, at 05:05, David Benjamin wrote:
> >> I'd suggest we also deprecate TLS 1.2 TLS_DHE_*, even when ephemeral:
> >>
> >> - The construction is broken. The leak itself in the Raccoon attack
> >> comes from TLS 1.2 removing leading zeros. We can't change the meaning
> >> of the existing code points, so any fix there would involve dropping
> >> them.
> >>
> >> - It lacks group negotiation, which makes it very difficult to migrate
> >> away from small groups. At least in the web, it's already no longer
> >> supported by most implementations.
> >>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/AAdv838-koo/m/bJv17voIBAAJ
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1496639
> >> https://weakdh.org/
> >>
> >> On Mon, Mar 8, 2021 at 12:52 PM Carrick Bartle
> >>  wrote:
> >>> Agreed. I'll change the title to reflect that.
> >>>
>  On Mar 8, 2021, at 7:33 AM, Martin Thomson  wrote:
> 
>  Well overdue.  We should do this.
> 
>  The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to
> match the document content.  I only see static or semi-static DH and ECDH
> key exchange being deprecated (in the document as non-ephemeral).
> 
>  ___
>  TLS mailing list
>  TLS@ietf.org
>  https://www.ietf.org/mailman/listinfo/tls
> >>>
> >>> ___
> >>> TLS mailing list
> >>> TLS@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/tls
> >
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Moving the ECH interop target

[Christopher Wood]

As discussed during today's call, -10 is now out. I'll update pointers in the 
interop matrix and related pages.

Stay tuned for a doodle to schedule the interim meetings!

Best,
Chris (no hat)

On Wed, Feb 24, 2021, at 10:07 AM, Christopher Wood wrote:
> The WG previously decided to make draft-ietf-tls-esni-09 the official 
> target for interop. The diff between this version and the current 
> editor's copy of the draft is below:
> 
>
> https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-tls-esni.txt=https://tlswg.github.io/draft-ietf-tls-esni/draft-ietf-tls-esni.txt
> 
> Given the size of the diff, and the recent update to HPKE to prepare it 
> for IRSG review, I'd like to propose that we cut -10 (when the 
> datatracker opens) and use that as the new interop target. This will 
> resolve the moving HPKE target going forward and let that part of the 
> protocol stabilize.
> 
> What do other implementers think?
> 
> Thanks,
> Chris (no hat)
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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

[TLS] I-D Action: draft-ietf-tls-esni-10.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : TLS Encrypted Client Hello
Authors : Eric Rescorla
  Kazuho Oku
  Nick Sullivan
  Christopher A. Wood
Filename: draft-ietf-tls-esni-10.txt
Pages   : 41
Date: 2021-03-08

Abstract:
   This document describes a mechanism in Transport Layer Security (TLS)
   for encrypting a ClientHello message under a server public key.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-esni-10.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-esni-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

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

[Carrick Bartle]

I'm not opposed to expanding the scope of this document to include deprecating 
DHE. Is there a major advantage to that being its own draft?


> On Mar 8, 2021, at 10:09 AM, Martin Thomson  wrote:
> 
> One thing at a time?
> 
> On Tue, Mar 9, 2021, at 05:05, David Benjamin wrote:
>> I'd suggest we also deprecate TLS 1.2 TLS_DHE_*, even when ephemeral:
>> 
>> - The construction is broken. The leak itself in the Raccoon attack 
>> comes from TLS 1.2 removing leading zeros. We can't change the meaning 
>> of the existing code points, so any fix there would involve dropping 
>> them.
>> 
>> - It lacks group negotiation, which makes it very difficult to migrate 
>> away from small groups. At least in the web, it's already no longer 
>> supported by most implementations.
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/AAdv838-koo/m/bJv17voIBAAJ
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1496639
>> https://weakdh.org/
>> 
>> On Mon, Mar 8, 2021 at 12:52 PM Carrick Bartle 
>>  wrote:
>>> Agreed. I'll change the title to reflect that.
>>> 
 On Mar 8, 2021, at 7:33 AM, Martin Thomson  wrote:
 
 Well overdue.  We should do this.
 
 The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match 
 the document content.  I only see static or semi-static DH and ECDH key 
 exchange being deprecated (in the document as non-ephemeral).
 
 ___
 TLS mailing list
 TLS@ietf.org
 https://www.ietf.org/mailman/listinfo/tls
>>> 
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

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

[Benjamin Kaduk]

On Mon, Mar 08, 2021 at 10:52:15AM -0800, Carrick Bartle wrote:
> If the draft to deprecate 1.0 and 1.1 becomes an RFC while this is still a 
> draft, I'll remove all mention of 1.0/1.1.

I expect it to become an RFC this week.

-Ben

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

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

[Carrick Bartle]

If the draft to deprecate 1.0 and 1.1 becomes an RFC while this is still a 
draft, I'll remove all mention of 1.0/1.1.


> On Mar 8, 2021, at 8:34 AM, John Mattsson 
>  wrote:
> 
> +1 for forbidding more old crap.
> 
> Lack of forward secrecy should imply at least NOT RECOMMENDED.
> 
> Does it make sense to forbid things for TLS 1.0 and TLS 1.1 when we soon have 
> an RFC forbidding use of TLS 1.0 and TLS 1.1?
> 
> Cheers,
> John
> 
> 
> -Original Message-
> From: TLS  on behalf of Martin Thomson 
> 
> Date: Monday, 8 March 2021 at 16:34
> To: "TLS@ietf.org" 
> Subject: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe
> 
> Well overdue.  We should do this.
> 
> The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match the 
> document content.  I only see static or semi-static DH and ECDH key exchange 
> being deprecated (in the document as non-ephemeral).
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

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

[Andrei Popov]

TLS_DHE is weak when used with interoperable key lengths. It also causes 
interop issues dues to several instances of under-specification (leading zeros, 
lack of group negotiation). I'm in favor of deprecating TLS_DHE.

Cheers,

Andrei

-Original Message-
From: TLS  On Behalf Of Martin Thomson
Sent: Monday, March 8, 2021 10:09 AM
To: David Benjamin ; Carrick Bartle 

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

One thing at a time?

On Tue, Mar 9, 2021, at 05:05, David Benjamin wrote:
> I'd suggest we also deprecate TLS 1.2 TLS_DHE_*, even when ephemeral:
> 
> - The construction is broken. The leak itself in the Raccoon attack 
> comes from TLS 1.2 removing leading zeros. We can't change the meaning 
> of the existing code points, so any fix there would involve dropping 
> them.
> 
> - It lacks group negotiation, which makes it very difficult to migrate 
> away from small groups. At least in the web, it's already no longer 
> supported by most implementations.
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrou
> ps.google.com%2Fa%2Fchromium.org%2Fg%2Fblink-dev%2Fc%2FAAdv838-koo%2Fm
> %2FbJv17voIBAAJdata=04%7C01%7CAndrei.Popov%40microsoft.com%7C47c5
> f995fc7949dc806108d8e25d6a80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
> 0%7C637508238161348087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=eb3SfPDYI
> BMeqtBRlCwTB5U4kc4r9%2FkREnmrHN%2FAegc%3Dreserved=0
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugz
> illa.mozilla.org%2Fshow_bug.cgi%3Fid%3D1496639data=04%7C01%7CAndr
> ei.Popov%40microsoft.com%7C47c5f995fc7949dc806108d8e25d6a80%7C72f988bf
> 86f141af91ab2d7cd011db47%7C1%7C0%7C637508238161348087%7CUnknown%7CTWFp
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3D%7C2000sdata=jQ0%2B%2Bh9q%2BSdHqIpeEyr9M08p8cAD6MG5U9OG4z9ybN
> 4%3Dreserved=0
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweak
> dh.org%2Fdata=04%7C01%7CAndrei.Popov%40microsoft.com%7C47c5f995fc
> 7949dc806108d8e25d6a80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> 7508238161348087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=nyyFho5b73MVWuD
> nV0uBdfZB2sUs4WUHox4q4aI3m9M%3Dreserved=0
> 
> On Mon, Mar 8, 2021 at 12:52 PM Carrick Bartle 
>  wrote:
> > Agreed. I'll change the title to reflect that.
> > 
> > > On Mar 8, 2021, at 7:33 AM, Martin Thomson  wrote:
> > > 
> > > Well overdue.  We should do this.
> > > 
> > > The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match 
> > > the document content.  I only see static or semi-static DH and ECDH key 
> > > exchange being deprecated (in the document as non-ephemeral).
> > > 
> > > ___
> > > TLS mailing list
> > > TLS@ietf.org
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > www.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=04%7C01%7CAndrei.
> > > Popov%40microsoft.com%7C47c5f995fc7949dc806108d8e25d6a80%7C72f988b
> > > f86f141af91ab2d7cd011db47%7C1%7C0%7C637508238161348087%7CUnknown%7
> > > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> > > CJXVCI6Mn0%3D%7C2000sdata=b4N4EYeD9YENeDJ4JDBTtz19UdCoeb1AhJl
> > > MxGrSHmk%3Dreserved=0
> > 
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > w.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=04%7C01%7CAndrei.Popo
> > v%40microsoft.com%7C47c5f995fc7949dc806108d8e25d6a80%7C72f988bf86f14
> > 1af91ab2d7cd011db47%7C1%7C0%7C637508238161348087%7CUnknown%7CTWFpbGZ
> > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > %3D%7C2000sdata=b4N4EYeD9YENeDJ4JDBTtz19UdCoeb1AhJlMxGrSHmk%3D&
> > amp;reserved=0

___
TLS mailing list
TLS@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=04%7C01%7CAndrei.Popov%40microsoft.com%7C47c5f995fc7949dc806108d8e25d6a80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508238161348087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=b4N4EYeD9YENeDJ4JDBTtz19UdCoeb1AhJlMxGrSHmk%3Dreserved=0

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

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

[Martin Thomson]

One thing at a time?

On Tue, Mar 9, 2021, at 05:05, David Benjamin wrote:
> I'd suggest we also deprecate TLS 1.2 TLS_DHE_*, even when ephemeral:
> 
> - The construction is broken. The leak itself in the Raccoon attack 
> comes from TLS 1.2 removing leading zeros. We can't change the meaning 
> of the existing code points, so any fix there would involve dropping 
> them.
> 
> - It lacks group negotiation, which makes it very difficult to migrate 
> away from small groups. At least in the web, it's already no longer 
> supported by most implementations.
> https://groups.google.com/a/chromium.org/g/blink-dev/c/AAdv838-koo/m/bJv17voIBAAJ
> https://bugzilla.mozilla.org/show_bug.cgi?id=1496639
> https://weakdh.org/
> 
> On Mon, Mar 8, 2021 at 12:52 PM Carrick Bartle 
>  wrote:
> > Agreed. I'll change the title to reflect that.
> > 
> > > On Mar 8, 2021, at 7:33 AM, Martin Thomson  wrote:
> > > 
> > > Well overdue.  We should do this.
> > > 
> > > The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match 
> > > the document content.  I only see static or semi-static DH and ECDH key 
> > > exchange being deprecated (in the document as non-ephemeral).
> > > 
> > > ___
> > > TLS mailing list
> > > TLS@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tls
> > 
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls

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

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

[David Benjamin]

I'd suggest we also deprecate TLS 1.2 TLS_DHE_*, even when ephemeral:

- The construction is broken. The leak itself in the Raccoon attack comes
from TLS 1.2 removing leading zeros. We can't change the meaning of the
existing code points, so any fix there would involve dropping them.

- It lacks group negotiation, which makes it very difficult to migrate away
from small groups. At least in the web, it's already no longer supported by
most implementations.
https://groups.google.com/a/chromium.org/g/blink-dev/c/AAdv838-koo/m/bJv17voIBAAJ
https://bugzilla.mozilla.org/show_bug.cgi?id=1496639
https://weakdh.org/

On Mon, Mar 8, 2021 at 12:52 PM Carrick Bartle  wrote:

> Agreed. I'll change the title to reflect that.
>
> > On Mar 8, 2021, at 7:33 AM, Martin Thomson  wrote:
> >
> > Well overdue.  We should do this.
> >
> > The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to
> match the document content.  I only see static or semi-static DH and ECDH
> key exchange being deprecated (in the document as non-ephemeral).
> >
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
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

[TLS] Comments massacred on the mike on draft-friel-tls-eap-dpp-01

[Watson Ladd]

Dear all,

Sorry about my audio quality issues: my laptop is a bit of a potato
and there may have been some coupling from my mike via the
table/directionality not as good as it should be.

My concern is that this protocol depends on things that TLS does not
claim to provide like secrecy of public keys. E.g. if we used ECDSA it
wouldn't work at all. Furthermore its not clear that these big
modifications to the handshake really are the right way vs. a
different key agreement.

IMHO we need an actual formal analysis of this. Just because DPP did
it, doesn't make it good. Even if the TLS handshake analysis shows
that the handshake is secure if the underlying exchange is secure,
it's not clear the underlying handshake is secure.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

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

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

[John Mattsson]

+1 for forbidding more old crap.

Lack of forward secrecy should imply at least NOT RECOMMENDED.

Does it make sense to forbid things for TLS 1.0 and TLS 1.1 when we soon have 
an RFC forbidding use of TLS 1.0 and TLS 1.1?

Cheers,
John


-Original Message-
From: TLS  on behalf of Martin Thomson 

Date: Monday, 8 March 2021 at 16:34
To: "TLS@ietf.org" 
Subject: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

Well overdue.  We should do this.

The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match the 
document content.  I only see static or semi-static DH and ECDH key exchange 
being deprecated (in the document as non-ephemeral).

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

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

Re: [TLS] Comments on draft-friel-tls-eap-dpp-01

[Eric Rescorla]

Taking a step back from the crypto, I'm trying to make sure I
understand the desired security properties. As I understand the
situation:

- the client has a preconfigured key pair (X_c, Y_c)
- the server is anonymous (i.e., doesn't have a valid TLS cert).
- the server is preconfigured with information about each
  client (in this case, Y_c).

And the desired property you are looking for is that:

1. The client authenticates to the server using X_c
2. The client will only connect to servers that know the
   per-client information

Is this correct?


Assuming it is, it seems like we could accomplish this with
less change to TLS. Here is one proposal (warning: not
at all analyzed so may be totally broken).

- Have the client take on the TLS server role, and use RFC 7250 raw
  public keys. This addresses requirement 1.

- Store a separate per-client value K_c (this can be derived from the
  X_c to ease the burden on the client) and use RFC 8773 external PSK
  with cert authentication to inject K_c into the key schedule.

-Ekr

On Mon, Mar 8, 2021 at 7:09 AM Scott Fluhrer (sfluhrer)  wrote:

> Again, last minute reviews…
>
>
>
> It would appear that the exact computations that both the client and the
> server need to perform needs to be explicitly spelled out, as there are
> several possibilities.
>
>
>
> Here is the one I could see that appear to have the security properties
> that you appear to be looking for:
>
>
>
> Variable names:
>
> g – Well known group generator
>
> h – The secret generator that is private to the client and
> the server
>
> z – The secret value known to the client; g^z = h
>
> x – The client’s ephemeral DH private value
>
> y – The server’s ephemeral DH private value:
>
>
>
> Client keyshare:
>
> This is the value g^x
>
>
>
> When the server receives this, he selects y (and retrieves the value h);
> he then transmits (as his keyshare) the value:
>
> h^y
>
> and stirs the value (g^x)^y into his KDF
>
>
>
> When the client receives this (h^y), he computes:
>
> (h^y) ^ (x z^-1)
>
> (where z^-1 is the modular inverse of z modulo the group order), and stirs
> that value into his KDF.
>
>
>
> With this protocol, it appears that the client needs to know not only h,
> but also the value z.  However, this really needs to be spelled out (and
> run past the CFRG to check for subtle issues)
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

Well overdue.  We should do this.

The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match the 
document content.  I only see static or semi-static DH and ECDH key exchange 
being deprecated (in the document as non-ephemeral).

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

[TLS] Comments on draft-friel-tls-eap-dpp-01

[Scott Fluhrer (sfluhrer)]

Again, last minute reviews...

It would appear that the exact computations that both the client and the server 
need to perform needs to be explicitly spelled out, as there are several 
possibilities.

Here is the one I could see that appear to have the security properties that 
you appear to be looking for:

Variable names:
g - Well known group generator
h - The secret generator that is private to the client and the 
server
z - The secret value known to the client; g^z = h
x - The client's ephemeral DH private value
y - The server's ephemeral DH private value:

Client keyshare:
This is the value g^x

When the server receives this, he selects y (and retrieves the value h); he 
then transmits (as his keyshare) the value:
h^y
and stirs the value (g^x)^y into his KDF

When the client receives this (h^y), he computes:
(h^y) ^ (x z^-1)
(where z^-1 is the modular inverse of z modulo the group order), and stirs that 
value into his KDF.

With this protocol, it appears that the client needs to know not only h, but 
also the value z.  However, this really needs to be spelled out (and run past 
the CFRG to check for subtle issues)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Comment on draft-sullivan-tls-opaque-00

[Scott Fluhrer (sfluhrer)]

I am glad that someone in the working group is looking at this.  However, as I 
reviewed this before the wg meeting, I was completely puzzled by this text 
(from section 6.1):

3DH

   C computes K = H(g^y ^ PrivU || PubU ^ x || PubS ^ PrivU || IdU || IdS )
   S computes K = H(g^x ^ PrivS || PubS ^ y || PubU ^ PrivS || IdU || IdS )

Obviously these needs to be the same for an honest client-server pair.  I can't 
see where the above variables are defined in the doc; I would assume that the 
meanings are:


  *   x, y are the private values from the ephemeral DH operation, and are 
randomly selected for each exchange.
  *   PrivU, PubU, PrivS, PubS are static values from the Opaque record.

However, if that's the case, I can't see how that could work; for one, g^y ^ 
PrivU and g^x ^ PrivS would be different values, and so differing values would 
be stirred into the Master Secret.  In addition, I can't see how PubU ^ x 
(where PubU and x would appear to be client specific) could be expected to be 
the same as PubS ^ y (as both those values would be server specific).

What am I missing?
___
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

[Salz, Rich]

Peter can certainly speak for himself :) but I don't think it's never.

I think it's also the kind of thing where someone does things manually, and 
then goes out into the field for a service operation.  So not just never, but 
also situations where automation isn't appropriate and installing software bits 
is like maintaining hardware blobs.

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

[TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

[The IESG]

The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Connection Identifiers for DTLS 1.2'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2021-03-28. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document specifies the Connection ID (CID) construct for the
   Datagram Transport Layer Security (DTLS) protocol version 1.2.

   A CID is an identifier carried in the record layer header that gives
   the recipient additional information for selecting the appropriate
   security association.  In "classical" DTLS, selecting a security
   association of an incoming DTLS record is accomplished with the help
   of the 5-tuple.  If the source IP address and/or source port changes
   during the lifetime of an ongoing DTLS session then the receiver will
   be unable to locate the correct security context.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/



No IPR declarations have been submitted directly on this I-D.





___
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

[Fries, Steffen]

Hi,

First of all thanks for all the discussion on that question, which is great 
input also to the discussion in IEC. 

> From: TLS  On Behalf Of Hannes Tschofenig
> I think it is useful to start with the problem description.
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. If the certificate is put onto a CRL , the 
RP would realize this during the next complete handshake and tear down the 
connection. An alternative of this could indeed be to utilize an external 
trigger like whenever the CRL is refreshed (which should happen every 24 
hours), the certificates of ongoing connections are validated regarding their 
status. As this is independent of TLS, it would work also with TLS 1.3.

By comparing, what has been used in TLS 1.2 we simply stumbled about the fact 
that the trigger to perform the revocation check is no longer available for 
both sides, client and server. As said, the client could be authenticated using 
post authentication but not the server. This would mean to solve the problem of 
identifying a revoked certificate in an ongoing session could be done 
externally of TLS but the result would be fed back to TLS, if a connection 
needs to be closed due to a revoked certificate. 

Regards
Steffen



> 
> It seems that you are concerned that there is a possibility for leakage or
> compromise of keying material during the lifetime of the session.
> What could happen?
> 
> * Long-term keys*,
> * Some keys used in the key hierarchy,
> * keys used for protecting the application traffic
> 
> Additionally, you could also consider the case that the trust anchor store 
> gets
> compromised.
> 
> In any case, you seem to be concerned about the leakage of long-term keys (at
> least that's what I get from the email thread).
> 
> If your long-term keys got compromised then you have a serious problem. Re-
> running even the full handshake will not indicate problem. It will just work 
> fine.
> 
> You will somehow have to find out that these long-term keys have been leaked,
> which will not be easy. Then, you need to isolate the endpoints using those
> compromised keys and reprovision new keys to them. You might want to
> terminate ongoing connections as well. Since you will often not know what
> exactly has been compromised (at least not quickly enough), you might need to
> take a range of steps to re-set it to a known good state (such as doing a
> firmware update, in case of an IoT device).
> 
> Many of these aspects are, however, outside the scope of TLS itself.
> 
> Could you elaborate on the threats you are trying to address?
> 
> Ciao
> Hannes
> 
> *: Often a device has more than one long-term key pair (used for different
> purposes). Without further complicating things, the impact depend a bit on
> which keys have been leaked.
> 
> -Original Message-
> From: TLS  On Behalf Of Nico Williams
> Sent: Friday, March 5, 2021 8:35 PM
> To: John Mattsson 
> Cc: tls@ietf.org
> Subject: Re: [TLS] Question to TLS 1.3 and certificate revocation checks in 
> long
> lasting connections
> 
> On Fri, Mar 05, 2021 at 06:42:40PM +, John Mattsson wrote:
> > >While renegotiation will never be re-added, there is post-handshake
> > >authentication (RFC 8446, section 4.6.2), and while that is currently
> > >about authenticating the _client_ to the server, it should be trivial
> > >to extend the protocol to support re-authenticating the server to the
> > >client as well.
> >
> > I think the current Post-Handshake authentication is not really
> > suitable for long-term connections. It assures that the other party is
> > still alive but it does not shut out any other third parties with
> > access to application_traffic_secret_N. Such parties may have gotten
> > the key with or without collaboration with one of the nodes.
> 
> We assume local security, so the only way the TLS keys could have leaked to
> third parties is if either a) the local security assumption fails, in which 
> case you
> have bigger problems, or b) the cryptographic security of TLS itself failed, 
> in
> which case you have bigger problems, or c) you're exceeding usage limits on a
> symmetric cipher.
> 
> Changing session keys wouldn't help you in cases (a) or (b).
> 
> I think the only interesting case is (c).  If you're using a 128-bit block 
> cipher,
> you're not in case (c) as you'd have to transfer something like 2PB 

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

[Olle E. Johansson]

> On 7 Mar 2021, at 17:25, Benjamin Kaduk  
> wrote:
> 
> On Sun, Mar 07, 2021 at 12:15:24PM +, Graham Bartlett wrote:
>> 
>> I would imagine that the implementation would pull the session down once
>> the certificate expires, so the session only lasts for the lifetime of the
>> certificate.
> 
> Many people expect this, but I don't think there's universal agreement
> that it's the right behavior.  The divide between authentication and
> authorization that (IIRC) Viktor called out is relevant here -- the
> initial key exchange and, to large extent, authentication, do not suddenly
> become invalid upon credential expiry, but any authorization derived from
> the credential might.  So it seems that whether the session should terminate
> at the certificate expiry time is rather dependent on what the session is
> being used for.

Maybe there’s a need for a BCP here. It is unclear to me how to apply these
discussions to SIP and we have a few points worth noting from this dicussion.

- Describe the dependencies in Benjamins statement above and how
  they apply to protocols
- Open a new session before deciding to close the old one
- Application timers to cert expiry

Seems like something for UTA to me.

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