Ilari Liusvaara writes:
>Furthermore, comparing the strengths of kex, auth, ciphering and PRF seems
>like comparing apples, orangles, pears and kumquants.
>
>Even if the nominal strengths are the same, the scaling of strengths is going
>to be different (e.g. the quadric vs. linear sub-treshold sc
Kyle Rose writes:
>In that case, we should dispense with any larger key sizes and recommend
>exactly one per algorithm, and vary only on algorithm. Adopting this would
>simplify things even further by reducing the cipher set list by an order of
>magnitude.
Yup.
>Sadly, I'm guessing there are nu
Clemens Hlauschek writes:
>I published a paper today on KCI-attacks in TLS. This might be of interest to
>the TLS WG.
>
>https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek
Some comments on this, it looks like it requires a "cert with static (EC)DH
key" in order to w
Ilari Liusvaara writes:
>a) ECDSA certs are usable for ECDH (modulo KeyUsage) because there is no
>ECDSA-specific keytype in X.509.
That's always concerned me about ECC certs, all you can say about a key is
"ECC", not "signing key" or "key agreement key" (I'm sure this was seen as a
great featur
they were added?
Peter.
From: Clemens Hlauschek [clemens.hlausc...@rise-world.com]
Sent: Wednesday, 12 August 2015 11:15
To: Peter Gutmann; tls@ietf.org
Subject: Re: [TLS] TLS and KCI vulnerable handshakes
On 08/11/2015 02:05 PM, Peter Gutmann wrote:
Viktor Dukhovni writes:
>I can't answer why, but I know what and when:
I was trying to avoid finger-pointing so I didn't go through the changelog to
see whodunnit, I was more interested in the motivation. Same for Apple, why
would you implement something that pretty much no-one else (at the tim
Martin Thomson writes:
>An endpoint that receives an illegal combination of "things" MAY choose to
>treat that as a fatal error.
Does that actually help? What it's saying in full is:
An endpoint that receives an illegal combination of "things" MAY choose to
treat that as a fatal error or
Martin Thomson writes:
>The opposite in fact. NSS checks extensions first. That is how we filter out
>ECC cipher suites if the named_groups extension doesn't list anything we
>support.
I have to do the same thing, bouncing back and forth between cipher suites and
extensions in order to find so
Yoav Nir writes:
>I feel the pain (I know some administrators who have made this mistake), but
>it’s always best to test with something like “openssl s_client”.
That's quite possibly the worst thing to test it with, because it's what
everyone else also tests against, so it's the thing that every
Jeffrey Walton writes:
>Somewhat off-topic, why does TLS not produce a few profiles. One can be
>"Opportunistic TLS Profile" with a compatible security posture and include
>ADH. Another can be a "Standard TLS Profile" and include things like export
>grade crypto, weak and wounder ciphers SSLv3, e
Stephen Farrell writes:
>We have BCP195 [1] that aims for the "general" case (for up to TLS1.2) and a
>draft [2] (current in IESG evaluation) for the embedded case. Are those the
>kind of thing you're after?
Sort of, but since they're not part of the TLS spec they essentially don't
exist (I've n
Stephen Farrell writes:
>I'm not sure how to process that comment. You ask for X, I ask is Y==X and
>your answer is that Y doesn't exist? Seems odd. ;-)
There's a difference between "X/Y exists" (but no-one knows about it) and "X/Y
exists and is actively used". As I said, I've never seen the BC
Salz, Rich writes:
>> An actual profile of TLS would be something like MUST TLS 1.1 or above,
>> MUST PFS suites, MUST AES and SHA256, MUST E-then-M (and by implication
>> what isn't explicitly permitted is denied).
>
>HTTP-2 did this kind of thing, and IIRC are the first to do so.
Some PKI stan
Viktor Dukhovni writes:
>Explicit profiles make some sense. They need not be defined by the TLS
>WG per-se, it might be enough for the TLS specification to reference an
>IANA profile registry, with the TLS-WG defining a "base" profile. Then
>other WGs (including the[ TLS WG) can define addit
Geoffrey Keating writes:
>That would affect the initial client hello, which I think we're trying to
>keep backwards compatible. It might be better to just define a rule like "if
>multiple extensions with the same number are present, their values are
>concatenated".
A better one would be "if you
Benjamin Kaduk writes:
>Well, this just came across my browser:
>http://google-opensource.blogspot.co.uk/2015/09/introducing-brotli-new-
>compression.html
There's a million compression algorithms [0] out there, you shouldn't have any
problem finding one to fit your needs, and you don't really ne
Short, Todd writes:
>Has there been any consideration to changing the record header for encrypted
>traffic to be 4 bytes (i.e. 32-bits)? 5 bytes is a very awkward size, and
>some processors do not handle odd byte offsets well (it was a complaint I
>heard from Cisco router/switch engineers).
Not
Eric Rescorla writes:
>The concern here is backward compatibility with inspection middleboxes which
>expect the length field to be in a particular place.
Given that the rest of TLS 1.3 is going to break compatibility with pretty
much everything everywhere, I can't see this as a big concern, may
Short, Todd writes:
>To be honest, it’s always kinda bugged me that SSL/TLS uses a 5-byte header,
>coming from my embedded network system background.
>
>[...]
+1. I wrote about this problem years ago in "Performance Characteristics of
Application-level Security Protocols",
https://www.cs.auckla
Short, Todd writes:
>I think the philosophy some people are going with, if we're going to break
>backwards compatibility, let's do it big time, so that we only have to do
>it once, and not make everyone play continuous catchup.
Exactly.
I'm also not convinced by the middlebox argument, anyth
Bryan A Ford writes:
>The idea of encrypting TLS record headers has come up before, the most
>important purpose being to hide record lengths and boundaries and make
>fingerprinting and traffic analysis harder.
Argh, no! I sent the following to the SSH list a few days ago in support of
someone e
Bryan A Ford writes:
>Feel free to attack my proposal but then please attack *my* proposal, not
>the old broken SSH approach.
I was actually commenting on the concept of encrypting headers in general,
not the specific case you'd given. That is, I assumed you'd specifically
chosen the one case
Nikos Mavrogiannopoulos writes:
>I believe your proposal is a nice example of putting the cart before the
>horse. Before proposing something it should be clear what do you want to
>protect from, what is the threat?
Exactly. If you want to thwart traffic analysis, you need to do something
like w
Bryan A Ford writes:
>It would work just as well and in exactly the same way if the AEAD is
>replaced with the traditional Encrypt-then-MAC construction, for example.
No it wouldn't, unless the encrypt part is a stream cipher. You're still
locked into using an AEAD stream cipher or the equivale
Jacob Appelbaum writes:
>I think the only thing that comes close is when I've named a classified US
>government surveillance program (XKeyscore) that would probably have trouble
>with it.
Why would XKeyscore have trouble with it? Standard off-the-shelf routers, not
even specialised USG surveill
Bryan Ford writes:
>We have repeatedly stated several relevant threat models here; you just
>don’t seem to be accepting them as threat models for some reason.
That's because they're not actual threat models, just handwringing about
vague, undefined bogeymen. Yoav Nir has made a good start, al
Jacob Appelbaum writes:
>TCP/IP and DNS are out of scope, though obviously related.
Why are they out of scope? You can't just ignore a threat if it's
inconvenient, you need to look at the overall picture. Arguing over plugging
a mousehole in the corner of the barn is pointless when two of the
Hubert Kario writes:
>miTLS does accept Application Data when it is send between Client Hello and
>Client Key Exchange and rejects it when it is sent between Change Cipher Spec
>and Finished.
Given that miTLS is a formally verified implementation, would this imply that
there's a problem with the
Jacob Appelbaum writes:
>On 12/4/15, Peter Gutmann wrote:
>> Jacob Appelbaum writes:
>>>TCP/IP and DNS are out of scope, though obviously related.
>> Why are they out of scope?
>
>They are out of scope for the TLS working group as far as I understand the
>org
Watson Ladd writes:
>On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann
>wrote:
>> Hubert Kario writes:
>>
>>>miTLS does accept Application Data when it is send between Client Hello and
>>>Client Key Exchange and rejects it when it is sent between Change Ciph
Watson Ladd writes:
>miTLS did not claim to be consistent with the RFC. Rather it claimed to be
>secure, and to interoperate with most other implementations in circumstances
>tested. The informal nature of the RFC makes it impossible to carry out
>formal verification against it.
By that argument
Watson Ladd writes:
>please cite the sentence of the TLS RFC which prohibits accepting application
>data records during the handshake.
Please cite the sentence of the TLS RFC which prohibits accepting SSH messages
during the handshake.
Please cite the sentence of the TLS RFC which prohibits exe
Dave Garrett writes:
>A TLS extension to negotiate max length might be viable.
I think a better starting point would be to look at the implementation that's
causing the problem. There's nothing magical about a 16K max segment size
that causes poor performance, TCP typically has an MSS of 1400-1
Kurt Roeckx writes:
>After the SLOTH paper, we should think about starting to deprecate TLS 1.0
>and TLS 1.1 and the SHA1 based signature algorithms in TLS 1.2.
The vulnerabilities shown in the SLOTH paper were based on the fact that
implementations still allow MD5 for authentication/integrity p
David Benjamin writes:
>In terms of getting rid of TLS 1.0 and TLS 1.1 altogether, we're seeing
>around 3% of connections using TLS 1.0 or TLS 1.1. That's quite high, and it's
>likely that enterprise deployments are much worse.
Embedded is even worse. I don't have any figures since it's mostly
Watson Ladd writes:
>Do the RFCs require the relevant checks or not?
No, they just specify the algorithms and bits on the wire (with a side-order
of MTI stuff for interoperability). It's up to implementers to not do stupid
things.
>That's because real cryptographers understand that this is onl
Watson Ladd writes:
>SHA-1 collisions have not yet been found. Marc Stevens has published
>algorithms he claims reduce the complexity of finding these collisions to
>feasible amounts, but they have not yet been run. However, free-start
>collisions have been found, as have ways to modify constants
Martin's comment reminded me of the following that I've been meaning to
post...
In a recent discussion among some crypto folks, the topic of what TLS 1.3
could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path from
TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is. Th
Karthikeyan Bhargavan writes:
>Coming back to digital signatures, all uses of weak hash functions are
>essentially broken.
Not necessarily. Use of weak hash functions where the attacker has time to do
offline precomputations/calculations are essentially broken. I'm not saying
"keep on using MD
Fabrice Gautier writes:
>"Do TLS libraries act strictly on those requirements, or do they leave it to
>the application layers?"
>
>"How do TLS libraries/server applications act when such requirements are not
>respected?"
This has already been discussed in the past, it's not up to TLS to constrai
Yoav Nir writes:
>Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0)
>that this WG is working on right now, why?
Embedded devices and similar systems with long-term requirements. Most of my
user base is embedded (or non-embedded equivalents, systems that need to run
in a
Hubert Kario writes:
>So lets not repeat those mistakes
Exactly, there are more than enough new ones for 2.0-called-1.3 to make that
we don't (necessarily) have to repeat existing ones (although I'm sure we will
in some cases).
And that's exactly my point, we're throwing away 20 years of refini
Salz, Rich writes:
>> TLS needs an LTS version that you can just push out and leave to its own
>> devices
>
>So don't you have that with TLS 1.1 and appropriate cipher and option
>choices?
That's the approach suggested previously by Peter Bowen, assemble it yourself
from a huge list of extension
Nikos Mavrogiannopoulos writes:
>That is because TLS 1.3 is a rewrite of the protocol, and requires a rewrite
>of the code base. Given that the majority of the issues in TLS
>implementations are in the code bases and not in the protocol, it is very
>risky to switch to such a new version just like
>From the writeups I've seen, what they're blocking is TLS 1.3, not ESNI.
Since ESNI can be de-anonymised with a high degree of success (see various
conference papers on this) and in any case doesn't matter for the most
frequently-blocked sites like Facebook, Instagram, Twitter, etc, it may not
eve
Christopher Wood writes:
>For the benefit of the list, would you mind sharing these references?
I handwaved this one because I don't catalogue these things and didn't want to
try and re-locate every preprint, paper, and report that's drifted across my
desk in the last 6-12 months to try and find
Christian Huitema writes:
>Fingerprinting is a real issue but from the reports, this is not what is
>happening here.
Sure, I was just pointing out that they're using the brute-force approach now
but presumably at some point will stop blocking when they've implemented a way
to bypass it. My gues
Rob Sayre writes:
>Do you think this fingerprinting will work with the newer ECH design, if the
>client can add arbitrary content to the encrypted payload?
ECH doesn't have any effect on web site fingerprinting so unless I've
misunderstood your question the answer would be "N/A".
Peter.
__
Christian Huitema writes:
>Defeating fingerprinting is really hard. It has been tried in the past, as in
>"make me look like Skype" or "make me look like wikipedia". The idea is to
>build a target model, then inject enough noise and padding in your traffic to
>match the target model. But that wa
Rob Sayre writes:
>I'm confused. That seems to be a bunch of boilerplate surrounding a Salon
>article from 2015:
I just took the first Google result that seems to cover the material...
>It also contains references to supplementary material, like whether
>Intelligent Design can be linked to info
David Fifield writes:
>Peter is surely referring to the influential "The Parrot is Dead" paper from
>2013
Yep, that was it, thanks (at least one person catalogues their reading by the
looks of it :-). Thanks for the ref to the followup, can't remember seeing
that, but doesn't that just reinforc
Salz, Rich writes:
>Do we need a short RFC saying “do not use static DH” ?
There are two things arguing against it:
Reason the first: Static-ephemeral DH was a dumb idea when it was proposed in
X9.42 more than twenty years ago and hasn't gotten any better since then. If
people haven't learned
Achim Kraus writes:
>Does using x25519 for ECDHE is significant less secure than using it with
>e.g. secp384r1?
The NIST curves AFAIK are never used that way, it's only done with 25519
(there was something about it in an OpenPGP draft, but I think GPG went
straight to 25519 and only used ECDSA f
Salz, Rich writes:
>Do you mean this because people will confuse DH with ECDHE ?
See my reply to Achim, it's not that but because banning static-ephemeral
(EC)DH will also affect all the cases where it's being applied as it if were
RSA.
Which, given that it's such a footgun would IMHO be a good
Filippo Valsorda writes:
>I feel like there should be nothing controversial in the context of TLS.
>
> Non-ephemeral FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DH_*) ought to be a
> MUST NOT, because they can't be implemented securely.
>
> Reusing ephemeral shares for ECDHE and DHE ought to
Russ Housley writes:
>I am sure you know that ephemeral-static DH was original used for S/MIME. The
>reasoning for ephemeral-static DH was not to make it work like RSA. Rather,
>the idea was to provide authentication of the static DH key holder by
>certifying the static DH public key.
... thus m
John Mattsson writes:
>Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
>especially psk_ke are both marked as RECOMMENDED. If used in the initial
>handshake, both modes have severe privacy problems,
PSK is used a fair bit in SCADA. There are no privacy problems there.
Filippo Valsorda writes:
>The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/tls or NSS
>or Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards
How do you know that? I don't know of any data supporting that (I'd love to
see it if you've got it, non-web use of TLS is the
Christian Huitema writes:
>Receiver side: receive the message, parser with generic ASN.1 decoder,
>process the message using the "parsed" representation, re-encode with DER,
>check the signature.
Except that no true Scots... uhh, sane person ever even tried that. I've
heard that there was one i
Ilari Liusvaara writes:
>The Diffie-Hellman support in TLS 1.2 is severly broken. There is no way to
>use it safely on client side. This has lead to e.g., all the web browers to
>remove support for it.
It's actually pretty simple, don't use toy key sizes. Many implementations
were never vulnera
Hanno Böck writes:
>I suggest reading:
>https://blog.hboeck.de/archives/841-Diffie-Hellman-and-TLS-with-nonsense-parameters.html
>https://eprint.iacr.org/2016/644
>https://www.openssl.org/news/secadv/20160128.txt
This just confirms what I said previously, this is an overreaction to a
completely
Achim Kraus writes:
>2. Why should a "uint16 iv_length" be added?
To make it explicit which of the bits being hashed is the IV. This is one of
the flaws of things like OAEP, there are a large number of implicitly-sized
fields controlled by external, unauthenticated parameters, so you can make t
Nick Lamb writes:
>You won't get such a certificate from a public CA (presumably meaning a CA
>issuing in the Web PKI).
Well, you're less likely to now thanks to CT. Before that public CAs issued
huge numbers of them, including EV certs.
>They're subject to the CA/B Baseline Requirements which
Stephen Farrell writes:
>In earlier iterations of the draft we included some survey results for TLS
>version usage in web, mail and OSes. I think your argument to special-case
>embedded systems or systems without s/w update would be a lot stronger if you
>or someone else had data to offer about t
Stephen Farrell writes:
>That said, if someone had words to suggest that might garner consensus, that
>would be good.
I think all it needs is something along the lines of "This BCP applies to TLS
as used on the public Internet [Not part of the text but meaning the area that
the IETF creates stan
Salz, Rich writes:
>The right thing to do, from a security viewpoint, is DO NOT USE TLS 1.0 OR
>TLS 1.1 If you have special circumstances, then do not follow the RFC (once
>published).
And how will the people who can ignore it know that it's OK for them to do so?
Once it's published, everyone wh
Eliot Lear writes:
>If a device can be at all critical (and even if it isn’t), then it should be
>upgraded or replaced.
The fact that many of these devices are extremely critical is precisely why
they're never replaced or upgraded, because they can't be taken out of
production.
Peter.
___
STARK, BARBARA H writes:
>If someone feels a strong need to ignore this in their own network, they will
>have no difficulty doing so (and have no difficulty justifying it to
>themselves and others inside their org).
It's actually the complete opposite, they will have every difficulty in doing
so
Bill Frantz writes:
>I would like to have a few more examples of "Can't be taken out of
>production".
Well as a bit of a generalisation anything running an RTOS is likely to be
something that can't be taken out of production, and certainly wouldn't be
taken out of production for something as min
Alan DeKok writes:
>OpenSSL has a feature SSL_MODE_AUTO_RETRY which makes it process TLS messages
>*after* the Finished message. i.e. the Session Ticket, etc. When an
>application calls SSL_Read(), all of the TLS data is processed, instead of
>just the "TLS finished" message. They've made this th
Ben Schwartz writes:
>If you are updating the text, I would recommend removing the claim about
>performance. In general, the ciphersuites specified in the text are likely
>to be slower than popular AEAD ciphersuites like AES-GCM.
Uhh... when is AES-GCM faster than SHA2, except on systems with h
Nico Williams writes:
>I've seen 5 day server certificates in use.
For IEC-62351 work you're far more likely to see certificates issued with an
expiry date of never, because the last thing you want is your power grid to be
taken offline due to a cert someone forgot to renew.
In terms of CRL u
Nico Williams writes:
>When expirations are short, you will not forget to renew. That's part of the
>point of short-lived certificates.
So instead of getting one chance a year for your control system to break
itself if the renewal fails, you get hundreds of them?
Peter.
_
Viktor Dukhovni writes:
>But if the signal is not ignored, and proper automation is applied,
>reliability actually improves.
No, it drops. You're going from a situation where you've eliminated any
chances of outages due to expired certs to one where you get to play Russian
roulette every single
Benjamin Kaduk writes:
>Just to confirm: the scenario you're using to contrast to the one described
>by Viktor (and Nico) is a scenarios in which the certificates expire at
>"never" (1231235959Z)?
Not that "never" since it would break a lot of things, but some time far
enough in the future t
David Benjamin writes:
>[*] From the conclusion of the paper: "The most straightforward mitigation
>against the attack is to remove support for TLS-DH(E) entirely, as most major
>client implementations have already stopped supporting them"
Just as you need to automatically add "in mice" to the e
Brian Smith writes:
>It would be useful for the browser vendors that recently dropped FFDHE
>support to share their measurements for how much RSA key exchange usage
>increased after their changes. That would help us quantify the real-world
>impact of this change.
... in mice.
Peter.
_
Lester White writes:
> Title : Preferred Pronouns Extension for TLS
I think the Security Considerations section needs to mention two security
considerations, firstly the preferred identity is an unauthenticated parameter
and can't safely be used until the Finished message definit
I've got some code that dumps TLS diagnostic info and realised it was
displaying garbage values for some signature_algorithms entries. Section
4.2.3 of the RFC says:
In TLS 1.2, the extension contained hash/signature pairs. The
pairs are encoded in two octets, so SignatureScheme valu
Eric Rescorla writes:
>As we are currently working on a 8446-bis, the best thing to do would be to
>file a PR at: https://github.com/tlswg/tls13-spec
Before I do that I thought I'd get some input on what to say, there's actually
two issues, the first being the one I mentioned. I was thinking so
Ilari Liusvaara writes:
>Actually, I think this is quite messy issue:
It certainly is.
>Signature schemes 0x0403, 0x0503 and 0x0603 alias signature algoritm 3 hash
>4, 5 and 6. However, those two things are not the same, because the former
>have curve restriction, but the latter do not.
That a
Hubert Kario writes:
>It only doesn't matter if you don't want to verify the certificate...
>
>It's one thing to be able to be able to verify an RSA-PSS signature on TLS
>level, it's entirely another to be able to properly handle all the different
>RSA-PSS limitations when using it in SPKI in X.5
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
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
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
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
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:
>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 :-).
_
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:
>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
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
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
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
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
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
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
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
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..
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 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
1 - 100 of 400 matches
Mail list logo
