Re: [TLS] TLS and KCI vulnerable handshakes

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: Clemens

Re: [TLS] TLS and KCI vulnerable handshakes

Clemens Hlauschek clemens.hlausc...@rise-world.com 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

Re: [TLS] TLS and KCI vulnerable handshakes

Ilari Liusvaara ilari.liusva...@elisanet.fi 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

Re: [TLS] Record header size?

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",

Re: [TLS] MUST x or what?

Martin Thomson martin.thom...@gmail.com 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

Re: [TLS] MUST x or what?

Martin Thomson martin.thom...@gmail.com 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

Re: [TLS] Consensus on PR 169 - relax certificate list requirements

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

Re: [TLS] Fwd: New Version Notification for draft-whyte-qsh-tls13-01.txt

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

Re: [TLS] TLS Record Size Limitation

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

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

Watson Ladd <watsonbl...@gmail.com> writes: >On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann <pgut...@cs.auckland.ac.nz> >wrote: >> Hubert Kario <hka...@redhat.com> writes: >> >>>miTLS does accept Application Data when it is send between Client Hello a

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

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

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

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

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

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

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

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

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

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

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

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

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

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

Re: [TLS] Record header size?

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

Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

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

Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

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

Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

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

Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

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

Re: [TLS] Fixing TLS

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

[TLS] Fixing TLS

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.

Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

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.

Re: [TLS] Server behavior when client certificate does not match the request ?

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,

Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]

Dave Garrett writes: >Also, as with any new system, we now have the ability to loudly stress to TLS >1.3+ implementers to not screw it up and test for future-proofing this time >around. I think that's the main contribution of a new mechanism, it doesn't really matter

Re: [TLS] Adoption of TLS-LTS

Russ Housley writes: >I do not think the TLS WG should take on any document that makes changes to >the TLS 1.2 protocol. So how is that different from any number of other TLS standards-track RFCs, say, RFC 7627 (one of the ones referenced in the draft), which was adopted

Re: [TLS] Adoption of TLS-LTS

Yoav Nir writes: >Mostly timing. The TLS working group is now working on TLS 1.3, so 1.2 should >be considered stable by now. As the draft says, this is intended for long-term support (on the order of a decade or more) of existing implementations, not an entirely new,

[TLS] Adoption of TLS-LTS

TLS-LTS, https://tools.ietf.org/html/draft-gutmann-tls-lts-03, has more or less stabilised, incorporating all the feedback I've had for it (there's only one open question still remaining), so I'd like to request that it now be adopted as a WG item. I'd also like to request an early/temporary

Re: [TLS] Adoption of TLS-LTS

Hubert Kario writes: >to be pedantic, the RFC describes itself "a profile" while in reality it >modifies the protocol in a way that will make it incompatible with "vanilla" >TLS 1.2 implementations >to be pedantic, the RFC describes itself "a profile" while in reality it

Re: [TLS] Fixing TLS

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

Re: [TLS] Adoption of TLS-LTS

Hubert Kario <hka...@redhat.com> writes: >On Monday 13 June 2016 19:51:42 Peter Gutmann wrote: >> Hubert Kario <hka...@redhat.com> writes: >> >to be pedantic, the RFC describes itself "a profile" while in reality >> >it modifies the

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Watson Ladd writes: >As written supporting this draft requires adopting the encrypt-then-MAC >extension. But there already is a widely implemented secure way to use MACs >in TLS: AES-GCM. This is there as an option if you want it. Since it offers no length hiding, it's

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

Martin Rex writes: >Though it is a pretty flawed assumption. > >I've seen an AEAD cipher implementation fail badly just recently (resulting >in corrupted plaintext that went unnoticed within TLS--MACing the ciphertext >is obviously a pretty dumb idea), something that is *MUCH* more

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Hubert Kario writes: >also, if it really is supposed to be Long Term Support, why it doesn't say >anything about implementation explicitly being able to handle big key sizes? >both RSA and DHE? I've deliberately avoided getting into that because it's such a rathole, you've

[TLS] TLS 1.2 Long-term Support Profile draft posted

After a number of, uh, gentle reminders from people who have been waiting for this, I've finally got around to posting the TLS-LTS draft I mentioned a while back. It's now available as: http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt Abstract: This document specifies a profile of TLS

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Karthikeyan Bhargavan writes: >Yes, I’d suggest hashing in the log up to ServerHello, or if you don’t want >to clone the hash state, then maybe the log up to ServerCertificate. OK, I've posted another update that specifies this, as well as use of EMS, and cleans up

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

Harlan Lieberman-Berg writes: >Couldn't you say the same about CTR mode, or stream ciphers themselves? Yep, the KSG ciphers are all equally bad, just RC4 in another form. Microsoft, and the downstream users of its APIs, were do badly burned by this over and over again that

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

ilariliusva...@welho.com writes: >Well, if you have suitable implementation for it, the hash in EMS is over >prefix of what hash in Finished is over (so if you can finalize multiple >times, you can get away with just one computation). The problem with this is that the

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Joachim Strömbergson writes: >When you say that "a Cortex M3 isn't going to be able to handle RSA-2048", >what do you mean specifically? Considering that it is being done by for >example SharkSSL [1], is supported by ARM mbed TLS (nee PolarSSL) [2] I fail >to see what

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Hubert Kario writes: >it doesn't explain where this "RSA-SHA-256" is used. IMHO it is ambiguous. > >The "no MAC truncation" is also not explicit about what the sizes should be. Well can you suggest some wording? I can't see how much more unambiguous a statement like "no MAC

Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC

Hubert Kario writes: >In my experience, many (12%) servers simply ignore the list of curves >advertised by client and use the P-256 curve always. > >Some (58%) check if it was advertised and fallback to non-ECDHE if P-256 is >not advertised. When I checked, which is a year or

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Hubert Kario writes: >I was thinking of something like the following: > > The length of verify_data (verify_data_length) in the Finished message > MUST be equal to the length of output of the hash function used as the > basis of the PRF selected for the ciphersuite. That

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Hubert Kario writes: >Note that I asked for "being able to handle", not "selects and uses". The issue here is that a Cortex M3 isn't going to be able to handle RSA-2048, no matter what an RFC says :-). That's what the "ability of the hardware to deal with large keys" was

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Wan-Teh Chang writes: >This is the procedure specified in PKCS #1 v2.1 (RFC 3447), Section 8.2.2, >with the additional requirement that the comparison in Step 4 be constant- >time, right? Good catch, thanks! I've added it to the draft. Peter.

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

Watson Ladd writes: >Why can't embedded devices use certificates? Because they have neither a DNS name nor a fixed IP address. I ran into this just last week with a customer, they couldn't use certs for their embedded devices and couldn't use PSK because the browser

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

Adam Langley writes: >Ideas for supporting this case (i.e. the "I want to do HTTPS to my router" >problem) in browsers have done the rounds a few times. This isn't for HTTPS to a router, it's to SCADA devices. The preferred interface to them is HTTPS, but since

Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

Bill Cox writes: >I spent 2 weeks last year tracking down a flaky bug that only occurs once in >every 256 connection: the leading 0 byte was no longer being stripped in a >code change I ported from OpenSSL master, and only Maria DB ran random tests >enough to trigger this

Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

Atul Luykx writes: >Here's a possible re-write of the second paragraph: That looks good. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

Aaron Zauner writes: >If so, could you suggest better wording for this specific paragraph? I would just leave it as "nonce", with no attempt at a definition. If there are any cryptographers who don't know what a nonce is they can look it up. If they use an authoritative source

Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

Aaron Zauner writes: >What do you think nonce stands for? >https://en.wikipedia.org/wiki/Cryptographic_nonce Well there's your first mistake, you're using Wikipedia as a reference. "nonce" is from medieval English, and predates modern cryptography and IVs by about 800 years. >In

Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

RFC Errata System writes: >The following errata report has been submitted for RFC5288, "AES Galois >Counter Mode (GCM) Cipher Suites for TLS". I think the erratum needs an erratum. Firstly, "nonce" doesn't mean "number used once", and secondly nonce re-use in AES-GCM

Re: [TLS] weird ECDSA interop problem with cloudflare/nginx

Ilari Liusvaara writes: >I recently (tried to) implement(ed) TLS 1.2 ciphersuite negotiation in a way >that always negotiates something if at least one valid configuration exists, >and respects TLS 1.2 rules. > >The resulting code was totally insane, and I am very much

Re: [TLS] weird ECDSA interop problem with cloudflare/nginx

Since I've referred to TLS-LTS a couple of times now I should mention that I've just posted an update, with the following changes: - Clarified what happens during a session resumption. - Fixed the ServerKeyExchange text to indicate what happens when the hash isn't the default SHA-256. Is the

Re: [TLS] weird ECDSA interop problem with cloudflare/nginx

Ilari Liusvaara writes: >The basic problem (let's ignore non-cert modes for a bit): > >When choosing the certificate, you need to consider if you have a ciphersuite >that can use some supported group and protection/prf-hash available. > >Similarly, when choosing a

Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

rfc-edi...@rfc-editor.org writes: >RFC 7919 > > Title: Negotiated Finite Field Diffie-Hellman Ephemeral > Parameters for Transport Layer Security (TLS) Does anyone have a test server running that implements this? Since I mention

Re: [TLS] Thoughts on Version Intolerance

Martin Rex writes: >Limiting PDU sizes to reasonably sane sizes is perfectly valid behaviour. >X.509v3 certificates can theoretically include CAT MPEGs and amount to >megabytes. We really need a TLS scanner that does this just to see what happens. When I created that cat-MPEG

Re: [TLS] TLS client puzzles

Salz, Rich writes: >Do IoT devices generally talk to public-facing web servers? Yes, in large quantities. Public web servers are often the only channel they have to the outside world (apart from direct access on the LAN segment they're on, but that's often only for admin

Re: [TLS] draft-rescorla-tls-subcerts

Eric Rescorla writes: >We've talked several times about designing some sort of TLS delegation >mechanism. A few of us got together and put together some initial thoughts >about the options at: >https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt That's going to be a tricky

Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

Viktor Dukhovni writes: >The client is expected to send a complete list of *all* the groups it >supports if it supports (any of) the new designated groups. Which means that >clients that support these groups will use only these groups with servers >that likewise suppose

Re: [TLS] PSS and TLS 1.3

Nikos Mavrogiannopoulos writes: >TLS 1.3 requiring a different key type, will provide an incentive for them to >update. No, it'll be an incentive for them to ignore the requirement, or work around it. The S/MIME WG looked at this years ago when they considered tying AES use to

Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

Bodo Moeller writes: >Peter, so your complaint is about the lack of support for explicitly >specified (non-"named") groups? It's the lack of support for DHE unless it's the exact parameters the server wants. At the moment if your implementation wants to use DHE (which pretty

Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

Ilari Liusvaara writes: >AFAIK, that failure can only happen if at least one of: [...] New groups are introduced but the server or client only support the old ones. So the server does ffdhe2048, the client does ffdhe2048', both are quite happy to do DHE-2048 but as a

Re: [TLS] 3DES diediedie

Tony Arcieri writes: >Should there be a 3DES "diediedie"? Only if there's an actualy issue. 3DES is still very widely supported (particularly in financial systems and embedded), and provides a useful backup to AES. An attack that recovers cookie if you can record 785GB of

Re: [TLS] CertficateRequest extension encoding

David Benjamin writes: >Either way I imagine our stack will just keep on ignoring it, so I don't feel >about this all too strongly. But the topic came up so I thought I'd suggest >this. I ignore it too. Client certs are so rare, and so painful to deploy, that I'm not

Re: [TLS] [Cfrg] 3DES diediedie

in place, it's how to get more crypto in place. -- Ian Grigg, 28 August 2016. ... and to raise the level of security of the rest of the system so that attackers are actually forced to target the crypto rather than just strolling around it. -- Peter Gutmann, in corollary. The device may

Re: [TLS] [Cfrg] 3DES diediedie

Ilari Liusvaara writes: >The TLS-style asymmetric designs don't come even close to cutting it if >client lacks good entropy source. Actually they're fine, see the comment about using entropy from both sides. You can run one side of a TLS communication with zero entropy

Re: [TLS] [Cfrg] 3DES diediedie

Richard Hartmann writes: >Is it correct when I say that the embedded programmers you talked to don't >care about any form of DES as they need/must/prefer to do AES, anyway? The only data point I have is that every time I've tried to disable DES in a new release

Re: [TLS] TLS 1.3 -> TLS 2.0?

Dave Garrett writes: >The HTTP/2 spec explicitly refers to TLS 1.3 and up as not needing the >security restrictions on TLS 1.2 it lays out. Given that LTS fixes all (known) problems in TLS 1.2 and earlier (hey, if you know of weaknesses/attacks, say so now), it doesn't

Re: [TLS] TLS 1.3 -> TLS 2.0?

Julien ÉLIE writes: >Considering that possible change, wouldn't it be useful to go on working on >draft-gutmann-tls-lts-05, and consider TLS-LTS not as a TLS extension but as >a real 1.3 version of the 1.x series? If the current 2.0-called-1.3 is renamed to 2.0, I'd be

Re: [TLS] TLS 1.3 -> TLS 2.0?

Dave Garrett writes: >I think it's time we just renamed TLS 1.3 to TLS 2.0. There are major >changes, so labeling it a major version seems more appropriate. > >[...] +1 to all of this. As people on the list know, I've been calling it "TLS 2.0-called-1.3" for a long

Re: [TLS] [Cfrg] 3DES diediedie

David McGrew (mcgrew) writes: >That’s great, facts leaven a debate. Yeah, but they also make it really boring, sigh. *Opinions*, now those are fun... Peter. ___ TLS mailing list TLS@ietf.org

Re: [TLS] [Cfrg] 3DES diediedie

David McGrew (mcgrew) writes: >See for instance slides 8 and 9 of Daniel Shumow's talk at NIST’s LWC >workshop last year: >http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shumow.pdf So looking at slide 6 from that, the first four systems he lists are

Re: [TLS] [Cfrg] 3DES diediedie

Jon Callas writes: >Current cryptographic standards work for IoT That's only if you use the circular argument that IoT is defined to be whatever can run DTLS (or whatever you take as "current cryptographic standards", the slides mention DTLS). An yeah, I can then define my IoT

Re: [TLS] Oracle's plans for Java crypto (mostly TLS-related)

Salz, Rich writes: >FYI: https://www.java.com/en/jre-jdk-cryptoroadmap.html >From that page: 2017-01-17 DSA Increase the minimum key length for DSA certificates to 1024 bits. Will Oracle also be announcing upcoming support for Windows 95, that newfangled Linux thing

Re: [TLS] Suspicious behaviour of TLS server implementations

Martin Rex writes: >The actual problem is the design flaw in TLS that availability of null >compression is not implied, but rather given a seperate codepoint, and the >server choosing null compression and continuing even when it is not >explicitly asserted by the client, is a

Re: [TLS] Suspicious behaviour of TLS server implementations

Andreas Walz writes: >Actually, I wasn't aware of the fact that the TLS 1.3 draft now explicitly >addresses this in the Presentation Language section: > >  "Peers which receive a message which cannot be parsed according to the >  syntax (e.g., have a length

Re: [TLS] Suspicious behaviour of TLS server implementations

Yoav Nir writes: >But if at some point all websites use HTTP-whatever-the-current-version-is >then maybe browsers can remove support for HTTP/1.1 and then your >embedded/SCADA/IoT devices won’t give us that rude shock. Since HTTP/2 pretty much guarantees that SCADA/IoT/etc

Re: [TLS] Suspicious behaviour of TLS server implementations

Ilari Liusvaara <ilariliusva...@welho.com> writes: >On Thu, Sep 22, 2016 at 05:11:39AM +0000, Peter Gutmann wrote: >> It also means you're going to be in for a rude shock when you encounter the >> ocean of embedded/SCADA/IoT devices with non-mainstream TLS implementations.

Re: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations

Andreas Walz writes: >However, where would you draw the line between "I can't" and "I don't want >to"? It's one of those judgement-call things, I don't know if you can strictly define it but as a rule of thumb I'd say that if you encounter it during normal

Re: [TLS] Antw: Re: Suspicious behaviour of TLS server implementations

Andreas Walz <andreas.w...@hs-offenburg.de> writes: >>>> Peter Gutmann <pgut...@cs.auckland.ac.nz> 21.09.16 17.54 Uhr >>> >> If you're writing a strict validating protocol parser than disconnecting in >> this case is a valid response, but if it's s

Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

Speaking of early assignments for code points, it'd be about time for one for TLS-LTS as well, otherwise it'll end up with the de facto 0x42 hard- coded into various implementations. So could I get an IANA early assignment for that? Peter. ___ TLS

Re: [TLS] Suspicious behaviour of TLS server implementations

Martin Thomson writes: >The advantage with deploying a new protocol is that you can be strict. If, >for example, all of the browsers implement TLS 1.3 and are strict, then >Amazon won't be able to deploy a buggy 1.3 implementation without noticing >pretty quickly.

Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

David Benjamin writes: >TLS 1.3 will resolve this with the new cipher suite negotiation, but I agree >this makes the specification basically undeployable with TLS 1.2. This issue >also got brought up here: >https://www.ietf.org/mail-archive/web/tls/current/msg18697.html

Re: [TLS] 3DES diediedie

Tony Arcieri writes: >As someone who works professionally in the payments industry alongside people >who are directly implementing EMV protocols, let me note: those are not IETF >protocols and should not have bearing on IETF/IRTF decisions regarding >deprecations of protocols

Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

Ryan Hamilton writes: >Alternatively, someone could write a "Legacy TLS" to "Current TLS" proxy, >which could run on the client's computer to sit in front of these legacy >devices. This would allow browsers to continue adding new security features >to protect users, while still

Re: [TLS] [Cfrg] 3DES diediedie

Karthikeyan Bhargavan writes: >If every message IoT device sends is a 16 bytes message consisting of one 8 >byte secret and one 8 byte known plaintext, then with a 64-bit cipher, we >only need roughly 64GB in order to get a meaningful collision (50% chance of

Re: [TLS] [Cfrg] 3DES diediedie

David McGrew (mcgrew) writes: >I don’t think you understood my point. IoT is about small devices connecting >to the Internet, and IETF standards should expect designed-for-IoT crypto to >be increasingly in scope. It is important to not forget about these devices, >amidst the

Re: [TLS] [Cfrg] 3DES diediedie

Stephen Farrell writes: >IIRC the IoT marketing term doesn't have a very long history so I don't >really know what substance lies behind that remark. I just used "IoT" because someone else had used it, since it's about as well- defined as "Web 2.0" I agree that it's

Re: [TLS] Industry Concerns about TLS 1.3

Andrei Popov writes: >Won’t the TLS WG stop addressing newly found protocol-level security issues >in TLS 1.2 at some point in the future? They already have, which is the point of TLS-LTS.  Since that fixes all known issues (and that also includes long-standing

Re: [TLS] Industry Concerns about TLS 1.3

Ryan Carboni writes: >I've never quite understood what TLS was supposed to be protecting against, >and whether or not it has done so successfully, or has the potential to do so >successfully. It's the Inside-Out Thread Model (also shared by a number of other security

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Martin Rex writes: >There is a concept called "provable correctness", The problem with provable whatever is that it merely proves that, as far as the provers can tell, the thing they're dealing with conforms to some abstract model. I don't think you can prove much about whatever

Re: [TLS] [Errata Verified] RFC5288 (4694)

RFC Errata System writes: >The following errata report has been verified for RFC5288, >"AES Galois Counter Mode (GCM) Cipher Suites for TLS". I think the erratum needs an erratum. Firstly, nonce doesn't mean "number used once". Secondly, nonce reuse doesn't just

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

Replying to several messages at once to save space: Ilari Liusvaara: >One can downnegotiate TLS 1.3 to TLS 1.2. Ah, you're obviously a fan of Steve Wozniak humour. When someone asked him whether it was possible to upgrade from an Apple II+ to an Apple IIe, he similarly said "yes, you unplug

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

Vlad Krasnov writes: >Second: I don’t think that the changes between TLS 1.3 and TLS 1.2 are >considered a major: just look at the difference between HTTP/2 and HTTP/1 - >those are completely different protocols. So are TLS 1.x and "1.3". It'd be interesting to hear from

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

Ilari Liusvaara writes: >Nope, I was referring to the very technical property that if client sends a >TLS 1.3 handshake, a TLS 1.2 server can still successfully interop, provoded >that the client does TLS 1.2 too That's like saying that PGP and S/MIME are compatible

Re: [TLS] how close are we?

Xiaoyin Liu writes: >Not directly related to Rich's question, but will we settle the "TLS 1.3 -> >TLS 2.0" >discussion (PR #612) before WGLC? Or has this already been closed as "keeping >the current name"? The impression I got from the discussion was that most people,

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

"Salz, Rich" writes: People already know that SSL3 is worse than "SSL" 1.0 though 1.2 , it's logical that SSL 1.3 continues that trend. creating "SSL" 4 will bring more confusion. Please explain that assertion. I was going to ask that too, the quoted text seems..., well,

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

Tony Arcieri writes: >There's already ample material out there (papers, presentations, mailing list >discussions, etc) which talks about "TLS 1.3". In other words, the TLS WG and a small number of people who interact with it call it TLS 1.3.  That's hardly a strong argument

  1   2   3   4   >