Re: [TLS] New cipher suites for SRP

[Dan Harkins]

On Mon, June 29, 2015 4:31 am, Hubert Kario wrote:
> On Friday 26 June 2015 20:39:24 Geoffrey Keating wrote:
>> Dave Garrett  writes:
>> > On Friday, June 26, 2015 07:48:01 pm Attila Molnar wrote:
>> > > Currently SRP cannot be used with newer crypto primitives such as
>> > > ciphers in AEAD mode or SHA-2 due to the lack of cipher suites
>> enabling
>> > > these. There's only 3DES and AES-CBC with SHA-1.
>> > >
>> > > Would there be support for expanding the SRP cipher suites?
>> >
>> > I don't think it's a good idea to add new SRP cipher suites.
>> >
>> > Instead, I think redefining SRP as an extension to PSK would make more
>> > sense. Use (EC)DHE_PSK cipher suites with an updated SRP extension to
>> get
>> > similar capabilities. This would make updating SRP to use newer crypto
>> > much easier, as modern PSK cipher suites are easier to get
>> standardized.
>> > The current SRP spec actually already appears to rely on PSK identity
>> > alert codes.
>> The problem with that is that there are surely many use cases where
>> you're willing to do SRP, or if no SRP you can do a regular ECDHE and
>> prompt for the username/password, but PSK is too insecure.
>>
>> I've been thinking an improved SRP would be useful.  It should:
>>
>> - Specify Modern cipher and hash algorithms as mentioned above
>>
>> - Replace the existing SHA1+seed with a password whitening function
>>   like PBKDF2, so that in the event of a compromised server cracking
>>   the password is harder, and also making online password guessing
>>   attacks (sending lots of username+password pairs to the server) more
>>   expensive*
>>
>> - Deprecate the 1024-bit and the 1536-bit group, and the previous SRP
>>   ciphersuites; and say that these should only be chosen if the server
>>   has a legacy verifier for a particular username which requires
>>   them.
>
> +1, provided we do two more things:
>
>  - Change the negotiation so that user name is not exchanged in the clear
>  - Change key exchange to do PFS

  TLS-pwd already supports both of these. It also supports ECC too,
which is problematic with the current SRP protocol.

  regards,

  Dan.



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

Re: [TLS] ECDH_anon

[Dan Harkins]

On Wed, January 27, 2016 9:47 am, Martin Thomson wrote:
> On 28 January 2016 at 02:17, Blumenthal, Uri - 0553 - MITLL
>  wrote:
>> Anon  ‎!= Ephemeral, despite some similarities.
>
>>From a protocol perspective, they are the same.  The distinction at
> the protocol level between ECDH_RSA (for example) and ECDH_anon is
> that ECDH_anon requires a ServerKeyShare message in the same way that
> ECDHE_RSA does.

  So? A static-static, static-ephemeral, and ephemeral-ephemeral
all look the same from a protocol perspective too but they are
very different and have very different properties.

  Dan.

> I agree that Nikos' point is a good one, but we've implementations of
> ECDHE_ that provide a stable value for their ephemeral key
> (unfortunately, that's the default mode in NSS).
>
> ___
> 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] ECDH_anon

[Dan Harkins]

On Sun, January 31, 2016 10:00 pm, Martin Thomson wrote:
> On 1 February 2016 at 16:56, Dan Harkins  wrote:
>>>>From a protocol perspective, they are the same.  The distinction at
>>> the protocol level between ECDH_RSA (for example) and ECDH_anon is
>>> that ECDH_anon requires a ServerKeyShare message in the same way that
>>> ECDHE_RSA does.
>>
>>   So? A static-static, static-ephemeral, and ephemeral-ephemeral
>> all look the same from a protocol perspective too but they are
>> very different and have very different properties.
>
> If a tree falls in the forest and no one deletes the private key, is
> it static or ephemeral.

  If you never use it again then its compromise would only expose
that 1 exchange so I'd say it's ephemeral. If you reuse it then it
becomes static.

  But if this problem is because we have code that is not deleting
the private keys for the ECDH_anon exchange then I'd say the pull
request should be with that codebase to fix that problem.

  Dan.



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

Re: [TLS] JPAKE

[Dan Harkins]

On Tue, February 16, 2016 8:34 pm, Tony Arcieri wrote:
> On Mon, Feb 15, 2016 at 4:33 PM, Robert Cragie
> 
> wrote:
>
>> In Thread, it is used for local device authentication and authorisation.
>> These use cases clearly benefit from a PAKE, i.e. getting deriving a
>> shared
>> cryptographic from a weaker shared password.
>>
>
> The better way to solve this problem is a device-specific "keychain",
> which
> possibly loops in some sort of secure enclave for decrypting secrets, and
> can authorize secret decryption based on the requesting app, derive a
> strong master secret from a weak password/pin (possibly using a PUF for
> anti-tamper). This is becoming a standard feature of the OSes on most
> devices humans actually physically interact with, e.g. most smartphones,
> tablets, and any OS you'd find on a laptop.

  What?!? How is that "better"? Having a "keychain" that loops in some
vague "secure enclave" that makes authorization decisions based on some
app deriving a "strong master secret from a weak password/pin" sounds
complicated, has more moving parts and more possibility of things
going wrong. If there's some password/pin involved then the protocol
should not depend on whether it's weak or not. Period. That means PAKE.

  Regarding JPAKE, it's support in OpenSSL is in the apps directory,
not the ssl directory. That is, there is no TLS ciphersuite that
supports it and that means no app can use it (except through system()
calls or some such ugliness). TLS-pwd is defined as a TLS ciphersuite
though.

  Dan.

> If you have this sort of keychain system, you can provision secrets
> on-the-fly, e.g. origin-bound certificates. Now you don't need PAKE.
> ___
> 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] SRP ?

[Dan Harkins]

  Hi,

On Wed, February 24, 2016 1:59 pm, Rick van Rein wrote:
> Hi,
>
>> Although the lack of modern cipher-suites for SRP makes it not very
>> attractive these days.
>>
> Does anyone know if work on something like "ECSRP" is going on, anywhere?
>
> We've recently worked on getting it working with PKCS #11,
>
> https://github.com/arpa2/srp-pkcs11
> https://github.com/arpa2/srp-pkcs11/blob/rfc5054_compat/doc/design/srp-pkcs11.pdf
>
> It could be interesting to see if this translates to the Elliptic Curve
> arena.
>
> I heard rumours of alternatives being weighed against one another, but
> failed to find anything concrete.  Links are quite welcome!

  Well there's TLS-PWD. Works just fine with ECC. Also provides
for protection of the client username from passive attack.

https://tools.ietf.org/html/draft-ietf-tls-pwd-07

Thanks for reminding me to update that draft :-)

  Dan.

> -Rick
>
> ___
> 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] SRP ?

[Dan Harkins]

On Thu, February 25, 2016 11:41 pm, Watson Ladd wrote:
> On Thu, Feb 25, 2016 at 11:33 PM, Dan Harkins  wrote:
>>
>>   Hi,
>>
>> On Wed, February 24, 2016 1:59 pm, Rick van Rein wrote:
>>> Hi,
>>>
>>>> Although the lack of modern cipher-suites for SRP makes it not very
>>>> attractive these days.
>>>>
>>> Does anyone know if work on something like "ECSRP" is going on,
>>> anywhere?
>>>
>>> We've recently worked on getting it working with PKCS #11,
>>>
>>> https://github.com/arpa2/srp-pkcs11
>>> https://github.com/arpa2/srp-pkcs11/blob/rfc5054_compat/doc/design/srp-pkcs11.pdf
>>>
>>> It could be interesting to see if this translates to the Elliptic Curve
>>> arena.
>>>
>>> I heard rumours of alternatives being weighed against one another, but
>>> failed to find anything concrete.  Links are quite welcome!
>>
>>   Well there's TLS-PWD. Works just fine with ECC. Also provides
>> for protection of the client username from passive attack.
>>
>> https://tools.ietf.org/html/draft-ietf-tls-pwd-07
>
> As well as my SPAKE2 draft, which can fit in TLS easily. The real
> problem here is that there is no reason not to use certificates in a
> lot of cases.

  Well if you're using a browser I'd agree with you. But when TLS
is used to protect non-browser traffic there are plenty of cases
where you won't have an implicit trust anchor database or you're
going to some server administered by someone who most likely only
has a self-signed cert (Let's Encrypt makes it easy to get a cert
for a web server but, again, that's kind of browser-centric).

  I address the case for certificate-less authentication in section
1.1 of the TLS-PWD I-D.

  regards,

  Dan.

>>
>> Thanks for reminding me to update that draft :-)
>>
>>   Dan.
>>
>>> -Rick
>>>
>>> ___
>>> 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
>
>
>
> --
> "Man is born free, but everywhere he is in chains".
> --Rousseau.
>


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

On 3/10/21 4:12 AM, Eric Rescorla wrote:



On Tue, Mar 9, 2021 at 11:43 PM Owen Friel (ofriel) <mailto:ofr...@cisco.com>> wrote:


*From:*TLS mailto:tls-boun...@ietf.org>>
*On Behalf Of *Eric Rescorla
*Sent:* 09 March 2021 06:27
*To:* Dan Harkins mailto:dhark...@lounge.org>>
*Cc:* mailto:tls@ietf.org>> mailto:tls@ietf.org>>
*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.


Is that a primary requirement or a derived requirement?


  I'm not sure of the distinction you're making here. But let me address
a misconception mentioned earlier (not by you, but mentioned nonetheless)
to hopefully clear this up:

In DPP the public key is not secret, but the knowledge of the public key is
supposed to be restricted to those who are legitimate owners of the thing.
The more gratuitously a thing distributes it's public key the less assurance
the thing will get that the holder of it's public key is legit. Consider 
that

the Oprah level of bootstrapping-- "you get my public key!, and you get my
public key!, and you get my public key!"-- would end up being TOFU since the
thing doesn't actually know who it ended up talking to (everyone could
theoretically have gotten the public key), but restriction of the thing's
public key to someone who purchased the thing-- consider transfer of data
in the cloud upon 

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Dan Harkins]

  Hi,

  I approve of this transition to standards track and I am implementing
this as well.

  regards,

  Dan.

On 11/29/23 7:51 AM, Joseph Salowey wrote:
RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with 
an External Pre-Shared Key) was originally published as experimental 
due to lack of implementations. As part of implementation work for the 
EMU workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there 
is ongoing implementation work. Since the implementation status of RFC 
8773 is changing, this is a consensus call to move RFC 8773 to 
standards track as reflected in 
[RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). 
This will also help avoid downref for the EMU draft.  Please indicate 
if you approve of or object to this transition to standards track 
status by December 15, 2023.


Thanks,

Joe, Sean, and Deirdre

___
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] Call for consensus: Removing 0-RTT client auth

[Dan Harkins]

  Hi Sean & Joe,

On Tue, March 29, 2016 5:59 am, Sean Turner wrote:
> All,
>
> To make sure we’ve got a clear way forward coming out of our BA
> sessions, we need to make sure there’s consensus on a couple of
> outstanding issues.  So...
>
> It seems that there is a clear consensus not to support 0-RTT client
> authentication in TLS 1.3 at this time.  If you think 0-RTT client
> authentication needs to be supported please indicate so now and provide
> your rationale.

  I don't think it needs to be supported and would be happy if
it was removed. It's a dangerous and flawed feature. My concern
is that if (which I fear is pronounced "when") an exploit is found
it might be easy to remove in a browser update but there's gonna
be some large TLS concentrator vendor that'll have a helluva time
getting its deployed boxes patched and it'll be ugly.

  The rationale for this-- to get an ad to me just that much faster
(an ad, I note, that I sure hope my ad blocking software will prevent
me from seeing), and that the people who want to do this know what
they're doing so it'll all be fine (which is not reassuring in the
least)-- just does not justify the risk.

  regards,

  Dan.


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

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Dan Harkins]

  Hi Sean,

  In general I support this but

  A stable, publicly available document is basically an RFC.
So when the TLS WG says no that means asking an AD to sponsor
or putting it into the Independent Stream process. So what it
looks like you're doing is punting this problem into the lap of
whoever is gonna be the Independent Stream Editor for this stuff
because he or she will start getting a steady stream of requests
for publication of documents  describing a fabulous new TLS
ciphersuite after the ADs tell everyone to "pound sand".

  I wonder if you have thought this through or prepped the
stuckee?

  regards,

  Dan.

On Tue, March 29, 2016 6:53 pm, Sean Turner wrote:
> Hi!
>
> In Yokohama, we discussed changing the IANA registry assignment rules for
> cipher suites to allow anyone with a stable, publicly available, peer
> reviewed reference document to request and get a code point and to add an
> “IETF Recommended” column to the registry.  This change is motivated
> by the large # of requests received for code points [0], the need to alter
> the incorrect perception that getting a code point somehow legitimizes the
> suite/algorithm, and to help implementers out.  We need to determine
> whether we have consensus on this plan, which follows:
>
> 1. The IANA registry rules for the TLS cipher suite registry [1] will be
> changed to specification required.
>
> 2. A new “IETF Recommended” column will be added with two values:
> “Y” or “N”.  Y and N have the following meaning:
>
>  Cipher suites marked with a “Y” the IETF has consensus on
>  and are reasonably expected to be supported by widely
>  used implementations such as open-source libraries.  The
>  IETF takes no position on the cipher suites marked with an
>  “N”.  Not IETF recommended does not necessarily (but can)
>  mean that the ciphers are not cryptographically sound (i.e.,
>  are bad).  Cipher suites can be recategorized from N to Y
>  (e.g., Curve448) and vice versa.
>
> 3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that
> matches the above so that the same information is available to those who
> don’t read the IANA considerations section of the RFC.
>
> Please indicate whether or not you could support this plan.
>
> Thanks,
>
> J&S
>
> [0] In the last year, the chairs have received requests for:
>
> PSK: https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/
> AES-OCB: https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt
> Kcipher2: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/
> dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/
> NTRU:  http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt
> JPAKE: not sure they got around to publishing a draft.
>
> [1]
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
>
>
> ___
> 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] call for consensus: changes to IANA registry rules for cipher suites

[Dan Harkins]

On Sun, April 3, 2016 7:24 pm, Salz, Rich wrote:
>
>>   A stable, publicly available document is basically an RFC.
>
> Not always; ISO et al.

  That's why I said "basically"; it's a qualifier.

  But keep in mind what kind of stable, publicly available
document needs to be published: a description not of the algorithm
but of how that algorithm get crammed into the TLS exchange.
(For example, not RFC 7539 which describes chacha20+poly1305 as
a glot but draft-ietf-tls-chacha20-poly1305 which says how to cram
that glot into TLS). So even if some one/company was able to get a
National Body to push in in ISO I doubt ISO would entertain
documents whose content was "cram alg described elsewhere into
TLS like this" with changes to ServerKeyExchange etc.

  Dan.


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

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Dan Harkins]

On Thu, March 31, 2016 10:51 am, Stephen Farrell wrote:
>
> If smaller devices don't use algorithms that can be used to talk to
> random servers on the Internet, then they are choosing to not try to
> get interop. That seems like a shame to me, unless there's a really
> good reason and IMO, mostly there isn't, at the ciphersuite level. I
> would hope we all won't make the GCM/CCM mistake again for example
> (that "we" being roughly some combination of IETF/IEEE folks).

  That's because you incorrectly define "interop" as talking to
random servers on the Internet. This browser-centric mode of thinking
causes you to reject cipher suites that the browser/webserver
community does not have any interest in.

  There are use cases where some app doesn't want to talk to random
servers on the Internet. It wants to talk to a set of specific servers
providing a specific stream of information unique to the app-- think
of some network monitoring or RF-quality app that provides sensing
data to servers and also sucks down neighbor air quality information
as it roams around. There are IoT use cases where devices just want
to talk to each other, not random servers on the Internet.

  The browser community wants 0-RTT; I don't give a damn about 0-RTT.
I want a PAKE (specifically TLS-pwd); the browser community doesn't
give a damn about PAKEs. We are both right. Because we have different
requirements.

> So I think the proposed change here, if it leads to fewer but more
> ubiquitously deployed ciphersuites, will help smaller devices. And I
> do think the IETF recommended column might lead us some way in that
> direction.

  Fewer is better... for one set of requirements, there's no reason to
have umpteen (> 2) ways of meeting the requirements. But to approach
this issue as if there is only one set of requirements (being able
to talk to random web servers on the Internet) is to cram a multiplicity
of differently shaped pegs into the proverbial round hole.

  regards,

  Dan.


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

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Dan Harkins]

On Mon, April 4, 2016 7:17 am, Watson Ladd wrote:
> On Mon, Apr 4, 2016 at 7:05 AM, Dan Harkins  wrote:
>>
>>
>> On Thu, March 31, 2016 10:51 am, Stephen Farrell wrote:
>>>
>>> If smaller devices don't use algorithms that can be used to talk to
>>> random servers on the Internet, then they are choosing to not try to
>>> get interop. That seems like a shame to me, unless there's a really
>>> good reason and IMO, mostly there isn't, at the ciphersuite level. I
>>> would hope we all won't make the GCM/CCM mistake again for example
>>> (that "we" being roughly some combination of IETF/IEEE folks).
>>
>>   That's because you incorrectly define "interop" as talking to
>> random servers on the Internet. This browser-centric mode of thinking
>> causes you to reject cipher suites that the browser/webserver
>> community does not have any interest in.
>>
>>   There are use cases where some app doesn't want to talk to random
>> servers on the Internet. It wants to talk to a set of specific servers
>> providing a specific stream of information unique to the app-- think
>> of some network monitoring or RF-quality app that provides sensing
>> data to servers and also sucks down neighbor air quality information
>> as it roams around. There are IoT use cases where devices just want
>> to talk to each other, not random servers on the Internet.
>>
>>   The browser community wants 0-RTT; I don't give a damn about 0-RTT.
>> I want a PAKE (specifically TLS-pwd); the browser community doesn't
>> give a damn about PAKEs. We are both right. Because we have different
>> requirements.
>
> Why can't embedded devices use certificates?

  Code bloat for a one-off enrollment protocol, no way to authenticate
to obtain the certificate, and the continued lack of that Global PKI
that was supposed to take care of everything and that is currently 20
years late in being delivered.

  Actually, that's not quite right. Some do use certificates...wrongly.
Usually what happens is the server generates a self-signed certificate
and the apps are given some "username" and "password" and the app
ignores the unauthenticated nature of the TLS connection and sends
the u/p credential on through.

  Dan.


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

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Dan Harkins]

On Mon, April 4, 2016 8:50 am, Phil Lello wrote:
> On Mon, Apr 4, 2016 at 3:36 PM, Dan Harkins  wrote:
>
>>
>> Usually what happens is the server generates a self-signed certificate
>> and the apps are given some "username" and "password" and the app
>> ignores the unauthenticated nature of the TLS connection and sends
>> the u/p credential on through.
>
> Isn't this use case more of an argument for an updated auth-digest to use
> something better than MD5? I'm not convinced MITM is a real concern for a
> typical IoT environment (however that's defined - I'm assuming http in a
> domestic environment).

  First of all, what makes you think it's MD5 digest and not just
plaintext? And updated by whom? These are ad hoc constructions done
because the alternative is too onerous.

  As someone who has stolen wi-fi from the apt next door that was
protected by a PSK I would say that doing a dictionary attack in
a "domestic environment" is entirely plausible. If I have to do a
soft AP advertising the neighbor's SSID in order to lure a set-top
box or thermostat or whatever to connect to me then that's a very
low bar.

  regard,

  Dan.



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

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Dan Harkins]

On Mon, April 4, 2016 10:46 am, Phil Lello wrote:
>>
>> >> Usually what happens is the server generates a self-signed
>> certificate
>> >> and the apps are given some "username" and "password" and the app
>> >> ignores the unauthenticated nature of the TLS connection and sends
>> >> the u/p credential on through.
>> >
>> > Isn't this use case more of an argument for an updated auth-digest to
>> use
>> > something better than MD5? I'm not convinced MITM is a real concern
>> for a
>> > typical IoT environment (however that's defined - I'm assuming http in
>> a
>> > domestic environment).
>>
>>   First of all, what makes you think it's MD5 digest and not just
>> plaintext? And updated by whom? These are ad hoc constructions done
>> because the alternative is too onerous.
>>
>
> I didn't say that. I was suggesting using a standard HTTP digest mechanism
> rather than sending a plaintext username/password. The IETF has already
> updated HTTP digest, so there's no work.
>
>>
>>   As someone who has stolen wi-fi from the apt next door that was
>> protected by a PSK I would say that doing a dictionary attack in
>> a "domestic environment" is entirely plausible. If I have to do a
>> soft AP advertising the neighbor's SSID in order to lure a set-top
>> box or thermostat or whatever to connect to me then that's a very
>> low bar.
>>
>
> Whilst you have my sympathy, I don't see how that's relevant; a dictionary
> attack can be used just as easily against a TLS protected resource.
> Securing the WiFi configuration so that devices connect to the correct one
> is not a TLS issue.

  I'm not asking for sympathy. I'm pointing out that your proposal
does not work.

  Mentioning the ease at which one can launch a dictionary attack
(regardless of the protocol) is relevant because you're proposing to
use a technique that is susceptible to dictionary attack (presumably,
but not necessarily, after misusing a certificate). As I mentioned, to
support this kind of use case I favor using a TLS cipher suite that
supports a PAKE  (draft-ietf-tls-pwd-07, for example). Using such a
cipher suite would mean that a dictionary attack cannot "be used just
as easily against a TLS protected resource."

  regards,

  Dan.


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

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Dan Harkins]

On Tue, April 5, 2016 7:42 am, Adam Langley wrote:
> On Tue, Apr 5, 2016 at 4:55 PM, Peter Gutmann 
> wrote:
>> How hard can it be to implement TLS-PSK?  I did it in a few hours in my
>> crypto
>> library.
>
> This is getting off topic (which is my fault) but, for us, it wouldn't
> be "just" implementing PSK.
>
> We would need to evangelise it sufficiently with enough vendors to
> make sure that it would be used and that we were building the right
> thing. (The solution might well not be just using PSK). Then we need
> to implement it and get the UI right, try and get other browsers to
> implement it, write specs, write test suites, write sample code for
> all the vendors, deal with the resulting bugs in implementations and
> many smaller things besides.
>
> That's not to say that we wouldn't be willing to put the effort in,
> but the demand hasn't been evinced yet.

  Don't bother. It's unlikely to be used in a browser. This just
underscores the point I was making that people use TLS differently
for different things and the requirements are not the same. Just as
it doesn't make sense to force a browser to implement a PSK (or PAKE)
cipher suite, it doesn't make sense to force some device with a
limited UI that has no interest in accessing random web servers to
use a public key.

  regards,

  Dan.


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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Dan Harkins]

  Hello,

On Mon, June 13, 2016 12:00 pm, Joseph Salowey wrote:
> For background please see [1].
>
> Please respond to this message indicating which of the following options
> you prefer by Monday June, 20, 2016
>
> 1. Use the same key for handshake and application traffic (as in the
> current draft-13)
>
> or
>
> 2. Restore a public content type and different keys

  I prefer (1).

  Dan.


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

Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

[Dan Harkins]

  I'm glad I have to opportunity to make you happy Sean :-)

On Mon, July 11, 2016 7:40 am, Sean Turner wrote:
> I think I can take this bit:
>
> On Jul 10, 2016, at 06:51, Peter Dettman 
> wrote:
>>
>> I'm also curious whether there is a precedent in other RFCs for an
>> explicit minimum curve bits, or perhaps a de facto implementer's rule?
>
> I'd be happy to be wrong here. but to my knowledge no there's not been
> an explicit minimum for curve bits.  There have however been similar (at
> least in my non-cryptographer mind) for RSA key sizes so if we wanted to
> define an explicit minimum curve bits then we could.

  draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensuring
the curves used provide commensurate strength with the ciphersuite
negotiated. Section 10, "Implementation Considerations", says:

   It is RECOMMENDED that implementations take note of the strength
   estimates of particular groups and to select a ciphersuite providing
   commensurate security with its hash and encryption algorithms.  A
   ciphersuite whose encryption algorithm has a keylength less than the
   strength estimate, or whose hash algorithm has a blocksize that is
   less than twice the strength estimate SHOULD NOT be used.

  And I would like to take this opportunity to remind everyone that
the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resistant
to dictionary attack and the former is not.

  regards,

  Dan.



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

Re: [TLS] Comments on TLS-ECJ-PAKE draft

[Dan Harkins]

  Hi Robert,

  This draft moves the NamedCurve/EllipticCurveList into the
ClientHello, and since the client sends X1 and ZKP(X1) in the
ClientHello it means that is going to be a list of 1. It basically
moves the client's key exchange portion from ClientKeyExchange into
ClientHello. So basically, if a client wants to do TLS-ECJ-PAKE
then that's the only thing it can offer and the parameters of
that exchange are all selected by the client, not the server.

  This is a fundamental change to TLS. If it's going to be offered,
it's the only thing that can be offered and therefore the only thing
that can be used. Seems like for a deployment either it's never used
or it's the only thing used and that makes it sort of a proprietary
protocol, not TLS.

  Dan.

On Thu, June 16, 2016 2:51 am, Robert Cragie wrote:
> I would like to ask the working group for comments on the TLS-ECJ-PAKE
> draft:
>
> https://tools.ietf.org/html/draft-cragie-tls-ecjpake-00
>
> Some brief notes:
>
> * This intended status is informational.
> * The draft is based on TLS/DTLS 1.2 as the Thread group required basis on
> existing RFCs wherever possible. For that reason and due to the WGs focus
> on TLS 1.3, I have understood from the chairs that it would not have
> received a great deal of attention from the WG, hence the intended status
> of informational.
> * The draft reflects the current use of the TLS_ECJPAKE_WITH_AES_128_CCM_8
> cipher suite in Thread (http://threadgroup.org/).
> * There is an experimental implementation in mbed TLS (
> https://github.com/ARMmbed/mbedtls)
> * The Thread group would like to get IANA assignments for 4 cipher suite
> values and one ExtensionType value as soon as possible.
> * There are at least four independent implementations, which have been
> used
> in interop. testing over the last 18 months.
> * The security considerations recommend restriction of the use of this
> cipher suite to Thread and similar applications and recommends it should
> not be used with web browsers and servers (mainly due to the long
> discussions regarding the use of PAKEs on this and other mailing lists).
>
> Robert
> ___
> 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 TLS-ECJ-PAKE draft

[Dan Harkins]

  Hi Robert,

  Sorry for the confusing comments. There are 2 but one follows
because of the other.

  The first comment concerns the fact that J-PAKE is a 4 message
handshake. This is different than other PAKES like EKE, SPAKE2,
dragonfly, or SRP which all establish their shared key in a single
2 message exchange. A 2 message exchange falls into the TLS handshake
elegantly, e.g.:

  - figure 1 in https://tools.ietf.org/html/rfc5054#page-5
and
  - figure 1 in https://tools.ietf.org/html/draft-ietf-tls-pwd-07#page-10

as opposed to:

  - figure 1 in
https://tools.ietf.org/html/draft-cragie-tls-ecjpake-00#page-7

where as you are making the TLS "Hello phase" into a "Hello plus
one-half of the key exchange phase". This is my comment about this
being a fundamental change to TLS.

  Now the 2nd comment that follows out of the 1st is that by
overloading the Hello Phase to include half the key exchange phase
you remove all ability to do negotiation. When TLS-ECJ-PAKE is
used it is the only thing that can be used. The client can only
offer it and it can only talk to servers that support it. Which
is why my 2nd comment is that this is fundamentally a proprietary
protocol. You don't need a cipher suite assignment for this because
you have no ability to negotiate it. You could make it 0xFF,0xFC-FF
(reserved for private use) and have no issues. You will never
have interop issues with some other TLS-like private protocol
that also uses 0xFF,0xFC-FF because you'll never talk to them. Your
TLS-ECJ-PAKE client always and only talks to your TLS-ECJ-PAKE
server so your private assignment of the private use cipher suites
cannot conflict with any other private assignment. Proprietary
protocols don't need cipher suite assignments and this is a
proprietary extension of TLS.

  regards,

  Dan.

On Tue, July 19, 2016 12:55 pm, Robert Cragie wrote:
> Hi Dan,
>
> What you say regarding the NamedCurve/EllipticCurveList is of course
> right.
> Whether this constitutes a fundamental change to TLS is debatable. The aim
> was never to propose this as a cipher suite for general inclusion in a
> range of supported cipher suites in a browser/server scenario as is
> pointed
> out in various places in the draft. The aim was to reuse TLS (a well-known
> and widely implemented protocol) as a vehicle to support the ECJ-PAKE
> method and to deliberately constrain the implementation parameters a
> priori. To me, that does not make this a proprietary protocol and the ease
> by which existing TLS implementations have been adapted to support
> TLS-ECJ-PAKE. I guess it does raise the wider question of "what is TLS"
> though and whether this approach flouts conventional thinking about TLS
> (which, IMHO, it doesn't).
>
> Robert
>
> On 18 July 2016 at 11:06, Dan Harkins  wrote:
>
>>
>>   Hi Robert,
>>
>>   This draft moves the NamedCurve/EllipticCurveList into the
>> ClientHello, and since the client sends X1 and ZKP(X1) in the
>> ClientHello it means that is going to be a list of 1. It basically
>> moves the client's key exchange portion from ClientKeyExchange into
>> ClientHello. So basically, if a client wants to do TLS-ECJ-PAKE
>> then that's the only thing it can offer and the parameters of
>> that exchange are all selected by the client, not the server.
>>
>>   This is a fundamental change to TLS. If it's going to be offered,
>> it's the only thing that can be offered and therefore the only thing
>> that can be used. Seems like for a deployment either it's never used
>> or it's the only thing used and that makes it sort of a proprietary
>> protocol, not TLS.
>>
>>   Dan.
>>
>> On Thu, June 16, 2016 2:51 am, Robert Cragie wrote:
>> > I would like to ask the working group for comments on the TLS-ECJ-PAKE
>> > draft:
>> >
>> > https://tools.ietf.org/html/draft-cragie-tls-ecjpake-00
>> >
>> > Some brief notes:
>> >
>> > * This intended status is informational.
>> > * The draft is based on TLS/DTLS 1.2 as the Thread group required
>> basis
>> on
>> > existing RFCs wherever possible. For that reason and due to the WGs
>> focus
>> > on TLS 1.3, I have understood from the chairs that it would not have
>> > received a great deal of attention from the WG, hence the intended
>> status
>> > of informational.
>> > * The draft reflects the current use of the
>> TLS_ECJPAKE_WITH_AES_128_CCM_8
>> > cipher suite in Thread (http://threadgroup.org/).
>> > * There is an experimental implementation in mbed TLS (
>> > https://github.com/ARMmbed/mbedtls)
>> > * The Thread group would like to get IANA ass

[TLS] Re: PQ Cipher Suite I-Ds: adopt or not?

[Dan Harkins]

  To answer Joe's question, yes I support 4 separate adoption calls
for the I-Ds in question.

On 12/16/24 2:21 PM, Martin Thomson wrote:

On Tue, Dec 17, 2024, at 08:59, Sean Turner wrote:

Is the WG consensus to run four separate adoption calls for the
individual I-Ds in question?

I would like to see adoption calls for the key exchange modes and not the 
signature modes.  The key exchange documents are both more ready and more 
urgent.


  I agree that the key exchange modes are more urgent. That said, I would
support adoption of this one:

https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/


and will advocate for it being "recommended = Y".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
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Dan Harkins]

  +1 for adoption

  Dan.

On 12/12/24 2:06 PM, Filippo Valsorda wrote:

2024-12-07 18:36 GMT+01:00 Watson Ladd :
Having MLKEM without a hybrid as an option in TLS when the 
interoperable choice is a hybrid is not going to exclude people.


Furthermore we didn't hybridize x25519 and RSA. It's clear some 
people believe ML-KEM is secure enough for their uses.


Agreed on both counts, +1 to adoption.

___
TLS mailing list --tls@ietf.org
To unsubscribe send an email totls-le...@ietf.org


--
"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
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: PQ Cipher Suite I-Ds: adopt or not?

[Dan Harkins]

  I agree with Scott (and Uri). We have the bandwidth to handle this
and the disagreement is over whether "recommended" is Y or N. That
contentious point is not going to resolve itself over any reasonable
amount of time. Let's just do these two and address that point when
the drafts are mature enough to advance.

  regards,

  Dan.

On 12/24/24 9:47 AM, Scott Fluhrer (sfluhrer) wrote:


I would humbly disagree.  I believe this working group has enough 
bandwidth to handle a couple of postquantum drafts (along with all the 
other drafts the WG is working on).  I believe that this is especially 
true because we pretty much agree on the contents – what we have 
disagreements about is whether or not to endorse those contents.


That said, if the working group decided to delay the hybrid signature 
drafts, I wouldn’t complain too loudly – those would also depend on 
the work in the LAMPS working group, and so they’re less likely to be 
immediately useful.


*From:*Rob Sayre 
*Sent:* Monday, December 23, 2024 4:26 PM
*To:* Scott Fluhrer (sfluhrer) 
*Cc:* John Mattsson ; 
Loganaden Velvindron ; TLS List 

*Subject:* Re: [TLS] Re: PQ Cipher Suite I-Ds: adopt or not?

Hi all, since I am still on the CC list,

I took the question to be about how to organize the work. If 
everything is a priority, there are no priorities.


That's why I want to do this one (and only this one), first:

https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/

Some of the other ones look like they could benefit from waiting, in 
the sense that contentious points might resolve themselves over time.


thanks,

Rob

On Mon, Dec 23, 2024 at 11:00 AM Scott Fluhrer (sfluhrer) 
 wrote:


TL;DR: Historical notes: not important for the current discussion.

To be clear about whether Cisco (or actually, me – I don’t
actually speak for Cisco, but I like to think they listen to my
advice) preferred NTRU or NTRU Prime – I actually didn’t have a
strong opinion.  I advocated NTRU because it made it to round 3
(rather than stopping at round 2 as NTRUPrime did), and so it
appeared to be a bit more mature (that is, having more
cryptanalysis).  If there was a general consensus towards NTRU
Prime, we would have happily gone along.

Other than that, John summarized the situation well – Cisco (or
actually, Cisco’s lawyers) are happy with how the IPR issues
around ML-KEM were resolved and are going forward with that (with
both pure and hybrid).

*From:*John Mattsson 
*Sent:* Monday, December 23, 2024 9:02 AM
*To:* Loganaden Velvindron ; Rob Sayre

*Cc:* TLS List 
*Subject:* [TLS] Re: PQ Cipher Suite I-Ds: adopt or not?

The thread starts with “Due to this, Cisco has preliminarily
considered Kyber unusable”

This is obviously not true anymore as Scott very clearly stated
that Cisco wants to see both hybrid and non-hybrid ML-KEM
standardized, and that they want to implement and ship both. I
agree with Scott. Also, I think Cisco was quite clear on that if
the IPR uncertainties regarding ML-KEM was not addresses, which
they were, they wanted NTRU, not NTRU Prime
https://datatracker.ietf.org/doc/html/draft-fluhrer-cfrg-ntru-01


Mozilla is obviously shipping ML-KEM in Firefox. I am an avid user
of Firefox, and I am happy to see X25519MLKEM768 on more and more
webpages.

Cheers,
John

*From: *Loganaden Velvindron 
*Date: *Monday, 23 December 2024 at 02:56
*To: *Rob Sayre 
*Cc: *TLS List 
*Subject: *[TLS] Re: PQ Cipher Suite I-Ds: adopt or not?

If there are some patent concerns regarding ML-KEM going forward,
Would
considering NTRU-Prime as a less risky option for TLS Kex?

(Please see this thread:

https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiscourse.mozilla.org%2Ft%2Fpatent-license-for-kyber%2F128114&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49fe1a69fb24e159b5808dd22f5004a%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638705157893766686%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Fi1LM1Q49lgZfAwBOQf5HhvEXZccY%2Bjk9VXHg6yHEaU%3D&reserved=0)


There is a section about patents here:

https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fntruprime.cr.yp.to%2Fwarnings.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49fe1a69fb24e159b5808dd22f5004a%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638705157893782148%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=T%2B2Ggx2ZxAV%2BCwqSvtrUlptlGHO9iYCFpCYf4Cq3xlA%3D&reserved=0



On Tue, 17 Dec 2024 at 02:53, Rob Sayre mailto:say...@g

[TLS] Re: Working Group Last Call for RFC8773bis

[Dan Harkins]

  Hello,

  I think the new draft addresses the FATT concerns and is ready.

  regards,

  Dan.

On 5/13/25 9:42 AM, Joseph Salowey wrote:
Russ has made modifications to the rfc8773bis and published a new 
draft [1] to address the comments from the FATT.  You can see the 
diffs with the previous version are here: [2] and the FATT commentary 
from IETF 122 here: [3].


This is a working group last call for this document.  If you believe 
this document has sufficiently addressed the concerns please indicate 
so on this thread.  If you do not think it is sufficient please 
indicate what text modifications would address your issue.  This call 
will remain open until May 28, 2025.


Thanks,
Sean, Deirdre and Joe

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis/
[2] https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-8773bis-06
[3] 
https://datatracker.ietf.org/meeting/122/materials/slides-122-tls-fatt-report-rfc8773bis-00


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org


--
"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
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for A PAKE Extension for TLS 1.3

[Dan Harkins]

  Hello,

  I support adoption, will probably implement it, and definitely
use it.

  As I mentioned at IETF 123, I do not think having multiple choices
for basically the same thing is a wise and I think the choice the
authors made to do SPAKE2+ was a mistake*. I would encourage paring
this down to a balanced PAKE (CPace) and an asymmetric PAKE (OPAQUE).

  regards,

  Dan.

* If a discrete logarithm for M is discovered then SPAKE2+ is broken.
While I do not think there is a backdoor in the H2C-derived M in the
draft, it is a high value target and a (unnecessary) weak point in
a system.

On 7/24/25 12:01 AM, Sean Turner wrote:

At IETF 122 & 123 we discussed draft-bmw-tls-pake13 [0]. The sense of room @ 
both sessions was that there was support for working on PAKEs in TLS.

This email starts the WG adoption call for draft-bmw-tls-pake13. If you support 
adoption and are willing to review and contribute text, please send a message 
to the list. If you do not support adoption of this draft, please send a 
message to the list and indicate why. This call will close at 2359 UTC on 07 
August 2025.

Cheers,
Deirdre, Joe, and Sean

[0] https://datatracker.ietf.org/doc/draft-bmw-tls-pake13/

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org


--
"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
To unsubscribe send an email to tls-le...@ietf.org