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

[Blumenthal, Uri - 0553 - MITLL]

I see two possibilities:


  1.  Nobody in the real world employs static DH anymore – in which case this 
draft is useless/pointless; or
  2.  On private networks people employ static DH to implicitly authenticate 
their peers (a-lá MQV) – in which case this draft is harmful.

Overall, I’m amazed by drafts like this one. Is nothing constructive remains 
out there to spend time and efforts on?
--
V/R,
Uri

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare


From: TLS  on behalf of Viktor Dukhovni 

Date: Sunday, April 21, 2024 at 14:07
To: tls@ietf.org 
Subject: [EXT] Re: [TLS] Deprecating Static DH certificates in the obsolete key 
exchange document
!---|
  This Message Is From an External Sender
  This message came from outside the Laboratory.
|---!

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

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

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

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

--
Viktor.

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

Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

I support Kris, and would like to see codepoints added for MLKEM-512, 
MLKEM-768, and MLKEM-1024.

-- 
V/R, 
Uri 




On 3/19/24, 00:11, "TLS on behalf of Kris Kwiatkowski" mailto:tls-boun...@ietf.org> on behalf of k...@amongbytes.com 
> wrote:


!---|
This Message Is From an External Sender
This message came from outside the Laboratory.
|---!


Hello,


I would like to express my support for getting a codepoint for ML-KEM (the 
queue was closed quicker than I expected, so didn’t have a chance to do it at 
the meeting). 


The motivation:
* First of all the integration is rather straightforward.
* MLKEM already got a large amount of research from the crypto community, from 
a large number of various research groups - theorists, designers, implementers 
as well as experts in side-channel protection. Deirdre mentioned that schemes 
were studied for the last 7 years, but it is worth remembering that Kyber is a 
modification of the LPR cryptosystem, introduced already in 2010. 
* There is a cost of 2-step migration (to hybrid and then pure PQ), I don’t 
believe it’s good to force you to pay the cost.


Additionally, I think I would also get a codepoint for MLKEM-512.


-- 
Kris Kwiatkowski
Cryptography Dev








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





smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: Time to first byte vs time to last byte

[Blumenthal, Uri - 0553 - MITLL]

Please, let us not assume every website is behind a CDN. 

Isn't that assumption reasonable? At least for global websites --- without CDN 
performance sucks.

Of course it isn’t.

 

As a reference point:

 

Consider reading the New York Times in Canberra,

 

Well, if you have nothing better to do there… ;-)

 

doesn't happen without CDN

 

Of course. The whole point is not to assume every website is behind CDN. Which 
part of “every” is unclear? 

Of course there are sites behind a CDN of some kind. And there are sites that 
are not.  It is stupid unwise to ignore that.



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

Also, what are the WG's thoughts on including standalone PQC signatures in the 
same draft?

 

I think that including standalone PQC sigs would be very desirable.

 

I don't think there is any particular reason to include PQC signatures in the 
same draft as PQ key establishment. In TLS 1.3, key establishment and signature 
are orthogonal concepts, and it will be easier to review if they are kept in 
separate documents.

 

On the one hand – you’re correct. On the other hand, though, considering 
implicitly-authenticated protocols, such as MQV, HMQV etc…?

Yes I’m aware that they don’t use explicit signatures, except to validate 
certificates.

 

From: TLS  On Behalf Of Deirdre Connolly
Sent: Tuesday, March 5, 2024 9:15 PM
To: TLS@ietf.org
Subject: [TLS] ML-KEM key agreement for TLS 1.3

 

I have uploaded a preliminary version of ML-KEM for TLS 1.3  and have a more 
fleshed out version to be uploaded when datatracker opens. It is a 
straightforward new `NamedGroup` to support key agreement via ML-KEM-768 or 
ML-KEM-1024, in a very similar style to -hybrid-design.

 

It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 compatible) 
ready to go when users are ready to use them.

 

Cheers,

Deirdre

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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

Also, what are the WG's thoughts on including standalone PQC signatures in the 
same draft?

 

I think that including standalone PQC sigs would be very desirable.

 

 

From: TLS  On Behalf Of Deirdre Connolly
Sent: Tuesday, March 5, 2024 9:15 PM
To: TLS@ietf.org
Subject: [TLS] ML-KEM key agreement for TLS 1.3

 

I have uploaded a preliminary version of ML-KEM for TLS 1.3  and have a more 
fleshed out version to be uploaded when datatracker opens. It is a 
straightforward new `NamedGroup` to support key agreement via ML-KEM-768 or 
ML-KEM-1024, in a very similar style to -hybrid-design.

 

It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 compatible) 
ready to go when users are ready to use them.

 

Cheers,

Deirdre



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: Time to first byte vs time to last byte

[Blumenthal, Uri - 0553 - MITLL]

 

On Sat, 9 Mar 2024 at 10:23, Bas Westerbaan 
 wrote:

Given that especially for the web, CDNs used much higher initcwnds,

 

Please, let us not assume every website is behind a CDN. 

 

Isn't that assumption reasonable? At least for global websites --- without CDN 
performance sucks.

 

Of course it isn’t. 

Though this probably was a troll, and I shouldn’t bite… 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

I would like to see Deirdre’s request satisfied, and a full number assigned. 

Regards,
Uri

> On Mar 7, 2024, at 09:19, Salz, Rich  
> wrote:
> 
> 
> This Message Is From an External Sender
> This message came from outside the Laboratory.
> Back to the topic at hand. I think it'd very bad if we'd have a codepoint for 
> pure ML-KEM before we have a codepoint for an ML-KEM hybrid. Process wise, I 
> think that's up to the designated experts of the IANA registry.
>  
> Currently the TLS designated experts really only look at the request itself, 
> without larger context: is the ALPN valid, is the requested protocol number 
> available, is the documentation freely available and so on.  Section 15 of 
> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/ changes that a 
> bit.
>  
> So if Deirdre requests a code point right now, we’d probably reject it but 
> that could be appealed somehow. Once the RFC is out, we could then see if 
> there’s WG consensus or if it’s still a work-in-progress, and assign full 
> number or provisional or tell her to use the private range.
>  
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Blumenthal, Uri - 0553 - MITLL]

 

 

--

V/R,

Uri

 

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

>nnerEndI very much appreciate having a concrete hybrid scheme that is 
>intentionally not generic.

 

Totally agree.

 

> This avoids the explosion of ciphertext suites that would otherwise occur, 
> and allows for better compatibility of libraries.

>  Fixing the key sizes to ML-KEM 768 and X25519 is aligned with our preferred 
> choices as well, and further increases interoperability.

 

Yes.

 

Except that I want also an option with ML-KEM 1024.

 

 

 

On Thu, Jan 11, 2024 at 9:31 AM Salz, Rich  
wrote:

I'm going to echo Bas to highlight that X-Wing is not generic to any IND-CCA 
KEM, it is a particular primitive construction based on the internal 
construction of ML-KEM in particular: 

 

I don’t think it’s our place to try to shoe-horn everything into one construct. 
 Particularly when we are in the experimentation phase of things.

 

If people want to have ML-KEM as a material in their composites, it sounds like 
they might want to learn from X-Wing, but not try to chop them to fit into that 
one keyhole, as it were.

 

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


 

-- 


Sophie Schmieg | Information Security Engineer | ISE Crypto | 
sschm...@google.com

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

>On Wed, Jan 3, 2024, at 15:30, Eric Rescorla wrote:
>> In the interest of clarity, I favor the WG declining to work on 
>> extending TLS 1.2, so these cipher suites should be marked as 
>> Recommended=No. I'm just concerned that closing the registries entirely 
>> will not have the best results.
>
> This is also my view. It would be a shame to embark on another attempt
> to use registry policies to control implementations, in defiance of
> everything we've learned about that not working.

I concur. (Except that I'd pick a word stronger and more descriptive than 
"shame". ;)


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

This draft will likely be ignored, except by the Web browser crowd, Swift UI, 
and such ilk. 

 

One problem with this draft is that such “fanatical/extremist” documents 
diminish credibility of the body that sanctioned them in the eyes of those who 
deal with “real” equipment (again, excluding stuff used to connect to YouTube 
or Amazon).

--

V/R,

Uri

 

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

 

 

From: TLS  on behalf of Rob Sayre 
Date: Tuesday, January 2, 2024 at 20:03
To: Martin Thomson 
Cc: "TLS@ietf.org" 
Subject: Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

 

It might be better to describe TLS 1. 2 as "overtaken by events". If you want 
to use CSS Grid or Swift UI (name any newish thing), you'll find yourself with 
a stack that supports TLS 1. 3, so there's no need to bother with TLS 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender 
This message came from outside the Laboratory. 
ZjQcmQRYFpfptBannerEnd

It might be better to describe TLS 1.2 as "overtaken by events". If you want to 
use CSS Grid or Swift UI (name any newish thing), you'll find yourself with a 
stack that supports TLS 1.3, so there's no need to bother with TLS 1.2 in those 
cases. Turning off TLS 1.2 is sometimes a good idea, because that traffic is 
composed of undesirable bots in many cases.

 

I know people also work on things that are old, but it seems ok to call them 
really old, because that is true. No one seems to disagree with this point in 
the draft: "TLS 1.3 [TLS13] is also in widespread use and fixes most known 
deficiencies with TLS 1.2".

 

If you think this draft is so strict that it will be ignored, you have nothing 
to worry about.

 

thanks,

Rob

 

 

 

 

On Tue, Jan 2, 2024 at 1:19 PM Martin Thomson  wrote:

On Wed, Jan 3, 2024, at 01:20, Salz, Rich wrote:
> That is not what the just-adopted draft says.  It says that except for 
> ALPN and exporters that no new registrations will be accepted for TLS 
> 1.2 and that new entries should have a Note comment that says “for TLS 
> 1.3 or later”. This is a change in the current policy.  It has always 
> said this; see page 3 of [1].

I should learn to read the IANA considerations.  This current says:

> IANA will stop accepting registrations for any TLS parameters [TLS13REG] 
> except for the following

Aside from the fact that the wording also says that IANA will stop accepting 
TLS 1.3 registrations too, I think that this is a very bad idea.



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

Most people in the positions you describe are not experts themselves, but rely 
on the recommendations and analysis of prominent industry groups because they 
know that that is likely to produce better answers than every IT practitioner 
trying to determine the answer themselves.

 

Agree, in general.

 

The best and brightest will say “what has the TLS working group at IETF said 
about this important topic?”  Which is why it is useful for us to provide high 
quality analysis and practical guidance about how we think any upcoming 
transition(s) and upgrade(s) will go.  And why it is important that we get it 
right …

 

And I don’t think we did.

 

TNX

 

From: TLS  On Behalf Of Salz, Rich
Sent: Tuesday, January 2, 2024 10:06 AM
To: Blumenthal, Uri - 0553 - MITLL 
Cc: TLS@ietf.org
Subject: Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

 

My starting assumption here is that the majority of people implementing TLS 
and/or deciding what to authorize for deployment TLS-wise, are not stupid, and 
understand the benefits of the newer protocol version, including its added 
security. And capable of evaluating the risks of moving to TLS 1.3 vs. staying 
with 1.2. 

 

That is a much nicer and broader brush than one I am willing to use to paint 
the IT industry.



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

>jQcmQRYFpfptBannerEnd

>>  Those who can move to 1.3+, will do so, regardless of this draft. Those who 
>>can’t, would

>>  do whatever’s appropriate in their case – again, regardless of this draft.

> 

> Same as for any other IETF document. :)

 

:-)

 

Yes, but not quite – as other IETF documents (usually) provide more of (IMHO) 
useful information. This one is (IMHO) a pure attempt of “legal spit”.

 

>  One difference in the current wording is that it would become trivially more 
>difficult to get a multi-vendor

> PQ solution for current TLS 1.2 implementations.

 

Yeah, a great accomplishment, indeed. Authors can be proud. :-(

 

> Assuming, of course, that “just use what was defined for TLS 1.3 or later” 
> somehow

> doesn’t occur to everyone.

 

My starting assumption here is that the majority of people implementing TLS 
and/or deciding what to authorize for deployment TLS-wise, are not stupid, and 
understand the benefits of the newer protocol version, including its added 
security. And capable of evaluating the risks of moving to TLS 1.3 vs. staying 
with 1.2. 

With the additional advantage of being aware of their CONOPS- and 
use-case-specific circumstances.

 

I have seen real (and important enough) cases where that kind of upgrade was 
infeasible, so the authorities chose to “accept the risk”. (And no, I cannot 
post details – so no need to bother asking.)

 

TNX

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

>>  I'm not Martin, but I believe that his point is that both TLS ciphersuites 
>>and TLS supported groups/EC curves

>>  permit registration outside of the IETF process based on the existence of.a 
>> specification. As long as PQC can

>>  fit into new ciphersuites and group types, then anyone can specify it for 
>> TLS 1.2, and it would in fact be

>>  TLS, just not standardized or Recommended.

> 

> That is not what the just-adopted draft says.  It says that except for ALPN 
> and exporters that no new

> registrations will be accepted for TLS 1.2 and that new entries should have a 
> Note comment that says

> “for TLS 1.3 or later”. This is a change in the current policy.  It has 
> always said this; see page 3 of [1].

 

Which is why this “just-adopted draft” is misguided and will probably be 
ignored in the field.

 

Those who can move to 1.3+, will do so, regardless of this draft. Those who 
can’t, would do whatever’s appropriate in their case – again, regardless of 
this draft.

 

> At the last meeting we decided NOT to freeze DTLS 1.2 since DTLS 1.3 has so 
> little deployment[4].

> This has complicated the wording of the above statement, which was raised at 
> [2] and [3]

 

[1] 
https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-new-draft-tls-12-is-frozen-00

[2] https://github.com/richsalz/tls12-frozen/issues/10

[3] https://github.com/richsalz/tls12-frozen/pull/13

[4] https://datatracker.ietf.org/doc/minutes-118-tls-202311060830/

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

-1 to Tim. 

 

You can tell the reader whatever you want. The fact remains that if the only 
way to add QR to the currently deployed TLS-1.2-based “stuff” is modifying 
TLS-1.2, then that’s what will be done in that particular case.  

 

I hope that the majority of the installed base would be able to migrate to PQ 
and TLS-1.3+ in a normal way. But in all likelihood, “special cases” will 
exist. 

--

V/R,

Uri

 

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

 

 

From: TLS  on behalf of Ira McDonald 

Date: Thursday, December 21, 2023 at 13:39
To: Tim Hollebeek , Ira McDonald 

Cc: Hannes Tschofenig , Bas 
Westerbaan , "Salz, Rich" 
, "TLS@ietf.org" 
Subject: [EXT] Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

 

+1 to Tim - tell the reader explicitly that they will only ever get PQC w/ TLS 
1. 3 or higher. Cheers, - Ira On Thu, Dec 21, 2023, 12: 34 PM Tim Hollebeek 
 wrote: I personally think 
this point 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender 
This message came from outside the Laboratory. 
ZjQcmQRYFpfptBannerEnd

+1 to Tim - tell the reader explicitly that they will only ever get PQC w/ TLS 
1.3 or higher.

 

Cheers,

- Ira

On Thu, Dec 21, 2023, 12:34 PM Tim Hollebeek 
 wrote:

I personally think this point is important enough to be made explicitly instead 
of implicitly.

 

If we want to communicate loudly and clearly that post-quantum cryptography is 
NEVER coming to TLS 1.2, we need to explicitly say that.

 

Otherwise people will say “I know you said TLS 1.2 was frozen, but post-quantum 
cryptography isn’t a feature, it’s a critical security vulnerability that needs 
to be patched regardless of any freezes.”

 

The answer will be and needs to be: “No, we told you clearly and explicitly 
that post-quantum cryptography would require moving to TLS 1.3 or later”.

 

-Tim

 

From: TLS  On Behalf Of Hannes Tschofenig
Sent: Monday, December 11, 2023 12:06 PM
To: Salz, Rich ; Hannes Tschofenig 
; Bas Westerbaan 
; Deirdre Connolly 

Cc: TLS@ietf.org
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

 

Hi Rich,

 

that is implied by a "feature freeze". No reason to highlight PQC (even though 
it is a hype topic right now).

 

Ciao

Hannes

 

Am 11.12.2023 um 17:18 schrieb Salz, Rich:

1.   I consider Section 3 "Implications for post-quantum cryptography" 
misplaced. I suggest to delete the section

2.   The motivation for the draft is unrelated to developments with PQC.

The point is to explain to people that we are going to need PQ crypto, and it 
*will not be a 1.2 enhancement*

 

 
___
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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: What is the TLS WG plan for quantum-resistant algorithms?

[Blumenthal, Uri - 0553 - MITLL]

Do we want rfc describing the final NIST standards? And for which? I'm ok with 
that — in this order of priority: ml-kem, ml-dsa, slh-dsa.
 

Probably yes, and in the order you described.

 

For which algorithms do we want to assign codepoints once the NIST standards 
are out? Codepoints are cheap and use cases/rules are different, but especially 
with the hybrids, I'd encourage us to try to be disciplined and keep the list 
as short as we can for now, so that early adopters for which it doesn't matter, 
all choose the same thing. The DNS mechanism of 
draft-davidben-tls-key-share-prediction helps on the performance side, but it 
doesn't solve the duplicate engineering/validation if there are a dozen 
essentially equivalent KEMs.
 

Leaving this question alone, at least for now.

 

Do we want to standardise non-hybrid KEMs for TLS? I don't care for them yet, 
but others might.
 

Absolutely yes.

 

Do we need hybrid signatures for the TLS handshake? I don't see the use, but 
could be convinced otherwise.
 

I don’t need/want them, but can’t/won’t forbid others from using them. They 
still don’t make sense to me.

 

What is the future of AuthKEM? That's definitely a different e-mail thread.
 

I hope it becomes a mainstream standard.

 

Concretely, after ML-KEM is finished, I was planning to update 
draft-schwabe-cfrg-kyber to match it, and proposing to register a codepoint for 
a single ML-KEM-768 hybrid in draft-ietf-tls-hybrid-design.

 

Great!

 

Thanks 

 

On Mon, Nov 6, 2023 at 10:10 AM John Mattsson 
 wrote:

Hi,


NIST has released draft standards for ML-KEM, ML-DSA, and ML-SLH. Final 
standards are expected in Q1 2024.

https://csrc.nist.gov/news/2023/three-draft-fips-for-post-quantum-cryptography

 

I would like to have standard track TLS (and DTLS, QUIC) RFCs for ML-KEM and 
ML-DSA (all security levels standardized by NIST) as soon as possible after the 
final NIST standards are ready. 3GPP is relying almost exclusively on IETF RFCs 
for uses of public key cryptography (the exception is ECIES for IMSI encryption 
but that will likely use HPKE with ML-KEM in the future).

 

Looking at the TLS document list, it seems severely lacking when it comes to 
ML-KEM, ML-DSA…

 

The adopted draft-ietf-tls-hybrid-design is an informal draft dealing with the 
pre-standard Kyber. 

https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/

AuthKEM is a quite big change to TLS

https://datatracker.ietf.org/doc/draft-wiggers-tls-authkem-psk/

 

This is not adopted, informal, and dealing with the pre-standard Kyber.

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

 

What is the TLS WG plan for quantum-resistant algorithms? My current view is 
that I would like ML-KEM-512, ML-KEM-768, ML-KEM-1024, ML-DSA-44, ML-DSA-65, 
and ML-DSA-87 registered asap. For hybrid key exchange I think X25519 and X448 
are the only options that make sense. For hybrid signing, ECDSA, EdDSA, and RSA 
could all make sense.

 

Cheers,
John

 

From: TLS  on behalf of internet-dra...@ietf.org 

Date: Friday, 8 September 2023 at 02:48
To: i-d-annou...@ietf.org 
Cc: tls@ietf.org 
Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-09.txt

Internet-Draft draft-ietf-tls-hybrid-design-09.txt is now available. It is a
work item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   Hybrid key exchange in TLS 1.3
   Authors: Douglas Stebila
Scott Fluhrer
Shay Gueron
   Name:draft-ietf-tls-hybrid-design-09.txt
   Pages:   23
   Dates:   2023-09-07

Abstract:

   Hybrid key exchange refers to using multiple key exchange algorithms
   simultaneously and combining the result with the goal of providing
   security even if all but one of the component algorithms is broken.
   It is motivated by transition to post-quantum cryptography.  This
   document provides a construction for hybrid key exchange in the
   Transport Layer Security (TLS) protocol version 1.3.

   Discussion of this work is encouraged to happen on the TLS IETF
   mailing list tls@ietf.org or on the GitHub repository which contains
   the draft: 
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-c404f4af2592f2f4=1=367fabf2-370b-4cec-b657-05a8499decf6=https%3A%2F%2Fgithub.com%2Fdstebila%2Fdraft-ietf-tls-hybrid-design.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/

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

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-hybrid-design-09

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

___
TLS mailing list
TLS@ietf.org

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

[Blumenthal, Uri - 0553 - MITLL]

AFAIK, they aren’t on TLS 1.3, at least so far. 

Regards,
Uri

> On Jul 14, 2023, at 12:54, Peter Gutmann  wrote:
> 
> !---|
>  This Message Is From an External Sender
>  This message came from outside the Laboratory.
> |---!
> 
> Blumenthal, Uri - 0553 - MITLL  writes:
> 
>> I’m aware of at least one company (using the term loosely) that uses custom
>> group, 
> 
> How does that work with TLS 1.3?
> 
> Peter.
> 


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

Hubert,

I’m aware of at least one company (using the term loosely) that uses custom 
group, and probably understands FFDH(E) better than you or me. Since they had 
their reasons for choosing custom, “can change … to use well-known groups” 
(obviously) does not apply. 

Regards,
Uri

> On Jul 14, 2023, at 12:33, Hubert Kario  wrote:
> 
> !---|
> This Message Is From an External Sender
> This message came from outside the Laboratory.
> |---!
> 
>> On Friday, 14 July 2023 18:03:25 CEST, Peter Gutmann wrote:
>> Hubert Kario  writes:
>> 
>>> FIPS requires to support only well known groups (all of them 2048 bit or
>>> larger), and we've received hardly any customer issues after implementing
>>> that as hard check (connection will fail if the key exchange uses custom DH
>>> parameters) good few years ago now.
>> 
>> Interesting, so you're saying that essentially no-one uses custom groups?  My
>> code currently fast-tracks the known groups (RFC 3526 and RFC 7919) but also
>> allows custom groups (with additional checking) to be on the safe side 
>> because
>> you never know what weirdness is out there, do you have an idea of what sort
>> of magnitude "hardly any" represents?
> 
> I wouldn't go as far as "nobody uses them", it's more like "people that use
> them, either have them configured unknowingly or can change configuration
> to use well known groups". So while it may cause interoperability issues,
> for people that really do care about interoperability with old systems,
> they are fine with tweaking DH configuration to make it happen (or simply
> end up using ECDHE and are completely unaware of the whole issue).
> 
> One more side note: in FIPS mode we also disable RSA ciphersuites, so the
> FFDHE and ECDHE, both with only well known groups, are the only two key
> exchanges that do work.
> 
>> And can something similar be said about SSH implementations?  There's fixed 
>> DH
>> groups and then the Swiss-army-knife diffie-hellman-group-exchange-*, but
>> AFAIK the only groups that ever get exchanged there are the RFC 3526/7919
>> ones.
> 
> nope, for OpenSSH those will be the safe-primes from /etc/ssh/moduli, though
> in FIPS mode we do ignore that file and indeed use RFC 3526 or 7919 groups
> of at least 2048 bits (don't remember what we default to, but we will accept
> either)
> -- 
> Regards,
> Hubert Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

Yes to Viktor's and Peter's comments. 

I can't understand fanaticism expressed in this "deprecate..." attempt. 
Besides, it is simply unwise. 

--
V/R,
Uri
 
There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 

On 7/14/23, 03:02, "TLS on behalf of Peter Gutmann"  wrote:
Viktor Dukhovni  writes:

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

This already happens a lot in wholesale banking, the admins have dutifully
disabled DH because someone said so and so all keyex falls back to RSA circa
1995, and worst possible situation to be in.

There needs to be clear text in there to say that if you can't do ECC then 
do
DH but never RSA, or even just "keep using DH because it's still vastly 
better
than the alternative of RSA".  At the moment the blanket "don't do DH" is in
effect saying "use RSA keyex" to a chunk of the market.

Peter.



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] AuthKEM: Splitting the draft and next steps

[Blumenthal, Uri - 0553 - MITLL]

In short - yes please. 

Thanks!

Regards,
Uri

> On Jul 4, 2023, at 02:01, Thom Wiggers  wrote:
> 
> 
> This Message Is From an External Sender
> This message came from outside the Laboratory.
> Hi all,
> 
> It has been a while since I have had time to work on the IETF draft for 
> AuthKEM (``draft-celi-wiggers-tls-authkem``, aka "KEMTLS"), and some of you 
> have previously asked when the draft (which is currently expired) will be 
> updated. In this email, I want to pick up the work again.
> 
> Specifically, I want to do the following:
> 
> * Split the proposal in two parts for improved legibility and applicability 
> to use cases
> * Once this is done and in a good shape, move forward towards consensus with 
> the aim of adoption
> 
> I will now describe the plan in more detail. I am welcoming further 
> suggestions, and would like to hear if these changes make sense and are 
> appreciated. If nothing else, you're welcome to help bikeshed draft names. :-)
> 
> The draft currently describes TLS authentication via KEM ("KEMTLS 
> authentication") and TLS-PSK-style abbreviated handshakes via KEM 
> (KEMTLS-PDK). The TLS authentication and the abbreviated KEM-based PSK-style 
> handshake probably are independently interesting. The two proposals can be 
> split and this would hopefully make evaluating them easier. AuthKEM and 
> "pre-shared KEM" can be independently implemented.
> 
> "Plain AuthKEM" is useful for mitigating the cost of post-quantum signature 
> schemes in "regular" TLS handshakes. Use of plain AuthKEM can be especially 
> attractive to devices that want to use mutually authenticated TLS, but would 
> like to re-use the (e.g. protected) implementation of the KEM algorithm for 
> ephemeral key exchange. Compared to Dilithium2, use of Kyber also offers 
> significant space savings.
> 
> "KEM-PSK" is interesting for embedded or IoT applications that currently are 
> using symmetric-key PSK with ephemeral key exchange. Using KEM-PSK avoids 
> symmetric-key key management issues, such as protected storage and key 
> distribution, while allowing PSK-style abbreviated TLS handshakes. Meanwhile, 
> no additional code is needed over the ephemeral key exchange algorithms. (In 
> the future, we could even investigate additional mechanisms to distribute the 
> server’s public key, such as putting it in HTTPS records alongside ECH, to 
> allow more clients to use the abbreviated handshake.)
> 
> I hope to get these changes done over the coming weeks, but I doubt it'll be 
> ready for IETF 117. But, as stated above, I do not want to drag this forward 
> in the unadopted state forever—it's been long enough already. So once 
> refactoring has happened, discussion has settled and consensus has been 
> reached, I intend to ask the chairs for a call for adoption.
> 
> Cheers, and thanks for your comments,
> 
> Also on behalf of my co-authors,
> 
> Thom
> PQShield
> 
> PS: we moved the Git repository to 
> https://github.com/kemtls/draft-celi-wiggers-tls-authkem
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Blumenthal, Uri - 0553 - MITLL]

That is correct - CNSA-2.0 prescribes the “NIST Kyber”, whatever changes this 
may include to the Kyber-1024, aka Kyber at NIST Sec Level V. 

One can speculate about what changes would be proposed during the public 
comments period, and which of them would be accepted. Regardless, until then we 
won’t know the *exact* details of the algorithm. 

However, if people consider experimenting with Kyber deployment now, and want 
to define appropriate MTI now (and want to use Hybrid, aka combined, key 
exchange) - then it’s as pointless now as it will be in the future to define 
P384+Kyber768, because either there won’t be such a Hybrid at all (NSA stated 
that they won’t require Hybrid in products that need their certification) or 
there will be P384+Kyber1024, whatever the latter will look like then. 

Regards,
Uri

> On Apr 2, 2023, at 06:43, Ilari Liusvaara  wrote:
> 
> On Sun, Apr 02, 2023 at 02:54:57AM +, Blumenthal, Uri - 0553 - MITLL 
> wrote:
>> CNSA-1.0 allows ECC only over P-384, unlike it’s predecessor Suite B
>> that also permitted P-256. P-521 is not included either. See
>> https://media.defense.gov/2021/Sep/27/2002862527/-1/-1/0/CNSS%20WORKSHEET.PDF
>> (page 1).
>> 
>> CNSA-2.0 allows only Kyber-1024. Not -768. See 
>> https://media.defense.gov/2021/Sep/27/2002862527/-1/-1/0/CNSS%20WORKSHEET.PDF
>> (page 4).
>> 
>> So, if somebody would insist on a CNSA-compliant hybrid - there is
>> only one candidate from each group to consider for the MTI. 
>> 
>> It also means that MTI für P-384 with Kyber-768 is likely to be quite
>> useless, as those not bound by CNSA would probably make other choices
>> (not P-384)  anyway, and those required to comply with CNSA will have
>> to settle for what I described. 
>> 
>> Did I make it clear enough? Or do you see a hole in my logic?
> 
> I think what "CRYSTALS: Kyber" means in CNSA-2.0 is the final
> specification. Which obviously is not available yet, so it is impossible
> to currently make any key exchange or asymmetric encryption compliant
> with CNSA-2.0.
> 
> As to what sense does publishing CNSA-2.0 before the algorithms are
> known make? Note that it does have algorithms for firmware signing
> fully specified, and urges those to be deployed as soon as possible.
> And I suppose there might be sense timing-wise on publishing a spec
> referencing a future spec that will likely undergo nontrivial draft
> period.
> 
> 
> 
> -Ilari
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Blumenthal, Uri - 0553 - MITLL]

CNSA-1.0 allows ECC only over P-384, unlike it’s predecessor Suite B that also 
permitted P-256. P-521 is not included either. See 
https://media.defense.gov/2021/Sep/27/2002862527/-1/-1/0/CNSS%20WORKSHEET.PDF  
(page 1).

CNSA-2.0 allows only Kyber-1024. Not -768. See 
https://media.defense.gov/2021/Sep/27/2002862527/-1/-1/0/CNSS%20WORKSHEET.PDF 
(page 4).

So, if somebody would insist on a CNSA-compliant hybrid - there is only one 
candidate from each group to consider for the MTI. 

It also means that MTI für P-384 with Kyber-768 is likely to be quite useless, 
as those not bound by CNSA would probably make other choices (not P-384)  
anyway, and those required to comply with CNSA will have to settle for what I 
described. 

Did I make it clear enough? Or do you see a hole in my logic?

Regards,
Uri

> On Apr 1, 2023, at 05:54, Ilari Liusvaara  wrote:
> 
> On Sat, Apr 01, 2023 at 02:12:14AM +, Kampanakis, Panos wrote:
>> Hi Bas,
>> 
>> I prefer for the MTI to be P-256+Kyber768 for compliance reasons.
> 
> Uh, I think this thing is too experimental to have any MTI.
> 
>> It would be trivial for servers to add support for both identifiers
>> as they introduce Kyber768, but you are right, the new draft should
>> include an MTI identifier.
> 
> The problem with having both is that it bifurcates the system. While
> being on wrong side is not a hard failure, it is still rather annoying
> perf hit.
> 
> For clients to support either, servers must support both.
> 
> At least with P-384 hybrid, folks are less likely to deploy the thing
> unless needed.
> 
> 
> 
> -Ilari
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Blumenthal, Uri - 0553 - MITLL]

Because that’s what CNSA requires. 

Regards,
Uri

> On Mar 29, 2023, at 00:45, Kampanakis, Panos  wrote:
> 
> 
>  
> > I would also like secp384r1_kyber1024 option, please.
>  
> Why do you up the ECDH curve sec level with Kyber1024? It adds unnecessary 
> size to the keyshare. like secp384r1_kyber768 combines two equivalent 
> security levels.
> Those that want to be extra conservative can go secp521r1_kyber1024 which 
> won’t be much worse than secp384r1_kyber1024 in performance or size.
>  
>  
>  
> From: TLS  On Behalf Of Blumenthal, Uri - 0553 - MITLL
> Sent: Tuesday, March 28, 2023 10:40 PM
> To: Krzysztof Kwiatkowski ; Christopher Wood 
> 
> Cc: TLS@ietf.org
> Subject: RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for 
> draft-ietf-tls-hybrid-design
>  
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you can confirm the sender and know the 
> content is safe.
> 
>  
> Can we add secp256r1_kyber768 option for those who prefer NIST curves?
>  
> I support this.
>  
> I would also like secp384r1_kyber1024 option, please.
>  
> Thanks


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Blumenthal, Uri - 0553 - MITLL]

Can we add secp256r1_kyber768 option for those who prefer NIST curves?

 

I support this. 

 

I would also like secp384r1_kyber1024 option, please.

 

Thanks



On 29 Mar 2023, at 10:48, Christopher Wood  wrote:

 

As discussed during yesterday's meeting, we would like to assess consensus for 
moving draft-ietf-tls-hybrid-design forward with the following strategy for 
allocating codepoints we can use in deployments.

1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this 
document through the process towards publication.
2. Write a simple -00 draft that specifies the target variant of 
X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully did 
this for us already [1].) Once this is complete, request a codepoint from IANA 
using the standard procedure.

The intent of this proposal is to get us a codepoint that we can deploy today 
without putting a "draft codepoint" in an eventual RFC.

Please let us know if you support this proposal by April 18, 2023. Assuming 
there is rough consensus, we will move forward with this proposal.

Best,
Chris, Joe, and Sean

[1] https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Resurrect AuthKEM?

[Blumenthal, Uri - 0553 - MITLL]

Richard, yes, you git it right.

From: Richard Barnes 
Date: Tuesday, March 21, 2023 at 4:32 PM
To: Blumenthal, Uri - 0553 - MITLL 
Cc: tls@ietf.org 
Subject: Re: [TLS] Resurrect AuthKEM?
Hi Uri,

Just to be clear, the AuthKEM draft you mean is this one?

https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-authkem/

Assuming that's the case, in case anyone else is confused (as I was), the 
"AuthKEM" here does not refer to a KEM implementing the AuthEncap/AuthDecap 
interface from RFC 9180.  Instead it refers to the construction in that 
document, which uses a normal KEM.

--Richard


On Tue, Mar 21, 2023 at 2:34 PM Blumenthal, Uri - 0553 - MITLL 
mailto:u...@ll.mit.edu>> wrote:
I’m surprised to see that there isn’t much (isn’t any?) discussion of the 
AuthKEM draft.

It seems pretty obvious that with the advent of PQ algorithms, the sheer sizes 
of signatures and public keys would make {cDm}TLS existing authentication and 
key exchange impractical in bandwidth-constrained environments, especially when 
higher security-level algorithms (like, what’s demanded by CNSA-2.0) are 
required.

Thus, implicit authentication (think – MQV, Hugo Krawczyk’s HMQV, etc.) seems 
to be a-must for making the PQ impact on bandwidth somewhat manageable.

I would like this WG to resurrect the AuthKEM draft.

I can’t be in Yokohama, and am not fanatical enough to spend nights on XMPP or 
such. But hopefully, we can discuss AuthKEM approach here on the list.

Thank you!
--
V/R,
Uri Blumenthal  Voice: (781) 981-1638
Secure Resilient Systems and Technologies   Cell:  (339) 223-5363
MIT Lincoln Laboratory
244 Wood Street, Lexington, MA  02420-9108

Web: https://www.ll.mit.edu/biographies/uri-blumenthal
Root CA: https://www.ll.mit.edu/llrca2.pem

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare

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

[TLS] Resurrect AuthKEM?

[Blumenthal, Uri - 0553 - MITLL]

I’m surprised to see that there isn’t much (isn’t any?) discussion of the 
AuthKEM draft. 

 

It seems pretty obvious that with the advent of PQ algorithms, the sheer sizes 
of signatures and public keys would make {cDm}TLS existing authentication and 
key exchange impractical in bandwidth-constrained environments, especially when 
higher security-level algorithms (like, what’s demanded by CNSA-2.0) are 
required.

 

Thus, implicit authentication (think – MQV, Hugo Krawczyk’s HMQV, etc.) seems 
to be a-must for making the PQ impact on bandwidth somewhat manageable.

 

I would like this WG to resurrect the AuthKEM draft.

 

I can’t be in Yokohama, and am not fanatical enough to spend nights on XMPP or 
such. But hopefully, we can discuss AuthKEM approach here on the list.

 

Thank you!

--

V/R,

Uri Blumenthal  Voice: (781) 981-1638 

Secure Resilient Systems and Technologies   Cell:  (339) 223-5363

MIT Lincoln Laboratory  

244 Wood Street, Lexington, MA  02420-9108  

 

Web: https://www.ll.mit.edu/biographies/uri-blumenthal

Root CA: https://www.ll.mit.edu/llrca2.pem

 

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Pqc] Did TLS AuthKEM die?

[Blumenthal, Uri - 0553 - MITLL]

>Without getting into details – EDHOC is still more “verbose” than CAKE-HI, 
>thus – not >“minimalistic” (which was one of our design goals).

 

The overhead except key shares and MACs in EDHOC is typically 21 bytes. If your 
protocol uses the NIST PQC algorithms with their large public keys and 
encapsulation sizes, I have a hard time to see that this “verbosity” (EDHOC has 
type and length for all fields so that it can be parsed without an agreed 
template) would matter much in practice :)

 

Overhead – compared to what? 

 

Re. agreed templates: it is about avoiding [the need to communicate and select] 
options.

 

 

From: Blumenthal, Uri - 0553 - MITLL 
Date: Friday, 27 January 2023 at 16:09
To: loic.ferre...@orange.com , Thom Wiggers 

Cc: John Mattsson , Mike Ounsworth 
, p...@ietf.org , 
tls@ietf.org 
Subject: Re: [Pqc] [TLS] Did TLS AuthKEM die?

Thank you Uri.

 

My pleasure.

 

Then what about CAKE-HI vs. EDHOC?

 

Ah, a good question – with a less-technical answer. 

 

Without getting into details – EDHOC is still more “verbose” than CAKE-HI, thus 
– not “minimalistic” (which was one of our design goals). At this point, EDHOC 
is not PQ, which precludes it from being evaluated and considered in our use 
cases. If DH in EDHOC is replaced by a PQ KEM – the numbers will start favoring 
CAKE-HI, but at this time is doesn’t look like there’s interest to make EDHOC 
Quantum-Resistant.

 

I’d say CAKE-HI could replace EDHOC, if and when Quantum Resistance is needed 
(and the channel can tolerate larger packet/message sizes), and when 
template-based approach is preferred to online negotiations.

 

By the way is there any specification of CAKE-HI available?

 

In the process of “release review”. ;-)

 

Thanks!

 

 

Orange Restricted

De : Blumenthal, Uri - 0553 - MITLL  
Envoyé : jeudi 26 janvier 2023 21:08
À : FERREIRA Loïc INNOV/IT-S ; Thom Wiggers 

Cc : John Mattsson ; Mike Ounsworth 
; p...@ietf.org; tls@ietf.org
Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die?

 

How would you compare CAKE-HI and cTLS?

 

Loïc, an excellent question. Naturally, there are similarities and differences. 

 

Similarities: 

1.   Both strive to reduce unnecessary communications;

2.   Both strive to avoid unnecessary negotiations;

3.   Both embrace “template-based specialization” that allows avoiding 
negotiations altogether (if I understood this part of cTLS correctly).

 

Differences:

4.   Different purpose: 

1.   cTLS is a compact Transport Layer Security that protects user data, 
and includes key exchange (as one of the mechanisms it utilizes to achieve its 
goal).

2.   CAKE-HI is a Key Exchange protocol that provides session keys (shared 
secret(s)) to other protocols that handle user data.

5.   Different degree of “minimization”, as CAKE-HI is much more 
minimalistic than cTLS: 

1.   cTLS tries to create a “leaner TLS” by paring the “fat” of TLS, 
backward-compatibility with TLS 1.2, etc. But quite a bit of TLS details 
remains there.

2.   CAKE-HI has nothing in common with the TLS handshaking, options, 
syntax, fields, and such. It has a set of cryptographic primitives that it 
employs to generate symmetric shared secret and satisfy security properties 
listed below.

6.   Thus, CAKE-HI cannot replace cTLS, (among other reasons) because by 
itself it does not provide user data protection (and requires another protocol, 
like SCIP to handle that), nor can cTLS “replace” CAKE-HI because it does a lot 
of things unnecessary for “pure” key exchange and carries more overhead than a 
truly minimalistic AKE needs.

 

On the sad part, CAKE-HI specification (actually, we’ll most likely present 
CHAKE-HI, aka – Compact Hybrid Authenticated Key Exchange Hiding Identities) 
lags behind in details that have been provided in cTLS ID 
(https://www.ietf.org/archive/id/draft-ietf-tls-ctls-07.html). But we’ll get 
there. ;-)

 

I realize the above is rather sketchy – please feel free to ask more questions, 
and I’ll do my best to answer them.

 

Thanks!

 

 

 

Orange Restricted

De : Pqc  De la part de Blumenthal, Uri - 0553 - MITLL
Envoyé : mercredi 25 janvier 2023 22:49
À : Thom Wiggers 
Cc : John Mattsson ; Mike Ounsworth 
; p...@ietf.org; tls@ietf.org
Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die?

 

I'll first ask the first question, and then try to clarify a few of the other 
things raised in this thread.

 

> Is AuthKEM dead?

 

I'd say it's hibernating. The draft has indeed expired: there was nothing 
significant to add since the last time we edited/updated it. I also couldn't 
make it to the last two IETF meetings (and due to conflict with Real World 
Crypto, I will most likely not be able to make IETF116 either). The TLS working 
group has seemed to want to focus on getting PQ key exchange out of the door, 
but if it's ready to continue the discussion on post-quantum authentication 
(which should include some other things like OCSP 

Re: [TLS] [Pqc] Did TLS AuthKEM die?

[Blumenthal, Uri - 0553 - MITLL]

Thank you Uri.

 

My pleasure.

 

Then what about CAKE-HI vs. EDHOC?

 

Ah, a good question – with a less-technical answer. 

 

Without getting into details – EDHOC is still more “verbose” than CAKE-HI, thus 
– not “minimalistic” (which was one of our design goals). At this point, EDHOC 
is not PQ, which precludes it from being evaluated and considered in our use 
cases. If DH in EDHOC is replaced by a PQ KEM – the numbers will start favoring 
CAKE-HI, but at this time is doesn’t look like there’s interest to make EDHOC 
Quantum-Resistant.

 

I’d say CAKE-HI could replace EDHOC, if and when Quantum Resistance is needed 
(and the channel can tolerate larger packet/message sizes), and when 
template-based approach is preferred to online negotiations.

 

By the way is there any specification of CAKE-HI available?

 

In the process of “release review”. ;-)

 

Thanks!

 

 

Orange Restricted

De : Blumenthal, Uri - 0553 - MITLL  
Envoyé : jeudi 26 janvier 2023 21:08
À : FERREIRA Loïc INNOV/IT-S ; Thom Wiggers 

Cc : John Mattsson ; Mike Ounsworth 
; p...@ietf.org; tls@ietf.org
Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die?

 

How would you compare CAKE-HI and cTLS?

 

Loïc, an excellent question. Naturally, there are similarities and differences. 

 

Similarities: 

-  Both strive to reduce unnecessary communications;

-  Both strive to avoid unnecessary negotiations;

-  Both embrace “template-based specialization” that allows avoiding 
negotiations altogether (if I understood this part of cTLS correctly).

 

Differences:

-  Different purpose: 

o   cTLS is a compact Transport Layer Security that protects user data, and 
includes key exchange (as one of the mechanisms it utilizes to achieve its 
goal).

o   CAKE-HI is a Key Exchange protocol that provides session keys (shared 
secret(s)) to other protocols that handle user data.

-  Different degree of “minimization”, as CAKE-HI is much more 
minimalistic than cTLS: 

o   cTLS tries to create a “leaner TLS” by paring the “fat” of TLS, 
backward-compatibility with TLS 1.2, etc. But quite a bit of TLS details 
remains there.

o   CAKE-HI has nothing in common with the TLS handshaking, options, syntax, 
fields, and such. It has a set of cryptographic primitives that it employs to 
generate symmetric shared secret and satisfy security properties listed below.

-  Thus, CAKE-HI cannot replace cTLS, (among other reasons) because by 
itself it does not provide user data protection (and requires another protocol, 
like SCIP to handle that), nor can cTLS “replace” CAKE-HI because it does a lot 
of things unnecessary for “pure” key exchange and carries more overhead than a 
truly minimalistic AKE needs.

 

On the sad part, CAKE-HI specification (actually, we’ll most likely present 
CHAKE-HI, aka – Compact Hybrid Authenticated Key Exchange Hiding Identities) 
lags behind in details that have been provided in cTLS ID 
(https://www.ietf.org/archive/id/draft-ietf-tls-ctls-07.html). But we’ll get 
there. ;-)

 

I realize the above is rather sketchy – please feel free to ask more questions, 
and I’ll do my best to answer them.

 

Thanks!

 

 

 

Orange Restricted

De : Pqc  De la part de Blumenthal, Uri - 0553 - MITLL
Envoyé : mercredi 25 janvier 2023 22:49
À : Thom Wiggers 
Cc : John Mattsson ; Mike Ounsworth 
; p...@ietf.org; tls@ietf.org
Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die?

 

I'll first ask the first question, and then try to clarify a few of the other 
things raised in this thread.

 

> Is AuthKEM dead?

 

I'd say it's hibernating. The draft has indeed expired: there was nothing 
significant to add since the last time we edited/updated it. I also couldn't 
make it to the last two IETF meetings (and due to conflict with Real World 
Crypto, I will most likely not be able to make IETF116 either). The TLS working 
group has seemed to want to focus on getting PQ key exchange out of the door, 
but if it's ready to continue the discussion on post-quantum authentication 
(which should include some other things like OCSP and CT), I'd be very happy to 
continue the discussion and work on AuthKEM.

 

We have a simplified protocol (CAKE-HI) inspired by and based on AuthKEM. Being 
simplified, CAKE is not really suitable for TLS. Thus, we’d like to see AuthKEM 
progressing within the TLS WG.

 

One change that we'd probably like to make soon is to include Kyber-based 
(hybrid / PQ/T) KEMs -- once those KEMs have been hammered out for the 
ephemeral key exchange.

 

Yes, something worth discussing.

 

I am currently working hard on wrapping up my PhD thesis* (which is largely on 
post-quantum TLS and KEMTLS in particular). This is another reason why the 
draft has been sitting there for a while. To me, right now, most of the 
"homework" behind the AuthKEM/KEMTLS proposal feels pretty "finished"; I'd 
argue we have some form of running code (as in the various KEMTLS experimental 

Re: [TLS] about hash and post-quantum ciphers

[Blumenthal, Uri - 0553 - MITLL]

John, I agree with all of your points.

 

TNX

 

P.S. Maybe it would be good for NIST to standardize BLAKE3. But until it does – 
…

--

V/R,

Uri

 

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

 

 

From: TLS  on behalf of John Mattsson 

Date: Friday, January 27, 2023 at 06:26
To: "tls@ietf.org" 
Cc: hojarasca2022 , "Salz, Rich" 

Subject: Re: [TLS] about hash and post-quantum ciphers

 

Hi,

 

I don't think non-standardized algorithms should be adopted by the WG. Even for 
just assigning a number, a good first step would be CFRG.

But this mail got me thinking:

 

- I think the lack of hash algorithm crypto agility in TLS 1.3 is 
unsatisfactory. The _only_ option in TLS 1.3 is SHA2.

 

- NIST is expected to exclusively use SHA3 in the lattice-based PQC algorithms. 
I think it would make very much sense to include SHA3 (the SHAKE variants) at 
the same time as the standardized NIST PQC algorithms.

 

- TLS 1.3 hardcodes use of the quite outdated HMAC and HDKF constructions that 
only exists because SHA2 is fixed-length and suffers badly from 
length-extension attacks. Modern hash algorithm like SHAKE/KMAC are 
variable-length and does not suffer from length-extension attacks. If SHA3 is 
added in the future, I think it would make sense to use KMAC instead of HMAC 
and HKDF. Might also be nice to use the duplex construction whose security can 
be shown to be equivalent to the sponge construction.

 

Cheers,

John

From: TLS  on behalf of Salz, Rich 

Date: Thursday, 26 January 2023 at 20:42
To: hojarasca2022 , tls@ietf.org 

Subject: Re: [TLS] about hash and post-quantum ciphers

In TLS 1.3, AES256-SHA384 is not mandatory to implement.

 

If there is a freely available published specification of BLAKE3, you can 
request an assigned number for it in the TLS registry [1]. 

 

Ø  Furthermore, NIST selected some post-quantum ciphers: 
https://nist.gov/pqcrypto 

 

Hm, are you new here?  The archives have a couple hundred messages about 
post-quantum.

 

[1] 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Pqc] Did TLS AuthKEM die?

[Blumenthal, Uri - 0553 - MITLL]

How would you compare CAKE-HI and cTLS?

 

Loïc, an excellent question. Naturally, there are similarities and differences. 

 

Similarities: 
Both strive to reduce unnecessary communications;
Both strive to avoid unnecessary negotiations;
Both embrace “template-based specialization” that allows avoiding negotiations 
altogether (if I understood this part of cTLS correctly).
 

Differences:
Different purpose:
cTLS is a compact Transport Layer Security that protects user data, and 
includes key exchange (as one of the mechanisms it utilizes to achieve its 
goal).
CAKE-HI is a Key Exchange protocol that provides session keys (shared 
secret(s)) to other protocols that handle user data.
Different degree of “minimization”, as CAKE-HI is much more minimalistic than 
cTLS:
cTLS tries to create a “leaner TLS” by paring the “fat” of TLS, 
backward-compatibility with TLS 1.2, etc. But quite a bit of TLS details 
remains there.
CAKE-HI has nothing in common with the TLS handshaking, options, syntax, 
fields, and such. It has a set of cryptographic primitives that it employs to 
generate symmetric shared secret and satisfy security properties listed below.
Thus, CAKE-HI cannot replace cTLS, (among other reasons) because by itself it 
does not provide user data protection (and requires another protocol, like SCIP 
to handle that), nor can cTLS “replace” CAKE-HI because it does a lot of things 
unnecessary for “pure” key exchange and carries more overhead than a truly 
minimalistic AKE needs.
 

On the sad part, CAKE-HI specification (actually, we’ll most likely present 
CHAKE-HI, aka – Compact Hybrid Authenticated Key Exchange Hiding Identities) 
lags behind in details that have been provided in cTLS ID 
(https://www.ietf.org/archive/id/draft-ietf-tls-ctls-07.html). But we’ll get 
there. ;-)

 

I realize the above is rather sketchy – please feel free to ask more questions, 
and I’ll do my best to answer them.

 

Thanks!

 

 

 

Orange Restricted

De : Pqc  De la part de Blumenthal, Uri - 0553 - MITLL
Envoyé : mercredi 25 janvier 2023 22:49
À : Thom Wiggers 
Cc : John Mattsson ; Mike Ounsworth 
; p...@ietf.org; tls@ietf.org
Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die?

 

I'll first ask the first question, and then try to clarify a few of the other 
things raised in this thread.

 

> Is AuthKEM dead?

 

I'd say it's hibernating. The draft has indeed expired: there was nothing 
significant to add since the last time we edited/updated it. I also couldn't 
make it to the last two IETF meetings (and due to conflict with Real World 
Crypto, I will most likely not be able to make IETF116 either). The TLS working 
group has seemed to want to focus on getting PQ key exchange out of the door, 
but if it's ready to continue the discussion on post-quantum authentication 
(which should include some other things like OCSP and CT), I'd be very happy to 
continue the discussion and work on AuthKEM.

 

We have a simplified protocol (CAKE-HI) inspired by and based on AuthKEM. Being 
simplified, CAKE is not really suitable for TLS. Thus, we’d like to see AuthKEM 
progressing within the TLS WG.

 

One change that we'd probably like to make soon is to include Kyber-based 
(hybrid / PQ/T) KEMs -- once those KEMs have been hammered out for the 
ephemeral key exchange.

 

Yes, something worth discussing.

 

I am currently working hard on wrapping up my PhD thesis* (which is largely on 
post-quantum TLS and KEMTLS in particular). This is another reason why the 
draft has been sitting there for a while. To me, right now, most of the 
"homework" behind the AuthKEM/KEMTLS proposal feels pretty "finished"; I'd 
argue we have some form of running code (as in the various KEMTLS experimental 
implementations we did for the academic work are pretty close to AuthKEM). We 
also have proofs, both pen-and-paper and two Tamarin models. If anyone has 
suggestions for concrete next steps, perhaps in which AuthKEM solves a problem 
that they're seeing, let us know. 

 

But in the end, AuthKEM, as any IETF WG proposal, can't get pushed over the 
line by some ivory tower academic like myself --- we will need people coming 
out and saying they want to have this.

 

For TLS we want AuthKEM. For other protocols – we have a similar alternative. 
;-)

 

By the way, if anyone wants to discuss KEM-based authentication for other 
protocol(s) by the way, I am always happy to talk, for example in the new PQUIP 
wg that's also addressed :-)

 

Please count me in. ;-)

 

Next, replying to John's comments:

 

Op di 24 jan. 2023 om 19:32 schreef John Mattsson 
:

Using ephemeral-static ECDH for implit authentication as in the Noise protocol 
has several benefits. The benefits of using KEMs instead of signatures seem 
more limited. The current proposal requires 3 full round-trips instead of 1.5 
round-trips for mutual authentication. If I understand correctly, the messages 
sizes are smaller than Kyber+Dilithium but similar to Kyber+

Re: [TLS] [Pqc] Did TLS AuthKEM die?

[Blumenthal, Uri - 0553 - MITLL]

I'll first ask the first question, and then try to clarify a few of the other 
things raised in this thread.

 

> Is AuthKEM dead?

 

I'd say it's hibernating. The draft has indeed expired: there was nothing 
significant to add since the last time we edited/updated it. I also couldn't 
make it to the last two IETF meetings (and due to conflict with Real World 
Crypto, I will most likely not be able to make IETF116 either). The TLS working 
group has seemed to want to focus on getting PQ key exchange out of the door, 
but if it's ready to continue the discussion on post-quantum authentication 
(which should include some other things like OCSP and CT), I'd be very happy to 
continue the discussion and work on AuthKEM.

 

We have a simplified protocol (CAKE-HI) inspired by and based on AuthKEM. Being 
simplified, CAKE is not really suitable for TLS. Thus, we’d like to see AuthKEM 
progressing within the TLS WG.

 

One change that we'd probably like to make soon is to include Kyber-based 
(hybrid / PQ/T) KEMs -- once those KEMs have been hammered out for the 
ephemeral key exchange.

 

Yes, something worth discussing.

 

I am currently working hard on wrapping up my PhD thesis* (which is largely on 
post-quantum TLS and KEMTLS in particular). This is another reason why the 
draft has been sitting there for a while. To me, right now, most of the 
"homework" behind the AuthKEM/KEMTLS proposal feels pretty "finished"; I'd 
argue we have some form of running code (as in the various KEMTLS experimental 
implementations we did for the academic work are pretty close to AuthKEM). We 
also have proofs, both pen-and-paper and two Tamarin models. If anyone has 
suggestions for concrete next steps, perhaps in which AuthKEM solves a problem 
that they're seeing, let us know. 

 

But in the end, AuthKEM, as any IETF WG proposal, can't get pushed over the 
line by some ivory tower academic like myself --- we will need people coming 
out and saying they want to have this.

 

For TLS we want AuthKEM. For other protocols – we have a similar alternative. 
;-)

 

By the way, if anyone wants to discuss KEM-based authentication for other 
protocol(s) by the way, I am always happy to talk, for example in the new PQUIP 
wg that's also addressed :-)

 

Please count me in. ;-)

 

Next, replying to John's comments:

 

Op di 24 jan. 2023 om 19:32 schreef John Mattsson 
:

Using ephemeral-static ECDH for implit authentication as in the Noise protocol 
has several benefits. The benefits of using KEMs instead of signatures seem 
more limited. The current proposal requires 3 full round-trips instead of 1.5 
round-trips for mutual authentication. If I understand correctly, the messages 
sizes are smaller than Kyber+Dilithium but similar to Kyber+Falcon (probably a 
bit larger in total).

Indeed, our mutual authentication story with plain AuthKEM is pretty weak; but 
to be fair, it appears mutual authentication is extremely rarely used in web 
browsing [0]. 

 

True. But as far as I’m concerned, web browsing is somebody else’s problem. ;-)

 

If continued, I think Kyber KEMs makes a lot more sense than ECDH KEM. For ECDH 
KEM you can do something much more efficient.

 

Naturally, OPTLS/draft-semistatic are indeed more elegant given DH/NIKE. I'd 
argue that we're looking at a KEM-based future, though: AFAIK we currently 
still don't have any satisfactory answers to the PQ NIKE question: CSIDH's 
security is still a big, on-going discussion, CSIDH is also awfully slow, and 
SIDH-based solutions (not to be confused with CSIDH) seem dead in the water. If 
any new proposals pop up, they will probably not have seen much cryptanalysis 
yet.

 

I concur.

 

TNX

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Did TLS AuthKEM die?

[Blumenthal, Uri - 0553 - MITLL]

Using ephemeral-static ECDH for implit authentication as in the Noise protocol 
has several benefits. The benefits of using KEMs instead of signatures seem 
more limited. The current proposal requires 3 full round-trips instead of 1.5 
round-trips for mutual authentication. If I understand correctly, the messages 
sizes are smaller than Kyber+Dilithium but similar to Kyber+Falcon (probably a 
bit larger in total).

 

Yes – but CNSA-2.0 only approves Dilithium, not Falcon. And NIST report 
mentions the difficulties validating Falcon implementations. 

 

If continued, I think Kyber KEMs makes a lot more sense than ECDH KEM. 

 

Yes, absolutely. 

 

 

From: TLS  on behalf of Blumenthal, Uri - 0553 - MITLL 

Date: Tuesday, 24 January 2023 at 19:15
To: Mike Ounsworth , p...@ietf.org 
, tls@ietf.org 
Subject: Re: [TLS] Did TLS AuthKEM die?

I truly hope AuthKEM is alive.

 

--

V/R,

Uri

 

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

 

 

From: TLS  on behalf of Mike Ounsworth 

Date: Tuesday, January 24, 2023 at 12:33
To: "p...@ietf.org" , "tls@ietf.org" 
Subject: [TLS] Did TLS AuthKEM die?

 

Thom, Sofía,

 

draft-celi-wiggers-tls-authkem is expired. Is that on purpose? Does it still 
have steam or is it dead?

 

---
Mike Ounsworth
Software Security Architect, Entrust

 

Any email and files/attachments transmitted with it are confidential and are 
intended solely for the use of the individual or entity to whom they are 
addressed. If this message has been sent to you in error, you must not copy, 
distribute or disclose of the information it contains. Please notify Entrust 
immediately and delete the message from your system. 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Did TLS AuthKEM die?

[Blumenthal, Uri - 0553 - MITLL]

I truly hope AuthKEM is alive.

 

--

V/R,

Uri

 

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

 

 

From: TLS  on behalf of Mike Ounsworth 

Date: Tuesday, January 24, 2023 at 12:33
To: "p...@ietf.org" , "tls@ietf.org" 
Subject: [TLS] Did TLS AuthKEM die?

 

Thom, Sofía,

 

draft-celi-wiggers-tls-authkem is expired. Is that on purpose? Does it still 
have steam or is it dead?

 

---
Mike Ounsworth
Software Security Architect, Entrust

 

Any email and files/attachments transmitted with it are confidential and are 
intended solely for the use of the individual or entity to whom they are 
addressed. If this message has been sent to you in error, you must not copy, 
distribute or disclose of the information it contains. Please notify Entrust 
immediately and delete the message from your system. 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

100% support the BCP route.

-- 
V/R,
Uri
 

On 12/22/22, 10:16, "TLS on behalf of Peter Gutmann"  wrote:

Hal Murray  writes:

>Would a BCP be a better approach?  That might provide a good setting to
>discuss the issues.  There is no reason to limit a BCP to TLSv1.2 or FFDHE.

That seems like a much better idea.  A deprecate RFC can only say "no" 
while a
BCP can cover alternatives, in this situation do this, in that situation do
that.

Peter.

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


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

True - but, unfortunately, quite a few readers misunderstand that and use depreciation as an excuse to remove support of deprecated algorithms and protocols. Wouldn’t be the first case an RFC gets misinterpreted. Regards,UriOn Dec 14, 2022, at 02:30, Rob Sayre  wrote:On Tue, Dec 13, 2022 at 8:14 PM Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> wrote:\ I think I’ve made my point already – there are devices that use FFDHE, which remain secure (so far), and may require access by new . Thus, an RFC that would prohibit it, sounds, as you said yourself, premature.Deprecated does not mean prohibited.thanks,Rob


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

Maybe you are saying this decision is premature. 

 

I certainly am, especially given that there are no security reasons driving it.

 

Surely there is a limit to this reasoning, though. 

 

Of course.

 

There is a MacOS 9 system right next to me, and it doesn't support anything 
beyond SSL3. I would not expect the IETF to accommodate that system.

 

Correct. And I wouldn’t expect the IETF to accommodate whatever Windows 95 used 
to support, if anybody still has it. But, as you said, there’s a limit to this 
reasoning as well. 

 

So, can you explain your point a bit more? 

 

I think I’ve made my point already – there are devices that use FFDHE, which 
remain secure (so far), and may require access by new . Thus, an RFC 
that would prohibit it, sounds, as you said yourself, premature.

 

I think "zero security reasons" sounds like something we should work out, but 
arguments like "who cares for systems like SCADA" are a bit off the mark. The 
IETF can't perpetually support systems that can't be upgraded, because attacks 
always get better.

 

I see a great distance between “perpetual” and “premature”. And SCADA is just 
one area, which I brought up because it’s closer to me than, e.g., 
browsers-and-websites realm.

 

And stand by my opinion that deprecating a perfectly functional and secure 
protocol (for reasons I consider frivolous at best) and ignore the likely harm 
such deprecation would cause, is, er, “premature”.

 

 

 

thanks,

Rob

 

 

On Tue, Dec 13, 2022 at 3:01 PM Blumenthal, Uri - 0553 - MITLL 
 wrote:

That sounds like deprecation to me (stop building new things this way...)

 

Build new things that stop interoperating with old things? Does not sound smart 
to me.

 

Not to mention that there’s zero security reasons for this deprecation.

 

I support deprecating all FFDHE cipher suites. The IETF should not perpetually 
support systems that can't be upgraded.

 

Yeah, who cares for systems like SCADA. Sure.

 

 

On Tue, Dec 13, 2022 at 7:51 AM Blumenthal, Uri - 0553 - MITLL 
 wrote:

I do not support deprecation, because there will be deployed devices (IoT, 
SCADA) that aren’t upgradable – and the new stuff will have to access them.

 

I’ll spare the group my personal opinion about this draft.

-- 

V/R,

Uri

 

 

From: TLS  on behalf of Ira McDonald 

Date: Tuesday, December 13, 2022 at 10:47
To: Sean Turner , Ira McDonald 
Cc: TLS List 
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites

 

Hi,

 

Yes - I support deprecating all FFDHE cipher suites including well-known groups.

 

Cheers,

- Ira

 

 

On Tue, Dec 13, 2022 at 9:46 AM Sean Turner  wrote:

During the tls@IETF 115 session topic covering 
draft-ietd-tls-deprecate-obsolete-kex, the sense of the room was that there was 
support to deprecate all FFDHE cipher suites including well-known groups. This 
message starts the process to judge whether there is consensus to deprecate all 
FFDHE cipher suites including those well-known groups. Please indicate whether 
you do or do not support deprecation of FFDHE cipher suites by 2359UTC on 6 
January 2023. If do not support deprecation, please indicate why.

NOTE: We had an earlier consensus call on this topic when adopting 
draft-ietd-tls-deprecate-obsolete-kex, but the results were inconclusive. If 
necessary, we will start consensus calls on other issues in separate threads.

Cheers,
Chris, Joe, and Sean
___
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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

That sounds like deprecation to me (stop building new things this way...)

 

Build new things that stop interoperating with old things? Does not sound smart 
to me.

 

Not to mention that there’s zero security reasons for this deprecation.

 

I support deprecating all FFDHE cipher suites. The IETF should not perpetually 
support systems that can't be upgraded.

 

Yeah, who cares for systems like SCADA. Sure.

 

 

On Tue, Dec 13, 2022 at 7:51 AM Blumenthal, Uri - 0553 - MITLL 
 wrote:

I do not support deprecation, because there will be deployed devices (IoT, 
SCADA) that aren’t upgradable – and the new stuff will have to access them.

 

I’ll spare the group my personal opinion about this draft.

-- 

V/R,

Uri

 

 

From: TLS  on behalf of Ira McDonald 

Date: Tuesday, December 13, 2022 at 10:47
To: Sean Turner , Ira McDonald 
Cc: TLS List 
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites

 

Hi,

 

Yes - I support deprecating all FFDHE cipher suites including well-known groups.

 

Cheers,

- Ira

 

 

On Tue, Dec 13, 2022 at 9:46 AM Sean Turner  wrote:

During the tls@IETF 115 session topic covering 
draft-ietd-tls-deprecate-obsolete-kex, the sense of the room was that there was 
support to deprecate all FFDHE cipher suites including well-known groups. This 
message starts the process to judge whether there is consensus to deprecate all 
FFDHE cipher suites including those well-known groups. Please indicate whether 
you do or do not support deprecation of FFDHE cipher suites by 2359UTC on 6 
January 2023. If do not support deprecation, please indicate why.

NOTE: We had an earlier consensus call on this topic when adopting 
draft-ietd-tls-deprecate-obsolete-kex, but the results were inconclusive. If 
necessary, we will start consensus calls on other issues in separate threads.

Cheers,
Chris, Joe, and Sean
___
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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

I do not support deprecation, because there will be deployed devices (IoT, 
SCADA) that aren’t upgradable – and the new stuff will have to access them.

 

I’ll spare the group my personal opinion about this draft.

-- 

V/R,

Uri

 

 

From: TLS  on behalf of Ira McDonald 

Date: Tuesday, December 13, 2022 at 10:47
To: Sean Turner , Ira McDonald 
Cc: TLS List 
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites

 

Hi,

 

Yes - I support deprecating all FFDHE cipher suites including well-known groups.

 

Cheers,

- Ira

 

 

On Tue, Dec 13, 2022 at 9:46 AM Sean Turner  wrote:

During the tls@IETF 115 session topic covering 
draft-ietd-tls-deprecate-obsolete-kex, the sense of the room was that there was 
support to deprecate all FFDHE cipher suites including well-known groups. This 
message starts the process to judge whether there is consensus to deprecate all 
FFDHE cipher suites including those well-known groups. Please indicate whether 
you do or do not support deprecation of FFDHE cipher suites by 2359UTC on 6 
January 2023. If do not support deprecation, please indicate why.

NOTE: We had an earlier consensus call on this topic when adopting 
draft-ietd-tls-deprecate-obsolete-kex, but the results were inconclusive. If 
necessary, we will start consensus calls on other issues in separate threads.

Cheers,
Chris, Joe, and Sean
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

Victor,  actually, I take it back - you may be right in that last point. Need 
to think. 

Regards,
Uri

> On Oct 7, 2022, at 14:59, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> 
>>> On Oct 7, 2022, at 14:42, Viktor Dukhovni  wrote:
>>> 
>>> On Fri, Oct 07, 2022 at 06:19:15PM +, Blumenthal, Uri - 0553 - MITLL 
>>> wrote:
>>> 
>>> Then publish the certificate. Then the victim is unable to read email
>>> encrypted to her. A DoS that costs the attacker very little,
>>> practically nothing.
>> 
>> What victim is that?
> 
> Person or organization, whose credentials and email address were in the 
> bogus/modified CSR. 
> 
>> All the PoP does is make it harder to convince your CA to attest that
>> someone else's key is yours.  It plays no role in the most critical role
>> of your CA, which is to not attest that your key is someone else's.  
> 
> Concur with both points above. 
> 
>> The scenario you suggest seems to me to require the latter.
> 
> I don’t think so.
> 
> 
> 
>>   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


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

> On Oct 7, 2022, at 14:42, Viktor Dukhovni  wrote:
> 
> On Fri, Oct 07, 2022 at 06:19:15PM +, Blumenthal, Uri - 0553 - MITLL 
> wrote:
> 
>> Then publish the certificate. Then the victim is unable to read email
>> encrypted to her. A DoS that costs the attacker very little,
>> practically nothing.
> 
> What victim is that?

Person or organization, whose credentials and email address were in the 
bogus/modified CSR. 

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

Concur with both points above. 

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

I don’t think so.



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


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

>  >You can replay the CSR and get the certificate request by the original party
>  >signed by whatever CA you want, but would that do you any good if you don't
>  >have the private key?
>
>  That's exactly the point, which others have also made in the thread.  Yes, 
> you
>  can do this, but then what? 

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

>  In other words, what real-world problem are we actually solving by requiring
>  PoP,

See above.

> how much existing practice will it break by doing so, and is it worth the
> cost?

Didn't you notice that the existing practice already includes/enforces PoP? And 
does not work for KEM keys?



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

Peter, "Compromised" in the context must necessarily mean "someone stole the 
key", because if someone "broke the crypto" - then none of the certs issued by 
that CA is worth the weight of electrons that carried it.

Oh, and could you please be a little more constructive?
-- 
V/R,
Uri
 

On 10/7/22, 13:05, "TLS on behalf of Peter Gutmann"  wrote:

Tim Hollebeek  writes:

>There’s also the problem that there’s no standard for secure proof of
>possession for revocation, despite a number of us calling for one for 
years.

This is one of the 8,000 (approximately) great unresolved PKIX disagreements
where about half of PKIX thought revocation should be made as easy as 
possible
to be able to deal with things like compromised keys [0] and the other half 
of
PKIX thought it should be made as difficult as possible to be able to deal
with DoS via hostile revocations (during one of the interminable debates
around this, one of the participants suggested that supplicants should be
required to fly to the CA's place of business and beg them on their knees to
revoke the cert).  The difficult-as-possible side mostly won in the 
standards
(e.g. the CMP requirement to sign a revocation request for a key you've lost
before it can be revoked) while the easy-as-possible mostly won in practice
because that's what people actually wanted.

Peter.

[0] "Compromised" meaning someone broke the crypto, not stole the key, since
that's not supposed to happen.

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


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

It largely isn’t necessary.  I like proof of possession for issuance, but 
mostly just to avoid nuisances.  But this topic is widely misunderstood.  I 
think if you took a poll of PKI professionals, you’d find that lots of them 
erroneously believe that issuance of a certificate certifies that the 
subscriber has the corresponding private key.  It doesn’t (in most ecosystems). 
 It just means the subscriber has asked for that particular public key to be 
associated with their identity.

 

It depends on your threat model, and on how your operations are set up.

 

It’s not uncommon for security researchers to grab a prominent public key, for 
example, a public WebPKI root, get a certificate issued to themselves for it, 
and claim to have found a security hole, when the proper response is: “You 
don’t have the private key.  What do you think you are able to do with that?”  
This comes up semi-regularly on mozilla.dev.security-policy.

 
Q: What do you think you are able to do with that?
A: Cause a Denial of Service (inability to decrypt received emails, aka – 
communicate), to both the perceived owner of the cert, and her correspondents. 
Revocation consequences (what you mention below) are possible (unclear).
 

One misconception here is that the principal herself is submitting the request, 
and so, such a self-induced DoS would simply be insane. In an organization, 
however, where multiple people are involved, it may not be as simple and 
straightforward. 

 

So I like proof of possession just to avoid those sorts of nuisance scenarios.  
If you can do it (e.g. in an automated issuance protocol), I think you should.

 

An automated scenario exacerbates the above risks.

 

But I also like not being forced to do proof of possession, because there are 
scenarios where being forced to do it makes things worse.  They tend to involve 
things like offline systems where it’s easier to securely get a bare public key 
across an air gap than it is to attempt to sign and transport a CSR.  There are 
probably others.

 

You certainly have a point here. Problem – it’s hard to write a “standard” that 
would accommodate all cases.

 

There’s also the problem that there’s no standard for secure proof of 
possession for revocation, despite a number of us calling for one for years.  
This means losing control of your CSR can be dangerous as some Certification 
Authorities will accept them as proof of possession for revocation purposes.

 

Another good point.

 

 

From: Spasm  On Behalf Of Mike Ounsworth
Sent: Thursday, October 6, 2022 10:05 PM
To: Peter Gutmann ; von Oheimb, David 
; John Gray ; 
tomas.gustavs...@keyfactor.com
Cc: sp...@ietf.org; morgan...@dataio.com; tls@ietf.org
Subject: Re: [lamps] [TLS] [EXTERNAL] Re: Q: Creating CSR for encryption-only 
cert?

 

Hi Peter,

 

We grappled with that same question in our recent work on non-interactive KEM 
PoPs, and I have to admit, came up emptier than we expected.

 

See appendix A of:

 

https://eprint.iacr.org/2022/703

 

---

Mike Ounsworth

From: Peter Gutmann 
Sent: Thursday, October 6, 2022 8:51:17 PM
To: von Oheimb, David ; John Gray 
; Mike Ounsworth ; 
tomas.gustavs...@keyfactor.com 
Cc: sp...@ietf.org ; morgan...@dataio.com 
; tls@ietf.org 
Subject: Re: [TLS] [lamps] [EXTERNAL] Re: Q: Creating CSR for encryption-only 
cert? 

 

A general question, motivated by "I need a different hammer because the one
I'm currently using isn't able to pound screws in properly": Why is PoP
actually required?  And by this I don't mean "why is it in theory a good
thing", I mean what actual attack that's been actively exploited in the real
world will use of PoP prevent?  We've been shipping raw PKCS #10's around for
decades (with no PoP) without causing the collapse of civilisation.

Peter.

Any email and files/attachments transmitted with it are confidential and are 
intended solely for the use of the individual or entity to whom they are 
addressed. If this message has been sent to you in error, you must not copy, 
distribute or disclose of the information it contains. Please notify Entrust 
immediately and delete the message from your system. 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

TL;DR
Need to create a CSR for a key pair whose algorithm does not allow signing 
(either because it’s something like Kyber, or because restriction enforced by 
HSM). How to do it?

Longer version:

There are several use cases that require certifying long-term asymmetric keys 
that are only capable of encryption/decryption – but not signing/verification. 
That could be either because the algorithm itself does not do signing, or 
because the private key is generated and kept in a secure hardware that 
enforces usage restriction. 

One example of a protocol that needs this is KEMTLS - which I hope is accepted, 
either as-is, or with simplification.

CSR is supposed to be signed by the corresponding private key to prove 
possession. Obviously, it cannot be done with a key such as described above. 
How is this problem addressed in the real world?  With AuthKEM and KEMTLS, how 
would these protocols get their certificates?

A short discussion of this issue on the OpenSSL mailing list brought up 
Certificate Management Protocol (CMP) and CRMF format. Is that where we're 
heading? Are the "big CAs" on board with it?

Thanks!
-- 
V/R,
Uri
 




smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] OCSP and browsers

[Blumenthal, Uri - 0553 - MITLL]

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

 

For your use case – perhaps. For my – no way.

 

 

On Fri, Sep 16, 2022 at 11:43 AM Salz, Rich  
wrote:

I think this is of general interest, so I’m posting here rather than poking 
friends I know.

 

Browsers are phasing out doing OCSP queries themselves. The common 
justification, which makes sense to me, is that there are privacy concerns 
about leaking where a user is surfing.

 

My question is, what are browsers doing, and planning, on doing about OCSP 
stapled responses? I think there are three possibilities:

No stapled response

A stapled, valid, “good” response

A stapled, expired or “bad” response

 

I can imagine two possibilities, proceeding or popping up a warning page. I 
haven’t seen the warning when there is no OCSP response, but maybe that does 
happen.

 

We’re still going to staple good responses, when we have them, but I am 
wondering if long-term we should still bother?

 

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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Blumenthal, Uri - 0553 - MITLL]

+1 on the 3 proposed by Scott and P256+Kyber512 proposed by Kris. 

 

“Me too”: +1 to the above.

 

From: TLS  On Behalf Of Kris Kwiatkowski
Sent: Wednesday, August 17, 2022 3:31 PM
To: tls@ietf.org
I support those choices, but would also add P256+Kyber512.
* (1) same reason as below (by Scott)
* (2) to be able to declare security of generated keys in FIPS-mode for
  _both_ - classical and post-quantum schemes (once Kyber is standardized). 
After double-checking with NIST today, currently there is no clear plan for
updating SP 800-56A with X25519 (opposite to SP 800-186).

Kind regards,
Kris

On 8/17/22 20:06, Scott Fluhrer (sfluhrer) wrote:
So that we get an initial answer to this (so we can put it into the draft - of 
course, we can debate what's in the draft...)
 
Illari suggested:
 
X25519+Kyber768
P384+Kyber768
 
Well, I would suggest adding in
 
X25519+Kyber512
 
For those situations where we need to limit the message size (perhaps DTLS and 
QUIC).
 
Is the working group happy with that?
 
-Original Message-
From: TLS  On Behalf Of Ilari Liusvaara
Sent: Saturday, August 13, 2022 11:12 AM
To: TLS@ietf.org
Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
 
On Fri, Aug 12, 2022 at 06:13:38PM +, Scott Fluhrer (sfluhrer) wrote:
Again, this is late, however Stephen did ask this to be discussed in the
working group, so here we go:
 
-Original Message-
From: TLS  On Behalf Of Stephen Farrell
Sent: Saturday, April 30, 2022 11:49 AM
To: Ilari Liusvaara ; TLS@ietf.org
Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
 
 
Hiya,
 
On 30/04/2022 10:05, Ilari Liusvaara wrote:
On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote:
- section 5: IMO all combined values here need to have
recommended == "N" in IANA registries for a while and that needs
to be in this draft before it even gets parked. Regardless of
whether or not the WG agree with me on that, I think the current
text is missing stuff in this section and don't recall the WG
discussing that
 
I think that having recommended = Y for any combined algorithm
requires NIST final spec PQ part and recommended = Y for the
classical part (which allows things like x25519 to be the classical part).
 
That is, using latest spec for NISTPQC winner is not enough. This
impiles recommended = Y for combined algorithm is some years out
at the very least.
 
I agree, and something like the above points ought be stated in the
draft after discussion in the WG.
 
Section 5 is 'IANA considerations', and would be where we would list
the various supported hybrids, which we don’t at the moment.
 
Well, if we were to discuss some suggested hybrids (and we now know
the NIST selection), I would suggest these possibilities:
 
- X25519 + Kyber512
- P256 + Kyber512
- X448 + Kyber768
- P384 + Kyber768
 
I would take:
 
X25519+Kyber768
P384+Kyber768
 
The reason for taking Kyber768 is because the CRYSTALS team recommends
it. The reason for taking P384 is because it is CNSA-approved, so folks that
need CNSA can use that.
 
Of course, that is likely to bust packet size limits. I do not think that is an
issue in TLS, but DTLS and QUIC might be another matter entierely (in theory
DTLS and QUIC can handle it just fine, practice might be another matter
entierely. And if such problems are there, it is good to know about those...
This stuff is experimental).
 
 
Of course, it's possible that NIST will tweak the definition of Kyber;
that's just a possibility we'll need to live with (and wouldn't change
what hybrid combinations we would initially define)
 
I would think such changes would just mean the interim post-quantum kex is
not compatible with the final one. Not that big of deal, there are tens of
thoursands of free codepoints. If an implementation  needs both, it can
probably share vast majority of the code.
 
 
 
-Ilari



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Blumenthal, Uri - 0553 - MITLL]

Robert,

I can’t agree more. 

Except: Structured Lattices indeed have been around not as long as, e.g., RSA 
or ECC - but for how long have RSA or ECC have been around Bauer they were 
included in cryptographic protocols? Without Hybrid?

Thanks!

Regards,
Uri

> On Aug 9, 2022, at 16:58, Robert Relyea  wrote:
> 
> 
> On 8/6/22 11:40 AM, Phillip Hallam-Baker wrote:
>> +1
>> 
>> Anything the WG does has to be proof against Quantum Cryptanalysis and LoW 
>> (Laptops on Weekends). The fact that the broken algorithms did not get 
>> picked does not change the fact that they made it to the third round.
> Lumping all the algorithms together is just a strawman. Yes two algorithms 
> made it to the 3rd and were broken. The reason Rainbow wasn't picked was 
> because it was broken before the end of the 3rd round. Multivarient equations 
> sounded good at the beginning, but all forms and uses of multivarient have 
> been broken.
> 
> Sike was in the 3rd round as an alternate. It was an alternate precisely 
> because the idea had the least time in which people work pushing on it. I was 
> never going to be picked as the final in this round. The algorithms in the 
> alternate list are the precisely because they are interesting, but not proven.
> 
> Structured Lattice is in between. It's been around a lot longer then 
> Multivarient or SIKE, but not as long as ECC, RSA or classic Code Based 
> algorithms. It's good to be skeptical, but it's also time to start getting 
> experience with it.
> 
>>> 
>>> 
>>> 
>>> 
>>> On Sat, Aug 6, 2022 at 1:53 PM Stephen Farrell  
>>> wrote:
 
 
 On 06/08/2022 17:47, Phillip Hallam-Baker wrote:
 > Are you proposing pure Kyber or a hybrid though?
 
 I've not heard anyone suggest securing an IETF protocol
 only via PQC algs. It'd be incredibly dim to make that
 suggestion IMO, esp now that two of the 3rd round entries
 have been busted. So I'm not worried that we'd even come
 close to landing there for TLS.
>> 
>> hybrid is where we should be now. We should have some confidence in Kyber, 
>> but we have a lot of confidence in RSA and ECC.
>> 
>> The issue of Kyber isn't that 2 3rd round entries were busted. The worry is 
>> we are still learning about the potential gotcha's of  structured lattice. 
>> (You thought side channel attacks on RSA were bad, what until you  have to 
>> implement a secure lattice cypher).
>> 
>> bob
>> 
>>> S.
>> 
>> 
>> ___
>> 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


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Blumenthal, Uri - 0553 - MITLL]

In yesterday’s working group meeting we had a bit of a discussion of the impact 
of the sizes of post-quantum key exchange on TLS and related protocols like 
QUIC. As we neglected to put Kyber’s key sizes in our slide deck (unlike the 
signature schemes), I thought it would be a good idea to get the actual numbers 
of Kyber onto the mailing list.

Before we dive into applying the NIST algorithms to TLS 1.3 let us first 
consider our security goals and recalibrate accordingly.

 

That’s always a good idea.

 

I have the luxury of having 0 users. So I can completely redesign my 
architecture if needs be. But the deeper I have got into Quantum Computer 
Cryptanalysis (QCC) PQC, the less that appears to be necessary.

 

Respectfully disagree – though if all you got to protect is your TLS-secured 
purchases from Amazon.com, I’d concede the point.

 

First off, let us level set. Nobody has built a QC capable of QCC and it is 
highly unlikely anyone will in the next decade. 

 

You cannot know that, and “professional opinions” vary widely.

 

So, what we are concerned about today is data we exchange today being 
cryptanalyzed in the future. 

We can argue about that if people want but can we at least agree that our #1 
priority should be confidentiality.

 

Yes and yes.

 

So the first proposal I have is to separate our concerns into two separate 
parts with different timelines:

 

#1 Confidentiality, we should aim to deliver a standards based proposal by 2025.

 

If we (well, some of us) got the data today that mustn’t be disclosed a decade 
from now, then we do not have the luxury of waiting till 2025. Otherwise, see 
above.

 

#2 Fully QCC hardened spec before 2030.

 

If by “fully…” you mean “including PQ digital signatures”, I’d probably agree.

 

That immediately reduces our scope to confidentiality. QCC of signature keys is 
irrelevant as far as the priority is concerned. TLS can wait for the results of 
round 4 before diving into signatures at the very least.

 

TLS probably can… Impact of PQ signatures seems mostly to be in the size of 
certs and such, no conceptual difference (unlike KEM)…

 

[This is not the case for the Mesh as I need a mechanism that enables me to 
upgrade from my legacy base to a PQC system. The WebPKI should probably give 
some thought to these concerns as well. We should probably be talking about 
deploying PQC root keys but that is not in scope for TLS.]

 

No idea – therefore, no comment.

 

Second observation is that all we have at this point is the output of the NIST 
competition and that is not a KEM. No sorry, NIST has not approved a primitive 
that we can pass a private key to and receive that key back wrapped under the 
specified public key. What NIST actually tested was a function to which we pass 
a public key and get back a shared secret generated by the function and a blob 
that decrypts to the key.

 

The output of NIST PQC is exactly KEM. And it’s fully specified.

 

NIST did not approve 'KYBER' at least it has not done so yet. 

 

NIST did – what it did not do is finalizing the specs, which requires public 
review. Some people conjecture that Kyber will not need many changes to become 
a “full” standard.

 

Since we won't have that report within the priority timeline, I suggest people 
look at the function NIST tested which is a non-interactive key establishment 
protocol. If you want to use Kyber instead of the NIST output, you are going to 
have to wait for the report before we can start the standards process.

 

I don’t think I understood that, but, offhand, I disagree.

 

Third observation is that people are looking at how to replace existing modules 
in the TLS exchange rather than asking where the most appropriate point to 
deploy PQC is. I have faced that exact same problem in the Mesh and I have a 
rather bigger problem because the Mesh is all about Threshold cryptography and 
there is no NIST threshold PQC algorithm yet.

 

TLS protocol includes derivation of “session” keys. Currently it employs 
asymmetric “pre-Quantum” crypto. That has to be replaced by PQ asymmetric 
crypto. That’s the most appropriate (and the only) point to deploy PQC in. I’ve 
no clue about Mesh, so exclude Mesh from my comment.

 

The solution I am currently working with is to regard QCC at the same level as 
a single defection. So if Alice has established a separation of the decryption 
role between Bob and the Key Service, both have to defect (or be breached) for 
disclosure to occur. Until I get Threshold PQC, I am going to have to accept a 
situation in which the system remains secure against QCC but only if the key 
service does not defect.

 

Skipping the above.

 

Applying the same principles to TLS we actually have two key agreements in 
which we might employ PQC:

 

1) The primary key exchange

2) The forward secrecy / ephemeral / rekey

 

Looking at most of the proposals they seem to be looking to drop the PQC scheme 
into the ephemeral 

Re: [TLS] PQC key exchange sizes

[Blumenthal, Uri - 0553 - MITLL]

What are the implications for environments that require NIST Sec Level 3 or 5?

Regards,
Uri

> On Jul 26, 2022, at 11:33, Martin Thomson  wrote:
> 
> On Tue, Jul 26, 2022, at 11:21, Stephen Farrell wrote:
>> Be interested in how that'd change the CH if ECH is used too.
>> I guess the answer mightn't make us happy;-)
> 
> PQ HPKE would not fit, but the Kyber-512 numbers mean that we should be OK 
> for ECH if we stuck with classical security.  For obvious reasons, that might 
> not be OK though.
> 
> If we wanted a PQ HPKE (or a Hybrid KEM) then ECH would blow out the size so 
> that we would end up with multiple packets for the CH.  That would be 
> basically unworkable from a performance perspective.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Better TLS Client Authentication

[Blumenthal, Uri - 0553 - MITLL]

This is not about what was there earlier, nor what has been in wider use so far 
(in which case, password clearly wins ;). 

 

Rather – what is the best (from security and usability point of view) mechanism 
now. I say – FIDO (or U2F, whatever) is the closest contender, if not the 
outright winner.

 

Thanks

-- 

V/R,

Uri

 

 

From: TLS  on behalf of Phillip Hallam-Baker 

Date: Wednesday, May 25, 2022 at 21:01
To: Tim Cappalli 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Better TLS Client Authentication

 

If we are looking at installed footprint, then TLS Client Auth wins. Don't 
accuse me of re-inventing the wheel because TLS Client Auth predates FIDO by 
decades.

 

It is a completely different application though. FIDO was designed to enable 
use of physical authenticator tokens. As far as I can see, soft tokens are an 
afterthought, they don't have a strategy for provisioning multiple devices with 
a private key bound to the same account.

 

My starting point here was that I was looking at how to make use of the Mesh to 
support FIDO auth without the need for a physical token. That is the route I 
expected to take. It was only when I looked into it that I suddenly realized 
that I don't need any of that, I can do everything I need with legacy browsers 
and legacy servers. The only thing that changes is a client enrollment app on 
the client side and an authorization module in the server.

 

No protocol changes, just a certificate profile.

 

At this point FIDO has far less deployed base than TLS Client Auth, I am happy 
to support FIDO as well but why wouldn't we want both?

I really don't think I am the person suffering from Not Invented Here.

 

 

I can provide the same key mobility capabilities in WebAuthn so that users can 
register for a Web site with their phone browser and then log in from their 
laptop without requiring an additional registration while maintaining the 
End-to-End security of the private keys. But that would require some 
significant extensions to FIDO and be more of a FIDO3.

 

The security properties of WebAuthn and TLS Client Auth are very different.TLS 
Client Auth is not limited to Web for a start. We could use it to secure IMAP, 
POP3 and SUBMIT client auth.

 

 

 

On Tue, May 24, 2022 at 1:11 AM Tim Cappalli  wrote:

You mentioned FIDO, but I didn't see a reason why you don't want to use it. The 
industry has largely accepted the mature FIDO standards stack (WebAuthn & CTAP) 
as the strong authentication method that replaces passwords in a privacy 
preserving and phishing resistant manner.

 

Why create something new, especially using technologies that are not very user 
friendly?

 

tim

 

From: TLS  on behalf of Phillip Hallam-Baker 

Date: Sunday, May 22, 2022 at 23:28
To: tls@ietf.org 
Subject: [TLS] Better TLS Client Authentication

I am looking for people interested in discussing the following proposal to 
create a profile of TLS Client Authentication certificates to enable 
transparent Web Site authentication in Philadelphia:

 

I have a three step plan for eliminating Password Authentication

 

1) Deploy an open standards based, E2E secure password vault

2) Transition Web sites to use of public key authentication

3) Deploy a 2FA type scheme to address 'ceremony' use cases

 

I don't want to get into detail here, but I believe the trick to eliminating 
passwords is to deploy a password management solution in phase 1 that creates a 
sufficiently large base of users whose devices are provisioned with the 
necessary private keys to make use of public key auth practical.

 

So, I had assumed that this was all about enabling FIDO. But when I look at 
what I want to achieve and what legacy deployments provide, I suddenly realized 
I can do everything I need using TLS client auth. The only question is what the 
BEST way to do it is going to be.

 

 

So I have running code that can provision key pairs and credentials to every 
device Alice owns:

 

https://www.youtube.com/watch?v=zrBv717w8yY

 

It would not take a great deal of extra effort to provision certificates into 
the Windows/MAC/etc keystores so that IE, Edge, Firefox, Chrome, Safari, etc. 
etc. can all make use of the certificates. Its just a question of writing a 
script.

 

 

I am pretty sure I can get 'something' to work. But I would appreciate some 
help from folk who are closer to the real-world implementations. 

 

Reading through the specs, I think we can make it so that after an (optional) 
one time registration, Alice can just use the Web site without the need to ever 
log in ever again.

 

The only reason Alice would ever need to repeat registration is if the Web Site 
had some policy requiring Alice to affirm that yes, this really is her device 
and she agrees to terms. That is what I call 'ceremony' and it is not an 
authentication issue. I have another way of addressing that issue.

 

 

As far as I can tell, all that I really need is to write a certificate profile 

Re: [TLS] Better TLS Client Authentication

[Blumenthal, Uri - 0553 - MITLL]

+1 for FIDO

Regards,
Uri

> On May 24, 2022, at 01:11, Tim Cappalli 
>  wrote:
> 
> 
> You mentioned FIDO, but I didn't see a reason why you don't want to use it. 
> The industry has largely accepted the mature FIDO standards stack (WebAuthn & 
> CTAP) as the strong authentication method that replaces passwords in a 
> privacy preserving and phishing resistant manner.
>  
> Why create something new, especially using technologies that are not very 
> user friendly?
>  
> tim
>  
> From: TLS  on behalf of Phillip Hallam-Baker 
> 
> Date: Sunday, May 22, 2022 at 23:28
> To: tls@ietf.org 
> Subject: [TLS] Better TLS Client Authentication
> 
> I am looking for people interested in discussing the following proposal to 
> create a profile of TLS Client Authentication certificates to enable 
> transparent Web Site authentication in Philadelphia:
>  
> I have a three step plan for eliminating Password Authentication
>  
> 1) Deploy an open standards based, E2E secure password vault
> 2) Transition Web sites to use of public key authentication
> 3) Deploy a 2FA type scheme to address 'ceremony' use cases
>  
> I don't want to get into detail here, but I believe the trick to eliminating 
> passwords is to deploy a password management solution in phase 1 that creates 
> a sufficiently large base of users whose devices are provisioned with the 
> necessary private keys to make use of public key auth practical.
>  
> So, I had assumed that this was all about enabling FIDO. But when I look at 
> what I want to achieve and what legacy deployments provide, I suddenly 
> realized I can do everything I need using TLS client auth. The only question 
> is what the BEST way to do it is going to be.
>  
>  
> So I have running code that can provision key pairs and credentials to every 
> device Alice owns:
>  
> https://www.youtube.com/watch?v=zrBv717w8yY
>  
> It would not take a great deal of extra effort to provision certificates into 
> the Windows/MAC/etc keystores so that IE, Edge, Firefox, Chrome, Safari, etc. 
> etc. can all make use of the certificates. Its just a question of writing a 
> script.
>  
>  
> I am pretty sure I can get 'something' to work. But I would appreciate some 
> help from folk who are closer to the real-world implementations. 
>  
> Reading through the specs, I think we can make it so that after an (optional) 
> one time registration, Alice can just use the Web site without the need to 
> ever log in ever again.
>  
> The only reason Alice would ever need to repeat registration is if the Web 
> Site had some policy requiring Alice to affirm that yes, this really is her 
> device and she agrees to terms. That is what I call 'ceremony' and it is not 
> an authentication issue. I have another way of addressing that issue.
>  
>  
> As far as I can tell, all that I really need is to write a certificate 
> profile for BTCA certificates.
>  
> The thing that I am dropping here is the notion that certificates are bound 
> to anything other than a key. So all this is telling the site is that this is 
> the same person who came to the site before. It is not providing the user 
> credential PKIX is really all about.
>  
> I do have some questions though. In particular whether using X.448/Ed448 
> certs is practical.
>  
> The big downside to my current approach is that the certs that are used are 
> going to be super-linking identifiers. But we are currently losing that fight.
>  
>  
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Deprecating Obsolete Key Exchange Methods in TLS

[Blumenthal, Uri - 0553 - MITLL]

Following the discussions around draft-bartle-tls-deprecate-ffdh and 
draft-aviram-tls-deprecate-obsolete-kex, and after consulting the chairs, we 
have merged the two drafts into draft-aviram-tls-deprecate-obsolete-kex.

 

The merged draft prescribes the following:

RSA key exchange is a MUST NOT.
 

NIST PQC API is Key Encapsulation – conceptually similar to RSA key exchange.

 

Non-ephemeral finite-field DH is a MUST NOT.
 

Overkill, and unnecessary. Should be SHOULD NOT.

 

Non-ephemeral ECDH is a SHOULD NOT.
 

OK.

 

Ephemeral finite-field DH (DHE) is a MAY, only when fully ephemeral, and only 
using a well-known group of size at least 2048 bits.
 

Overkill, though requiring sufficiently large group size is fine.

 

 

We added greater justification for point 3 above to address concerns previously 
raised on the list.

 

We'd love to hear your thoughts.

 

best wishes,

Carrick and Nimrod



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Revised hybrid key exchange draft

[Blumenthal, Uri - 0553 - MITLL]

I don't see much benefit in the revised construction.

--
Regards,
Uri
 
There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 

On 1/24/22, 10:14, "TLS on behalf of D. J. Bernstein"  wrote:

Nimrod Aviram writes:
> To summarize, we recommend using our new proposed construction. It’s 
fast,
> easy to implement, and provides provable security.

The baseline construction is faster and is easier to implement, so
you're saying it doesn't provide "provable security"? Can you please
clarify what precisely you mean by "provable security" here? 

---Dan



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

The APOP attack demonstrates that concatenating secrets may be dangerous, as a 
general cryptographic practice.

 

I disagree with the word “general” here.

 

As to the TLS KDF, if future SHA256 cryptanalysis results in collisions,

 

Since (if memory serves me) KDF is HMAC-based, rather than merely SHA-based – 
it won’t matter from the security point of view whether SHA256 will or will not 
show collisions.

 

This likely violates the security proof for TLS 1.3, in and of itself.

 

I don’t think so.

 

A similar violation of the security guarantee seems to arise when using hybrid 
key exchange with a PQ KEM.

 

I absolutely don’t think so.

 

Or if that's what you're asking: As we write, we are unaware of a way to apply 
the APOP attack to the TLS KDF.

 

Excellent, thanks! I concur here.

 

We view this as an opportunity to defend-in-depth against such issues, while 
the document is not yet finalized.

 

I think we’re OK as-is.

 

 

On Wed, 1 Sept 2021 at 23:34, Blumenthal, Uri - 0553 - MITLL  
wrote:

How does the described AOAP attack apply to TLS KDF?

 

--

Regards,

Uri

 

There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

 

 

From: TLS  on behalf of Nimrod Aviram 

Date: Wednesday, September 1, 2021 at 15:58
To: "" 
Cc: Eylon Yogev , Ilan Komargodski , 
Benjamin Dowling , Eyal Ronen 
Subject: [TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3

 

(This note is also available on Github for ease of reading.)

 

This note identifies a possible security problem in the "Hybrid key exchange in
TLS 1.3" document, stemming from how cryptographic secrets are combined. In
short: constructions that concatenate secrets are vulnerable when the underlying
hash function is not collision-resistant. We are unaware of a full attack
that leverages the underlying problem. However, we view this as an opportunity
to defend-in-depth against such issues, while the document is not yet finalized.
We propose a new construction that seems robust to this potential issue, and we
are in the process of writing a technical report that includes a full security
proof.

# Concatenating Secrets May Be Dangerous

The APOP attack (see appendix for a brief description) demonstrates that
concatenating secrets to potentially attacker-controlled input might be
dangerous. Currently, the "Hybrid key exchange in TLS 1.3" document uses secret
concatenation as the preferred way to combine secrets. (This was an
understandable design choice given how little this issue has been studied.)

We recommend a defense-in-depth approach against this potential issue. We should
not concede to an attacker even the ability to cause a collision in an internal
state of the key schedule. Moreover, this part of TLS is likely particularly
amenable to ossification: Whatever we standardize will likely persist for 5-10
years. (We do note that TLS mixes in the client and server nonces, so additional
offensive techniques would be required to exploit this for a full attack.)

We note that concatenation is also used in the "TLS 1.3 Extended Key Schedule"
document.

# Our proposed construction

We have identified an alternative construction that we believe could provide
defense-in-depth against this issue. We are in the process of writing a
technical report that includes a full security proof.
The required assumptions on the hash function appear to be much milder than
collision resistance; instead, we likely only need multi-preimage-resistance:
Essentially, requiring only that computing preimages for multiple images is
hard.

The construction is: 
combined_key = H(HMAC(key=H1(k1), data=2||F(k2)) xor HMAC(key=H2(k2), 
data=1||F(k1))) 
where || denotes concatenation, H denotes the underlying hash function, and: 
H1(k) = H('derive1' || k) 
H2(k) = H('derive2' || k) 
F is defined as follows:
Let m denote the input to F. We split m into blocks, according to the block size
of H: 
m = m1||m2||...||mn 
Let j~=3 denote an “expanding factor” (the value chosen for j in practice
depends on how strong an assumption we want to rely on; we expect 3 to be 
enough).
Then 
F(m) = 
H(0||m1)||H(1||m1)||...||H(j-1||m1)||H(0||m2)||H(1||m2)||...||H(j-1||m2)||H(0||mn)||H(1||mn)||...||H(j-1||mn)

This construction is cheap to calculate and would be used only in the key
schedule, which is not a bottleneck for TLS performance.

# Adding another layer to the TLS key schedule may also be problematic

Another strategy for mixing secrets is to add the second secret to another layer
of the TLS key schedule. This strategy is already used to mix a PSK and an ECDHE
secret in TLS 1.3, as well as in AuthKEM, and it was also considered for the
Hybrid key exchange docum

Re: [TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

How does the described AOAP attack apply to TLS KDF?

 

--

Regards,

Uri

 

There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

 

 

From: TLS  on behalf of Nimrod Aviram 

Date: Wednesday, September 1, 2021 at 15:58
To: "" 
Cc: Eylon Yogev , Ilan Komargodski , 
Benjamin Dowling , Eyal Ronen 
Subject: [TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3

 

(This note is also available on Github for ease of reading.)

 

This note identifies a possible security problem in the "Hybrid key exchange in
TLS 1.3" document, stemming from how cryptographic secrets are combined. In
short: constructions that concatenate secrets are vulnerable when the underlying
hash function is not collision-resistant. We are unaware of a full attack
that leverages the underlying problem. However, we view this as an opportunity
to defend-in-depth against such issues, while the document is not yet finalized.
We propose a new construction that seems robust to this potential issue, and we
are in the process of writing a technical report that includes a full security
proof.

# Concatenating Secrets May Be Dangerous

The APOP attack (see appendix for a brief description) demonstrates that
concatenating secrets to potentially attacker-controlled input might be
dangerous. Currently, the "Hybrid key exchange in TLS 1.3" document uses secret
concatenation as the preferred way to combine secrets. (This was an
understandable design choice given how little this issue has been studied.)

We recommend a defense-in-depth approach against this potential issue. We should
not concede to an attacker even the ability to cause a collision in an internal
state of the key schedule. Moreover, this part of TLS is likely particularly
amenable to ossification: Whatever we standardize will likely persist for 5-10
years. (We do note that TLS mixes in the client and server nonces, so additional
offensive techniques would be required to exploit this for a full attack.)

We note that concatenation is also used in the "TLS 1.3 Extended Key Schedule"
document.

# Our proposed construction

We have identified an alternative construction that we believe could provide
defense-in-depth against this issue. We are in the process of writing a
technical report that includes a full security proof.
The required assumptions on the hash function appear to be much milder than
collision resistance; instead, we likely only need multi-preimage-resistance:
Essentially, requiring only that computing preimages for multiple images is
hard.

The construction is: 
combined_key = H(HMAC(key=H1(k1), data=2||F(k2)) xor HMAC(key=H2(k2), 
data=1||F(k1))) 
where || denotes concatenation, H denotes the underlying hash function, and: 
H1(k) = H('derive1' || k) 
H2(k) = H('derive2' || k) 
F is defined as follows:
Let m denote the input to F. We split m into blocks, according to the block size
of H: 
m = m1||m2||...||mn 
Let j~=3 denote an “expanding factor” (the value chosen for j in practice
depends on how strong an assumption we want to rely on; we expect 3 to be 
enough).
Then 
F(m) = 
H(0||m1)||H(1||m1)||...||H(j-1||m1)||H(0||m2)||H(1||m2)||...||H(j-1||m2)||H(0||mn)||H(1||mn)||...||H(j-1||mn)

This construction is cheap to calculate and would be used only in the key
schedule, which is not a bottleneck for TLS performance.

# Adding another layer to the TLS key schedule may also be problematic

Another strategy for mixing secrets is to add the second secret to another layer
of the TLS key schedule. This strategy is already used to mix a PSK and an ECDHE
secret in TLS 1.3, as well as in AuthKEM, and it was also considered for the
Hybrid key exchange document. This strategy is vulnerable as well to collisions
in the underlying hash function, and we propose using one secure construction
for mixing secrets.

Consider a standard PSK+ECDHE TLS 1.3 handshake. Then 
handshake_secret = HKDF_Extract(IKM=ECDHE_secret, 
salt=Derive_Secret(early_secret)) 
early_secret = HKDF_Extract(IKM=PSK, salt=000) 
HKDF_Extract(IKM, salt) = HMAC(k=salt, data=IKM)

Therefore, early_secret = HMAC(k=000, data=PSK). 
Assume a non-collision-resistant hash function. Then an attacker that can
establish multiple PSKs of their choice with another party can cause two
sessions with two different PSKs to share the same early_secret. If the other
party reuses ECDH(E) values, the attacker can also cause the handshake_secret to
be identical.

Furthermore, 
Client_Handshake_Traffic_Secret = 
  HMAC(k=Handshake_Secret, data=Label||H(ClientHello...ServerHello)) 
If the attacker is the server, and the hash function allows for chosen-prefix
collisions, the attacker can choose two ServerHello messages such that for two
different ClientHello messages, 

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

[Blumenthal, Uri - 0553 - MITLL]

A closer look at your referenced CVEs suggests these can be classified as (i) 
lack of checking for improperly generated DH groups; (ii) exploiting 
overflow/underflow/carry bugs. To me, nothing seems to be new here and more 
likely a failure of implementers to heed to results and advice predating the 
CVEs by years (and sometimes decades) or in QA processes. E.g., with respect to 
(i), one had not gotten oneself into trouble if one had actually bothered to 
implement domain parameter checks. In the literature of implementation attacks, 
OpenSSL has proven to be an excellent "implementation security flaw paper 
generator".

 

I have yet to see evidence that ephemeral-static ECDH would be inherently 
insecure.

 

If a consistent history of directly linked vulnerabilities across major 
implementations doesn't show something is unsafe, I don't think there is 
progress to be made in the discussion. Blaming the implementers is not 
particularly interesting to me.

 

First, is this the only mode that has “directly linked vulnerabilities”? 
Second, cutting corners (e.g., for performance sake) by omitting domain 
parameters check, or not taking care of over/underflow, and such, cannot be 
considered a “protocol or algorithm fault”. Blame who you want, but the facts 
are here.

 

 

Anyway, I don't have an opinion on SHOULD NOT vs MUST NOT, as long as it leads 
to Recommended: N in the registry.

 

“MUST NOT” => “if you do that, you’re not compliant, period”.

“SHOULD NOT” => “don’t do that, unless you have very good reasons, and can 
explain to your customers why it’s really OK in that particular case”.

 

Correct, both should lead to “Not Recommended”.

 

 

On 2021-08-27 9:34 a.m., Filippo Valsorda wrote:

[snip] 

 

This is empirically disproved by a number of vulnerabilities that are 
exploitable (or near-misses for other reasons) only in ephemeral-static mode, 
such as CVE-2016-0701, CVE-2016-7055, CVE-2017-3732, CVE-2017-3736, 
CVE-2017-3738, CVE-2019-1551 just in the past 5 years in OpenSSL, and 
CVE-2017-8932 and CVE-2021-3114 in Go. https://eprint.iacr.org/2011/633 gives a 
good explanation of how these attacks work, and you might find 
https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squeezing-A-Key-Through-A-Carry-Bit-wp.pdf
 interesting as well.

OpenSSL:

CVE-2016-0701: improper generation of Diffie-Hellman group

The DH_check_pub_key function in crypto/dh/dh_check.c in OpenSSL 1.0.2 before 
1.0.2f does not ensure that prime numbers are appropriate for Diffie-Hellman 
(DH) key exchange, which makes it easier for remote attackers to discover a 
private DH exponent by making multiple handshakes with a peer that chose an 
inappropriate number, as demonstrated by a number in an X9.42 file.

CVE-2016-7055: carry-propagation bug

There is a carry propagating bug in the Broadwell-specific Montgomery 
multiplication procedure in OpenSSL 1.0.2 and 1.1.0 before 1.1.0c that handles 
input lengths divisible by, but longer than 256 bits. Analysis suggests that 
attacks against RSA, DSA and DH private keys are impossible. This is because 
the subroutine in question is not used in operations with the private key 
itself and an input of the attacker's direct choice. Otherwise the bug can 
manifest itself as transient authentication and key negotiation failures or 
reproducible erroneous outcome of public-key operations with specially crafted 
input. Among EC algorithms only Brainpool P-512 curves are affected and one 
presumably can attack ECDH key negotiation. Impact was not analyzed in detail, 
because pre-requisites for attack are considered unlikely. Namely multiple 
clients have to choose the curve in question and the server has to share the 
private key among them, neither of which is default behaviour. Even then only 
clients that chose the curve will be affected.

CVE-2017-3732: carry-propagation bug

There is a carry propagating bug in the x86_64 Montgomery squaring procedure in 
OpenSSL 1.0.2 before 1.0.2k and 1.1.0 before 1.1.0d. No EC algorithms are 
affected. Analysis suggests that attacks against RSA and DSA as a result of 
this defect would be very difficult to perform and are not believed likely. 
Attacks against DH are considered just feasible (although very difficult) 
because most of the work necessary to deduce information about a private key 
may be performed offline. The amount of resources required for such an attack 
would be very significant and likely only accessible to a limited number of 
attackers. An attacker would additionally need online access to an unpatched 
system using the target private key in a scenario with persistent DH parameters 
and a private key that is shared between multiple clients. For example this can 
occur by default in OpenSSL DHE based SSL/TLS ciphersuites. Note: This issue is 
very similar to CVE-2015-3193 but must be treated as a separate problem.

CVE-2017-3736: carry-propagation bug

There is a carry propagating bug in the x86_64 

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

[Blumenthal, Uri - 0553 - MITLL]

Static-ephemeral is not “so unsafe to implement”, not any more than any other 
mode. It shouldn’t be encouraged, but shouldn’t be killed off either.

 

This is empirically disproved by a number of vulnerabilities that are 
exploitable (or near-misses for other reasons) only in ephemeral-static mode, 
such as CVE-2016-0701, CVE-2016-7055, CVE-2017-3732, CVE-2017-3736, 
CVE-2017-3738, CVE-2019-1551 just in the past 5 years in OpenSSL, and 
CVE-2017-8932 and CVE-2021-3114 in Go. https://eprint.iacr.org/2011/633 gives a 
good explanation of how these attacks work, and you might find 
https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squeezing-A-Key-Through-A-Carry-Bit-wp.pdf
 interesting as well.

 

Anyway, we keep going in circles around what deprecation is. In my opinion, an 
IETF deprecation doesn't "kill off" anything, it just says it's not encouraged, 
so it sounds like you support deprecation in those terms.

 

Do we agree on “SHOULD NOT”?

 

 

On Sun, Aug 22, 2021 at 9:32 PM Carrick Bartle  wrote:

>   which is a main reason cited for deprecating RSA in 
> draft-aviram-tls-deprecate-obsolete-kex.

 

Have the authors look at Post-Quantum KEMs?

 

I'm not sure why PQ KEMs are relevant here.

 

 

On Aug 17, 2021, at 10:41 AM, Blumenthal, Uri - 0553 - MITLL  
wrote:

 

>  Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do not 
> provide

>  forward secrecy,

 

Unless you use semi-static exchange, which in many cases makes sense.

 

>   which is a main reason cited for deprecating RSA in 
> draft-aviram-tls-deprecate-obsolete-kex.

 

Have the authors look at Post-Quantum KEMs?

 

>  Do you object to just the citation of the Raccoon attack or do you also feel 
> that we

>  should keep these ciphersuites that do not provide forward secrecy around?

 

I think these suites should stay around. 

 

While static-static indeed do not provide forward secrecy (and many of us – 
though not everybody! – carry for that), static-ephemeral DH and ECDH are 
perfectly fine from that point of view.

 

 

 

On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL 
 wrote:

I agree with Rene’s points.

 

-- 

Regards,

Uri

 

 

From: TLS  on behalf of Rene Struik 

Date: Friday, August 13, 2021 at 09:58

Dear colleagues:

 

I think this document should absolutely *not* be adopted, without providing far 
more technical justification. The quoted Raccoon attack is an easy to mitigate 
attack (which has nothing to do with finite field groups, just with poor design 
choices of postprocessing, where one uses variable-size integer representations 
for a key). There are also good reasons to have key exchanges where one of the 
parties has a static key, whether ecc-based or ff-based (e.g., sni, opaque), 
for which secure implementations are known. No detail is provided and that 
alone should be sufficient reason to not adopt.

 

Rene

 

On 2021-07-29 5:50 p.m., Joseph Salowey wrote:

This is a working group call for adoption for Deprecating FFDH(E) Ciphersuites 
in TLS (draft-bartle-tls-deprecate-ffdhe-00). We had a presentation for this 
draft at the IETF 110 meeting and since it is a similar topic to the key 
exchange deprecation draft the chairs want to get a sense if the working group 
wants to adopt this draft (perhaps the drafts could be merged if both move 
forward).  Please review the draft and post your comments to the list by 
Friday, August 13, 2021.  

 

Thanks,

 

The TLS chairs

 

___

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls

 

-- 

email: rstruik@gmail.com | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

___

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

 

 

 

Attachments:

· smime.p7s

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

Thanks for all the discussion on this topic.  There are several modes that TLS 
1.2 can operate with respect to DH.  Below is a proposal on cases to merge some 
of the cases covered by this draft into the obsolete keyex draft.  I'd like to 
see if there is some consensus to make this change before we adopt it into the 
working group. 

 

static-static where both client and server have DH certificates with long term 
keys.  I think we have general consensus that this mode should be a must not.  
To deprecate this mode I think we need to state that clients MUST NOT use 
certificates of type rsa_fixed_dh and dsa_fixed_dh and server MUST NOT request 
them.  Would the working group support merging this guidance into the obsolete 
keyex draft?  
 

Static-static is OK only when coupled with ephemeral (for forward secrecy), 
using the static part for implicit mutual authentication. Not good when used 
“alone”. Within the TLS context, OK to “MUST NOT”.

 

ephemeral-static where the client uses an ephemeral key and the server uses a 
long term key.  This mode does not provide forward secrecy.  I'm not sure we 
have reached consensus on how far to deprecate this option.  Would the working 
group support MUST NOT use these ciphersuites unless forward secrecy does not 
matter for your use case and any implementation guidance provided to avoid 
weaknesses is followed?
Forward secrecy here is “asymmetric”: “server fails” -> “secrecy fails”. There 
are use cases…

I recommend “SHOULD NOT” here.

 

[FV] The implementation guidance to avoid weaknesses in any ephemeral-static 
exchange is "don't get anything wrong, anything at all, all the way down to 
your field arithmetic libraries". I don't think that's a workable 
recommendation, and I believe we should deprecate modes that are so unsafe to 
implement.

 

Static-ephemeral is not “so unsafe to implement”, not any more than any other 
mode. It shouldn’t be encouraged, but shouldn’t be killed off either.

 

ephemeral-ephemeral  - I think these are already covered in the obsolete keyex 
draft. 
Absolutely no reason to deprecate or obsolete this mode.

 

 

On Sun, Aug 22, 2021 at 9:32 PM Carrick Bartle  wrote:

>   which is a main reason cited for deprecating RSA in 
> draft-aviram-tls-deprecate-obsolete-kex.

 

Have the authors look at Post-Quantum KEMs?

 

I'm not sure why PQ KEMs are relevant here.

 

 

On Aug 17, 2021, at 10:41 AM, Blumenthal, Uri - 0553 - MITLL  
wrote:

 

>  Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do not 
> provide

>  forward secrecy,

 

Unless you use semi-static exchange, which in many cases makes sense.

 

>   which is a main reason cited for deprecating RSA in 
> draft-aviram-tls-deprecate-obsolete-kex.

 

Have the authors look at Post-Quantum KEMs?

 

>  Do you object to just the citation of the Raccoon attack or do you also feel 
> that we

>  should keep these ciphersuites that do not provide forward secrecy around?

 

I think these suites should stay around. 

 

While static-static indeed do not provide forward secrecy (and many of us – 
though not everybody! – carry for that), static-ephemeral DH and ECDH are 
perfectly fine from that point of view.

 

 

 

On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL 
 wrote:

I agree with Rene’s points.

 

-- 

Regards,

Uri

 

 

From: TLS  on behalf of Rene Struik 

Date: Friday, August 13, 2021 at 09:58

Dear colleagues:

 

I think this document should absolutely *not* be adopted, without providing far 
more technical justification. The quoted Raccoon attack is an easy to mitigate 
attack (which has nothing to do with finite field groups, just with poor design 
choices of postprocessing, where one uses variable-size integer representations 
for a key). There are also good reasons to have key exchanges where one of the 
parties has a static key, whether ecc-based or ff-based (e.g., sni, opaque), 
for which secure implementations are known. No detail is provided and that 
alone should be sufficient reason to not adopt.

 

Rene

 

On 2021-07-29 5:50 p.m., Joseph Salowey wrote:

This is a working group call for adoption for Deprecating FFDH(E) Ciphersuites 
in TLS (draft-bartle-tls-deprecate-ffdhe-00). We had a presentation for this 
draft at the IETF 110 meeting and since it is a similar topic to the key 
exchange deprecation draft the chairs want to get a sense if the working group 
wants to adopt this draft (perhaps the drafts could be merged if both move 
forward).  Please review the draft and post your comments to the list by 
Friday, August 13, 2021.  

 

Thanks,

 

The TLS chairs

 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
 
-- 
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
___

TLS mailing list

TLS@ietf.org

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

[Blumenthal, Uri - 0553 - MITLL]

On 8/17/21, 16:16, "Benjamin Kaduk"  wrote:
>On Tue, Aug 17, 2021 at 07:25:33PM +0000, Blumenthal, Uri - 0553 - MITLL 
> wrote:
>> I see absolutely nothing wrong with using FFDH(E) and ECDH, 
>> as long as at least one of the keys is ephemeral.
>> There is no need to “warn away”, IMHO. 

>That's an interesting position to take.  Let me see if I understand it 
> correctly.
>(I will just write "DH" even though I mean (EC)DH.)

And a very nice analysis, thank you!

>Static-static DH results in re-generating the same derived key on multiple 
> protocol
>instantiations, which is in some sense reusing a single key for multiple 
> things and
>thus disrecommended. .  .  .  . So there's plenty of risk here and reasons 
> to stay away.

Correct. Agreed.

>Ephemeral-static DH makes a new derived key for each protocol 
> instantiation and
>simplifies the analysis  .  .  .  but anyone armed with a protocol 
> transcript
>who discovers the secret part of the static DH value can recover the 
> derived
>key and deprotect the application data.  Forward secrecy is not obtained 
> until
>the "static" private value is discarded, leaving risk of loss
>of confidentiality due to endpoint compromise.

Correct. Relative risks and concerns of client vs. server security are out of 
scope for
this discussion.

>Ephemeral-ephemeral DH also makes a new derived key for each protocol 
> instantiation,
>but also allows the private DH values to be discarded "immediately",  .  . 
>  .  .  .

I'd say, "*requires* the private DH values to be discarded 'immediately'".

>This provides the strongest kind of forward secrecy (provided that 
> endpoints
>actually discard the private ephemeral values), and is again a step up from
>the ephemeral-static case.

It certainly is, and IMHO it's the preferred way, unless realities (of the 
environment, etc.) disallow it.

>In light of the above, it seems that your concerns are more focused on 
> "key reuse" than
>forward secrecy.  Is that correct?

Ha! Both are important, but absolutely - "key reuse" is a much bigger (and 
immediate!) concern.
In my environment there are other ways to mitigate (not alleviate completely!) 
the threat to
forward secrecy.

>I have heard a lot of people saying that forward secrecy is important to 
> them, so it's
>not clear that your stance is the consensus position.

I cannot claim consensus. Forward secrecy is probably as important to me as it 
is to the next guy - it's about the price I'd have to pay for it, the relative 
(not necessarily monetary) cost, and the willingness to consider other 
mitigation methods.

Thanks!


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

I see absolutely nothing wrong with using FFDH(E) and ECDH, as long as at least 
one of the keys is ephemeral. There is no need to “warn away”, IMHO. 

Regards,
Uri

> On Aug 17, 2021, at 15:19, Salz, Rich  
> wrote:
> 
> 
> I still support adoption, as I said a couple of weeks ago. I also still think 
> we should consider merging this and 
> draft-aviram-tls-deprecate-obsolete-kex-00.
>  
> I know that I’ve also said this before (can’t find it in my “sent mail” 
> folder), but the fact that some communities can still use this safely, or 
> must use it (for a variety of reasons usually around the infeasibility of 
> upgrading), doesn’t mean that the general populace should not be warned away 
> from doing these kinds of things.
>  
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

>  Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do not 
>provide

>  forward secrecy,

 

Unless you use semi-static exchange, which in many cases makes sense.

 

>   which is a main reason cited for deprecating RSA in 
> draft-aviram-tls-deprecate-obsolete-kex.

 

Have the authors look at Post-Quantum KEMs?

 

>  Do you object to just the citation of the Raccoon attack or do you also feel 
> that we

>  should keep these ciphersuites that do not provide forward secrecy around?

 

I think these suites should stay around. 

 

While static-static indeed do not provide forward secrecy (and many of us – 
though not everybody! – carry for that), static-ephemeral DH and ECDH are 
perfectly fine from that point of view.

 

 

 

On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL 
 wrote:

I agree with Rene’s points.

 

-- 

Regards,

Uri

 

 

From: TLS  on behalf of Rene Struik 

Date: Friday, August 13, 2021 at 09:58

Dear colleagues:

 

I think this document should absolutely *not* be adopted, without providing far 
more technical justification. The quoted Raccoon attack is an easy to mitigate 
attack (which has nothing to do with finite field groups, just with poor design 
choices of postprocessing, where one uses variable-size integer representations 
for a key). There are also good reasons to have key exchanges where one of the 
parties has a static key, whether ecc-based or ff-based (e.g., sni, opaque), 
for which secure implementations are known. No detail is provided and that 
alone should be sufficient reason to not adopt.

 

Rene

 

On 2021-07-29 5:50 p.m., Joseph Salowey wrote:

This is a working group call for adoption for Deprecating FFDH(E) Ciphersuites 
in TLS (draft-bartle-tls-deprecate-ffdhe-00). We had a presentation for this 
draft at the IETF 110 meeting and since it is a similar topic to the key 
exchange deprecation draft the chairs want to get a sense if the working group 
wants to adopt this draft (perhaps the drafts could be merged if both move 
forward).  Please review the draft and post your comments to the list by 
Friday, August 13, 2021.  

 

Thanks,

 

The TLS chairs

 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
 
-- 
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

I agree with Rene’s points.

 

-- 

Regards,

Uri

 

 

From: TLS  on behalf of Rene Struik 

Date: Friday, August 13, 2021 at 09:58

Dear colleagues:

 

I think this document should absolutely *not* be adopted, without providing far 
more technical justification. The quoted Raccoon attack is an easy to mitigate 
attack (which has nothing to do with finite field groups, just with poor design 
choices of postprocessing, where one uses variable-size integer representations 
for a key). There are also good reasons to have key exchanges where one of the 
parties has a static key, whether ecc-based or ff-based (e.g., sni, opaque), 
for which secure implementations are known. No detail is provided and that 
alone should be sufficient reason to not adopt.

 

Rene

 

On 2021-07-29 5:50 p.m., Joseph Salowey wrote:

This is a working group call for adoption for Deprecating FFDH(E) Ciphersuites 
in TLS (draft-bartle-tls-deprecate-ffdhe-00). We had a presentation for this 
draft at the IETF 110 meeting and since it is a similar topic to the key 
exchange deprecation draft the chairs want to get a sense if the working group 
wants to adopt this draft (perhaps the drafts could be merged if both move 
forward).  Please review the draft and post your comments to the list by 
Friday, August 13, 2021.  

 

Thanks,

 

The TLS chairs



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
 
-- 
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt

[Blumenthal, Uri - 0553 - MITLL]

>>> - can cache or fetch the peer public keys in order to do KEMTLS
>> I did not say that. As far as I can tell now, there's no way to fetch 
> (outside/OOB of this protocol) peer's pub keys or certs.
>
>draft-ietf-tls-esni does it with DNS HTTPS RRs, but indeed it would 
> require new efforts to make it happen with additional operational challenges.

Most likely it won't work in my environment, but need to check.

>If caching the peer public key is an option for your use case, then cache 
> management could be an operational challenge for clients that talk to many 
> peers.

Exactly! 

Open question for now.

>If caching peer public keys is not an option either, then you will have to 
> pay the price of an extra round-trip to get the peer KEM public key. 

Yes, and this is what we've been planning for. In general, one extra round-trip 
is not a "pain point" for my use case, as long as one round-trip fits into the 
link constraints.

Now that you mentioned the possibility of caching keys, and paying that extra 
round-trip price only once - we'll evaluate the implementation costs of doing 
that.

Thanks!

    -----Original Message-
From: Blumenthal, Uri - 0553 - MITLL  
Sent: Thursday, July 22, 2021 8:49 AM
To: Kampanakis, Panos 
Cc: tls@ietf.org; Douglas Stebila ; Eric Rescorla 

Subject: RE: [EXTERNAL] [TLS] Comments on 
draft-celi-wiggers-tls-authkem-00.txt

On Jul 22, 2021, at 00:46, Kampanakis, Panos  wrote:
> 
> Hi Uri,
> 
> Thank you for the clarifications. 
> 
> So you have a usecase that 
> - want to use PQ algorithms
> - is significantly affected by an extra 1-2 or 4-5KB on the link
> - does not send a cert chain, only leaf certs

Yes. 

> - can cache or fetch the peer public keys in order to do KEMTLS

I did not say that. As far as I can tell now, there's no way to fetch 
(outside/OOB of this protocol) peer's pub keys or certs. 

Caching received and validated keys to ease the reconnects is an 
interesting idea. I'll need to figure whether the comm savings outweigh the 
extra complexity and branching of the protocol. 

> Although I don't consider it the general usecase, maybe KEMTLS is the way 
to go there. 

I'm 99.9% sure it is.

> Other good options imo for it would be draft-ietf-tls-ctls and rfc7924 to 
save even more on data put on the link.

Thank you! Seems applicable - let me check. 

Thanks

> -Original Message-
> From: Blumenthal, Uri - 0553 - MITLL  
> Sent: Tuesday, July 13, 2021 1:17 AM
> To: Kampanakis, Panos 
> Cc:  ; Douglas Stebila ; 
Eric Rescorla 
> Subject: RE: [EXTERNAL] [TLS] Comments on 
draft-celi-wiggers-tls-authkem-00.txt
> 
>> If we are talking NIST Level 5 (and I am assuming you are
>> discussing mTLS), 
> 
> Yes. ;-)
> 
>> ...have you calculated the total CertVerify+cert chain sizes
>> there assuming 2 ICAs let's say? 
> 
> More or less. ;-)
> 
> My use case has all the ICAs pre-loaded - the transmitted chain contains 
only one entity cert. I'm sacrificing flexibility for performance under 
constraints. Size is the real enemy here.
> 
> 
>> And would constrained devices or mediums that sweat about 5KB
>> really be able to support PQ KEMs and Sigs at NIST Level 5?
> 
> My tests showed that they *do* support PQ KEMs (NTRU and Kyber - haven't 
tried McEliece ;) and Sigs (Falcon and Dilithium - haven't tried Rainbow ;) at 
Level 5. Caveat - they do only Sig *verification* (which suits me fine).
> 
> (I posted benchmarks from Intel Core i9, but they work acceptably well on 
the "smaller" chips.)
> 
> Also, sorry if I did not make it clear - it's not the *devices* 
themselves that sweat 5KB, it's their austere links.
> 
> 
> 
>-Original Message-
>From: TLS  On Behalf Of Blumenthal, Uri - 0553 - 
MITLL
>Sent: Monday, July 12, 2021 11:39 PM
>To: Douglas Stebila ; Eric Rescorla 
>Cc:  
>Subject: RE: [EXTERNAL] [TLS] Comments on 
draft-celi-wiggers-tls-authkem-00.txt
> 
>CAUTION: This email originated from outside of the organization. Do 
not click links or open attachments unless you can confirm the sender and know 
the content is safe.
> 
> 
> 
>Let me emphasize the reasons Douglas brought up. Note that I need to 
use NIST Sec Level 5 algorithms. So, Kyber-1024 and Dilithium5 (other 
algorithms show even worse ratio between KEM and signature!).
> 
>Communications costs:
>- Difference in public key sizes: 1568 bytes of Kyber vs. 2592 bytes 
of Dilithium =>

Re: [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt

[Blumenthal, Uri - 0553 - MITLL]

On Jul 22, 2021, at 00:46, Kampanakis, Panos  wrote:
> 
> Hi Uri,
> 
> Thank you for the clarifications. 
> 
> So you have a usecase that 
> - want to use PQ algorithms
> - is significantly affected by an extra 1-2 or 4-5KB on the link
> - does not send a cert chain, only leaf certs

Yes. 

> - can cache or fetch the peer public keys in order to do KEMTLS

I did not say that. As far as I can tell now, there's no way to fetch 
(outside/OOB of this protocol) peer's pub keys or certs. 

Caching received and validated keys to ease the reconnects is an interesting 
idea. I'll need to figure whether the comm savings outweigh the extra 
complexity and branching of the protocol. 

> Although I don't consider it the general usecase, maybe KEMTLS is the way to 
> go there. 

I'm 99.9% sure it is.

> Other good options imo for it would be draft-ietf-tls-ctls and rfc7924 to 
> save even more on data put on the link.

Thank you! Seems applicable - let me check. 

Thanks

> -----Original Message-
> From: Blumenthal, Uri - 0553 - MITLL  
> Sent: Tuesday, July 13, 2021 1:17 AM
> To: Kampanakis, Panos 
> Cc:  ; Douglas Stebila ; Eric 
> Rescorla 
> Subject: RE: [EXTERNAL] [TLS] Comments on 
> draft-celi-wiggers-tls-authkem-00.txt
> 
>> If we are talking NIST Level 5 (and I am assuming you are
>> discussing mTLS), 
> 
> Yes. ;-)
> 
>> ...have you calculated the total CertVerify+cert chain sizes
>> there assuming 2 ICAs let's say? 
> 
> More or less. ;-)
> 
> My use case has all the ICAs pre-loaded - the transmitted chain contains only 
> one entity cert. I'm sacrificing flexibility for performance under 
> constraints. Size is the real enemy here.
> 
> 
>> And would constrained devices or mediums that sweat about 5KB
>> really be able to support PQ KEMs and Sigs at NIST Level 5?
> 
> My tests showed that they *do* support PQ KEMs (NTRU and Kyber - haven't 
> tried McEliece ;) and Sigs (Falcon and Dilithium - haven't tried Rainbow ;) 
> at Level 5. Caveat - they do only Sig *verification* (which suits me fine).
> 
> (I posted benchmarks from Intel Core i9, but they work acceptably well on the 
> "smaller" chips.)
> 
> Also, sorry if I did not make it clear - it's not the *devices* themselves 
> that sweat 5KB, it's their austere links.
> 
> 
> 
>-Original Message-
>From: TLS  On Behalf Of Blumenthal, Uri - 0553 - 
> MITLL
>Sent: Monday, July 12, 2021 11:39 PM
>To: Douglas Stebila ; Eric Rescorla 
>Cc:  
>Subject: RE: [EXTERNAL] [TLS] Comments on 
> draft-celi-wiggers-tls-authkem-00.txt
> 
>CAUTION: This email originated from outside of the organization. Do not 
> click links or open attachments unless you can confirm the sender and know 
> the content is safe.
> 
> 
> 
>Let me emphasize the reasons Douglas brought up. Note that I need to use 
> NIST Sec Level 5 algorithms. So, Kyber-1024 and Dilithium5 (other algorithms 
> show even worse ratio between KEM and signature!).
> 
>Communications costs:
>- Difference in public key sizes: 1568 bytes of Kyber vs. 2592 bytes of 
> Dilithium => 1024 extra bytes to carry over channel each way;
>- Signature: extra 4595 bytes each way, because in addition to exchanging 
> certs (aka "signed public keys", which is inevitable) you need to sign the 
> exchange and communicate that signature across;
>- Total: 5619 extra bytes each way. For peer-to-peer broadband 
> connections, you can say "so what?". But my links are *very* austere.
> 
>Computation costs (ballpark, on a powerful CPU):
>- KEM: keygen 15us, encap 18us, decap 14us (say, double encap and decap 
> for PFS-providing exchange);
>- Signature: sign 113us, verify 55us;
>- Comparison: 134us for signature-less KEM vs. 215us for TLS-like exchange 
> => almost twice as long;
>- Difference may be negligible for Intel Xeon, but for my much weaker 
> hardware it matters.
> 
>So, for constrained environments with austere comm links, signature-less 
> "authkem" is God-sent.
>Big servers that need to support many clients (so they care how much CPU 
> cycles and comm bytes they spend on every connection) would appreciate these 
> savings too.
> 
>@ekr,I hope this provides convincing explanation why "authkem" is needed.
> 
>P.S. I know that Falcon has much more favorable sizes - but (a) it takes 
> three times as long to sign, and (b) it uses FP calculations, which isn't 
> great to implement in my environment.
>--
>Regards,
>Uri
> 
>There are two ways to design a system. One is to make is so simple there 
> are obviously no deficiencies.
>

Re: [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt

[Blumenthal, Uri - 0553 - MITLL]

> If we are talking NIST Level 5 (and I am assuming you are
> discussing mTLS), 

Yes. ;-)

> ...have you calculated the total CertVerify+cert chain sizes
> there assuming 2 ICAs let's say? 

More or less. ;-)

My use case has all the ICAs pre-loaded - the transmitted chain contains only 
one entity cert. I'm sacrificing flexibility for performance under constraints. 
Size is the real enemy here.


> And would constrained devices or mediums that sweat about 5KB
> really be able to support PQ KEMs and Sigs at NIST Level 5?

My tests showed that they *do* support PQ KEMs (NTRU and Kyber - haven't tried 
McEliece ;) and Sigs (Falcon and Dilithium - haven't tried Rainbow ;) at Level 
5. Caveat - they do only Sig *verification* (which suits me fine).

(I posted benchmarks from Intel Core i9, but they work acceptably well on the 
"smaller" chips.)

Also, sorry if I did not make it clear - it's not the *devices* themselves that 
sweat 5KB, it's their austere links.



-Original Message-
From: TLS  On Behalf Of Blumenthal, Uri - 0553 - MITLL
Sent: Monday, July 12, 2021 11:39 PM
To: Douglas Stebila ; Eric Rescorla 
Cc:  
Subject: RE: [EXTERNAL] [TLS] Comments on 
draft-celi-wiggers-tls-authkem-00.txt

CAUTION: This email originated from outside of the organization. Do not 
click links or open attachments unless you can confirm the sender and know the 
content is safe.



Let me emphasize the reasons Douglas brought up. Note that I need to use 
NIST Sec Level 5 algorithms. So, Kyber-1024 and Dilithium5 (other algorithms 
show even worse ratio between KEM and signature!).

Communications costs:
- Difference in public key sizes: 1568 bytes of Kyber vs. 2592 bytes of 
Dilithium => 1024 extra bytes to carry over channel each way;
- Signature: extra 4595 bytes each way, because in addition to exchanging 
certs (aka "signed public keys", which is inevitable) you need to sign the 
exchange and communicate that signature across;
- Total: 5619 extra bytes each way. For peer-to-peer broadband connections, 
you can say "so what?". But my links are *very* austere.

Computation costs (ballpark, on a powerful CPU):
- KEM: keygen 15us, encap 18us, decap 14us (say, double encap and decap for 
PFS-providing exchange);
- Signature: sign 113us, verify 55us;
- Comparison: 134us for signature-less KEM vs. 215us for TLS-like exchange 
=> almost twice as long;
- Difference may be negligible for Intel Xeon, but for my much weaker 
hardware it matters.

So, for constrained environments with austere comm links, signature-less 
"authkem" is God-sent.
Big servers that need to support many clients (so they care how much CPU 
cycles and comm bytes they spend on every connection) would appreciate these 
savings too.

@ekr,I hope this provides convincing explanation why "authkem" is needed.

P.S. I know that Falcon has much more favorable sizes - but (a) it takes 
three times as long to sign, and (b) it uses FP calculations, which isn't great 
to implement in my environment.
--
Regards,
Uri

There are two ways to design a system. One is to make is so simple there 
are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare


On 7/12/21, 20:59, "TLS on behalf of Douglas Stebila"  wrote:

Hi Eric,

The main motivation is that, in some cases, post-quantum signatures are 
larger in terms of communication size compared to a post-quantum KEM, under the 
same cryptographic assumption.

For example, the KEM Kyber (based on module LWE) at the 128-bit 
security level has 800-byte public keys and 768-byte ciphertexts.  The matching 
signature scheme Dilithium (also based on module LWE) has 1312-byte public keys 
and 2420-byte signatures.  Doing KEM-based server authentication rather than 
signature-based server authentication would thus save 2164 bytes per handshake.

We would still need digital signatures for a PKI (i.e., the root and 
intermediate CAs would sign certificates using PQ digital signature schemes), 
but the public key of the endpoint server can be a KEM public key, not a 
digital signature public key.

Douglas


> On Jul 12, 2021, at 20:30, Eric Rescorla  wrote:
>
> Hi folks,
>
> I have just given draft-celi-wiggers-tls-authkem-00.txt a quick
> read. I'm struggling a bit with the rationale, which I take to be
> these paragraphs:
>
>In this proposal we use the DH-based KEMs from 
[I-D.irtf-cfrg-hpke].
>We believe KEMs are especially worth discussing in the context of 
the
>TLS protoc

Re: [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt

[Blumenthal, Uri - 0553 - MITLL]

Let me emphasize the reasons Douglas brought up. Note that I need to use NIST 
Sec Level 5 algorithms. So, Kyber-1024 and Dilithium5 (other algorithms show 
even worse ratio between KEM and signature!). 

Communications costs:
- Difference in public key sizes: 1568 bytes of Kyber vs. 2592 bytes of 
Dilithium => 1024 extra bytes to carry over channel each way;
- Signature: extra 4595 bytes each way, because in addition to exchanging certs 
(aka "signed public keys", which is inevitable) you need to sign the exchange 
and communicate that signature across;
- Total: 5619 extra bytes each way. For peer-to-peer broadband connections, you 
can say "so what?". But my links are *very* austere.

Computation costs (ballpark, on a powerful CPU):
- KEM: keygen 15us, encap 18us, decap 14us (say, double encap and decap for 
PFS-providing exchange); 
- Signature: sign 113us, verify 55us;
- Comparison: 134us for signature-less KEM vs. 215us for TLS-like exchange => 
almost twice as long;
- Difference may be negligible for Intel Xeon, but for my much weaker hardware 
it matters.

So, for constrained environments with austere comm links, signature-less 
"authkem" is God-sent. 
Big servers that need to support many clients (so they care how much CPU cycles 
and comm bytes they spend on every connection) would appreciate these savings 
too.

@ekr,I hope this provides convincing explanation why "authkem" is needed. 

P.S. I know that Falcon has much more favorable sizes - but (a) it takes three 
times as long to sign, and (b) it uses FP calculations, which isn't great to 
implement in my environment. 
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 

On 7/12/21, 20:59, "TLS on behalf of Douglas Stebila"  wrote:

Hi Eric,

The main motivation is that, in some cases, post-quantum signatures are 
larger in terms of communication size compared to a post-quantum KEM, under the 
same cryptographic assumption.  

For example, the KEM Kyber (based on module LWE) at the 128-bit security 
level has 800-byte public keys and 768-byte ciphertexts.  The matching 
signature scheme Dilithium (also based on module LWE) has 1312-byte public keys 
and 2420-byte signatures.  Doing KEM-based server authentication rather than 
signature-based server authentication would thus save 2164 bytes per handshake. 
 

We would still need digital signatures for a PKI (i.e., the root and 
intermediate CAs would sign certificates using PQ digital signature schemes), 
but the public key of the endpoint server can be a KEM public key, not a 
digital signature public key.

Douglas


> On Jul 12, 2021, at 20:30, Eric Rescorla  wrote:
> 
> Hi folks,
> 
> I have just given draft-celi-wiggers-tls-authkem-00.txt a quick
> read. I'm struggling a bit with the rationale, which I take to be
> these paragraphs:
> 
>In this proposal we use the DH-based KEMs from [I-D.irtf-cfrg-hpke].
>We believe KEMs are especially worth discussing in the context of the
>TLS protocol because NIST is in the process of standardizing post-
>quantum KEM algorithms to replace "classic" key exchange (based on
>elliptic curve or finite-field Diffie-Hellman [NISTPQC]).
> 
>This proposal draws inspiration from [I-D.ietf-tls-semistatic-dh],
>which is in turn based on the OPTLS proposal for TLS 1.3 [KW16].
>However, these proposals require a non-interactive key exchange: they
>combine the client's public key with the server's long-term key.
>This imposes a requirement that the ephemeral and static keys use the
>same algorithm, which this proposal does not require.  Additionally,
>there are no post-quantum proposals for a non-interactive key
>exchange currently considered for standardization, while several KEMs
>are on the way.
> 
> I see why this motivates using a KEM for key establishment, but I'm
> not sure it motivates this design, which seems like a fairly radical
> change to TLS. As I understand the situation, in the post-quantum
> world we're going to have:
> 
> - non-interactive KEMs (as you indicate above)
> - some sort of signature system (otherwise we won't have certificates).
> 
> This certainly argues that we need a KEM for key establishment, but
> not for authentication. Instead, why can't we use signatures for
> authentication, as TLS does today? I.e., the certificates would have a
> (potentially post-quantum) signing key in them and you then use the
> KEM for key establishment and the signing key for authentication.
> That would give us a design much closer to the 

Re: [TLS] Advancing draft-ietf-tls-hybrid-design

[Blumenthal, Uri - 0553 - MITLL]

I personally do not find the proposed approach appealing (or even useful).

There are three possibilities.

a. Quantum computers capable of breaking crypto (QC) become practical *and* 
NIST PQC winner(s) resist both quantum and classic attacks;
b. QC become practical, and NIST PQC candidates fail (doesn't matter whether 
they fall to classic or quantum attack!);
c. QC do *not* materialize, *and* PQC candidates fail to classic attacks.

The only possibility justifying the hybrid exchange is (c), which I personally 
find the least probable. In both (a) and (b) addition of ECC does not make the 
KE any more secure than without it.
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 

On 7/6/21, 21:19, "TLS on behalf of Douglas Stebila"  wrote:

Dear TLS working group,

We wanted to see if there is any further feedback on our draft "Hybrid key 
exchange in TLS 1.3" 
(https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/) and what steps 
are required for it to advance further.  We have not received any new feedback 
from the working group since we posted our last non-trivial update in October 
2020.

The draft as written does not actually specify any post-quantum algorithms 
nor give identifiers for specific algorithm combinations, only the formats for 
hybrid key exchange messages and key derivation.  We have received a suggestion 
that the draft be updated to include identifiers for hybrid key exchange 
combining elliptic curve groups and the KEMs currently in Round 3 of the NIST 
PQC standardization process, so that implementations can begin testing 
interoperability using numbers listed in the draft, rather than relying on ad 
hoc lists for such purposes.  Is that something the working group would like to 
see, or would you prefer to leave it as it currently stands, without any 
specific algorithm identifiers?

Douglas, Scott, and Shay
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Deprecating FFDHE + RSA Key Exchange

[Blumenthal, Uri - 0553 - MITLL]

As has been pointed out, TLS is *not* just the Web. And TLS peers are not 
necessarily browsers.

 

Yes, there are reasons to avoid deprecating FFDHE with RSA signatures on the 
open Internet (besides that doing it would be silly counterproductive, as not 
everybody uses ECC).

 

Limiting FFDHE to well-known groups would probably be a good idea. Though it 
would be educational to hear from those who for some reasons need weird 
“special” groups of weird sizes.

--

Regards,

Uri

 

There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

 

 

From: TLS  on behalf of Nimrod Aviram 

Date: Tuesday, April 6, 2021 at 05:28
To: "" 
Subject: [TLS] Deprecating FFDHE + RSA Key Exchange

 

Dear all,

Following the discussion around draft-bartle-tls-deprecate-ffdhe, what are your 
thoughts on deprecating RSA key exchange, and Finite-Field Diffie-Hellman? 
(This would probably happen in a separate document.)

Considering the following different areas/use cases:
1. On the open Internet/web, both key exchange methods have been superseded by 
ECDH. Browser support for FFDHE has been entirely removed IIUC, so formally 
deprecating FFDHE should not be a problem (right?). Are there any reasons to 
avoid deprecating FFDHE and RSA on the open Internet?
2. On local networks, deprecating both key exchange methods may leave some 
endpoints without any key exchange algorithms. Could you please give feedback 
on the following:
a. Is the number of such endpoints large enough that we shouldn’t deprecate 
these methods?
b. If the answer to the above is yes, what would be a good plan/timeline to 
deprecate them?

We could also consider limiting FFDHE to well-known groups of at least 2048 
bits, with fully ephemeral secrets. But this would likely cause enough 
interoperability problems that we might as well deprecate it fully, right?

thanks,
Nimrod




smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS Opaque

[Blumenthal, Uri - 0553 - MITLL]

I like the mechanism, and therefore support it’s adoption. 

Regards,
Uri

> On Mar 31, 2021, at 12:18, Salz, Rich  
> wrote:
> 
> 
> We had a presentation on TLS opaque at IETF 110, but we have not had much 
> discussion of this document on the list.  The chairs would like to see more 
> discussion on the document before considering it for adoption.  There is at 
> least one question on the list that has gone unanswered for some time [1].  
>  
> I don’t have an opinion on the mechanism or on adoption.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Blumenthal, Uri - 0553 - MITLL]

>> You may claim that my environment does not represent yours. Sure,
 >   > fine. Similarly, *yours does NOT represent mine*.
>
>I'm not telling you what to do.

By making a statement "this solution works" without any qualifiers, you 
essentially are.
The truth is - it works well for *some* environments, including yours. I've 
some where it would work too.
Unfortunately, I *also* have plenty where it cannot work.

>. . . . .  It's reasonable to suspect that even someone I
>know and I know is smart may not have all the relevant details.

My point is - we *both* may not have all the relevant details about each 
other's environments. Which is why I absolutely disagreed with your "this 
solution works" statement. 

>Besides, your
>
>>>> With all due respect, *absolutely not*.
>
>followed by no explanation, seems like much more likely to be intended
>to cause offense than "I'm not sure what it is you're imagining"
>followed by an explanation.  I took it at face value however, and
>followed up.  What a crime.

;-) OK, touche.

 


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Blumenthal, Uri - 0553 - MITLL]

> >> So instead of getting one chance a year for your control system to 
break
> >> itself if the renewal fails, you get hundreds of them?
> >
> >Yes.  Exactly.  It's a human factors problem.  And this solution 
works.
> 
> With all due respect, *absolutely not*.

I'm not sure what it is you're imagining.  What actually happens in the
cases I'm familiar with is .  .  .  .  .

Well-put - the point being that the cases you're familiar with do not cover the 
entire spectrum of use cases. Specifically, they do not match *my* operating 
environment.

You may claim that my environment does not represent yours. Sure, fine. 
Similarly, *yours does NOT represent mine*.

And let's dispose with the "you're imagining" crap, shall we? I think we've 
known each other long enough to be more polite. Otherwise, suit yourself.


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Blumenthal, Uri - 0553 - MITLL]

On 3/7/21, 17:36, "TLS on behalf of Nico Williams"  wrote:
>
>On Sun, Mar 07, 2021 at 09:57:40AM +, Peter Gutmann wrote:
>> Nico Williams  writes:
>> > When expirations are short, you will not forget to renew.  That's
>> > part of the point of short-lived certificates.
>> 
>> So instead of getting one chance a year for your control system to break
>> itself if the renewal fails, you get hundreds of them?
>
>Yes.  Exactly.  It's a human factors problem.  And this solution works.

With all due respect, *absolutely not*.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

[Blumenthal, Uri - 0553 - MITLL]

+1 to Eric.

 

Re. GCM – one problem it has is catastrophic failure if nonce is mis-/re-used. 
Which is why I’d rather see AES-GCM-SIV.

--

Regards,

Uri

 

There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

 

 

From: TLS  on behalf of Eric Rescorla 
Date: Thursday, February 11, 2021 at 18:13
To: Jack Visoky 
Cc: John Mattsson , "TLS@ietf.org" 

Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher 
Suites

 

 

 

On Thu, Feb 11, 2021 at 3:08 PM Jack Visoky  wrote:

Hi Eric,

 

I don’t have numbers offhand but I will say that many platforms I have 
experience with have some sort of HW support, and might include things like 
DMA. In these cases ChaCha20-Poly1305 is way behind in terms of performance 
(which is expected as I believe it was mainly targeted to software-only 
implementations). 

 

I’ll anticipate that someone might ask if GCM is not better that SHA-256 with 
hardware support, and of course I will have to say it depends on the platform. 
For some cases it will be, and others it will not. Here is a link to some 
performance numbers which show SHA-256 is faster than GCM 
https://www.ti.com/lit/an/swra667/swra667.pdf?ts=1613069390182. In other cases 
GCM may not be supported on a platform but SHA256 is, of course that’s kind of 
a strawman but it could occur.

 

I doubt it covers the whole difference, but I'd note that SHA-256 is not the 
right comparison point, because what you need here is HMAC, which requires 
nested SHA invocations. This is especially relevant if you have to go back and 
forth to the hardware each time.

 

-Ekr

 

Note I am not endorsing this platform or affiliated with it in any way, just 
want to give an example. And it really is just an example, sorry to repeat 
again but I just want to drive home the point that YMMV on things like this.

 

Thanks,

 

--Jack

 

 

From: Eric Rescorla  
Sent: Thursday, February 11, 2021 2:51 PM
To: Jack Visoky 
Cc: John Mattsson ; TLS@ietf.org
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher 
Suites

 

 

 

On Thu, Feb 11, 2021 at 11:13 AM Jack Visoky  wrote:

Hi John, Eric,

 

Thanks for the input. We will certainly make some changes to the draft 
regarding the inspection case. However, I can’t support removing the 
performance/latency information completely, as I have heard from those who have 
this very concern. That said, we will edit the language to make it clear that 
this is not true in all cases.

 

Well, the draft just claims that there are latency concerns, but doesn't 
present details. If you want to make this case, it would be helpful to present 
performance numbers that show that these ciphersuites are substantially faster 
than the alternative algorithms (in particular ChaCha20/Poly1305) which is 
quite fast on many low end platforms.

 

-Ekr

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Blumenthal, Uri - 0553 - MITLL]

>I would suggest the strong, unambiguous statement with explanation for
>why the statement is being made.

Yes. 

>There is no need to describe (possible) exceptions.

My opinion is exactly the opposite. Do describe the exceptions, as precisely 
and unambiguously as you can.

I don't buy the assumption that "one can never figure all the possible reasons 
when/why  should not apply".



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Sending Custom DHE Parameters in TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

In some cases toy key sizes are necessary. 

E.g., classes where your students break encryption because the keys are weak or 
small.

Regards,
Uri

> On Oct 12, 2020, at 19:42, Peter Gutmann  wrote:
> 
> Ilari Liusvaara  writes:
> 
>> The Diffie-Hellman support in TLS 1.2 is severly broken. There is no way to
>> use it safely on client side. This has lead to e.g., all the web browers to
>> remove support for it.
> 
> It's actually pretty simple, don't use toy key sizes.  Many implementations
> were never vulnerable to Logjam et al because they applied the simple measure
> of... not using toy key sizes.
> 
>> There is no way to ensure that the parameters sent are not totally broken,
>> e.g.:
> 
> This requires that the server that you're connecting to is malicious.  If
> you're connecting to a malicious server then you've got bigger things to worry
> about then what they set g to.
> 
>> This has lead to e.g., all the web browers to remove support for it.
> 
> Because throwing out the baby with the bathwater and jumping on the next shiny
> thing that comes along every time someone points out a problem seems to be a
> requirement for crypto protocol implementers.
> 
> Peter.
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Sending Custom DHE Parameters in TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

I suggest that custom parameters should be allowed, and documented as 
completely under user/administrator responsibility.

Ensuring that a custom modulus is not "too small" or "too large" (etc.) in that 
case is not your problem or your business.



On 10/12/20, 13:32, "TLS on behalf of Ilari Liusvaara"  wrote:

On Mon, Oct 12, 2020 at 12:36:06PM -0400, Michael D'Errico wrote:
> 
> It appears that there may be a need to revert to the
> old way of sending Diffie-Hellman parameters that
> the server generates.  I see that TLS 1.3 removed
> this capability*; is there any way to add it back?

The Diffie-Hellman support in TLS 1.2 is severly broken. There is no
way to use it safely on client side. This has lead to e.g., all the web
browers to remove support for it.

There is no way to ensure that the parameters sent are not totally
broken, e.g.:

- Modulus too small.
- Modulus too large.
- Modulus not prime (has been used as a backdoor!).
- Modulus is weak (possibly backdoored).
- Subgroup order does not have large prime factor.

Even checking the third would require primality test, and primality
tests at relevant sizes are slow. And the fourth and fifth can not be
checked at all in general case.


For ECDHE, TLS 1.2 allowed server to specify custom curve to do the
key exchange with. Rightfully pretty much nobody implemented that.


I think TLS WG should withdraw recommendation (as flawed) on all
TLS_DHE_* ciphersuites.


-Ilari

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


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

[Blumenthal, Uri - 0553 - MITLL]

I would prefer the minimum encoding length.

 

From: TLS  on behalf of "Salz, Rich" 

Date: Monday, October 5, 2020 at 22:23
To: Eric Rescorla , Marten Seemann 
Cc: "" 
Subject: Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

 

Can you just say “QUIC rules but use the minimum possible length”?



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

> On Sep 30, 2020, at 08:51, Watson Ladd  wrote:
> 
> Recommended N doesn't stop people from using PSK when appropriate if
> other constraints make it the most appropriate choice.

It does, because this "stop" occurs on a business level, not the technical... 
Realm of advertisement, claimed security and compliance, etc. Where a business 
manager is afraid to scare potential customers away by implementing/selling 
something "not recommended", because even if he himself managed to read the doc 
to the end and understand what that's about, he cannot trust all the customers 
to do so... Plus the potential legal cases when a customer who was cyber-hit, 
sues the manufacturer because he "did something against recommendations"... 
That's not your favorite Ivory tower, and not a peer-reviewed academic 
publication/conference. 

Now, since it's a rough morning and I feel grumpy - let me be blunt, and say 
that IMHO this whole "recommend" idea sounds *stupid*. Recommended by who and 
for who? WT... do the "recommenders" know about the spectrum of use cases? 
Based on the above exchange - not a lot. If you want to "recommend" for the Web 
browsers (which seems a fairly safe niche to pontificate) - say so explicitly, 
and enjoy. Otherwise - 


> 
>> 
>> In discussions in the IETF I notice for some the IoT computing world starts 
>> with Cortex A-class devices, as they are found in Raspberry Pis, tablets and 
>> phones. Those are high performance processors where crypto is lightning 
>> fast. But don't forget the other family of processors, of which there are 
>> probably more than a 80 billion out in the wild already.
>> 
>> Ciao
>> Hannes
>> 
>> -----Original Message-
>> From: TLS  On Behalf Of Watson Ladd
>> Sent: Wednesday, September 30, 2020 2:29 AM
>> To: Blumenthal, Uri - 0553 - MITLL 
>> Cc: tls@ietf.org
>> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>> 
>>> On Tue, Sep 29, 2020 at 12:49 PM Blumenthal, Uri - 0553 - MITLL 
>>>  wrote:
>>> 
>>> I share Achim's concerns.
>>> 
>>> But I believe the explanations will turn out mostly useless in the real 
>>> world, as the "lawyers" of the industry are guaranteed to steer away from 
>>> something "not recommended".
>>> 
>>> In one word: bad.
>> 
>> Why is PSK so necessary? There are very few devices that can't handle the 
>> occasional ECC operation.  The key management and forward secrecy issues 
>> with TLS-PSK are real. Steering applications that can afford the CPU away 
>> from PSK and toward hybrid modes is a good thing and why this registry 
>> exists imho.
>> 
>> 
>> --
>> Astra mortemque praestare gradatim
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> IMPORTANT NOTICE: The contents of this email and any attachments are 
>> confidential and may also be privileged. If you are not the intended 
>> recipient, please notify the sender immediately and do not disclose the 
>> contents to any other person, use it for any purpose, or store or copy the 
>> information in any medium. Thank you.
> 
> 
> 
> -- 
> Astra mortemque praestare gradatim


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

Because PSK is one of the affordable and reliable quantum-resistant key 
exchanges that work *today*? And done environments do not wish to do any EC 
operations.

Yes, key management issues are real. Those who need it, understand the 
implications.

Regards,
Uri

> On Sep 29, 2020, at 20:30, Watson Ladd  wrote:
> 
> On Tue, Sep 29, 2020 at 12:49 PM Blumenthal, Uri - 0553 - MITLL
>  wrote:
>> 
>> I share Achim's concerns.
>> 
>> But I believe the explanations will turn out mostly useless in the real 
>> world, as the "lawyers" of the industry are guaranteed to steer away from 
>> something "not recommended".
>> 
>> In one word: bad.
> 
> Why is PSK so necessary? There are very few devices that can't handle
> the occasional ECC operation.  The key management and forward secrecy
> issues with TLS-PSK are real. Steering applications that can afford
> the CPU away from PSK and toward hybrid modes is a good thing and why
> this registry exists imho.
> 
> 
> -- 
> Astra mortemque praestare gradatim


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

I share Achim's concerns. 

But I believe the explanations will turn out mostly useless in the real world, 
as the "lawyers" of the industry are guaranteed to steer away from something 
"not recommended".

In one word: bad.

On 9/29/20, 12:31, "TLS on behalf of Achim Kraus"  wrote:

Hi list,

I'm still worrying about the "recommended" and the (mis-)interpretation
of that. I'm fine with the explanation

---
Note

 If an item is not marked as "Recommended", it does not
 necessarily mean that it is flawed; rather, it indicates that
 the item either has not been through the IETF consensus process,
 has limited applicability, or is intended only for specific use
 cases.
---

but, I feel uncomfortable considering too many decision makers will not
read that details. Though the "recommendation" is changing over the
time, I would feel more comfortable, if the N would be amended by the
Y-period.

e.g. N (was Y 2001-2015)

FMPOV, if someone reads that, it may explain, that the N is a recent one
and some use-case will still need some time to adapt for the new
recommendations.

best regards
Achim Kraus

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


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

I sincerely hope that the TLS group will NOT make the same decision [as LAKE - 
to drop PSK].

Regards,
Uri

> On Sep 23, 2020, at 07:50, Hannes Tschofenig  
> wrote:
> 
> 
> Hi Carrick,
>  
> you note that SCADA is a pretty specific use case. SCADA sounds specific but 
> TLS is used widely in the IoT market. It is even used in devices that use 
> smart cards, which use TLS with PSK to protect their provisioning protocol.
>  
> I am worried that marking a ciphersuite as N with the meaning that it "has 
> not been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases" is hard for readers to understand which 
> of these three cases were actually the reason for marking it as “N”. The "has 
> not been through the IETF consensus process" will scare off many people.
>  
> For most people the web is the generic case and everything else is a 
> “specific use case”. Sure, the web is very important but TLS is a generic 
> protocol used in many environments.  
>  
> I don’t understand John’s motivation. The LAKE group makes a decision to 
> remove PSK support. That’s good for them. Does this imply that the TLS group 
> also needs to make the same decision?
>  
> Ciao
> Hannes
>  
> From: Carrick Bartle  
> Sent: Monday, September 21, 2020 6:19 PM
> To: Hannes Tschofenig 
> Cc: Carrick Bartle ; Filippo Valsorda 
> ; tls@ietf.org
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>  
> Can you justify your reasoning? 
>  
> Which part?
>  
> 
> 
> On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig  
> wrote:
>  
> Hi Carrick, 
>  
> Can you justify your reasoning? 
>  
> The challenge I have with the work on IoT in the IETF that the preferences 
> for pretty much everything changes on a regular basis.
>  
> I don’t see a problem that requires a change. In fact, I have just posted a 
> mail to the UTA list that gives an overview of the implementation status of 
> embedded TLS stacks and PSK-based ciphersuites are widely implemented.  
>  
> Ciao
> Hannes
>  
> From: TLS  On Behalf Of Carrick Bartle
> Sent: Monday, September 21, 2020 5:31 AM
> To: Filippo Valsorda 
> Cc: tls@ietf.org
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>  
> I'm also fine with marking psk_ke as not recommended to be consistent with 
> the non-PFS ciphers, but there are plenty of valid use cases that justify 
> keeping dhe_psk_ke as recommended for external PSKs. Several of these use 
> cases are detailed in draft-ietf-tls-external-psk-guidance-00.
>  
>  
>  
> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda  wrote:
>  
> 2020-09-19 13:48 GMT+02:00 Peter Gutmann :
> John Mattsson  writes:
>  
> >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
> >especially psk_ke are both marked as RECOMMENDED. If used in the initial
> >handshake, both modes have severe privacy problems,
>  
> PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
> just because there's a concern for one specific environment doesn't mean it
> should be banned for any use.  In particular, I think if a specific industry
> has a particular concern, they should profile it for use in that industry but
> not require that everyone else change their behaviour.
>  
> Indeed, if the SCADA industry has a particular need, they should profile TLS 
> for use in that industry, and not require we change the recommendation for 
> the open Internet.
>  
> Setting Recommended to N is not "banning" anything, it's saying it "has not 
> been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases". SCADA sounds like a pretty specific 
> use case.
>  
> I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
> wouldn't be marked N like all suites lacking PFS.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>  
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you. 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>  
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you. 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS 

Re: [TLS] TLS ECH, how much can the hint stick out?

[Blumenthal, Uri - 0553 - MITLL]

IMHO, Rich is 100% correct here. 

If it’s not deployable (and to me it means **universally** deployable, not 
merely within the US), if fails *all* of the security goals completely. 

Regards,
Uri

> On Sep 11, 2020, at 09:27, Salz, Rich  
> wrote:
> 
> 
> I think we should be careful with the word "broken" ... here we're talking 
> about "don't stick out", which is a deployment consideration only. The main 
> security goal is confidentiality of the ClientHelloInner.
>  
> Perhaps this is just being pedantic, but I disagree with the tone of this. We 
> want deployable confidentiality, and “don’t stick out” is something we 
> believe is a necessary requirement to be deployable.
>  
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Possible blocking of Encrypted SNI extension in China

[Blumenthal, Uri - 0553 - MITLL]

I’m pretty sure your reasoning is wrong. In the ideal world, if *everybody* 
enabled ESNI - then *maybe* the GFW would relent. 

The way things are - is not smart pretending reality is not what it is. 

Using your terminology - better blend with the crowd, because you aren’t likely 
to live long enough to see the crowd change to match you. 

There are a lot of technical details why the whole crowd won’t change 
regardless of your wishes - e.g., who controls TLS implementations in various 
devices - but I won’t go there. 

Regards,
Uri

> On Aug 9, 2020, at 11:36, David Fifield  wrote:
> 
> On Thu, Jul 30, 2020 at 11:16:50AM -0700, Christian Huitema wrote:
>> Thanks for the report. I think this relates to our ambivalence about the
>> requirement for ESNI to not "stick out". That requirement is hard to
>> meet, and designs have drifted towards an acceptation that it is OK to
>> stick out as long as a sufficiently large share of the traffic does it.
>> If that share is large, goes the reasoning, it would be too costly for
>> censors to just "drop everything that looks like ESNI". Well, given
>> actors like the Great Firewall, one wonders.
> 
> There's nothing wrong with that reasoning, in my opinion. To blend in
> with a crowd, you can change yourself to match the crowd; or you can
> change the crowd to match yourself. My feeling is that ESNI is currently
> easy to block (or to put it in terms I like, *inexpensive* to block)
> because very few TLS connections use it--nothing valuable depends on it
> yet. Whereas if encrypted SNI were somehow deployed suddenly and
> massively such that it became a normal feature of TLS connections both
> essential and inessential, it would be more difficult (read: expensive)
> to block.
> 
> After all, even the GFW is not all-powerful. Surely it would prefer to
> abolish TLS altogether, but it's too late for that. At this point,
> blocking TLS would cost too much--not in terms of implementing firewall
> rules, but in how much essential communication it would damage. Put
> another way, the GFW itself, and the people who operate/manage it, would
> feel some of the pain of blocking.
> 
> I don't mean to imply that coordinated deployment is the only path to
> success, just saying that if SNI encryption were already widespread,
> even an obvious tag like 0xffce would not be a useful distinguisher. And
> though I find it useful to think of these things in terms of the costs
> of overblocking, it's not an infallible guide. A large organization like
> the GFW is made up of many conflicting motivations, and it is as prone
> as any other to making bad decisions and enacting policies that are
> evidently against its own interests. For that reason I believe it's
> possible to reduce the risk surrounding the deployment of encrypted SNI,
> but not eliminate it completely.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

[Blumenthal, Uri - 0553 - MITLL]

As my personal opinion - both.


On 7/27/20, 10:22, "TLS on behalf of Salz, Rich"  wrote:

>Understood. However, in this particular case, instead of "if you want 
to do this, then do it that way, and I'll help you inter-operate" I prefer "if 
you want to do this - you're on your own, don't seek a blessing or advice from 
me".

So you don't feel that community is welcome here at the IETF, or that you 
won't personally participate?


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


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

[Blumenthal, Uri - 0553 - MITLL]

Nancy,

Understood. However, in this particular case, instead of "if you want to do 
this, then do it that way, and I'll help you inter-operate" I prefer "if you 
want to do this - you're on your own, don't seek a blessing or advice from me".

Regards,
Uri

On 7/27/20, 08:56, "Nancy Cam-Winget (ncamwing)"  wrote:

The document is not imposing any standards but rather provide guidelines 
for those implementing TLS proxies;  given that proxies will continue to exist 
I'm not sure why there is a belief that the IETF should ignore this.

Warm regards, Nancy

On 7/27/20, 5:20 AM, "OPSEC on behalf of Blumenthal, Uri - 0553 - MITLL" 
 wrote:

I support Stephen and oppose adoption. IMHO, this is not a technology 
that IETF should standardize.


On 7/25/20, 10:07, "TLS on behalf of Stephen Farrell" 
 wrote:


I oppose adoption. While there could be some minor benefit
in documenting the uses and abuses seen when mitm'ing tls,
I doubt that the effort to ensure a balanced document is at
all worthwhile. The current draft is too far from what it'd
need to be to be adopted.

Send to ISE.

S.

On 23/07/2020 02:30, Jen Linkova wrote:
> One thing to add here: the chairs would like to hear active and
> explicit support of the adoption. So please speak up if you 
believe
> the draft is useful and the WG shall work on getting it published.
> 
> On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
>  wrote:
>>
>> Folks,
>>
>>
>>
>> This email begins a Call For Adoption on 
draft-wang-opsec-tls-proxy-bp.
>>
>>
>>
>> Please send comments to op...@ietf.org by August 3, 2020.
>>
>>
>>
>> 
Ron
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> ___
>> OPSEC mailing list
>> op...@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsec
> 
> 
> 
> --
> SY, Jen Linkova aka Furry
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 




smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

[Blumenthal, Uri - 0553 - MITLL]

You may have a point regarding finishing this draft - but let's cross that 
bridge when we get there. :-)

Regards,
Uri

Sent from my iPhone

> On Feb 21, 2020, at 17:26, Stephen Farrell  wrote:
> 
> 
> 
>> On 21/02/2020 22:11, Watson Ladd wrote:
>> 
>> https://blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/
>> https://blog.cloudflare.com/the-tls-post-quantum-experiment/
>> 
>> This was also presented at the NIST standardization workshop in October of 
>> 2019.
> 
> Thanks. I read through [1]. It's fine work, but does not
> convince me that this draft is ready to be an RFC before
> the "winning" algs are known, as some have characteristics
> that are quite different from the two that were tested
> here. I maintain my position that adoption is fine but
> finishing this before NIST are done is not.
> 
> Cheers,
> S.
> 
> [1]
> https://csrc.nist.gov/CSRC/media/Presentations/measuring-tls-key-exchange-with-post-quantum-kem/images-media/sullivan-session-1-paper-pqc2019.pdf
> 
> 
>> 
>>> 
>>> Ta,
>>> S.
> <0x5AB2FAF17B172BEA.asc>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

[Blumenthal, Uri - 0553 - MITLL]

I agree with Watson's reasoning.

We know now all we need to to start working on generic mechanisms.

Regards,
Uri

Sent from my iPhone

> On Feb 21, 2020, at 17:11, Watson Ladd 
>  wrote:
> 
> On Fri, Feb 21, 2020 at 2:08 PM Stephen Farrell
>  wrote:
>> 
>> 
>> 
>>> On 21/02/2020 22:02, Watson Ladd wrote:
>>> We have already deployed widespread experiments that conducted the
>>> hybridization described in this draft, already have implementations
>>> supporting an approach similar to this draft, and that produced
>>> valuable input to the standardization process. It really didn't matter
>>> that it was SIKE or NewHope that was being hybridized, and they have
>>> very different characteristics.
>> 
>> Documented where?
> 
> https://blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/
> https://blog.cloudflare.com/the-tls-post-quantum-experiment/
> 
> This was also presented at the NIST standardization workshop in October of 
> 2019.
> 
>> 
>> Ta,
>> S.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

[Blumenthal, Uri - 0553 - MITLL]

I support its adoption.

 

From: TLS  on behalf of Joseph Salowey 
Date: Thursday, February 13, 2020 at 12:13 PM
To: "" 
Subject: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

 

The authors of "Hybrid Key Exchange" have asked for adoption of their draft as 
a WG item.  Please state whether you support adoption of this draft as a WG 
item by posting a message to the TLS list by 2359 UTC 28 February 2020.  Please 
include any additional information that is helpful in understanding your 
position.

NOTE:
If the draft is adopted, the working group has change control over the draft 
and the timing of its progression.  This means the document does not have to be 
perfect as the working group can and will make changes.  Adopting the draft 
means the working group thinks the topic is a good idea and the draft is a good 
place to start the work.  

Thanks,
Chris, Joe, and Sean

[0] https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/ 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

[Blumenthal, Uri - 0553 - MITLL]

I don't expect you to be knowledgeable about 25+ proposed algorithms.

I expect you to be knowledgeable about the ballpark of the new key sizes that 
practically all of the candidates use. The shortest keys are in the ballpark of 
a few KB, and I won't go into the size of the largest ones.

You may not want to *adopt* them now - but you better be ready to support Key 
Exchange for sizes far larger than what's currently implemented. And keep in 
mind that while Signatures aren't a priority yet, that will come eventually.



On 2/12/20, 5:50 PM, "Stephen Farrell"  wrote:
  
Hiya,

On 12/02/2020 21:57, Martin Thomson wrote:
> Only a few of them.  Some are OK, but the number is few, I agree.  I
> haven't found a good summary of the second round candidates and I
> don't have time to dig into all of the candidates.

Fine reason to wait and see IMO.

I'd be much happier adopting this if we did that with
the explicit understanding that we won't produce an
RFC until the "winners" in the NIST process are known
and their properties understood. (I don't mean waiting
for a FIPS or formal NIST document but at least for
the final announcement from their process.)

If the plan were to adopt this and produce an RFC now
(e.g. to mix different curves or something) then I am
against that. There's no need for such combinations so
the real rationale here is PQC and we (at least I, but
I suspect also many IETF participants) don't know enough
about the relevant algorithms yet. (And expecting us
to be knowledgeable about 25+ algorithms isn't realistic.)

Cheers,
S.




smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

[Blumenthal, Uri - 0553 - MITLL]

 I'm jumping in late - so apologies in advance for potential ignorant comments:

On 2/12/20, 3:48 PM, "TLS on behalf of Martin Thomson"  wrote:

>  Larger public keys and/or ciphertexts - if we need these, we're in serious 
> trouble. 
> To give you an idea, even at 1k, these will start being much harder to deploy.
> Getting close to 64k adds all sorts of complication.  

You saw the key sizes that the NIST PQC candidates require? How would you 
suggest dealing with them unless there's support for larger public keys?




smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

[Blumenthal, Uri - 0553 - MITLL]

I concur with Hubert, and think that DER in this context is perfectly OK.

On 10/2/19, 6:59 AM, "TLS on behalf of Hubert Kario"  wrote:

On Wednesday, 2 October 2019 00:15:13 CEST Peter Gutmann wrote:
> Hubert Kario  writes:
> >a lax DER parser sounds like an oxymoron to me... :)
> 
> That's why I assumed it was an accident/error.  Writing a spec that relies
> on buggy parser implementations in order to work is asking for trouble.

well, SEC 1 does not require the ECDSA-Sig-Value structure to be encoded 
with 
DER, it's TLS that does that (and I'd say for the better, given the 
multitude 
of ways you can encode SEQUENCE in BER...)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

[Blumenthal, Uri - 0553 - MITLL]

>  A side note: we will also upload the Markdown file of this draft into the 
>same git 

>  repository at https://github.com/alipay/tls13-sm-spec later to make 
it a totally

    >  public involved progress.

 

I think this is exactly what was needed/asked-for. Thank you!



On Aug 19, 2019, at 7:51 PM, Kepeng Li  wrote:

 

Currently, we uploaded some of the referenced documents here:

https://github.com/alipay/tls13-sm-spec

 

@Rene, Parts 1 and 3 can be found in the link above.

 

Hope it helps.

 

Thanks,

 

Kind Regards

Kepeng

 

--

发件人：李克鹏(易深) 

发送时间：2019年8月19日(星期一) 17:38

收件人：sean+ietf ; joe ; caw 


抄　送：tls@ietf.org ; "Blumenthal, Uri - 0553 - MITLL" 
; Paul Yang 

主　题：Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1..3

 

Hi WG chairs,

 

Can we place the referenced documents in the TLS WG GitHub?

https://github.com/tlswg

 

According to the discussion below, this can help people to read and understand 
the referenced specifications.

 

Thanks,

 

Kind Regards

Kepeng 

 

发件人: TLS  代表 "Blumenthal, Uri - 0553 - MITLL" 

日期: 2019年8月18日 星期日 22:08
收件人: Paul Yang 
抄送: "tls@ietf.org" 
主题: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

 

IMHO, placing the documents on GitHub would be perfect, and quite sufficient. 

 

Please make sure to post the name of the repo here. ;/)

 

I leave it to others to decide whether they'd want copies of today PDF files 
sent to the mailing list directly.

Regards,

Uri

 

Sent from my iPhone


On Aug 17, 2019, at 01:03, Paul Yang  
wrote:

Good points.

 

The good news is that we have found some English PDFs of SM2, including the 
missing part 1 and part 3. Will continue to find English translations of other 
SM standards mentioned in the draft.

 

So, if we host a free website, say on Github or so, to provide those docs, is 
it convenient for you guys? Or should we just drop the   PDF files to this 
mailing list as attachments?

 

On Aug 16, 2019, at 10:58 PM, Rene Struik  wrote:

 

Arguably, "national" crypto specifications garnish more stature if these are 
made available to the pubic by that standard-setting body itself (who, thereby, 
acts as its authoritative source), without deference to a third party (that 
may, independently from the originator, enforce document control [e.g., by 
effectuating technical changes or enforcing controlled dissemination]).

 

Since your draft introducing SM cipher suites with TLS1.3 appeals to the 
authority of a standard-setting authority, easy availability of the full and 
accredited technical documentation to the IETF community helps in scrutiny and, 
e.g., evaluating claims in the security considerations section.

 

On 8/16/2019 3:06 AM, Kepeng Li wrote:

Hi Rene and all,

 

> Since the ISO documents are not available to the general 
> public without payment, it would be helpful to have a freely available 
> document (in English) from an authoritative source. Having such a 
> reference available would be helpful to the IETF community (and 
> researchers).
About the references to ISO documens, I think it is a general issue for IETF 
drafts.

 

How does the other IETF drafts make the references to ISO documents? ISO 
documents are often referenced by IETF drafts.

 

Thanks,

 

Kind Regards

Kepeng

——

Re: [TLS] Draft for SM cipher suites used in TLS1.3
Rene Struik  Thu, 15 August 2019 15:34 UTCShow header
Hi Paul:
 
I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 on 
the (non-secured) websites you referenced, but only found Chinese 
versions (and Chinese website navigation panels [pardon my poor language 
skills here]). Since the ISO documents are not available to the general 
public without payment, it would be helpful to have a freely available 
document (in English) from an authoritative source. Having such a 
reference available would be helpful to the IETF community (and 
researchers). Please note that BSI provides its specifications in German 
and English, so as to foster use/study by the community. If the Chinese 
national algorithms would be available in similar form, this would serve 
a similar purpose.
 
FYI - I am interested in full details and some time last year I tried to 
download specs, but only Parts 2, 4, and 5 were available [1], [2], [3], 
not Parts 1 and 3.
 
Best regards, Rene
 
[1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - 
Part 5 - Parameter Definition (SEMB, July 24, 2018)
[2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - 
Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018)
[3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - 
Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018)
 
On 8/15/2019 10:16 AM, Paul Yang wrote:
> Hi all,
> 
>

Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

[Blumenthal, Uri - 0553 - MITLL]

IMHO, placing the documents on GitHub would be perfect, and quite sufficient. 

Please make sure to post the name of the repo here. ;/)

I leave it to others to decide whether they'd want copies of today PDF files 
sent to the mailing list directly.

Regards,
Uri

Sent from my iPhone

> On Aug 17, 2019, at 01:03, Paul Yang  
> wrote:
> 
> Good points.
> 
> The good news is that we have found some English PDFs of SM2, including the 
> missing part 1 and part 3. Will continue to find English translations of 
> other SM standards mentioned in the draft.
> 
> So, if we host a free website, say on Github or so, to provide those docs, is 
> it convenient for you guys? Or should we just drop the   PDF files to this 
> mailing list as attachments?
> 
>> On Aug 16, 2019, at 10:58 PM, Rene Struik  wrote:
>> 
>> Arguably, "national" crypto specifications garnish more stature if these are 
>> made available to the pubic by that standard-setting body itself (who, 
>> thereby, acts as its authoritative source), without deference to a third 
>> party (that may, independently from the originator, enforce document control 
>> [e.g., by effectuating technical changes or enforcing controlled 
>> dissemination]). 
>> 
>> Since your draft introducing SM cipher suites with TLS1.3 appeals to the 
>> authority of a standard-setting authority, easy availability of the full and 
>> accredited technical documentation to the IETF community helps in scrutiny 
>> and, e.g., evaluating claims in the security considerations section.
>> 
>>> On 8/16/2019 3:06 AM, Kepeng Li wrote:
>>> Hi Rene and all,
>>> 
>>> > Since the ISO documents are not available to the general 
>>> > public without payment, it would be helpful to have a freely available 
>>> > document (in English) from an authoritative source. Having such a 
>>> > reference available would be helpful to the IETF community (and 
>>> > researchers).
>>> About the references to ISO documens, I think it is a general issue for 
>>> IETF drafts.
>>> 
>>> How does the other IETF drafts make the references to ISO documents? ISO 
>>> documents are often referenced by IETF drafts.
>>> 
>>> Thanks,
>>> 
>>> Kind Regards
>>> Kepeng
>>> ——
>>> Re: [TLS] Draft for SM cipher suites used in TLS1.3
>>> 
>>> Rene Struik  Thu, 15 August 2019 15:34 UTCShow header
>>> 
>>> Hi Paul:
>>> 
>>> I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 on 
>>> the (non-secured) websites you referenced, but only found Chinese 
>>> versions (and Chinese website navigation panels [pardon my poor language 
>>> skills here]). Since the ISO documents are not available to the general 
>>> public without payment, it would be helpful to have a freely available 
>>> document (in English) from an authoritative source. Having such a 
>>> reference available would be helpful to the IETF community (and 
>>> researchers). Please note that BSI provides its specifications in German 
>>> and English, so as to foster use/study by the community. If the Chinese 
>>> national algorithms would be available in similar form, this would serve 
>>> a similar purpose.
>>> 
>>> FYI - I am interested in full details and some time last year I tried to 
>>> download specs, but only Parts 2, 4, and 5 were available [1], [2], [3], 
>>> not Parts 1 and 3.
>>> 
>>> Best regards, Rene
>>> 
>>> [1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - 
>>> Part 5 - Parameter Definition (SEMB, July 24, 2018)
>>> [2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - 
>>> Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018)
>>> [3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - 
>>> Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018)
>>> 
>>> On 8/15/2019 10:16 AM, Paul Yang wrote:
>>> > Hi all,
>>> >
>>> > I have submitted a new internet draft to introduce the SM cipher 
>>> > suites into TLS 1.3 protocol.
>>> >
>>> > https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00
>>> >
>>> > SM cryptographic algorithms are originally a set of Chinese national 
>>> > algorithms and now have been (or being) accepted by ISO as 
>>> > international standards, including SM2 signature algorithm, SM3 hash 
>>> > function and SM4 block cipher. These algorithms have already been 
>>> > supported some time ago by several widely used open source 
>>> > cryptographic libraries including OpenSSL, BouncyCastle, Botan, etc.
>>> >
>>> > Considering TLS1.3 is being gradually adopted in China's internet 
>>> > industry, it's important to have a normative definition on how to use 
>>> > the SM algorithms with TLS1.3, especially for the mobile internet 
>>> > scenario. Ant Financial is the company who develops the market leading 
>>> > mobile app 'Alipay' and supports payment services for Alibaba 
>>> > e-commerce business. We highly are depending on the new TLS1.3 
>>> > protocol for both performance and security purposes. We 

Re: [TLS] Re： Draft for SM cipher suites used in TLS1.3

[Blumenthal, Uri - 0553 - MITLL]

AFAIK, all the ISO standards that IETF refers to, were defined elsewhere first, 
i.e., ISO defined them based on some open submissions, publications, etc.

 

I fully agree with Rene – if you want the specs standardized, provide the 
complete specs, including the missing parts 1 and 3.

 

 

 

From: TLS  on behalf of Kepeng Li 

Reply-To: Kepeng Li 
Date: Friday, August 16, 2019 at 3:15 AM
To: "rstruik.ext" , TLS 
Subject: [TLS] Re： Draft for SM cipher suites used in TLS1.3

 

Hi Rene and all,

 

> Since the ISO documents are not available to the general 
> public without payment, it would be helpful to have a freely available 
> document (in English) from an authoritative source. Having such a 
> reference available would be helpful to the IETF community (and 
> researchers).
About the references to ISO documens, I think it is a general issue for IETF 
drafts.

 

How does the other IETF drafts make the references to ISO documents? ISO 
documents are often referenced by IETF drafts.

 

Thanks,

 

Kind Regards

Kepeng

——

Re: [TLS] Draft for SM cipher suites used in TLS1.3
Rene Struik  Thu, 15 August 2019 15:34 UTCShow header
Hi Paul:
 
I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 on 
the (non-secured) websites you referenced, but only found Chinese 
versions (and Chinese website navigation panels [pardon my poor language 
skills here]). Since the ISO documents are not available to the general 
public without payment, it would be helpful to have a freely available 
document (in English) from an authoritative source. Having such a 
reference available would be helpful to the IETF community (and 
researchers). Please note that BSI provides its specifications in German 
and English, so as to foster use/study by the community. If the Chinese 
national algorithms would be available in similar form, this would serve 
a similar purpose.
 
FYI - I am interested in full details and some time last year I tried to 
download specs, but only Parts 2, 4, and 5 were available [1], [2], [3], 
not Parts 1 and 3.
 
Best regards, Rene
 
[1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - 
Part 5 - Parameter Definition (SEMB, July 24, 2018)
[2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - 
Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018)
[3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - 
Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018)
 
On 8/15/2019 10:16 AM, Paul Yang wrote:
> Hi all,
> 
> I have submitted a new internet draft to introduce the SM cipher 
> suites into TLS 1.3 protocol.
> 
> https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00
> 
> SM cryptographic algorithms are originally a set of Chinese national 
> algorithms and now have been (or being) accepted by ISO as 
> international standards, including SM2 signature algorithm, SM3 hash 
> function and SM4 block cipher. These algorithms have already been 
> supported some time ago by several widely used open source 
> cryptographic libraries including OpenSSL, BouncyCastle, Botan, etc.
> 
> Considering TLS1.3 is being gradually adopted in China's internet 
> industry, it's important to have a normative definition on how to use 
> the SM algorithms with TLS1.3, especially for the mobile internet 
> scenario. Ant Financial is the company who develops the market leading 
> mobile app 'Alipay' and supports payment services for Alibaba 
> e-commerce business. We highly are depending on the new TLS1.3 
> protocol for both performance and security purposes. We expect to have 
> more deployment of TLS1.3 capable applications in China's internet 
> industry by this standardization attempts.
> 
> It's very appreciated to have comments from the IETF TLS list :-)
> 
> Many thanks!
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
 

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

[Blumenthal, Uri - 0553 - MITLL]

One more thing: I would expect to use SIDH rather than SIKE. 

 

Because to emulate the security advantages of DH, you’d have to run two SIKE’s 
– one in each direction.

 

 

From: TLS  on behalf of "Panos Kampanakis (pkampana)" 

Date: Tuesday, July 30, 2019 at 3:37 PM
To: "Scott Fluhrer (sfluhrer)" , "" 

Subject: Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

 

+1 for option 2. The combinatoric explosion and complexity of 1 is unnecessary. 
I expect that just a few, conservative, acceptably efficient, classical+PQ 
combinations need to be standardized and used. Combining a classical algo with 
more than one postquantum algorithms in a key exchange does not seem practical 
based on the PQ candidates key sizes and performance.

 

Panos

 

 

From: TLS  On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Tuesday, July 30, 2019 11:21 AM
To:  
Subject: [TLS] Options for negotiating hybrid key exchanges for postquantum

 

During the physical meeting in Montreal, we had a discussion about postquantum 
security, and in particular, on how one might want to negotiate several 
different ‘groups’ simultaneously (because there might not be one group that is 
entirely trusted, and I put ‘groups’ in scarequotes because postquantum key 
exchanges are typically not formed from a Diffie-Hellman group).

 

At the meeting, there were two options presented:

 

Option 1: as the supported group, we insert a ‘hybrid marker’ (and include an 
extension that map lists which combination the hybrid marker stands for)

For example, the client might list in his supported groups 
hybrid_marker_0 and hybrid_marker_1, and there would be a separate extension 
that lists hybrid_marker_0 = X25519 + SIKEp434 and hybrid_marker_1 = X25519 + 
NTRUPR653.  The server would then look up the meanings of hybrid_marker_0 and 1 
in the extension, and then compare that against his security policy.

In this option, we would ask IANA to allocate code points for the various 
individual postquantum key exchanges (in this example, SIKEp434 and NTRUPR653), 
as well a range of code points for the various hybrid_markers.

 

Option 2: we have code points for all the various combinations that we may want 
to support; hence IANA might allocate a code point X25519_SIKEp434 and another 
code point for X25519_NTRUPR653.  With this option, the client would list 
X25519_SIKEp434 and X25519_NTRUPR653 in their supported groups.

In this option, we would ask IANA to allocate code points for 
all the various combinations that we want allow to be negotiated.

 

I would like to make an argument in favor of option 1:

 

-  It is likely that not everyone will be satisified with “X25519 plus 
one of a handful of specific postquantum algorithms”; some may prefer another 
elliptic curve (for example, x448), or perhaps even a MODP group; I have talked 
to people who do not trust ECC); in addition, other people might not trust a 
single postquantum algorithm, and may want to rely on both (for example) SIKE 
and NewHope (which are based on very different hard problems).  With option 2, 
we could try to anticipate all the common combintations (such as 
P384_SIKEp434_NEWHOPE512CCA), however that could very well end up as a lot of 
combinations.

-  There are likely to be several NIST-approved postquantum key 
exchanges, and each of those key exchanges are likely to have a number of 
supported parameter sets (if we take the specific postquantum key exchange as 
analogous to th ECDH protocool, the “parameter set” could be thought of an 
analogous to the specific elliptuc curve, and it modifies the key share size, 
the performance and sometimes the security properties).  In fact, one of the 
NIST submissoins currently has 30 parameter sets defined.  Hence, even if NIST 
doesn’t approve all the parameter sets (or some of them do not make sense for 
TLS in any scenario), we might end up with 20 or more different key 
exchange/parameter set combinations that do make sense for some scenario that 
uses tLS (be it in a tranditional PC client/server, a wireless client, two 
cloud devices communicating or an IOT device).

-  In addition, we are likely to support additional primitives in the 
future; possibly National curves (e.g. Brainpool), or additional Postquantum 
algorithms (or additional parameter sets to existing ones).  Of course, once we 
add that code point, we’ll need to add the additional code points for all the 
combinations that it’ll make sense in (very much like we had to add a number of 
ciphersuites whenever we added a new encryption algorithm into TLS 1.2).

 

It seemds reasonable to me that the combination of these two factors are likely 
to cause us (should we select option 2) to define a very large number of code 
points to cover all the various options that people need.

 

Now, this is based on speculation (both of the NIST process, and additional 
primitives that will be added to the 

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

[Blumenthal, Uri - 0553 - MITLL]

The nuisance with just a flag is the client can't express [what I think are] 
reasonable preferences. It should be able to say things like: 

 

Offhand, I don’t see at all why the client should be able to say any of these 
“don’t”s:

 

* Don't do X25519 + P-256. This is just silly.

* Don't do PQ1 on its own. I really want the PQ scheme paired with something 
more established.

* Don't do PQ1 + PQ2. I said something more established, please.

* Don't do PQ1 + X25519 + P-256. Why are you doing three of these?

* Don't do PQ1 + PQ2 + PQ3 + PQ4 + X25519 + P-256 + P-384 + FFDHE2048 + 
FFDHE3072, oww my head.

 

This is the only thing that IMHO the client should be able to say:

 

* PQ1 + X25519 is cool. I like that combo.

 

 

 

 

On Tue, Jul 30, 2019 at 2:48 PM Andrei Popov  wrote:

Given these options, I also prefer option 2, for some of the same reasons.

 

For my understanding though, why not have the client advertise support for 
hybrid-key-exchange (e.g. via a “flag” extension) and then KeyShareServerHello 
can contain two KeyShareEntries (essentially, using the same format as 
KeyShareClientHello? This would solve the Cartesian product issue.

 

Cheers,

 

Andrei

 

From: TLS  On Behalf Of David Benjamin
Sent: Tuesday, July 30, 2019 11:24 AM
To: Watson Ladd 
Cc: TLS List 
Subject: Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

 

I think this underestimates the complexity cost of option 1 to the protocol and 
implementations. Option 1 means group negotiation includes entire codepoints 
whose meaning cannot be determined without a parallel extension. This compounds 
across everything which interacts with named groups, impacting everything from 
APIs to config file formats to even UI surfaces. Other uses of NamedGroups are 
impacted too. For instance, option 2 fits into draft-ietf-tls-esni as-is. 
Option 1 requires injecting hybrid_extension into ESNI somehow.. Analysis must 
further check every use, say, incorporates this parallel lookup table into 
transcript-like measures.

 

The lesson from TLS 1.2 code points is not combined codepoints vs. split ones. 
Rather, the lesson is to avoid interdependent decisions:

 

* Signature algorithms in TLS 1.2 were a mess because the ECDSA codepoints 
required cross-referencing against the supported curves list. The verifier 
could not express some preferences (signing SHA-512 with P-256 is silly, and 
mixing hash+curve pairs in ECDSA is slightly off in general). As analogy to 
option 1's ESNI problem, we even forgot to allow the server to express curve 
preferences. TLS 1.3 combined signature algorithm considerations into a single 
codepoint to address all this.

 

* Cipher suites in TLS 1.2 were a mess because they were half-combined and 
half-split. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 said to use some ECDHE key 
exchange, but you need to check if you have a NamedGroup in common first. It 
said to use ECDSA, but you need to check signature algorithms (which themselves 
cross-reference curves) first. Early drafts of TLS 1.3 had it even worse, where 
a TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 full handshake morphed into 
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 on resumption. Thus, TLS 1.3 cipher 
suites negotiate solely AEAD + PRF hash.

 

In fairness to TLS 1.2, some of this was a consequence of TLS 1.2's evolution 
over time as incremental extensions over SSL 3.0. And sometimes we do need to 
pay costs like these. But hybrid key exchanges fit into the NamedGroup "API" 
just fine, so option 2 is the clear answer. Code points are cheap. Protocol 
complexity is much more expensive.

 

It's true that standards are often underspecified. This means the IETF should 
finish the job, not pass all variations through. RSA-PSS is a clear example of 
what to avoid. It takes more bytes to merely utter "RSA-PSS with SHA-256 and 
usual parameters" in X.509 than to encode an entire ECDSA signature! We should 
not define more than a handful of options, regardless of the encoding..

 

On Tue, Jul 30, 2019 at 12:18 PM Watson Ladd  wrote:

 

On Tue, Jul 30, 2019, 8:21 AM Scott Fluhrer (sfluhrer)  
wrote:

During the physical meeting in Montreal, we had a discussion about postquantum 
security, and in particular, on how one might want to negotiate several 
different ‘groups’ simultaneously (because there might not be one group that is 
entirely trusted, and I put ‘groups’ in scarequotes because postquantum key 
exchanges are typically not formed from a Diffie-Hellman group).

 

At the meeting, there were two options presented:

 

Option 1: as the supported group, we insert a ‘hybrid marker’ (and include an 
extension that map lists which combination the hybrid marker stands for)

For example, the client might list in his supported groups 
hybrid_marker_0 and hybrid_marker_1, and there would be a separate extension 
that lists hybrid_marker_0 = X25519 + SIKEp434 and hybrid_marker_1 = X25519 + 
NTRUPR653.  The server would 

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

[Blumenthal, Uri - 0553 - MITLL]

On 5/31/2019, 17:34, "TLS on behalf of Geoff Keating"  wrote:
>> On 21 May 2019, at 2:08 pm, Hugo Krawczyk  wrote:
>> 
>> A clarification on the text suggest below by Russ.
>> 
>> The way I see it, the external PSK as used in 
draft-ietf-tls-tls13-cert-with-extern-psk is not intended as
>> a means of authentication but as a way of regaining forward secrecy in 
case the (EC)DHE mechanism
>>  is ever broken (e.g., by cryptanalysis or by a quantum computer).
>
>  It’s a bit problematic if the expected use of the draft is with 
quantum-resistant
>  certificates...

This is not the intent/expected use. 
   
The intent is to protect the content of the session against being recorded now 
and decrypted later.

In short, no problem.



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

One question that I have after reading it: I understand why one wants to 
implement this extension, but I don’t see how the two endpoints would arrive at 
that external PSK. 

Sadly - we're back to the 1980's in terms of key management.   The obvious 
answers are a) they meet to exchange keys, b) they're given a key through a 
KDC, c) they get them in the mail. (and I'm really not kidding about (c))

I don’t think I get it. There’s a ton of submissions at NIST PQC, most came 
with some formal proofs. I can’t believe none of them is good enough. Anything 
from that pool should be better than nothing…?

Also, if you do have a running KDC, why would you want/need TLS 1.3 ECDHE in 
addition to it? 

Would such a pre-shared key be long-term (i.e., good/used for many 
connections), or is it going to be a use-once thing?

 

 

From: TLS  on behalf of Russ Housley 

Date: Monday, May 20, 2019 at 3:21 PM
To: Joe Salowey 
Cc: IETF TLS 
Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

 

TLS 1.3 Extension for Certificate-based Authentication with an External PSK 
ensures the US Government has a quantum-resistant option for TLS in the interim 
years until post-quantum algorithms emerge from the NIST process. For this 
reason, there is an intent to specify this extension in future procurements.

 

Russ

 




On May 15, 2019, at 9:20 AM, Joseph Salowey  wrote:

 

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

 

On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey  wrote:

This is the working group last call for the "TLS 1.3 Extension for 
Certificate-based Authentication with an External Pre-Shared Key” draft 
available at 
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/. 
Please review the document and send your comments to the list by 2359 UTC on 23 
April 2019.

 

Thanks,
Chris, Joe, and Sean







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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

I reviewed this draft (“browsed through” would be a more honest statement). I 
didn’t spot an obvious problem with it.

One question that I have after reading it: I understand why one wants to 
implement this extension, but I don’t see how the two endpoints would arrive at 
that external PSK.

From: TLS  on behalf of Russ Housley 

Date: Monday, May 20, 2019 at 3:21 PM
To: Joe Salowey 
Cc: IETF TLS 
Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

TLS 1.3 Extension for Certificate-based Authentication with an External PSK 
ensures the US Government has a quantum-resistant option for TLS in the interim 
years until post-quantum algorithms emerge from the NIST process. For this 
reason, there is an intent to specify this extension in future procurements.

Russ



On May 15, 2019, at 9:20 AM, Joseph Salowey 
mailto:j...@salowey.net>> wrote:

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

On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey 
mailto:j...@salowey.net>> wrote:
This is the working group last call for the "TLS 1.3 Extension for 
Certificate-based Authentication with an External Pre-Shared Key” draft 
available at 
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/. 
Please review the document and send your comments to the list by 2359 UTC on 23 
April 2019.

Thanks,
Chris, Joe, and Sean


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

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

[Blumenthal, Uri - 0553 - MITLL]

On 5/6/19, 7:22 AM, "TLS on behalf of Hubert Kario"  wrote:
> Sure, and that was the really strange thing with TLS 1.2, why not just say
> SHA-2 or better only, rather than adding mechanisms that were much, much
> weaker than its predecessors?  So the simple fix is just to use SHA-2 only
> for TLS 1.2.

I don't know as I wasn't there when that was discussed, but one reason 
could 
be the same as the problems we are facing now with RSA-PSS in TLS 1.3: 
smartcards and HSMs that are limited to old algorithms.

HSMs are more likely than not to support SHA-2. Smartcards rarely perform hash 
themselves, relying on the software that uses them.


Also, don't forget that signature_algorithms, at least in theory[1], was 
supposed to also influence server certificate selection, and SHA-1 was used 
in 
vast majority of certificates in PKI.

Alas. Only in some (albeit large) enclaves.


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

Re: [TLS] TLS1.3 HkdfLabel - value of label<0..6> ?

[Blumenthal, Uri - 0553 - MITLL]

A naive question: is HKDF implemented placing secret in the "salt" argument, 
and label in the "key" argument, as NIST 800-56B says? Or putting label into 
"salt" and secret into "key"?

Regards,
Uri

Sent from my iPhone

> On Mar 31, 2019, at 09:46, Ilari Liusvaara  wrote:
> 
>> On Sun, Mar 31, 2019 at 08:38:47PM +0800, M K Saravanan wrote:
>> Hi,
>> 
>> https://tools.ietf.org/html/rfc8446
>> 
>> 7.1.  Key Schedule
>> 
>>   The key derivation process makes use of the HKDF-Extract and
>>   HKDF-Expand functions as defined for HKDF [RFC5869], as well as the
>>   functions defined below:
>> 
>>   HKDF-Expand-Label(Secret, Label, Context, Length) =
>>HKDF-Expand(Secret, HkdfLabel, Length)
>> 
>>   Where HkdfLabel is specified as:
>> 
>>   struct {
>>   uint16 length = Length;
>>   opaque label<7..255> = "tls13 " + Label;
>>   opaque context<0..255> = Context;
>>   } HkdfLabel;
>> 
>> 
>> In this struct, what is the value of label<0..6>?
> 
> The syntax "opaque label<7..255>" means that label is octet string of
> at least 7 and at most 255 octets, and that its length is encoded using
> 1 octet. The string "tls13 " is 6 octets long, so that impiles that
> Label is at least 1 octet and at most 249 octets long.
> 
> So for example if Label is "s hs traffic", then the label (including
> the length field) is:
> 
> \x12 "tls13 s hs traffic"
> 
> The \x12 is the octet with value 18 (which happens to be ASCII DC2)
> because the remainder is 18 octets.
> 
> And as another example if Label is "c e traffic", then the label
> (again including length field is: 
> 
> \x11 "tls13 c e traffic"
> 
> The \x11 is the octet with value 17 (which happens to be ASCII DC1)
> because the remainder is 17 octets.
> 
> 
> In the first case, if the ciphersuite has SHA-256 hash, then the
> whole HkdfLabel looks like the following (in hex):
> 
> 00 20#32 octets of output (2 octets)
> 12#18 octets label length (1 octet)
> "tls13 s hs traffic"#The actual label (18 octets)
> 20#32 octet transcript input (1 octet).
> hash(client_hello+server_hello)#Transcript (32 octets).
> 
> In total, this is 54 bytes (64 bytes after adding HKDF and SHA-256
> internal overhead). There is only one output block, and the input
> fits into one block so evaluating the HKDF-Expand takes 4 SHA-256
> block operations.
> 
> 
> The one ciphersuite using SHA-384 would instead give (in hex):
> 
> 00 30#48 octets of output (2 octets)
> 12#18 octets label length (1 octet)
> "tls13 s hs traffic"#The actual label (18 octets)
> 30#48 octet transcript input (1 octet).
> hash(client_hello+server_hello)#Transcript (48 octets).
> 
> In total, 70 bytes. Again, only one output block and only one input
> block, so evaluation takes 4 SHA-384 block operations.
> 
> 
> 
> -Ilari
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls