[TLS]Re: HRR support (was something else)

[Joseph Birr-Pixton]

On Wed, 5 Jun 2024 at 14:24, Peter Gutmann 
wrote:

> Martin Thomson  writes:
>
> >Are you saying that there are TLS 1.3 implementations out there that don't
> >send HRR when they should?
>
> There are embedded TLS 1.3 implementations [*] that, presumably for space/
> complexity reasons and possibly also for attack surface reduction, only
> support the MTI algorithms (AES, SHA-2, P256) and don't do HRR.
>
> We found this out because of Google's noncompliant implementation in
> Chrome.
> In the presence of compliant implementations that do the MTI algorithms in
> the
> client hello, you don't need HRR
>

That is not a correct interpretation, in my opinion. Offering a key_share
for every MTI key exchange is not required, because:

>   Clients MAY send an empty client_shares vector in order to request
>   group selection from the server, at the cost of an additional round
>   trip

This clause requires HRR support from all peers.

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

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Joseph Birr-Pixton]

On Fri, 29 Sept 2023 at 15:45, Bas Westerbaan  wrote:

> We have been investigating turning on post-quantum key agreement for
> connections from Cloudflare to origin servers. In testing, we found that
> 0.34% of origins will fail to establish a connection if we send
> X25519Kyber768Draft00 keyshare directly (while still advertising support
> for classical keyshares.)  As expected, a significant portion of failures
> seem to be caused by the large ClientHello. Interestingly though, the
> majority of these failures don't seem to be specific to the size of the
> ClientHello, but are rather caused by the origin not supporting
> HelloRetryRequest correctly. We're still digging into it, and will share
> our findings later on.
>
> Anyway, even though it's a small fraction of origins, we cannot send a PQ
> keyshare immediately and completely break the websites in front of those
> few origins. Instead, we are going [1] for the following approach: we send
> a X25519 keyshare, but advertise support for Xyber.
>

If the client is happy with either X25519 alone or X25519Kyber768, why not
send shares for both in the first ClientHello? Yes, that adds more bloat
there (but it's already large) but it need not require any additional
computation (because the prefix of a X25519Kyber768 share is a valid X25519
share, and the server can only proceed with one).

Would be good if draft-tls-westerbaan-xyber768d00 either mentions this as a
blessed implementation choice, or conversely disrecommends it and explains
why.

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

[TLS] TLS client fingerprinting

[Joseph Birr-Pixton]

Hello,

Recently I've become aware that "TLS fingerprinting" is a thing. I
understand it has been deployed by Google, Cloudflare, Apple and others to
(at a guess)  "authenticate" TLS clients. For example, I understand that
certain Google Android cloud services refuse to interop with anything that
doesn't look like openssl-1.1.1 with a specific configuration. That is very
disappointing.

GREASE is ineffective at diffusing fingerprinting -- and that was never its
goal -- because it seems fingerprinting processes ("JA3" seems popular?)
actively remove the published GREASE code points if they are encountered.

But it seems the spirit of GREASE was to avoid the protocol rusting shut,
and here we have another case of the protocol becoming defined by
implementation rather than standard -- now TLS implementations have to
strictly follow a fingerprint accidentally defined by other implementations
or risk interop failure. We now receive defect reports asking us to
determine and identically reproduce the behaviour of old OpenSSL versions.
This is a terrible situation -- cipher suites, extensions, and named groups
all have rusted shut.

I'd like to ask if there any latent knowledge in the WG:

1. why do extensions not have a defined order (such as in order of code
point) to reduce this as a source of fingerprinting? I'm aware of the
specific ordering constraint on the TLS1.3 PSK binder extension, but as far
as I know this is the only time extension ordering has ever been specified.
It seems odd that TLS1.3 had such a variety of privacy improvements, but
not here?

2. what's going on in appendix E.3 in RFC8446? There's a reference there to
[HCJC16] but the text does not address the main fingerprinting findings in
[HCJC16] at all.

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

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

[Joseph Birr-Pixton]

On Sun, 24 Jan 2021 at 23:03,  wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
>
> Title   : Delegated Credentials for TLS

I'm a little confused too by the meaning of 4.1.3:

#   1.  Validate that DelegatedCredential.cred.valid_time is no more than
#   7 days.

I read this as saying that a certificate can only be usable for
delegation in the first 7 days after it's notBefore. That follows from
valid_time being an offset in seconds from notBefore, and validation
step 3 covers the "maximum validity period" mentioned elsewhere in the
draft. This sounds a bit odd.

Honestly, I find the name and definition of valid_time a little
unclear. It's neither a "validity time" instant, or a period. Perhaps
"validity_offset"? But it may be simpler to just make it 64 bits and
_make_ it a UTC instant -- with the added benefit that this may result
in fewer implementations doing unsigned 32-bit arithmetic on times in
seconds and breaking ~15 years hence.

I think this draft would also benefit from explicitly drawing out (d)
in this thought process:

a) for performance reasons[1], it seems unlikely that RSA keys are
workable as delegated credentials.
b) a huge amount of the webpki is still built on RSA.
c) given (a) and (b), a common deployment strategy will mean mixed
authentication cryptography in handshake authentication: RSA for the
webpki portion, ECDSA/EdDSA perhaps for delegation.
d) and this is OK (as it is in webpki), and totally allowed, and expected.

Thanks,
Joe

[1] expensive, non-deterministic key generation; large key sizes

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

Re: [TLS] TLS Impact on Network Security draft updated

[Joseph Birr-Pixton]

Hello,

I would like to suggest that this draft is expanded to cover the use cases
of governments, such as those recently seen in Kazakhstan. This will
ideally leave the reader with a fuller impression of the risks inherent in
the technology being described here.

- section 1: add a sentence to the introduction, eg. "Governments may wish
to intercept their citizen's traffic for the purpose of identifying and
combating political dissent."
- section 4: add subsection "09 - Suppression of Dissent" covering this use
case of the technology.

Thanks,
Joe




On Sun, 21 Jul 2019 at 14:51, Nancy Cam-Winget (ncamwing) <
ncamw...@cisco.com> wrote:
>
> Hi,
>
> Thanks to all the feedback provided, we have updated the
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
>
> draft.  At this point, we believe the draft is stable and would like to
request its publication as an informational draft.
>
>
>
> Warm regards,
>
> Nancy
>
>
>
>
>
> ___
> 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] 0-RTT profiles

[Joseph Birr-Pixton]

Hello,

> Application protocols MUST NOT use 0-RTT data without a profile that defines 
> its use.
> That profile needs to identify which messages or interactions are safe to use 
> with 0-RTT
> and how to handle the situation when the server rejects 0-RTT and falls back 
> to 1-RTT.

0-RTT has now at least two large deployments on the public internet
that I know of. Are there any such "profiles" published or being
worked on?

Thanks for any pointers.

Cheers,
Joe

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

Re: [TLS] New version intolerance caused by draft-26 supported_versions change?

[Joseph Birr-Pixton]

On 9 April 2018 at 22:29, Eric Rescorla  wrote:
> PR#1163 was just about what the server sends.

Aha. This is the bit I missed. I had interpreted "you can't negotiate
pre-TLS 1.3 with supported_versions" applied to both ends.

Thanks!
Joe

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

[TLS] New version intolerance caused by draft-26 supported_versions change?

[Joseph Birr-Pixton]

Hello,

PR#1163 in draft-26 seems to have broken interop with previous drafts
with a variety of deployed implementations. draft-26 and later clients
fail with a protocol_version alert.

Affected Internet servers include:

cloudflare.com: offers draft-23, intolerant to draft-26
www.apple.com: seemingly unwilling to negotiate any draft, but
intolerant anyway(?)
www.microsoft.com: same
google.com: same

https://jbp.io/assets/tls13-logs/cloudflare.broken.txt
https://jbp.io/assets/tls13-logs/apple.broken.txt
https://jbp.io/assets/tls13-logs/microsoft.broken.txt
https://jbp.io/assets/tls13-logs/google.broken.txt

In all these cases, offering TLS1.2 in supported_versions (ie, the
pre-draft-26 behaviour) works, and TLS1.2 is negotiated:

https://jbp.io/assets/tls13-logs/cloudflare.works.txt
https://jbp.io/assets/tls13-logs/apple.works.txt
https://jbp.io/assets/tls13-logs/microsoft.works.txt
https://jbp.io/assets/tls13-logs/google.works.txt

Corroboration appreciated.  It's totally possible I'm doing something stupid :)

Thanks,
Joe

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

[TLS] Two draft-22 comments

[Joseph Birr-Pixton]

Hello,

Draft 22 says:

  An implementation may receive an unencrypted record of type
  change_cipher_spec consisting of the single byte value 0x01 at any
  time during the handshake and MUST simply drop it without further
  processing.

That requirement is hard to meet in a library that implements both
TLS1.2 and TLS1.3 -- a CCS prior to ServerHello would have to be both
fatally rejected (TLS1.2) and dropped without further processing
(TLS1.3).

Are there any problems with tightening up "at any time during the
handshake"? Or perhaps I should be interpreting the time prior to
ServerHello as not being "during the handshake"?

--

There's inconsistency in whether the supported_versions extension is
allowed in HelloRetryRequest.  4.2.1 and B.3.1.1 say no, but 4.1.4,
4.2 and 9.2 say yes. I'll assume that's an omission and submit a PR.

Cheers,
Joe

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

Re: [TLS] RFC 6066 - Max fragment length negotiation

[Joseph Birr-Pixton]

On 18 March 2017 at 09:36, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote:
> Joseph Birr-Pixton <jpix...@gmail.com> writes:
>
>>With the greatest of respect, mbedtls *doesn't* implement
>>max_fragment_length[1], because it doesn't fragment handshake messages as
>>required by the spec. Attempts to use it with a conforming peer will fail to
>>handshake.
>
> What's the largest handshake message it sends?

In my case, a KB or so of client certificate.

> I would assume that for at
> least the larger fragment sizes it'd be OK, because no handshake message would
> get large enough to require fragmentation.

True. Personally I was interested in the 512 byte max_fragment_length,
because this is the best match for devices with the minimum IP MTU of
576 bytes. As a server, that breaks sending really any kind of
certificate chain. As a client, it breaks client auth for similar
reasons.

> Incidentally, has anyone else who's implemented this dealt in the weird
> omission of 8K by using the logical value 5 that follows 1, 2, 3, 4 for 512,
> 1K, 2K, and 4K?  In many cases 8K is just what you need, it halves memory
> consumption while being large enough to not have to worry about fragmenting
> handshake messages.

Mmm, that is a strange omission. Personally I think this extension's
encoding of the available lengths is too much policy and not enough
mechanism. For want of an extra byte!

Cheers,
Joe

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

Re: [TLS] RFC 6066 - Max fragment length negotiation

[Joseph Birr-Pixton]

On 17 March 2017 at 16:01, Hannes Tschofenig  wrote:
> Here are my 5 cents: we implement this extension in our mbed TLS stack

With the greatest of respect, mbedtls *doesn't* implement
max_fragment_length[1], because it doesn't fragment handshake messages
as required by the spec. Attempts to use it with a conforming peer
will fail to handshake.

When I came across this a year or so ago, I concluded that nobody
could have actually deployed max_fragment_length using mbedtls.

Cheers,
Joe

[1] https://github.com/ARMmbed/mbedtls/issues/387

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

[TLS] MTI kx groups, HelloRetryRequest and "Incorrect DHE Share"

[Joseph Birr-Pixton]

Hi folks,

It appears to me that HRR is a pretty large and tricky source of
complexity in TLS1.3. Judging by the implementations page, 40% don't
support it right now. It's *precisely the kind of thing* that vendors
could easily ship broken/missing support for, and they'd get away with
it for years until it causes a interop problem.

The only case where it is used is (4.1.1):

  If there is overlap in the "supported_groups" extension but the client
  did not offer a compatible "key_share" extension, then the server will
  respond with a HelloRetryRequest

We could entirely remove HRR if we slightly strengthen the MTI
language covering kx groups:

- Clients must not only "implement", but actually offer a key share
for NISTP-256 for every ClientHello.

Note: Obviously, this doesn't apply to PSK-only connections where
psk_key_exchange_modes was provided and did not contain psk_dhe_ke.

This need not have any additional computational overhead, because the
client can amortise the key generation over all handshakes where the
server does not select P-256 (hopefully most of them!). In any case,
it's one fixed-base pointmul. It obviously costs 64 bytes-odd on the
wire, but only if the client wasn't going to send a NISTP-256 share
otherwise.

Did I miss something? Are there any other uses of HRR in TLS1.3 which
means we can't get rid of it in this way?

Cheers,
Joe

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

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Joseph Birr-Pixton]

For what it's worth I would prefer TLS4.

Cheers,
Joe

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

[TLS] PSS SignatureScheme ordinal choice

[Joseph Birr-Pixton]

Just a quick question. In TLS1.3 we have:

 enum {
  rsa_pkcs1_sha1 (0x0201),
  rsa_pkcs1_sha256 (0x0401),
  rsa_pkcs1_sha384 (0x0501),
  rsa_pkcs1_sha512 (0x0601),
  ecdsa_secp256r1_sha256 (0x0403),
  ecdsa_secp384r1_sha384 (0x0503),
  ecdsa_secp521r1_sha512 (0x0603),
(then)
  rsa_pss_sha256 (0x0804),
  rsa_pss_sha384 (0x0805),
  rsa_pss_sha512 (0x0806),
  } SignatureScheme;

This kind of looks like someone was trying to make the
rsa_pss_shasomething ordinals be decodable by a TLS1.2 implementation
given a SignatureAlgorithm reservation for PSS of 8, but got the bytes
the wrong way around.

Is this an error, or am I missing something subtle?

Cheers,
Joe

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

Re: [TLS] Require deterministic ECDSA

[Joseph Birr-Pixton]

Thanks for the discussion so far on this.

I've closed PR 406; it is replaced by:

https://github.com/tlswg/tls13-spec/pull/408

to wit:

- ECDSA details para says RFC6979 is RECOMMENDED (I've tried to keep
this part succinct, but I think it fits next to the X9.62 reference).
- Crypto pitfalls section has a new point with a little further
discussion, trying to impress upon the reader how badly this goes
wrong.

Cheers,
Joe

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

Re: [TLS] Require deterministic ECDSA

[Joseph Birr-Pixton]

Hi,

The other benefit is being able to test that a critical code path
produces the correct answers. With randomised k, this is not really
possible. For instance, you can choose k with the top bit clear
without any obvious or externally-testable effects, except effectively
publishing your long-term private key after a large number of
signatures[1].

Given the history of these things, I would perhaps challenge the
assumption that all TLS stacks will have a bug-free, thread-safe,
fork-safe, high quality, uncompromised, backdoor-free, unbiased random
number generator :)

Cheers,
Joe

[1]: 
http://people.rennes.inria.fr/Jean-Christophe.Zapalowicz/papers/asiacrypt2014.pdf

On 23 January 2016 at 19:27, Jacob Maskiewicz <jmask...@eng.ucsd.edu> wrote:
> The main argument I see from the RFC for deterministic ECDSA is computing k
> on systems without high quality entropy sources. But any system running a
> TLS stack is already going to have a high quality entropy source for
> client/server randoms and IVs and such, so what's the benefit of
> deterministic ECDSA here?
>
> -Jake M
>
> On Jan 23, 2016 11:13 AM, "Joseph Birr-Pixton" <jpix...@gmail.com> wrote:
>>
>> Hi,
>>
>> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA.
>>
>> For discussion, here's a pull request with possible language:
>>
>> https://github.com/tlswg/tls13-spec/pull/406
>>
>> Cheers,
>> Joe
>>
>> ___
>> 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] Require deterministic ECDSA

[Joseph Birr-Pixton]

Hi,

I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA.

For discussion, here's a pull request with possible language:

https://github.com/tlswg/tls13-spec/pull/406

Cheers,
Joe

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