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

[Owen Friel (ofriel)]

From: TLS  On Behalf Of Eric Rescorla
Sent: 09 March 2021 06:27
To: Dan Harkins 
Cc:  
Subject: Re: [TLS] Comments on draft-friel-tls-eap-dpp-01



On Mon, Mar 8, 2021 at 1:18 PM Dan Harkins 
mailto:dhark...@lounge.org>> 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).

[ofriel]Its not true that the server does not have a valid TLS cert, the EAP 
server will have a cert but the client will have no way of verifying it. Its 
more https://tools.ietf.org/html/rfc8446#appendix-C.5.


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

[ofriel] Another requirement is that the full public key Y_c is not transmitted 
as part of TLS handshake from client to server. We cannot not use RFC 7250 as 
is. Instead, something like the Known Certificates proposal in cTLS 
https://tools.ietf.org/html/draft-ietf-tls-ctls-01#section-5.1.3 would work.

Something like this could work:

Setup:

Client has X_c, Y_c
Server is provisioned with Y_c (the bootstrap RPK)

Both sides could derive (using some suitable hashing algorithm):

keyID = H1(Y_c)
PSK = H2(Y_c)

Server keeps a map of keyID to Y_c.

keyID could be common or unique for the PSK and RPK.

C->S: Client sends the keyID for the derived PSK

ClientHello
+tls_cert_with_extern_psk
+pre_shared_key identity=keyID

S->C: Server looks up the Y_c, derives PSK, and injects into key_schedule. 
Server sends its PKI Certificate/CertificateVerify which client ignores. Server 
requests client cert so that client can prove it knows X_c.

ServerHello
+pre_shared_key selected_identity=keyID
{EncryptedExtensions}
{CertificateRequest}
{Certificate}
{CertificateVerify}
{Finished}

C->S: Ignores server Certificate/CertificateVerify. If handshake reaches here, 
at this stage, server has proven knowledge of Y_c via derived PSK.

{Certificate, cert_data does not include RPK, but instead keyID as per cTLS}
{CertificateVerify}
{Finished}

Server verifies Finished. At this stage, client has proven knowledge of X_c.

I believe this meets the requirements that:
- server proves knowledge of Y_c
- client proves knowledge of X_c
- Y_c is not send over the wire in cleartext
- reuse existing RFCs, aligns better with existing TLS flows, no new extensions 
(well we need to do something for Certificate including keyID)

-Ekr

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

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

[Owen Friel (ofriel)]

From: TLS  On Behalf Of Joseph Salowey
Sent: 09 March 2021 23:47
To: Dan Harkins 
Cc:  
Subject: Re: [TLS] Comments on draft-friel-tls-eap-dpp-01



On Mon, Mar 8, 2021 at 1:17 PM Dan Harkins 
mailto:dhark...@lounge.org>> 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.
[Joe] Technically, I think it would be possible for the supplicant to take on 
the TLS server role and the server the TLS client role.  This would be counter 
to the way all TLS based EAP protocols work today, but there is nothing 
fundamental to EAP that prevents it.
[ofriel] This would be a huge change for EAP, require a lot of standards work, 
and be massive task to get deployed across the EAP installed base. As you say, 
it is counter to everything EAP today, and it doesn’t seem practical.

- 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) 
mailto:40cisco@dmarc.ietf.org>> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Tue, Mar 9, 2021 at 1:05 PM Viktor Dukhovni  wrote:
>
> 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.

Depreciation is how you get the laggards to replace things.
Depreciation leads, not tails, replacement. Because we depreciated
RC4, PCI stopped being silly about mandating its uses. Had we not done
this, they would have continued as is.

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

This was already done via the UTA working group.

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

That is depreciation.

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

There is no protocol police. To the extent that industries want to
ensure that systems are secure, they have to ensure updates for the
life of the system. I think it's reasonable to require implementation
and deployment of 12 year old standards.

Sincerely,
Watson Ladd

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



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

[Brian Smith]

Carrick Bartle  wrote:

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

PFS isn't all-or-nothing. I do think each key should be used when
practical, although I don't know why it would be bad to reuse a key for a
very short period of time. E.g. if one has a key, and as soon as it is used
once, asynchronously kicks off the generation of its replacement, then
using that key until the replacement has been generated seems OK to me.
Things get more problematic the longer/more the key is reused.

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

RSA is on-topic because deprecating DHE cipher suites quite directly leads
to more use of RSA key exchange. There's already evidence of this from
Firefox, where they had to enable more RSA key exchange cipher suites
immediately after disabling the DHE cipher suites.

It is true that RSA key exchange is widely used; the purpose of deprecating
it is to put political pressure on implementers to make it less widely
used. That's the whole point of these deprecation RFCs.

RSA is the worst key exchange mechanism in TLS w.r.t. to PFS, which is the
reason the paper cites for avoiding ECDH key reuse for ECDHE cipher suites.
Why is it horrible to reuse an ECDH key a few times but it's OK to reuse an
RSA key millions of times?

Is RSA "broken enough"? That goes back to my point that while in theory one
could do a perfect job of protecting their server's private keys, in
practice many will fail at it. That's why we mandated PFS cipher suites in
TLS 1.3 and in HTTP/2, to reduce the harm in losing control of the private
key.

The draft makes the good point that it would be hard to secure a DH(E)
implementation against timing attacks. But, RSA is the *hardest* to secure
key exchange mechanism w.r.t. timing attacks. Not only does it require very
careful coding within the core crypto library, but it also requires very
error-prone and non-obvious logic within the TLS implementation. Raccoon
mitigations wouldn't require that. (For the record, the difficulty of
mitigating the timing side channels mentioned in the Raccoon paper seems to
be quite overstated. We could all do it if we wanted to.)

Anyway, to be clear, I'm not advocating for DHE cipher suites in TLS 1.2.
I'm advocating against encouraging more use of RSA cipher suites, and I'm
against encouraging the continued use of TLS 1.2 in general. Deprecating
(EC)DH(E) key exchange without deprecating RSA has the rhetorical effect of
saying RSA key exchange is not as dangerous as (EC)DH(E); I don't think
that's true at all. Things need to upgrade to TLS 1.3 and things need to
drop RSA key exchange in favor of forward secret key exchange.

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

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

[Carrick Bartle]

Oh, never mind, presumably you're referring to the proposal in this thread.


> On Mar 9, 2021, at 4:47 PM, Carrick Bartle 
>  wrote:
> 
>> The proposal on the table is to deprecate FFDHE. 
> 
> Sorry, the title of the document is incorrect and will be changed. The actual 
> proposal is not to deprecate FFDHE but to deprecate FFDH and prohibit key 
> reuse for FFDHE.
> 
> 
>> On Mar 9, 2021, at 1:04 PM, Viktor Dukhovni  wrote:
>> 
>> 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
> 
> ___
> 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

[Carrick Bartle]

> The proposal on the table is to deprecate FFDHE. 

Sorry, the title of the document is incorrect and will be changed. The actual 
proposal is not to deprecate FFDHE but to deprecate FFDH and prohibit key reuse 
for FFDHE.


> On Mar 9, 2021, at 1:04 PM, Viktor Dukhovni  wrote:
> 
> 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

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

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

[Brian Smith]

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

Thanks. I forgot about the CBC cipher suites. What I mean to say is that it
doesn't support any cipher suites with AEAD ciphers and PFS except the DHE
ones. The result was that Firefox had to choose between enabling the
CBC-SHA2 cipher suites or enabling RSA + AEAD for compatibility with it,
and they chose to latter; see
https://bugzilla.mozilla.org/show_bug.cgi?id=1638369.

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

Re: [TLS] implementing ESNI/ECH draft-09

[Rob Sayre]

On Sun, Feb 28, 2021 at 9:35 AM Stephen Farrell 
wrote:

>
> - This is *much* harder to implement compared to ESNI as
>it interacts with the rest of the TLS stack/library in
>many more ways. It should be an explicit goal to reduce
>that complexity IMO and not increase it further.
>

I agree that ECH is much more difficult to implement*, but I think the
changes required are all improvements.

Some of the complexity stems from accommodating clear-text ClientHello as
well as ECH.

thanks,
Rob

* Except in the sense that all of the crypto is delegated correctly
now--happy to let lower-level libraries do HPKE etc.
___
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] 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?
> 
> 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?

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



> On Mar 8, 2021, at 7:57 PM, Viktor Dukhovni  wrote:
> 
> 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 

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

[Joseph Salowey]

On Mon, Mar 8, 2021 at 1:17 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.
>
> [Joe] Technically, I think it would be possible for the supplicant to take
on the TLS server role and the server the TLS client role.  This would be
counter to the way all TLS based EAP protocols work today, but there is
nothing fundamental to EAP that prevents it.


> - 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)  40cisco@dmarc.ietf.org> 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 listTLS@ietf.orghttps://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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls