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

[Tim Hollebeek]

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.

 

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 …

 

-Tim

 

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] Adoption call for 'TLS 1.2 Feature Freeze'

[Tim Hollebeek]

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



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

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

[Tim Hollebeek]

I’m fine if the cocktail napkin says “we’ll either do A or B, we’re still 
figuring that out”.

 

What I’m trying to avoid is the situation where everyone has a different 
notional quantum-safe TLS design in their heads, but nobody realizes it because 
nobody has bothered to try to write down the details, even at a very high level.

 

If it changes in the future due to new events or analysis, that’s ok too.

 

-Tim

 

From: Bas Westerbaan  
Sent: Monday, November 6, 2023 1:14 PM
To: Tim Hollebeek 
Cc: John Mattsson ; TLS@ietf.org
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

 

 

(3)-(5) are exactly the hard problems I’ve been thinking a lot about lately.  
I’d actually be tempted to say that AuthKEM vs signatures is something we 
should figure out ASAP.  I read AuthKEM again this morning, and it has a lot of 
attractive features, but I’m not quite sure what the right answer is yet.

 

I don't think we can settle the future of PQ authentication in TLS just yet — 
there are still many unknowns. To name a few:

 

1. What signature schemes are on the horizon? MAYO [1] from the NIST signatures 
on-ramp would be great, if it doesn't turn out to be broken.

 

2. How will the confidence in existing schemes develop? AuthKEM will look 
different depending on whether it can use Kyber-512 or Kyber-1024. Also, will 
it replace Dilithium5 or Dilithium2?

 

3. What other higher level changes is the ecosystem able to adopt? For instance 
Merkle Tree Certs [2].

 

These are all hard questions, and although I do not believe we can answer them 
now, we should be thinking about them right now. I think we should have 
different pots on the fire, so to say.

 

Best,

 

 Bas

 

[1] https://pqmayo.org/params-times/

[2] https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/

 



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

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

[Tim Hollebeek]

So, I was talking to Mike Ounsworth about similar issues at the PQC hackathon.  
I would like us to agree on what a cocktail napkin description of the desired 
PQC end state for all the affected protocols looks like.  I think that would be 
very helpful, and this thread looks like it’s starting to explore what that 
would look like for TLS.

 

The reason is because I think the transition is going to be an order of 
magnitude harder than the end state, and it’s going to be TWO orders of 
magnitude harder if we don’t have at least rough agreement on what end state 
we’re trying to get to.  We tend to be working on the individual parts right 
now, without the bigger picture being nailed down, which is what we need to be 
doing right now, but we need to get past that pretty soon.

 

(1) and (2) are pretty standard crypto transition problems that we will argue 
about for quite some time, but fundamentally aren’t that hard and I think we’ll 
figure them out pretty easily.

 

(3)-(5) are exactly the hard problems I’ve been thinking a lot about lately.  
I’d actually be tempted to say that AuthKEM vs signatures is something we 
should figure out ASAP.  I read AuthKEM again this morning, and it has a lot of 
attractive features, but I’m not quite sure what the right answer is yet.

 

This stuff is hard.

 

-Tim

 

From: TLS  On Behalf Of Bas Westerbaan
Sent: Monday, November 6, 2023 12:37 PM
To: John Mattsson 
Cc: TLS@ietf.org
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

 

Thanks for bringing this up. There are a bunch of (implicit) questions in your 
e-mail.

 

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

 

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

 

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

 

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

 

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

 

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.

 

Best,

 

 Bas

 

 

On Mon, Nov 6, 2023 at 10:10 AM John Mattsson 
mailto:40ericsson@dmarc.ietf.org> > 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 mailto:tls-boun...@ietf.org> > on behalf of 
internet-dra...@ietf.org   
mailto:internet-dra...@ietf.org> >
Date: Friday, 8 September 2023 at 02:48
To: i-d-annou...@ietf.org   
mailto:i-d-annou...@ietf.org> >
Cc: tls@ietf.org   mailto: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 

Re: [TLS] New Version Notification for draft-ounsworth-lamps-pq-external-pubkeys-00.txt

[Tim Hollebeek]

When considering caching large public keys for TLS (or other protocols), please 
make sure the security considerations section carefully considers whether the 
proposed mechanism leaks information about whether the client has previously 
contacted the server and possibly how recently, etc.  

 

-Tim

 

From: TLS  On Behalf Of Kampanakis, Panos
Sent: Tuesday, October 10, 2023 9:48 PM
To: Mike Ounsworth ; tls@ietf.org
Subject: Re: [TLS] New Version Notification for 
draft-ounsworth-lamps-pq-external-pubkeys-00.txt

 

Personally, I am against any practical use of McEliece given all the other 
available options. 1MB public keys are unnecessary, impact performance, and are 
wasteful.

 

Regardless of the public key in the cert though, RFC7924 allows (with other 
caveats) for not sending the server cert (and public key) if the client has 
prior knowledge of it. So, it solves the issue for TLS at least in one 
direction. 

 

Are there any other uses for this draft? For example, what use-cases would see 
a material difference by omitting 1-2KB of the Dilithium or Falcon public key 
when the rest of the cert will still amount to 2-3KB (4-7KB if we add in SCTs)? 

 

 

 

 

 

From: TLS mailto:tls-boun...@ietf.org> > On Behalf Of 
Mike Ounsworth
Sent: Saturday, September 30, 2023 6:19 PM
To: tls@ietf.org  
Subject: [TLS] FW: [EXTERNAL] New Version Notification for 
draft-ounsworth-lamps-pq-external-pubkeys-00.txt

 

Hi TLS WG!

 

This is both a new draft announcement, and a request for a short (5 min?) 
speaking slot at 118.

 

We want to socialize the idea of X.509 certificates with external public keys 
(ie the cert contains a link and hash of the public key that can be fetched or 
cached out-of-band.

 

The primary motivator of this LAMPS draft is Classic McEliece encryption certs, 
but we think this could also be valuable for TLS authentication certs. 

 

Consider the following two potential use-cases:

 

1. Browsers

Browsers already have mechanisms to cache intermediate CA certificates. It does 
not seem like a big leap to also cache external public keys for the server 
certs of frequently-visited websites. (yes, yes, I know that the idea of 
caching server public keys runs counter to the desire for the Internet to move 
to 14-day certs. Shrug)

 

2. Mutual-auth TLS within a cluster

Consider a collection of docker containers within a kubernetes cluster. 
Consider that each container has a local volume mount of a read-only database 
of the public keys of all containers in the cluster. Then 
container-to-container mutual-auth TLS sessions could use much smaller 
certificates that contain references to public key objects in the shared 
database, instead of the large PQ public keys themselves.

 

---

Mike Ounsworth

 

From: Spasm <  spasm-boun...@ietf.org> On Behalf 
Of Mike Ounsworth
Sent: Saturday, September 30, 2023 5:16 PM
To: 'LAMPS' <  sp...@ietf.org>
Cc: John Gray <  john.g...@entrust.com>; 
Markku-Juhani O. Saarinen <  m...@pqshield.com>; 
David Hook <  david.h...@keyfactor.com>
Subject: [lamps] FW: [EXTERNAL] New Version Notification for 
draft-ounsworth-lamps-pq-external-pubkeys-00.txt

 

Hi LAMPS! This is both a new draft announcement, and a request for a short (5 
min?) speaking slot at 118. Actually, this is not a new draft. Back in 2021 
Markku and I put forward a draft for External Public Key -- 
draft-ounsworth-pq-external-pubkeys-00 

 

Hi LAMPS!

 

This is both a new draft announcement, and a request for a short (5 min?) 
speaking slot at 118.

 

Actually, this is not a new draft. Back in 2021 Markku and I put forward a 
draft for External Public Key -- draft-ounsworth-pq-external-pubkeys-00 (the 
only reason this is an -00 is because I included "lamps" in the draft name). 
The idea is that instead of a putting the full public key in a cert, you just 
put a hash and pointer to it:

 

   ExternalValue ::= SEQUENCE {

 location GeneralName,

 hashAlg  AlgorithmIdentifier,

 hashVal  BIT STRING

   }

   

That allows super small PQ certs in cases where you can pass the public key 
blob through some out-of-band mechanism.

 

Here's the mail list discussion from 2021:

 

 https://mailarchive.ietf.org/arch/msg/spasm/yv7mbMMtpSlJlir8H8_D2Hjr99g/

 

 

It turns out that BouncyCastle has implemented this at the request of one of 
their customers as a way around megabyte sized Classic McEliece certs; it is 
especially useful for usecases where clients have a way to fetch-and-cache or 
be pre-provisioned with its peer's public keys out-of-band. As such, Entrust 
and 

Re: [TLS] Adoption call for draft-jackson-tls-cert-abridge

[Tim Hollebeek]

The WebPKI has a few features that enable this, which other PKIs really should
consider adopting.  It's one of the few fully transparent PKIs I'm currently 
aware of,
where all of the intermediate and root CAs, and most of the end entity 
certificates
are publicly known and available.

For those reasons, doing this for the WebPKI first and expanding outward from
there makes a lot of sense.

I support adoption as well.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Stephen Farrell
> Sent: Tuesday, August 1, 2023 5:18 PM
> To: Christopher Wood ; TLS@ietf.org
> Subject: Re: [TLS] Adoption call for draft-jackson-tls-cert-abridge
> 
> 
> Hiya,
> 
> I saw the presentation and scanned the draft and support adoption on the
> basis that this could be useful before any certificates using PQC algorithms 
> are
> in play so the target of an experimental RFC is fine, even moreso as I could
> imagine details/codepoints changing over time as new better compressions
> are found.
> 
> I could see this also being a valuable input to work that aims to evolve PKI 
> in
> the face of a potential CRQC but I think it'd be premature to adopt on that
> basis alone as that overall topic needs broader consideration (best done IMO
> in a year or two and not now). In any case, I guess the CCADB doesn't and
> won't have entries using PQC algs for some time, and they might decide to
> handle things in some other way themselves so I'm not sure adopting this as a
> PQ scheme now actually makes sense.
> 
> IIUC it's also a bit of a pity that this'd be formally limited to the WebPKI, 
> being
> based on the CCADB. I guess handling the pretense that nobody uses
> letsencrypt for smtp/tls is probably better handled as part of another
> discussion elsewhere. (One worth having though.)
> 
> Cheers,
> S.
> 
> 
> On 01/08/2023 20:35, Christopher Wood wrote:
> > Hi all,
> >
> > Based on positive feedback received during IETF 117, this email begins an
> adoption call for "Abridged Compression for WebPKI Certificates" (draft-
> jackson-tls-cert-abridge).
> >
> > The datatracker page for this document can be found here:
> > https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/
> >
> > And the GitHub repository can be found here:
> > https://github.com/dennisjackson/draft-jackson-tls-cert-abridge
> >
> > Please indicate whether or not your support adoption of this document in its
> current state. Procedure questions raised during the WG meeting last week
> can be ironed out in the event of this item being adopted.
> >
> > This call for adoption will conclude on August 16.
> >
> > Thanks,
> > Chris, for the chairs
> > ___
> > 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] Abridged Certificate Compression (dictionary versioning)

[Tim Hollebeek]

I wish root programs accepted roots from new CAs at a speed where a one year
old dictionary would be a problem.  Cross-certificates are already generally 
required 
for several years, on average.  However, cross-certificates are not ideal, as 
they increase 
server configuration problems and chain length, which as we've been discussing 
sometimes has performance impacts.

It's something I wish the industry would fix, and I'm glad that improvements in 
this 
area are getting discussed again at CABF.

But yes, we should be careful that we do not introduce a new mechanism that
would potentially add a new bottleneck to root ubiquity, even if it isn't and 
won't
be the long pole today.  Because we don't want it to become the long pole in the
future as the ecosystem continues to improve.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 9:31 PM
> To: Dennis Jackson ; TLS List
> 
> Subject: Re: [TLS] Abridged Certificate Compression (dictionary versioning)
> 
> I wish there was a study of the certs issued by newly introduced CAs in CCADB
> and how quickly they ramp up. I am concerned that a 1 year old dictionary
> could end up slowing down a good amount of destinations. But again, that
> slowdown does not mean an outage. And servers could ensure they get their
> certs issued or cross-issued by relatively mature CAs if they do not want PQ 
> Sig
> related slowdowns.
> 
> Btw, in 3.1.1 I noticed
> - "Remove all intermediate certificates which are not signed by root 
> certificates
> still in the listing."
> 
> That could eliminate some 2+ ICA cert chains. Any reason why?
> 
> 
> 
> -Original Message-
> From: Dennis Jackson 
> Sent: Wednesday, July 12, 2023 1:01 PM
> To: Kampanakis, Panos ; TLS List 
> Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression (dictionary
> versioning)
> 
> 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.
> 
> 
> 
> On 12/07/2023 04:54, Kampanakis, Panos wrote:
> 
> > Hi Dennis,
> >
> > Appendix B.1 talks about 100-200 new ICA and 10 Root certs per year. In
> the past I had looked at fluctuations of CCADB and there are daily changes.
> When checking in the past, I did not generate the ordered list as per pass 1 
> on
> a daily basis to confirm it, but I confirmed the fluctuations. The commits in
> https://github.com/FiloSottile/intermediates/commits/main  show it too.
> Given that, I am wondering if CCADB is not that stable. Are you confident that
> ICA dictionaries (based on CCADB) won't materially change often?
> 
> I checked the historical data for the last few years to ballpark a rate of 
> 100-200
> new intermediates per year. A uniform distribution of arrivals would mean 2 to
> 4 changes a week, which matches Filippo's commit frequency [1]. In practice
> Filippo's commits include removals (which we don't care about) and batched
> additions (which we do), but the numbers seem about right.
> 
> In terms of impact, the question is how much usage do those new ICAs see in
> their first year. If we expect websites to adopt them equally likely as 
> existing
> ICAs then they should make up <5% of the population. I think in practice they
> see much slower adoption and so the impact is even lower, for example a
> reasonable proportion are vanity certificates with limited applicability or
> intended to replace an existing cert in the future. If we wanted to confirm 
> this
> we could build the abridged cert dictionaries for '22 and then use CT to 
> sample
> the cert chains used by websites that year. I'll see if I can find the time 
> to put
> that together.
> 
> If there was an appetite for a faster moving dictionary, we could use the
> scheme I sketched in the appendix to the draft. But I think we should try to
> avoid that complexity if we can.
> 
> Best,
> Dennis
> 
> [1] https://github.com/FiloSottile/intermediates/graphs/commit-activity
> 
> ___
> 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] Abridged Certificate Compression

[Tim Hollebeek]

SCTs have always seemed surprisingly large to me, and it has always seemed
like there should be a more compact representation that has the same security
properties, but I've never found the time to look more closely at it.  If 
someone
does have the time, figuring out how to reduce the size of SCTs would be quite 
helpful.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 2:23 PM
> To: Dennis Jackson ; TLS List
> 
> Subject: Re: [TLS] Abridged Certificate Compression
> 
> > The performance benefit isn't purely in the ~1KB saved, its whether it 
> > brings
> the chain under the QUIC amplification limit or shaves off an additional 
> packet
> and so avoids a loss+retry. There's essentially no difference in 
> implementation
> complexity, literally just a line of code, so the main tradeoff is the 
> required disk
> space on the client & server.
> 
> Fair. I would add one more tradeoff which is pulling the end-entity certs in 
> the
> CT window for pass 2. This is an one time cost for each dictionary version, so
> maybe not that bad.
> 
> Regardless, would compressing the leaf bring us below the QUIC 3.6KB
> threshold for Dilithium 2 or 3 certs whereas not suppressing would keep us
> above? I think it is not even close if we are talking WebPKI. Without SCTs,
> maybe compressing could keep us below 4KB for Dilithium 2 leaf certs. But
> even then, if we add the CertVerify signature size we will be well over 4KB.
> 
> Additionally, would compressing the leaf bring us below the 9-10KB threshold
> that Bas had tested to be an important inflection point? For WebPKI, it may
> the 8-9KB cert below 9KB if we add the CertVerify signature size. Maybe not. 
> It
> would need to tested. For Dilithium 3, maybe compression could render the
> 11-12KB cert below 9KB if we got lucky, maybe not, but if we add the
> CertVerify signature we won’t make it. For non-WebPKI, they will already be
> below 9-10KB.
> 
> So, I am arguing that we can't remain below the QUIC threshold by
> compressing the leaf Dilithium cert. And we could remain below the 9-10KB
> only for Dilithium2 leaves.  I could be proven wrong if you have implemented
> it.
> 
> One more argument for making pass 2 optional or allowing for just pass 1
> dictionaries is that if we are not talking about WebPKI we don't have the
> luxury of CT logs. But we would still want to option of compressing / omitting
> the ICAs by using CCADB.
> 
> 
> 
> 
> -Original Message-
> From: Dennis Jackson 
> Sent: Wednesday, July 12, 2023 12:39 PM
> To: Kampanakis, Panos ; TLS List 
> Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression
> 
> 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.
> 
> 
> 
> On 12/07/2023 04:34, Kampanakis, Panos wrote:
> 
> > Thanks Dennis. Your answers make sense.
> >
> > Digging a little deeper on the benefit of compressing (a la Abridged
> > Certs draft) the leaf cert or not. Definitely this draft improves vs
> > plain certificate compression, but I am trying to see if it is worth
> > the complexity of pass 2. So, section 4 shows a 2.5KB improvement over
> > plain compression which would be even more significant for Dilithium
> > certs, but I am trying to find if the diff between ICA
> > suppression/Compression vs ICA suppression/Compression+leaf
> > compression is significant. [/n]
> >
> > I am arguing that the table 4 numbers would be much different when
> > talking about Dilithium certs because all of these numbers would be
> > inflated and any compression would have a small impact. Replacing a CA
> > cert (no SCTs) with a dictionary index would save us ~4KB (Dilithium2)
> > or 5.5KB (Dilithium3). That is significant. [/n]
> >
> > Compressing the leaf (of size 8-9KB (Dilithium2) or 11-12 KB (Dilithium 3))
> using any mechanism would trim down ~0.5-1KB compared to not
> compressing. That is because the PK and Sig can't be compressed and these
> account for most of the PQ leaf cert size. So, I am trying to see if pass 2 
> and
> compression of the leaf cert benefit us much.
> 
> I think there's a fairly big difference between suppressing CA certs in SCA 
> and
> compressing CA certs with pass 1 of this draft. But I do agree its fair to 
> ask if
> pass 2 is worth the extra effort.
> 
> The performance benefit isn't purely in the ~1KB saved, its whether it brings
> the chain under the QUIC amplification limit or shaves off an additional 
> packet
> and so avoids a loss+retry. There's essentially no difference in 
> implementation
> complexity, literally just a line of code, so the main tradeoff is the 
> required disk
> space on the client & server.
> 
> Best,
> Dennis
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing 

Re: [TLS] Abridged Certificate Compression (server participation)

[Tim Hollebeek]

Honestly, people can blame all sorts of things for the OCSP stapling problems,
but there was nothing inherently wrong with the approach.  The implementations
were just pretty poor due to issues Hubert Kario correctly outlined.  In 
general,
the needs of server operators and maintainers of server software and the
challenges they face are not always taken into account as well as they should 
be.

I think the best way to avoid those problems in this case would be to get up 
front
buy-in from one or two major server software implementors, to make sure they
agree with the approach and would be willing to implement it.

I'm also very happy with the recent efforts in the ecosystem to increase 
transparency around all the existing intermediate CAs, and the fact that this 
enables this sort of technology going forward.  There are a bunch of 
interesting 
points in this thread that I look forward to thinking more about and discussing 
in a few weeks.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 2:01 PM
> To: Dennis Jackson ; TLS List
> 
> Subject: Re: [TLS] Abridged Certificate Compression (server participation)
> 
> Imo, the dictionary approach a simple way of trimming down the PQ auth
> data. And your argument for the frequency of synching OCSP staples vs these
> certs is a good one. I hope TLS termination points will agree if this moves
> forward, but personally I don't find the approach too bad.
> 
> -Original Message-
> From: TLS  On Behalf Of Dennis Jackson
> Sent: Wednesday, July 12, 2023 1:16 PM
> To: Kampanakis, Panos ; TLS List
> 
> Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression (server
> participation)
> 
> 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.
> 
> 
> 
> On 12/07/2023 05:02, Kampanakis, Panos wrote:
> 
> > The abridged certs draft requires a server who participates and fetches
> dictionaries in order to make client connections faster. As Bas has pointed 
> out
> before, this paradigm did not work well with OSCP staples in the past. Servers
> did not chose to actively participate and go fetch them.
> >
> > Are we confident that servers would deploy the dictionary fetching
> mechanism to benefit their connecting clients?
> 
> I think OCSP staples is quite a bit different from this draft. OCSP Staples
> requires the server to fetch new data from the CA every day or week. It's
> inherently hard to do this reliably, especially with the large number of poor
> quality or poorly maintained OCSP servers and the large fraction of operators
> who do not want their servers making outbound connections. Besides these
> barriers I don't think the benefit was huge as clients already cached OCSP
> responses for up to a week so at most it was speeding up one connection per
> client per week (this was before network partitioning in browsers) and at
> worst it was breaking your website entirely.
> 
> In contrast, this draft aims to speed up every connection that isn't using
> session tickets, cause no harm if its misconfigured or out of date and be slow
> moving enough that the dictionaries can be shipped as part of a regular
> software release and so suitable for anyone willing to update their server
> software once a year (or less). Similarly, these updates aren't going to 
> involve
> code changes, just changes to the static dictionaries, so they are suitable 
> for
> backporting or ESR releases.
> 
> It would definitely be good to hear from maintainers or smaller operators if
> they have concerns though!
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] Proposal to make TLS universal

[Tim Hollebeek]

I wish people would stop citing the Cloudflare example as if something 
nefarious is going on there.  It is absolutely, 100% false that the identity in 
a certificate should identify who Cloudflare is getting the certificate on 
behalf of.  Cloudflare requests the certificates, holds the keys, and operates 
the servers.  It is the correct entity to identify as the certificate subject.

Modern web architectures are complicated, and there are other organizations 
participating in other roles.  It would be possible to name those as well, but 
you'd have to define the roles, what they mean, how to validate them, and how 
to put them into certificates.  If people want to make proposals in that area, 
they certainly can.  But Cloudflare isn't doing anything wrong here.

-Tim

From: TLS  On Behalf Of Yannick LaRue
Sent: Tuesday, March 28, 2023 12:29 AM
To: tls@ietf.org
Subject: [TLS] Proposal to make TLS universal

Dear TLS Working Group,

Thank you for your response to our previous message from Eric Rescorla. We 
appreciate your clarification on the use of ECDH ephemeral for encrypting the 
exchange of certificates in the TLS 1.3 handshake.

Based on this information, we have a new proposal to make TLS universal and 
promote the use of encryption across the internet. Our idea is to use ECDH 
ephemeral to create secure connections for sites that do not have certificates. 
This will provide a low level of security for these sites, but still better 
than the current situation where plaintext HTTP is used for these sites. 
Furthermore, using a certificate for a site should provide a medium level of 
security, which is already the case. Finally, mutual authentication should 
provide a high level of security. We believe this approach would be in line 
with the spirit of the Browser Forum, which seeks to promote universal 
encryption on the internet.

Furthermore, our proposal to use ECDHE for securing connections without a 
certificate provides the same level of assurance as the use of low-assurance 
certificates, such as those issued by Let's Encrypt or Cloudflare, which do not 
guarantee the identity of the server and its owners. In fact, many certificates 
simply guarantee that the site is hosted by a particular provider, such as the 
certificate used any site on Cloudflare, which lists Cloudflare, Inc. as the 
organization. Our proposal offers a more universal approach to encryption that 
doesn't rely on specific certificate authorities or their levels of assurance, 
and it would bring the benefits of encryption to all sites, regardless of their 
level of technical sophistication or resources.

Additionally, it is worth noting that many websites currently use low-assurance 
certificates simply to meet TLS requirements and enable encryption on their 
channels. This practice goes against the original philosophy of TLS, which was 
designed to provide strong assurance of server identity. Therefore, our 
proposal to include a low-assurance level using ephemeral ECDH in TLS would not 
only make the protocol universal but also help mitigate this problem. This 
reinforces the idea of including a method within TLS for users to securely 
utilize the protocol without having to resort to workarounds.

We believe that by making encryption available to all sites, we can promote 
greater security on the internet. This proposal will also help users understand 
the level of security provided by their connections and will encourage them to 
demand stronger security where it is necessary.

Thank you for your consideration, and we look forward to your response.

Best regards,

Yannick LaRue
SSE Carte à Puce Inc.
___
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?

[Tim Hollebeek]

I think he is.

In order to pull off your attack, you need to convince a CA that you have their 
identity, so you can bind an arbitrary public key to it, then publish it.

But if you can attach an arbitrary public key to someone else's identity, 
you're going to use that for MITM and not the DoS you described.  Which is far 
worse.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Blumenthal, Uri - 0553 -
> MITLL
> Sent: Friday, October 7, 2022 3:04 PM
> To: tls@ietf.org
> Subject: Re: [TLS] [lamps] [EXTERNAL] Re: Q: Creating CSR for encryption-
> only cert?
> 
> 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
___
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?

[Tim Hollebeek]

> > 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, just wanted to point out that this is one of the most humorous things
> I've read in a while.   I should make a poster or t-shirt out of this 
> statement
> (as we watch civilization collapse around us for other reasons)   

If it doesn't include a picture of raw PKCS #10 on top of sushi rice, I won't 
buy it.

-Tim

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

[Tim Hollebeek]

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

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.

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.

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.

-Tim

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 
mailto:pgut...@cs.auckland.ac.nz>>
Sent: Thursday, October 6, 2022 8:51:17 PM
To: von Oheimb, David 
mailto:david.von.ohe...@siemens.com>>; John Gray 
mailto:john.g...@entrust.com>>; Mike Ounsworth 
mailto:mike.ounswo...@entrust.com>>; 
tomas.gustavs...@keyfactor.com 
mailto:tomas.gustavs...@keyfactor.com>>
Cc: sp...@ietf.org 
mailto:sp...@ietf.org>>; 
morgan...@dataio.com 
mailto:morgan...@dataio.com>>; 
tls@ietf.org mailto: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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] OCSP and browsers

[Tim Hollebeek]

Also, the amount of work necessary to make Certificate Transparency work with 
three day certificates is probably not worth the effort.

It's not that you can't do it ... the easiest way is to break the 1-1 
correspondence between SCTs and certificates, and make allowances for issuing a 
series of certificates that are identical except for serial numbers and dates, 
and can all reasonably share the same CT entry.  But that's a non-trivial 
redesign.

Blowing up CT logs by a factor of 100 is also possible but less desirable.

I was a huge fan of the extremely short-lived cert idea, but I think it's time 
may have passed.  The compressed CRL stuff that browsers are already 
contemplating and deploying is a better path forward.

-Tim

From: TLS  On Behalf Of Salz, Rich
Sent: Sunday, October 2, 2022 9:14 AM
To: Phillip Hallam-Baker 
Cc: tls@ietf.org
Subject: Re: [TLS] OCSP and browsers


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



Not all CA's in use on the WebPKI support ACME.  Automating a single-host to 
renew every 48 hours (have to allow for faults and retries) is okay, as long as 
you are confident your site will not be done during the "get new cert" window.  
As you scale up to millions of sites and/or thousands of locations, it's much 
less simple.



But I'm still looking for an answer about what browsers and OCSP see as their 
future.


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

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

[Tim Hollebeek]

Thanks for the pointer to that draft, it’s very helpful.  The security 
considerations sections touches on my concerns a little bit, but probably needs 
more detail in this area.

Another thing that might help is some sort of extension or signal that 
indicates that the certificate is intended to be used in this manner.  
Otherwise we’re adding new and potentially surprising behavior to all the 
existing IP address certificates out there, whether they want it or not.  If 
the behavior is “opt-in” by all the participants that desire it, that would be 
safer.

Maybe that’s not necessary, still reading and thinking this through.  It’s an 
interesting use case.

-Tim

From: Erik Nygren 
Sent: Thursday, July 28, 2022 7:14 PM
To: Tim Hollebeek 
Cc: David Benjamin ; TLS@ietf.org
Subject: Re: [TLS] Representing IP addresses in SNI -- proposed draft

The use-case that may increase IP certificates is this from ADD's DDR:

https://datatracker.ietf.org/doc/html/draft-ietf-add-ddr-08#section-4.2

At a high-level, the client talks insecurely to their configured local DNS 
resolver with IP address "A"
and queries for "_dns.resolver.arpa."
That returns a SVCB record that points to another DNS resolver that may have 
hostname dot.example.com<http://dot.example.com>
with IP address "B".
As part of the "Verified Discovery" logic, the client connects to 
dot.example.com<http://dot.example.com> (IP address "B")
but then has to verify that the presented TLS certificate contains IP address 
"A".

If they share an IP address this is straight-forward (and a "normal" IP address 
cert).
But if A and B are different IPs then "dot.example.com<http://dot.example.com>" 
in this case may need
a separate IP address "B" (and hostname) for each IP address "A" that might be 
in-use
(with perhaps some efficiencies possible through SAN-packing).

Erik


On Thu, Jul 28, 2022 at 3:04 PM Tim Hollebeek 
mailto:tim.holleb...@digicert.com>> wrote:
I’m worried about the fact that this means a certificate that was issued for 
and intended to be used by a particular IP address is now potentially usable on 
any arbitrary IP address via this behavior.  Though I haven’t thought it all 
the through yet, it seems to me to be likely that there are use cases where 
this has at least mild unexpected security consequences.  Bonus points if you 
find a way this makes it easier to collect traffic intended for that IP from a 
different IP.

On .in-addr.arpa certificates, I’ve been trying to find out why there are web 
servers running on those domains since I was at my previous employer over five 
years ago, and have been periodically asking about them:

https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg11410.html

If anyone knows why they exist, I’d love to know.

Also, if IP certificates are getting more common again, I’d love to hear about 
those use cases as they’re not on my radar at this time.  When I wrote the 
ballot for validation of IP addresses, it was a royal pain and took a few years 
because no one was actually interested in them.  My impression was that they 
were slowly going away with time, but I haven’t looked at the numbers recently.

-Tim

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of Erik 
Nygren
Sent: Wednesday, July 27, 2022 4:59 PM
To: David Benjamin mailto:david...@chromium.org>>
Cc: TLS@ietf.org<mailto:TLS@ietf.org>
Subject: Re: [TLS] Representing IP addresses in SNI -- proposed draft

Both of these are very good concerns about the compatibility risk.
I think David's alternative of having a new extension (eg, server_name_ip)
might address a bunch of the issues and be cleaner than any of the other hacks.
It would have a higher implementation overhead, but also might be more likely 
to be deployable.

I checked search.censys.io<http://search.censys.io> and there appear to be 
around 150M certificates
with IP addresses in them that it is aware of, and that is pretty much a 
guarantee
that some of them will break with sending something new in an existing SNI 
extension...

Erik


On Wed, Jul 27, 2022 at 4:16 PM David Benjamin 
mailto:david...@chromium.org>> wrote:
I agree this is quite a compatibility risk. In addition to messing with SNI 
lookup, there are servers that try to correlate TLS SNI and HTTP Host. Indeed, 
when we accidentally sent IP literals in SNI, we broke a server that tried to 
do that but got very confused by the colons in an IPv6 literal. That server 
would likely also be confused by this draft, less by syntax and more by 
SNI/Host mismatch. I would be surprised if this option were viable.

Another option, which doesn't require redefining existing fields, is to simply 
allocate a new extension. Though I agree with Martin that one would expect the 
server to know its own IP. If you implicitly interpret a missing server_name 
extensio

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

[Tim Hollebeek]

I’m worried about the fact that this means a certificate that was issued for 
and intended to be used by a particular IP address is now potentially usable on 
any arbitrary IP address via this behavior.  Though I haven’t thought it all 
the through yet, it seems to me to be likely that there are use cases where 
this has at least mild unexpected security consequences.  Bonus points if you 
find a way this makes it easier to collect traffic intended for that IP from a 
different IP.

On .in-addr.arpa certificates, I’ve been trying to find out why there are web 
servers running on those domains since I was at my previous employer over five 
years ago, and have been periodically asking about them:

https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg11410.html

If anyone knows why they exist, I’d love to know.

Also, if IP certificates are getting more common again, I’d love to hear about 
those use cases as they’re not on my radar at this time.  When I wrote the 
ballot for validation of IP addresses, it was a royal pain and took a few years 
because no one was actually interested in them.  My impression was that they 
were slowly going away with time, but I haven’t looked at the numbers recently.

-Tim

From: TLS  On Behalf Of Erik Nygren
Sent: Wednesday, July 27, 2022 4:59 PM
To: David Benjamin 
Cc: TLS@ietf.org
Subject: Re: [TLS] Representing IP addresses in SNI -- proposed draft

Both of these are very good concerns about the compatibility risk.
I think David's alternative of having a new extension (eg, server_name_ip)
might address a bunch of the issues and be cleaner than any of the other hacks.
It would have a higher implementation overhead, but also might be more likely 
to be deployable.

I checked search.censys.io and there appear to be 
around 150M certificates
with IP addresses in them that it is aware of, and that is pretty much a 
guarantee
that some of them will break with sending something new in an existing SNI 
extension...

Erik


On Wed, Jul 27, 2022 at 4:16 PM David Benjamin 
mailto:david...@chromium.org>> wrote:
I agree this is quite a compatibility risk. In addition to messing with SNI 
lookup, there are servers that try to correlate TLS SNI and HTTP Host. Indeed, 
when we accidentally sent IP literals in SNI, we broke a server that tried to 
do that but got very confused by the colons in an IPv6 literal. That server 
would likely also be confused by this draft, less by syntax and more by 
SNI/Host mismatch. I would be surprised if this option were viable.

Another option, which doesn't require redefining existing fields, is to simply 
allocate a new extension. Though I agree with Martin that one would expect the 
server to know its own IP. If you implicitly interpret a missing server_name 
extension as "I want the IP cert for this connection's IP", it's already 
unambiguous. Granted, there may be edge cases because missing server_name can 
also mean "I want the default cert" and perhaps your "default" cert and IP cert 
are different.

On Wed, Jul 27, 2022 at 12:17 PM Martin Thomson 
mailto:m...@lowentropy.net>> wrote:
Hi Erik,

As far as it goes, this might work.  However, I'm not sure about the effect of 
this on compatibility.  I'm concerned that maybe this would end up causing some 
servers to choke.  Servers that receive SNI can sometimes use that SNI value to 
lookup the correct certificate.  Your design could have those servers searching 
for a certificate that doesn't exist.

Anything along these lines would need to be tested for compatibility - 
extensively - before it could even be trialed.

(I never saw the DDR as having deployment problems along these lines.  It isn't 
THAT hard to know your own IP address for that purpose.)

On Wed, Jul 27, 2022, at 14:38, Erik Nygren wrote:
> Following discussions in ADD around the DDR draft (as well as in UTA
> around Martin Thomson's PR to add IP address SANs to 6125-bis),
> I wrote up a draft on how IP addresses might be represented in SNI:
>
>   https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
>
> There are at least three different ways we could do it, but this draft
> proposes what seems to be the least bad while also talking about the
> other alternatives.  (I suspect we'd want to move the alternatives
> to an appendix or remove entirely from a final version.)
>
> Is this interesting to the working group?
> While IP address SANs have a bunch of corner cases and gaps,
> they do seem to be picking up new uses.
>
> What motivated me to realize we need to solve this is that
> draft-ietf-add-ddr uses IP SANs in a new way.  Rather than the
> client connecting to an IP address and expecting to see a SAN
> (where returning a cert associated with the IP address containing
> a SAN that the client connected to is straight-forward),
> DDR has clients connecting to a different IP and then
> expects to find an original IP also in the SAN list.
> This means that for an ISP with a 

Re: [TLS] DNS-based Encrypted SNI

[Tim Hollebeek]

One of the things we found out with CAA is that this extremely optimistic view
of the support for unknown RR types by large hosting providers is not 
accurate.

-Tim

> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Paul Wouters
> Sent: Monday, July 2, 2018 11:53 PM
> To: tls@ietf.org
> Subject: Re: [TLS] DNS-based Encrypted SNI
>
> On Mon, 2 Jul 2018, Eric Rescorla wrote:
>
> >   https://tools.ietf.org/html/draft-rescorla-tls-esni-00
>
> > This is at a pretty early stage, so comments, questions, defect
> > reports welcome.
>
>
>   This structure is placed in the RRData section of a TXT record as a
>   base64-encoded string.  If this encoding exceeds the 255 octet limit
>   of TXT strings, it must be split across multiple concatenated strings
>   as per Section 3.1.3 of [RFC4408].
>
> It is strongly recommended not to use TXT records. Why not use a new
> RRTYPE? Everything these days knows how to serve unknown record types (see
> RFC 3597). The only possibly exception is provisioning tools of small 
> players,
> but this document starts of saying you basically need to be on a bulk 
> hosting
> provider anyway. They can properly provision.
>
> I need to think more about the document to see if there is really not 
> something
> simpler or better possible.
>
> Paul
>
> ___
> 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] TLS DNSSEC chain consensus text, please speak up...

[Tim Hollebeek]

I think there’s room for two people in front of the steamroller.  And I have a 
towel.  How many votes does that get me?

 

-Tim

 

From: Melinda Shore [mailto:melinda.sh...@nomountain.net] 
Sent: Thursday, May 17, 2018 9:21 PM
To: Tim Hollebeek <tim.holleb...@digicert.com>
Cc: Paul Wouters <p...@nohats.ca>; <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

 

And to be clear, it's not that nobody is going to implement the extension (it's 
already been done in an IETF hackathon and elsewhere), the work on the 
extension was funded by Mozilla, and there's been an outstanding request for 
this in Bugzilla.  What's not being implemented is the proposed changes.

 

But, it's clear that those guys don't intend to compromise and we're going to 
be deadlocked pretty much forever unless someone does something.  That's not 
going to be Viktor and it's not going to be the chairs, so I guess it's me.  

 

Melinda

 

On Thu, May 17, 2018, 16:20 Tim Hollebeek <tim.holleb...@digicert.com 
<mailto:tim.holleb...@digicert.com> > wrote:

I’m actually fine with that.  You have to consider P_{extension implemented and 
used}.

 

Different people will disagree about the value of P.

 

-Tim

 

From: Paul Wouters [mailto:p...@nohats.ca <mailto:p...@nohats.ca> ] 
Sent: Thursday, May 17, 2018 8:18 PM
To: Tim Hollebeek <tim.holleb...@digicert.com 
<mailto:tim.holleb...@digicert.com> >
Cc: James Cloos <cl...@jhcloos.com <mailto:cl...@jhcloos.com> >; Ted Lemon 
<mel...@fugue.com <mailto:mel...@fugue.com> >; <tls@ietf.org 
<mailto:tls@ietf.org> > <tls@ietf.org <mailto:tls@ietf.org> >
Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

 

 

On May 17, 2018, at 19:44, Tim Hollebeek <tim.holleb...@digicert.com 
<mailto:tim.holleb...@digicert.com> > wrote:

Making things more complicated with no obvious benefit just makes things
more complicated.

I oppose adding two bytes for some nebulous future purpose.

 

The consequence of this opinion would be this:

 

https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00

 

Which is a lot of complexity for one TLS extension to define the behaviour of 
another TLS extension. And it still adds two bytes in the 2nd extension.

 

So if you believe more simplicity is better, then you made the wrong choice.

 

 

Paul

___
TLS mailing list
TLS@ietf.org <mailto: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] TLS DNSSEC chain consensus text, please speak up...

[Tim Hollebeek]

I’m actually fine with that.  You have to consider P_{extension implemented and 
used}.

 

Different people will disagree about the value of P.

 

-Tim

 

From: Paul Wouters [mailto:p...@nohats.ca] 
Sent: Thursday, May 17, 2018 8:18 PM
To: Tim Hollebeek <tim.holleb...@digicert.com>
Cc: James Cloos <cl...@jhcloos.com>; Ted Lemon <mel...@fugue.com>; 
<tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

 

 

On May 17, 2018, at 19:44, Tim Hollebeek <tim.holleb...@digicert.com 
<mailto:tim.holleb...@digicert.com> > wrote:

Making things more complicated with no obvious benefit just makes things
more complicated.

I oppose adding two bytes for some nebulous future purpose.

 

The consequence of this opinion would be this:

 

https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00

 

Which is a lot of complexity for one TLS extension to define the behaviour of 
another TLS extension. And it still adds two bytes in the 2nd extension.

 

So if you believe more simplicity is better, then you made the wrong choice.

 

 

Paul



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

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

[Tim Hollebeek]

Making things more complicated with no obvious benefit just makes things
more complicated.

I oppose adding two bytes for some nebulous future purpose.

-Tim

> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of James Cloos
> Sent: Wednesday, May 16, 2018 6:20 PM
> To: Ted Lemon 
> Cc:  
> Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up...
> 
> > "TL" == Ted Lemon  writes:
> 
> TL> Melinda made a pretty serious technical objection.  Your response is
not
> TL> responsive to her objection.   She explicitly said that her objection
was
> TL> not the two bytes.
> 
> I don't see anything in her note today which is a technical objection.
> 
> And I've seen no useful or reasonable objections to Viktor's suggestion.
> 
> The sixteen bit field harms no one, and when defined and used provides
> significant benefit to many.
> 
> -JimC
> --
> James Cloos  OpenPGP: 0x997A9F17ED7DAEA6
> 
> ___
> 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-exported-authenticator

[Tim Hollebeek]

I generally really like it.

 

My only comment is about the use of a zero byte as a separator in a string 
(4.2.2).

 

There are commonly used languages where this is likely to lead to 
implementation bugs, causing the signature to be computed over a shorter length 
than expected.

 

While I doubt this causes any problems other than failures and debugging pain, 
the first 64 bytes contain the octet 32; I don’t see any reason why byte 87 
can’t also be octet 32.

 

-Tim

 

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Nick Sullivan
Sent: Thursday, May 3, 2018 4:16 PM
To: Sean Turner 
Cc: TLS WG 
Subject: Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

 

Does anyone have any comments about the draft, criticisms, or votes of support?

 

Nick

On Thu, May 3, 2018 at 1:12 PM Sean Turner  > wrote:



> On Apr 21, 2018, at 10:25, Sean Turner   > wrote:
> 
> 
>> On Apr 19, 2018, at 16:32, Sean Turner >  > wrote:
>> 
>> All,
>> 
>> This is the working group last call for the "Exported Authenticators in TLS" 
>> draft available at 
>> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ 
>>  . 
>>  Please review the document and send your comments to the list by 2359 UTC 
>> on 4 April 2018.
> 
> … 4 May 2018 ...

Just a reminder the WGLC ends tomorrow.

spt
___
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 draft-ietf-tls-dnssec-chain-extension

[Tim Hollebeek]

> The webpki is changing dramatically. The amount of CAB/forum violations
> seems to be increasing, partially as a result of these violations getting
> exposed
> by certificate transparancy and perhaps partially because of the financial
> strain
> caused by the free LetsEncrypt.

Uniformed speculations that are just flat out wrong do not help anyone.

LetsEncrypt, if anything, has been a big help to the CA industry.  Both free 
and paid offerings are seeing significant growth.  Let's not spread FUD about 
"financial strain" that does not actually exist.  And furthermore, it's best 
not suggest hypothetical unproved ("seems to be") observations are caused by 
the previously mentioned cause that doesn't actually exist.  That's 
irresponsible.

Tools like cablint have actually contributed far more to improvements in the 
technical compliance of certificates from vendors who previously didn't adhere 
that closely to strict compliance with RFCs, CABF requirements, required 
certificate profiles, and so on.  CT is less responsible, as it is only 
required for EV (though many large CAs have voluntarily started logging all 
certificates).  Many bad certificates were still found the old fashioned way: 
by crawling for them.

There's an old story about an intelligence analyst who found a handful of 
suspicious structures in a remote desert.  More resources were assigned to 
figure out what they were.

A few months later, the number of structures was observed to be increasing 
rapidly.  More resources were assigned.

Pretty soon, new ones were found every day.  People started panicking, and 
someone was dispatched to investigate on the ground.

It turned out to be a kind of water condenser common in the region, and the 
increase in numbers was only because people had started looking for them. 
They had always been there, just no one paid attention to them.

The truth is that the increase in activity around problems with various 
certificates is because people are just paying far more attention to even the 
smallest, most obscure details of every issued web PKI certificate these days: 
far, far more than they did even just two or three years ago.

And that's a good thing, not a bad thing.  Progress is being made.  The 
certificates being issued by almost every CA out there are much technically 
cleaner than they  were when I first started doing CA things, maybe five years 
ago.

The Symantec swamp cleanup effort is also responsible for a significant 
fraction (the majority?) of recent reports.

-Tim


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

Re: [TLS] Additional TLS 1.3 results from Chrome

[Tim Hollebeek]

> I'm not sure I agree renumbering is the right reaction, though I don't 
> object to
> that. This could be a case where it's overall better that those specific 
> devices
> suffer breakage, and hopefully then do get firmware updated to support
> TLS1.3 or TLS-without-extended-random-or-dual-ec
> at some point.

It's never better to break large numbers of things, if it can be avoided at 
low
cost.  The reaction isn't going to be "TLS 1.3 broke my printer, it's time to
upgrade my firmware.", it's going to be "TLS 1.3 broke my printer, which was
working perfectly fine.  TLS 1.3 is bad.  I wonder what else they got wrong.
People shouldn't use TLS 1.3."

-Tim



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

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

[Tim Hollebeek]

Because it's easier for the client to decide what the client understands
than it is for the server to decide what the client understands.  Less
complexity = less failures.  

Note that this is how XP was handled for code signing.  The Authenticode
spec actually made it so if you did things in the right order, XP would only
see the SHA-1 signature, while more recent operating systems would see both
the SHA-1 and SHA-2 signatures, ignore the SHA-1 signature, and use the
SHA-2 signature.  This allowed doubly-signed binaries that worked both on XP
and non-XP systems.  Unfortunately the technical steps to do so weren't
widely publicized, but I know some companies took advantage of it.

However, servers are easier to upgrade than clients, which is why you see
some of the server side support you mention.  I know CloudFlare in
particular helped a lot of people cope with communicating with clients who
had different certificate capabilities.  It isn't a bad thing that both
approaches exist.

-Tim

> -Original Message-
> From: Andrei Popov [mailto:andrei.po...@microsoft.com]
> Sent: Friday, December 15, 2017 12:25 PM
> To: Tim Hollebeek <tim.holleb...@digicert.com>; Ilari Liusvaara
> <ilariliusva...@welho.com>
> Cc: tls@ietf.org
> Subject: RE: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in
> general, and what we can do in TLS
> 
> > Ideally, you'd want certificates to be able to have two signatures
> > during the transition period, in order to support clients who have
> > transitioned and those who have not.
> 
> > Hosting multiple certificates and switching based on the client is
> > feasible, but requires some technical wizardry and isn't possible in all
> situations.
> 
> For my understanding, why is the former (double-signed certs, where either
> signature is trusted) better than the latter (multiple certs with
different
> algorithms)?
> The latter is currently supported by some TLS servers.
> 
> Cheers,
> 
> Andrei


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

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

[Tim Hollebeek]

So, this has been discussed extensively at the CA/Browser forum, for obvious
reasons.

In my mind, it is not so important to identify and define and implement an
alternative hash.

What *is* important is that the protocol and associated software is able to
support a smooth transition period where people are moving from one
algorithm to another.

Ideally, you'd want certificates to be able to have two signatures during
the transition period, in order to support clients who have transitioned and
those who have not.  Unfortunately RFC 5280 is deficient in that regard.
Hosting multiple certificates and switching based on the client is feasible,
but requires some technical wizardry and isn't possible in all situations.

A lot of these transitions are painful because with the way things currently
work, algorithms have to reach near ubiquity before the transition can begin
(the popularity of Windows XP was a huge problem).

The transition will happen at different rates for various industries and use
cases that have different security requirements, so everyone needs to be
able to move at a pace that makes sense for their needs.  It needs to be
carefully coordinated, and yes, transitions will take years.  The current
maximum certificate lifetime is a compromise between the speed at which
changes can be made, and the pain imposed by replacement, which largely
still isn't automated.  I know people are working to improve that, but we
are where we are.

-Tim

> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara
> Sent: Friday, December 15, 2017 11:50 AM
> To: Andrei Popov 
> Cc: tls@ietf.org
> Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in
> general, and what we can do in TLS
> 
> On Fri, Dec 15, 2017 at 06:41:06PM +, Andrei Popov wrote:
> > It's true, the migration will be slow, but IMHO it still makes sense
> > to define and implement an alternative hash.
> 
> Agreed. However, on certificates front, we need a method to perform
> backward-compatible algorithm transition. Because non-backward-
> compatible ones are just too hard. As we have seen _twice_.
> 
> On TLS handshake hashes, the transitions are already backward- compatible.
> But that does not mean the transition will be easy.
> 
> 
> 
> 
> -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