Andrei Popov writes:
>I'm with Richard on this one. Not a fan of the "mTLS" concept: it causes
>confusion where customers ask whether "mTLS" is a different protocol or a
>specific TLS implementation? However, it can be argued that this unfortunate
>term has already taken root.
+1, Richard pretty
Andrei Popov writes:
>I support *not* making Curve 25519 MTI in TLS 1.3.
Same here, there's already enough new stuff required by 1.3 without adding even
more.
Peter.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf
internet-dra...@ietf.org writes:
>This document specifies that outside of urgent security fixes, no new
>features will be approved for TLS 1.2.
In that case it would probably be a good idea to get TLS-LTS frozen in RFC
form rather than drafts before TLS 1.2 gets frozen:
https://datatracker.ietf
Dennis Jackson writes:
>The recently adopted Key Share Prediction draft [1] allows servers to signal
>which key shares they'd like to see.
Sure, but that both assumes you've got DNS in operation and that client and
server will go through the DNS backchannel to set up TLS parameters before
trying
Robert Relyea writes:
>I will also point out that even though x25519 is 'only' SHOULD, it's the most
>selected option, while p256 is the most 'available' (by a small margin).
See my previous comment on the likely dubious validity of this data, when the
dominant platform only offers 25519 then th
Eric Rescorla writes:
>One more thing: we are finalizing RFC 8446-bis right now, so if there is WG
>consensus to require that clients offer all MTI curves in the key_shares of
>their initial CH, then that would be a straightforward text change.
That would fix things, something like saying a clie
Joseph Birr-Pixton writes:
>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
Mike Shaver writes:
>You mentioned in another message that some embedded TLS implementations also
>omit MTI support for code size or attack surface reasons.
They don't omit MTI support, they *only* support MTI (think Grigg's Law,
"there is only one mode and that is secure"). So when faced with
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 algori
Nick Harper writes:
>I see no requirement in section 9 nor in section 4.2.8 requiring MTI curves
>be present in the key_share extension if that extension is non-empty.
Just because it's possible to rules-lawyer your way around something doesn't
make it valid (I also see nothing in the spec sayin
D. J. Bernstein writes:
>Sorry, can you please clarify which statistics would be heavily skewed by
>Chrome retrying connections to 0.6% of servers?
Since Chrome does 25519 but not the MTI P256 in its client hello, and Chrome
and the Chrome code base are everywhere, this will skew the statistics
Filippo Valsorda writes:
>The most important performance consideration in TLS is avoiding Hello Retry
>Request round-trips due to the server supporting none of the client's key
>shares.
This is already a huge problem with Chrome because it doesn't support any MTI
curves in its client hello, whic
Blumenthal, Uri - 0553 - MITLL writes:
>Nobody in the real world employs static DH anymore – in which case this draft
>is useless/pointless
It's not "any more", AFAICT from my inability to find any evidence of the
certificates needed for it in 25-odd years it's "nobody has ever used static
DH" (
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
Joseph Salowey writes:
>At IETF 119 we had discussion that static DH certificates lead to static key
>exchange which is undesirable.
Has anyone every seen one of these things, meaning a legitimate CA-issued one
rather than something someone ran up in their basement for fun? If you have,
can I h
Salz, Rich writes:
> 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 evaluat
Arnaud Taddei writes:
>This is why I asked the question whether there would be volunteers to design
>a ‘survey’ approach.
>
>This could bring data points from the broader community that could help guide
>this particular area of the work.
I don't think the problem is volunteers, it's getting anyon
Watson Ladd writes:
>Why would deploying that change to TLS 1.2 be easier than deploying TLS 1.3?
One is making a (presumably) small tweak to an existing deployed protocol, the
other is deploying an entirely new protocol. They're totally different
things.
(Not to mention additional issues like
Loganaden Velvindron writes:
>I'm curious. Are those embedded devices or IoT type of appliances where the
>firmware has a TLS library that will never be updated ?
Typically, yes. Many devices don't support remote firmware update, or need
physical access to do it so it's never done, or will be d
Viktor Dukhovni writes:
>Peter, is there anything beyond TLS-TLS that you're looking to see work on?
>Is the issue foreclosing on opportunities to do anticipated necessary work,
>or is it mostly that the statement that the work can't happen causing
>disruption with audits and other bureaucratic i
Off-list: Funny that you should mention nuclear power plants, at least one of
the systems I'm thinking of is used in nuclear power control. Those things are
remarkably resilient, including in at least one case having the facility
overrun by an invading army. They looted all the standard PCs bu
Rob Sayre writes:
>>On Mon, Dec 11, 2023 at 5:30 PM Peter Gutmann
>>wrote:
>>
>>Absolutely clear. I work with stuff with 20-30 year deployment and life
>>cycles. I'm fairly certain TLS 1.2 will still be around when the WebTLS
>>world is debating the m
Rob Sayre writes:
>>Given that TLS 1.2 will be around for quite some time
>Not clear.
Absolutely clear. I work with stuff with 20-30 year deployment and life
cycles. I'm fairly certain TLS 1.2 will still be around when the WebTLS world
is debating the merits of TLS 1.64 vs. TLS 1.65.
(This is
Watson Ladd writes:
>How does a feature freeze make it impossible to keep supporting TLS 1.2 as
>is?
Because if there's some tweak required for some reason (I don't know what that
could be since I can't predict the future) the draft seems to prohibit it.
Peter.
In all the rush to jump on the bandwagon, no-one has yet answered the question
I posed earlier: For anyone who's already moved to TLS 1.3 the draft is
irrelevant, and for people who have to keep supporting TLS 1.2 gear more or
less indefinitely it makes their job hard if not impossible. So what's
Deirdre Connolly writes:
>At the TLS meeting at IETF 118 there was significant support for the draft
>'TLS 1.2 is in Feature Freeze' (
>https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/) This call is
>to confirm this on the list. Please indicate if you support the adoption of
>this
Viktor Dukhovni writes:
>On Fri, Nov 17, 2023 at 09:57:42AM +0000, Peter Gutmann wrote:
>> Could this use/behaviour be referenced somewhere to provide guidance for
>> implementers in general? It'd be good to have this made an official way to
>> do
>> things rath
Viktor Dukhovni writes:
>Indeed, Postfix 3.9 (release estimated Q1 '2024), when compiled against
>OpenSSL 3.2 (release estimated circa next week), will automatically signal
>client certificate types X.509(0) and RPK(2) iff and only a client
>certificate is configured (available).
Could this use/
It's OK, just appeared on the admin page.
The Uni email can be pretty messed up sometimes so whenever things seem to take
too long I check that they're actually still working. All fine, as you were
:-).
Peter.
From: TLS on behalf of Michael P1
Sent
Viktor Dukhovni writes:
>I think what you're really saying, is that it may be time replace the extant
>client certificate request message with a completely new one, because the old
>one is ossified.
No, just have the server echo back the cert-auth flag from the client to
indicate that it really
Andrei Popov writes:
>An "I really mean it" flag. We can add these for every TLS message, not just
>authentication-related ones. Just to make sure the peer truly is serious
>about the TLS handshake.
It really depends on how servers react when they see client-cert-auth when
they're not expecting
Viktor Dukhovni writes:
>I don't see in your comment anything to suggest that the flag is a no-go.
Oh, it's definitely not a no-go, just pointing out that you shouldn't read too
much into seeing a cert request from a server. In other words if the client
says "I have a cert" and the server respo
Andrei Popov writes:
>Yes, but, arguably, such broken clients won't be fixed by adding new
>extensions/flags/etc. If they do not comply with the simple RFC language that
>exists, can we expect them to implement the new flag correctly?
I would argue that it's the server that's broken, not the cli
This draft still has the same problem that's been pointed out previously:
Clients MUST NOT offer and servers MUST NOT select FFDHE cipher
suites in TLS 1.2 connections.
What this means is that if the implementation doesn't support ECC, as some do,
then it's in effect saying:
Clients and
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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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,
I wrote:
>Salz, Rich writes:
Argh, sorry, text-trimming fail, I was quoting Viktor Dukhovni but cut out the
wrong block of text.
Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Salz, Rich writes:
>The formulation I would choose would be:
>
> - MUST prefer ECDHE key exchange, when supported, over FFDHE key exchange.
> - MUST prefer FFDHE key exchange, when supported, over RSA key exchange.
I think there should also be some wording around avoiding falling back to RSA
bec
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 some
Richard Barnes writes:
>Let's Encrypt issues roughly 3 million publicly trusted certificates per day
>that contain the client authentication EKU
But they just set that by default for every cert they issue so it's pretty
much meaningless. There are public CAs that set keyAgreement for RSA certs,
Ilari Liusvaara writes:
>You mean overflow the maximum field size (64kB)?
No, just the 16kB message size, so you get what should be a ~100-byte cert
request that's 20-30kB long. The code assumed - and I know this is crazy talk
here - that a 100-byte message would fit easily into a 16kB I/O buff
Salz, Rich writes:
>Is this generally used? Would things go badly if we stopped sending them?
Just as a data point, in the SCADA world it seems to be universally ignored.
I've seen everything from servers that send a list containing every CA in
existence, so much data in that one field that it
Ben Smyth writes:
>Because pre_shared_key appears in ClientHello and ServerHello, whilst
>psk_key_exchange_modes only appears in the former?
That's a circular argument, pre_shared_key already has two different forms
that depend on whether it's the ClientHello or ServerHello it so this is
saying
On the subject of clarification, the update also needs to explain why PSK is
split across two separate extensions, psk_key_exchange_modes and
pre_shared_key, with complex and awkward reconciliation rules between then,
and why the PSK has to be the last extension in the client hello. I can't see
an
Viktor Dukhovni writes:
>I am tacitly assuming that the implementation community might be somewhat
>more pragmatic than the WG, and be willing to improve the behaviour of the
>current extension, or perhaps the "silent majority" of the WG would in fact
>be willing be more pragmatic on resumption,
Viktor Dukhovni writes:
>The protocol specification needs to say something along the lines of:
I'm not sure if this will work though. The PSK stuff is already the second
biggest dog's breakfast in the spec (why are there two extensions used to
communicate PSK information, with complex reconcili
Viktor Dukhovni writes:
>I took a look at whether it is practically possible for a client to "opt-in"
>to (ostensibly cheaper) non-DHE TLS 1.3 resumption by sending a
>"psk_key_exchange_modes" extension consisting of just "psk_ke".
>
>Turns out that at least when the server is OpenSSL, the client
Viktor Dukhovni writes:
>Yes, once TLS 1.3 is closer to 20 years old, we'll know whether TLS 1.2 can
>or should be retired, but until such time, TLS 1.2 is likely to still be with
>us (embedded in home routers, printers, refrigerators, ...).
Another thing we need a lot more time to find out is w
Chuck Lever III writes:
>We're implementing TLSv1.3 support for PSK and note there is a capability in
>the PSK extension described in S 4.2.11 for sending a list of identities. We
>don't find support for a list of alternate identities implemented in user
>space TLS libraries such as GnuTLS or Ope
Hubert Kario writes:
>Because there are software stacks that allow configuration of arbitrary
>parameters for FFDH (see GnuTLS, OpenSSL), and there are software stacks that
>generate one public key share and reuse it for a long time, or allow
>configuration of this kind of behaviour (see old Open
Hubert Kario writes:
>It's also easy and quick to verify that the server *is* behaving correctly
>and thus is not exploitable.
It's also a somewhat silly issue to raise, if we're worried about a server
using deliberately broken FFDHE parameters then why aren't we worried about
the server leaking
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
John Mattsson writes:
>A more reasonable approach would be to deprecate all cipher suites without
>_ECDHE_.
>
>While the WG is in deprecation mode, please deprecate all non-AEAD cipher
>suites as well. RFC 7540 did this 7.5 years ago...
An even more reasonable approach would be to mandate EMS, E
Rob Sayre writes:
>For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
>endlessly keeping old cipher suites alive. The unwise cost-cutting in those
>areas does not constrain the rest of the internet.
And for my part I'm... well not really sick of but resigned to accepting the
fa
Carrick Bartle writes:
>In the situation you've described, they've been told they shouldn't use RSA
>either, so clearly it doesn't matter to them what we've deprecated or not.
Yup, because if you give people the choice between not A but not B either then
they have to ignore one of the two, and
Nimrod Aviram writes:
>Let me clarify that the document also has RSA as a MUST NOT.
>
>So there will be no reason to read this document and switch from FFDHE to
>RSA.
If you tell people they can't have A but they can't have B either then they're
going to have to choose one of the two in order to
Blumenthal, Uri - 0553 - MITLL writes:
>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.
It's actually much worse than just SCADA, there are deployments in things like
wholesale banking where t
Valery Smyslov writes:
>I would add that if a (D)TLS profile for HL7 is written, UTA can be a natural
>home for this draft.
This seems to be like using an S-300 to take out a drone, to update the
rabbits and cruise missiles analogy. The OP described the behaviour of a
broken TLS implementation
Martin Thomson writes:
>The exact same thing, just using different words and style.
But it's not the same thing, it only seems to cover some TLS 1.3 extensions.
Thus my suggestion to call it "Extensions to the SSLKEYLOGFILE Format for TLS
1.3".
Peter.
__
Martin Thomson writes:
>Maybe the web page is easier to consume, but a spec needs to be a little more
>precise in definition.
Well at the moment the web page defines what's used in practice and the spec
defines... something? A hope for the future? An extension to the current
usage? At the mom
Martin Thomson writes:
>I just posted https://datatracker.ietf.org/doc/draft-thomson-tls-keylogfile/
This looks like some variant of
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format
but I'm not sure what it is or what form it takes. Is it an extension of that
for TLS
John Gray writes:
>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
Blumenthal, Uri - 0553 - MITLL writes:
>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.
"Compromised" meant (at the time, I was t
Tomas Gustavsson writes:
>I'd like to add that adding a challenge-response POP need to be built into
>protocols as well, not only in CSR formats/specification. Only adding a
>method for this to PKCS#10, without also specifying how it is to be used in
>ACME, CMP, EST and SCEP will most likely wrea
von Oheimb, David writes:
>Peter, the argument you gave below:
>
>> 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.
>
>a
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 shou
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
w
Brockhaus, Hendrik writes:
>During the last LAMPS interim call, I mentioned this topic as well. It was
>decided to add support for KEM keys in RFC4210bis. Sean said, that he is
>working on a draft on PoP for KEM keys.
Uhh... CMP has supported KEM keys since day one. And signing keys, and key
ag
Ashley Kopman writes:
>But I want to be clear that I do not intend to implement a solution and try
>to sell it to the community.
Sure, and I wasn't saying that, just pointing out the problems that have
arisen in other situations where industry bodies have adopted orphan standards
that ended up r
Ashley Kopman writes:
>Although our use case is aviation, our goal is to write this draft so that it
>can be used by other domains.
Someone has to say this, so I may as well: I don't think you'll have to worry
about anyone else using it. The PKIX WG left behind it a long trail of RFCs
that no-o
Kyle Rose writes:
>A large attack surface can't be avoided with the MTI for these protocols.
It can be vastly reduced by only implementing the MTI rather than every
possible bell and whistle in existence. Also since an RTU (remote terminal
unit) doesn't need to talk to every single piece of bro
Kyle Rose writes:
>IMO, the two requirements "Prohibit upgrades" and "Leverage general-purpose
>network protocols with large attack surfaces" are in direct conflict.
Only if you implement them with large attack surfaces, for which again see my
earlier comments.
Peter.
_
Kyle Rose writes:
>I wish I had some more context for this area of embedded devices. For example:
>
> * Why is an RTC more expensive (along whatever axis you choose) than a NIC
>(wifi or ethernet)?
Quoting "IoT / SCADA Crypto, What you Need to Know":
The device often won't have any on-board t
Robert Moskowitz writes:
>The article is unclear if this is a TLS 1.2 and/or 1.3 problem. It does
>claim that 1.3 does not fix all problems with TLS.
It's neither TLS 1.2 or 1.3, it's an ECDSA problem. The paper happened to use
TLS because it's a convenient way to probe the Internet for proble
Kyle Rose writes:
>Expired CAs are definitely a problem for PKI participation after such a
>delay, but probably one that is dwarfed by the near certain existence of
>known vulnerabilities in firmware that hasn't been updated in 10 years. So
>it's probably best they remain air-gapped and don't par
Christian Huitema writes:
>For example, the device will get some notion of time from the dates in the
>certificates that are provisioned during enrollment. Maybe that's enough to
>move from the 10 years scenario to the one year scenario, and then call NTP.
>But it would probably be better to spel
Kyle Rose writes:
>What Peter said isn't quite right, since (for example) you wouldn't want to
>be obliged to distribute revocations for compromised but long-expired
>certificates under the assumption that a properly-functioning client wouldn't
>accept them anyway
Ah, good point.
However, you a
Hal Murray writes:
>Many security schemes get tangled up with time. TLS has time limits on
>certificates. That presents a chicken-egg problem for NTP when getting
>started.
>
>I'm looking for ideas, data, references, whatever?
For commercial CAs, the expiry time is a billing mechanism, not a s
Phillip Hallam-Baker writes:
>Quantum Annoyance:
I thought a Quantum Annoyance was someone who keeps banging on about imaginary
attacks that don't exist as a means of avoiding having to deal with actual
attacks that have been happening for years without being addressed.
Peter.
___
David Benjamin writes:
>Regardless, I don't think it's worth the time to define and deploy a fixed
>variant of TLS 1.2 DHE. We've already defined a successor twice over.
TLS 1.3 is a non-starter for lots of embedded stuff so that leaves ECDHE which
I assume is what you're referring to with "succ
Rob Sayre writes:
>Couldn't an implementation use data from a preexisting agreement in a
>conventional TLS handshake?
Yep, that's more or less TOFU then. TLS isn't supposed to do that though
because then it would look like it was SSH, or some reason like that.
I sketched out TOFU-for-TLS years
Ilari Liusvaara writes:
>Unfortunately, that does not work because it would require protocol
>modifications requiring coordinated updates to both clients and servers.
I was thinking of it more as a smoke-em-if-you-got-em option, since -LTS is by
negotiation it'd be something to the effect that i
An additional comment on this, a pretty straightforward solution is to use the
TLS-LTS one:
TLS-LTS sends the full set of DH parameters, X9.42/FIPS 186 style,
not p and g only, PKCS #3 style. This allows verification of the DH
parameters, which the current format doesn't allow:
o T
Ben Smyth writes:
>should we consider PSK-mode authentication weaker than certificate-based
>authentication?
No, it's much stronger. With cert-based server auth, a client will connect to
anything that has a certificate from any CA anywhere, in other words pretty
much anything at all, and declar
An indirect question on the overall premise here: Given that SCVP is
essentially nonexistent (unless there's some niche market somewhere using it
that I'm not aware of, which is why I didn't use an unqualified
"nonexistent"), does it really matter much? If an RFC falls in the forest and
all that..
Felipe Gasper writes:
>It begs the question … how relevant is certificate revocation nowadays? How
>big of a problem is it if TLS validity checks ignore it?
Given that mbedTLS is unlikely to be used in public web servers, which means
in turn it's unlikely to be used with certificates issued by p
Rob Sayre writes:
>The WG is not obligated to support TLS 1.2.
Is that an official WG position, that the TLS WG has abandoned TLS 1.2? If it
is, can I have change control over it, because if the WG doesn't want to
support it, someone will have to.
(I'm not fussed either way, but would like to
Salz, Rich writes:
>Peter has forgotten more about long-term embedded applications than the rest
>of us have experience. I’ll leave it to him to say why it’s important.
I was making a more general point about not assuming that the only thing that
matters is TLS 1.3 vs. TLS 1.2, and that that's a
David Benjamin writes:
>The operators themselves are probably not in a position to either implement
>supported_versions or not in TLS 1.2. If an operator, for whatever reason,
>only has a TLS 1.2 implementation on hand, it presumably predates TLS 1.3 and
>thus does not implement supported_version
alex.sch...@gmx.de writes:
>I would really appreciate a response to get some clarification on what the
>intended interpretation is, i.e., when the extension should be used.
There's not really any contradiction, encrypt-then-MAC has nothing to do with
AEAD which is an all-in-one mode, so it doesn
Reposted here (with permission) since I think it's important to get this on
the record for discussion on this list. It's always interesting to read about
protocol implementation details, especially if others can learn from them.
Peter.
-- Snip --
Please change your mind about your announced rel
David Benjamin writes:
>RFC7919 tried to solve the problem but, by reusing the old cipher suites, it
>fails to solve the problem.
It didn't just not solve the problem, it made things worse: 7919 doesn't say
"I want to do DHE, if possible with these parameters", it says "I will only
accept DHE if
Viktor Dukhovni writes:
>with confirmation from Peter Gutmann below that any custom groups we're
>likely to encounter are almost certainly safe
Well, I haven't examined every crypto library on the planet, it's not to say
there isn't something somewhere that implements
Viktor Dukhovni writes:
>OK, who goes around bothering to actually generate custom DH parameters, and
>with what tools, but then does not use a "strong" (Sophie Germain) prime?
That's better :-). That was my thought too, every DH/DLP keygen I've seen
generates either Sophie Germain or FIPS 186
Viktor Dukhovni writes:
>I strongly doubt there's a non-negligible server population with weak locally
>generated groups.
Would you care to rephrase that so we can make sure you're saying what we
think you're saying in order to disagree with it?
Peter :-).
_
Scott Fluhrer (sfluhrer) writes:
>The problem is that it is hard for the client to distinguish between a well
>designed server vs a server that isn't as well written, and selects the DH
>group in a naïve way.
What should the client do if it could detect this? And how would it
distinguish betwee
Viktor Dukhovni writes:
>Can you explain what you mean by "don't do things that you should never have
>been doing in the first place"?
Just what the draft says, don't use static-ephemeral DH, don't reuse DHE
secrets, etc. It seems a bit like publishing an RFC telling people not to
stick forks i
Viktor Dukhovni writes:
>The only other alternative is to define brand new TLS 1.2 FFDHE cipher code
>points that use negotiated groups from the group list. But it is far from
>clear that this is worth doing given that we now have ECDHE, X25519 and X448.
There's still an awful lot of SCADA gear
Ryan Sleevi writes:
>For example, the NSS library used by Mozilla has well exceeded a thousand
>lines of code so far.
Is that purely to parse PSS in X.509, or for the overall PSS implementation?
I know PSS is a dog's breakfast of arbitrary parameters and values, but I'm a
bit suspicious of that
Hubert Kario writes:
>I suggest you go back to the RFCs and check exactly what is needed for proper
>handling of RSA-PSS Subject Public Key type in X.509. Specifically when the
>"parameters" field is present.
Looking at the code I'm using, it's four lines of extra code for PSS when
reading sigs
1 - 100 of 400 matches
Mail list logo
