Re: [TLS] draft-ietf-tls-tls13-24 supported_versions complexity

On Thu, Mar 1, 2018 at 5:24 AM, Nikos Mavrogiannopoulos wrote: > The TLS draft after version -21 requires TLS1.3 servers to negotiate > pre-TLS1.3 versions with a new, mechanism. The document states: > >"If this extension is present, servers MUST ignore the >

[TLS] draft-ietf-tls-tls13-24 supported_versions complexity

The TLS draft after version -21 requires TLS1.3 servers to negotiate pre-TLS1.3 versions with a new, mechanism. The document states: "If this extension is present, servers MUST ignore the ClientHello.legacy_version value and MUST use only the "supported_versions" extension to determine

Re: [TLS] draft-ietf-tls-tls13-24 supported_versions complexity

I believe you are misinterpreting the text, but agree that it could be made more clear. Suppose that the ClientHello includes a supported_versions extensions that contains two values, TLS 1.4 and TLS 1.0, and the server supports TLS 1.3 and below. My interpretation of the current draft is

Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

I’ve submitted the following PR to make sure we answer IANA questions*: https://github.com/tlswg/tls13-spec/pull/1159 One thing I’d like to get input on is which of the RSA-PSS signature schemes should be recommended. The IANA considerations currently recommends rsa_pss_sha256, rsa_pss_sha384,

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

Hi, I've been analysing the record protocol spec for TLS 1.3 a bit, specifically the new padding mechanism. I think there's a possible timing attack on a naïve implementation of de-padding. Maybe this is already known to people who've been paying more attention than me! Recall that the

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

There's another, more cache-friendly approach too, which is to record the position of the highest non-zero byte as the decryption occurs (while that cache-line of plaintext is still in-cache) in-order. I found that a bit easier to implement in constant time too because it's easy to generate an

Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

On Fri, Mar 2, 2018 at 7:32 AM, Benjamin Kaduk wrote: > To expound a bit more on my thinking, pss_pss is what we actually want > people to be using, thus it should be Recommended, but pss_rsae is what > people are actually going to be using (to large extent), and that is >

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

Hi Kenny, Yes, this is something we are aware of. Here's the relevant text from the document: https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.appendix.E.3 I don't think we're likely to change the protocol, but if you have some proposed text that you think would be informative

[TLS] New Internet-Draft: draft-housley-tls-tls13-cert-with-extern-psk-00

I would like to get comments on this Internet-Draft. Once a round of comments have been received and folded into -01, I would like to work with folks that did the earlier proofs with Tamarin to make sure that the this does not negatively impact the TLS 1.3 protocol changes that were made to

[TLS] Possible timing

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

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

> On Mar 1, 2018, at 2:13 PM, Shumon Huque wrote: > >> On Wed, Feb 28, 2018 at 3:07 PM, Nico Williams wrote: >> IF there's an objection to modifying the extension in order to add a >> pin-to-DANE TTL field, I would propose the following instead: >> >>

Re: [TLS] New Internet-Draft: draft-housley-tls-tls13-cert-with-extern-psk-00

Martin: > > This seems like a welcome addition. I'm not sure why you think that > PQ needs are a good motivation for this work though. Managing > external PSKs is so unwieldy that it almost seems like this would do > more harm than good in that regard. I find this more interesting from > the

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

On Tue, Feb 27, 2018 at 6:36 PM, Nico Williams wrote: > On Tue, Feb 27, 2018 at 11:24:31AM -0500, Shumon Huque wrote: > > On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote: > > > Several of us were well aware of this during the early days of the > > >

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

Hi Ekr. Ah that's great, thanks - and I think the text in the Appendix already addresses the issues very well. Sorry for the bandwidth consumption. Cheers, Kenny -Original Message- From: Eric Rescorla Date: Thursday, 1 March 2018 at 22:27 To: "Paterson, Kenny"

Re: [TLS] New Internet-Draft: draft-housley-tls-tls13-cert-with-extern-psk-00

Hi Russ, This seems like a welcome addition. I'm not sure why you think that PQ needs are a good motivation for this work though. Managing external PSKs is so unwieldy that it almost seems like this would do more harm than good in that regard. I find this more interesting from the perspective

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

The data ultimately needs to be returned to the calling application, presumably some HTTP parser, which in turn passes data up to more calling code and so on. Conversely, the data must have been produced by some also application-level process on the sender, some HTTP serializer, before it was

Re: [TLS] draft-ietf-tls-tls13-24 supported_versions complexity

FWIW, this was BoringSSL's interpretation as well. We don't consider supported_versions an acceptable TLS 1.2 (or earlier) ServerHello extension. I generally agree that we shouldn't add new unnecessary combinations. (TBH, I don't even consider the ability to advertise TLS 1.3 and TLS 1.1 on the

Re: [TLS] draft-ietf-tls-tls13-24 supported_versions complexity

On Thu, Mar 1, 2018 at 10:42 AM, David Benjamin wrote: > FWIW, this was BoringSSL's interpretation as well. We don't consider > supported_versions an acceptable TLS 1.2 (or earlier) ServerHello > extension. I generally agree that we shouldn't add new unnecessary >

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

On Wed, Feb 28, 2018 at 3:07 PM, Nico Williams wrote: > IF there's an objection to modifying the extension in order to add a > pin-to-DANE TTL field, I would propose the following instead: > > Make the pin-to-DANE be "forever" but make it so it can easily be >

Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

I should note that Ben pointed out in the PR that we might need to specify all 6 as recommended. I can kind of get behind that because before we were doing PSS regardless of the identifier. Thoughts? spt > On Mar 1, 2018, at 09:58, Sean Turner wrote: > > I’ve submitted the

Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

To expound a bit more on my thinking, pss_pss is what we actually want people to be using, thus it should be Recommended, but pss_rsae is what people are actually going to be using (to large extent), and that is still a deployment that we consider good and useful, for now.  Maybe in 5 years the

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

On Fri, Mar 2, 2018 at 10:23 AM, Daniel Kahn Gillmor wrote: > You could of course check from the front of the plaintext, keeping every > non-zero value: > > char ptype = 0; > for (i = 0; i < plaintext_len; i++) > if plaintext[i] > ptype = plaintext[i]; What

Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

Okay that was a fail on my part I meant to put all 6 in. Updated the PR. spt > On Mar 1, 2018, at 20:05, Martin Thomson wrote: > > I think that I was suggesting this: > > The following values SHALL be marked as > "Recommended": ecdsa_secp256r1_sha256,

Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

> On Mar 1, 2018, at 16:31, Martin Thomson wrote: > > On Fri, Mar 2, 2018 at 7:32 AM, Benjamin Kaduk wrote: >> To expound a bit more on my thinking, pss_pss is what we actually want >> people to be using, thus it should be Recommended, but pss_rsae

[TLS] I-D Action: draft-ietf-tls-sni-encryption-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : SNI Encryption in TLS Through Tunneling Authors : Christian Huitema Eric

Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

I think that I was suggesting this: The following values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,rsa_pss_pss_sha512, and ed25519. On Fri, Mar

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

On Thu, Mar 1, 2018 at 5:12 PM, Martin Thomson wrote: > On Fri, Mar 2, 2018 at 10:23 AM, Daniel Kahn Gillmor > wrote: > > You could of course check from the front of the plaintext, keeping every > > non-zero value: > > > > char ptype = 0; > >

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

On Fri, Mar 2, 2018 at 12:17 PM, Eric Rescorla wrote: > This is fun, but I want to note that many (most) APIs are not zero-copy but > rather involve > SSL_Read() copying data from some internal buffer into a caller supplied > buffer. So > that operation also needs to be made