Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

Joseph Salowey writes: > The last call has come and gone without any comment. Please indicate if > you have reviewed the draft even if you do not have issues to raise so the > chairs can see who has reviewed it. Also indicate if you have any plans to > implement the draft. I looked at the

Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

Viktor Dukhovni writes: > TL;DR: Should TLS client abort DHE-RSA handshakes with a peer > certificate that *only* lists: > > X509v3 Key Usage: > Key Encipherment, Data Encipherment Yes, because in DHE-RSA, the RSA key is used for signing, and this is an

Re: [TLS] WGLC for draft-ietf-tls-sni-encryption

m...@sap.com (Martin Rex) writes: > If anyone really thinks that there should be a scheme where a > server's hostname is no longer transfered in a cleartext (including > TLS extension SNI), then first of all a *NEW* distinct URI method > should be defined for that purpose, e.g. "httph://" as a

Re: [TLS] integrity only ciphersuites

"Nancy Cam-Winget \(ncamwing\)" writes: > In following the new IANA rules, we have posted the draft > https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-00 > to document request for registrations of HMAC based cipher > selections with TLS 1.3…..and are soliciting feedback from

Re: [TLS] Captive portals, "access administratively disabled" and alert messages

Two problems with this proposal, that don't occur with the proposal the capport WG is working on, are: - What do you do if you get one of these alerts over multipath TCP? - What happens if some site far away on the Internet sends you one of these alerts? Perhaps because DNS was forged and

Re: [TLS] TLS specification clarification in case of client authentication: different CA with DN different only in case

devzero2000 writes: > Hello everyone > > >From the tls 1.2 specification, speaking of client authentication, > https://tools.ietf.org/html/rfc5246#section-7.4.4 par 7.4.4 (but it is the > same for the last tls draft 1.3 par. 4.2.4.) > > when he says: > >

Re: [TLS] comments on draft-ietf-tls-tls13-19

Ilari Liusvaara writes: > > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos > > wrote: > > > > > My issue with OCSP when used under TLS was how to determine the > > > validity of the response when the nextUpdate field is missing. I've > > >

Re: [TLS] Industry Concerns about TLS 1.3

BITS Security writes: > Outbound TLS connections require MITM for decryption. Inbound or > internal TLS connections can be decrypted with an RSA private key > under TLS 1.2. It would be unwise to build a security or regulatory structure on the principle that MITM

Re: [TLS] Industry Concerns about TLS 1.3

Ryan Carboni writes: > in the internet of things, DH is actually > less secure than normal public key exchange. Servers are more likely to > have entropy than embedded devices. I think that's backwards; in a 'normal' public key exchange, it is the client that generates the

Re: [TLS] CertficateRequest extension encoding

Peter Gutmann writes: > 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.

Re: [TLS] 3DES diediedie

Tony Arcieri writes: > This attack was published today[*]: > > https://sweet32.info/ > > I bring it up because I think the threat model is similar to the threats > that lead to RC4 "diediedie" > > https://www.rfc-editor.org/info/rfc7465 > > Should there be a 3DES

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

Peter Gutmann writes: > The problem is that 7919 doesn't say "I want to do DHE, if possible > with these parameters", it says "I will only accept DHE if you use > these parameters, otherwise you cannot use DHE but must drop back to > RSA". Talk about cutting off your

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

Peter Gutmann writes: > Viktor Dukhovni writes: > > >There's no guess, the client sends its full list of supported > >groups, and the server picks the one it likes. > > ... and if the client doesn't get it exactly right, the server has to

Re: [TLS] Keeping TLS extension points working

Hubert Kario writes: > On Thursday, 28 July 2016 06:12:48 CEST Watson Ladd wrote: > > On Thu, Jul 28, 2016 at 3:28 AM, Hubert Kario wrote: > > > On Wednesday, 27 July 2016 09:50:18 CEST Wan-Teh Chang wrote: > > >> Another source of interop failures is the

Re: [TLS] Adoption of TLS-LTS

Peter Gutmann writes: > 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 > > Oh, right.

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

Ryan Hamilton <r...@google.com> writes: > On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating <geo...@geoffk.org> > wrote: > > > So, I don't think HTTP is generally safe against attacker-forced > > replay, and would suggest great caution in allowing it. &g

Re: [TLS] Require deterministic ECDSA

[I guess we're top-posting...] Another benefit is that if it turns out the entropy source is broken, then if client/server random or IV is guessable, that's something that affects one connection and can be addressed for future connections by fixing the entropy source. But if k generation is

Re: [TLS] Controlling use of SHA-1

Viktor Dukhovni writes: > On Thu, Oct 22, 2015 at 08:42:51AM +0100, Rob Stradling wrote: > > > IINM this also changes the fallback for servers that choose to include a > > PKIX trust anchor certificate in the Server Certificate message. > > The signatures of

Re: [TLS] Review of PR #209

Daniel Kahn Gillmor writes: > Consider a server has an ongoing session wrapped in TLS that uses client > authentication to approve or deny some requests from the client. It > remembers what requests the client has made as some sort of relevant > state. Let's take an

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

William Whyte writes: > Hi all, > > We've updated the TLS 1.3 Quantum Safe Handshake draft to use extensions as > suggested by DKG in Prague. All comments welcome. > > There's an interesting issue here: McEliece keys, which should be > permissible, are larger in

Re: [TLS] Should we require implementations to send alerts?

Martin Thomson writes: > On 12 September 2015 at 13:49, Eric Rescorla wrote: > > "Nobody must ever be required to send an alert. Any requirement for sending > > an alert should be SHOULD, at most." > > This was a point of debate for HTTP/2 as well. The

Re: [TLS] DSA support in TLS 1.3.

Jeffrey Walton noloa...@gmail.com writes: Also, if DSA was to be supported, one would need to specify how to determine the hash function (use of fixed SHA-1 doesn't fly). And 1024-bit prime is too small. FIPS186-4 (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf) partially