Re: [TLS] Commentary on the client authentication presentation slides

2015-07-28 Thread David Benjamin
Sent from the right email this time. (Sorry folks who got it twice. One of these days I'll not mess this up! :-) ) On Tue, Jul 28, 2015 at 6:28 PM David Benjamin david...@google.com wrote: On Fri, Jul 24, 2015 at 1:02 AM Andrei Popov andrei.po...@microsoft.com wrote: Thanks for the detailed

Re: [TLS] Commentary on the client authentication presentation slides

2015-08-02 Thread David Benjamin
On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara ilari.liusva...@elisanet.fi wrote: On Tue, Jul 28, 2015 at 6:28 PM David Benjamin david...@google.com wrote: Are you intending that this mechanism be enabled by default for HTTP/2 or would the prohibition against renego still apply

Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-00

2015-08-04 Thread David Benjamin
On Tue, Aug 4, 2015 at 12:20 PM Salz, Rich rs...@akamai.com wrote: Personally, I would rather see the nonce construction follow the form defined in the respective TLS version. [DB: Adding back in for context: That means including redundant bytes in TLS 1.2 and only getting the full

Re: [TLS] Commentary on the client authentication presentation slides

2015-08-10 Thread David Benjamin
On Mon, Aug 10, 2015 at 3:05 PM Andrei Popov andrei.po...@microsoft.com wrote: Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2. Correct, anything less than this will create deployment problems. But

Re: [TLS] Application data during renegotiation handshake

2015-11-12 Thread David Benjamin
On Wed, Nov 11, 2015 at 10:43 PM Yoav Nir wrote: > > > On 12 Nov 2015, at 3:32 AM, Adam Langley wrote: > > > > The TLS 1.3 post-handshake client-auth was intended, as I recall, to > > support HTTP/1.1 over TLS 1.3. > > No, it was (and is) presented

Re: [TLS] Application data during renegotiation handshake

2015-11-16 Thread David Benjamin
cleaner" and "ugly compat solution" to be the same, that is certainly preferable, no? It's possible my guesses about your constraints are incorrect, but so far I'm not seeing any reason that wouldn't be possible. What am I missing here? David > > > *From:*

Re: [TLS] PR for anti-downgrade mechanism

2015-10-19 Thread David Benjamin
On Mon, Oct 19, 2015 at 11:10 AM Eric Rescorla wrote: > On Mon, Oct 19, 2015 at 7:37 AM, Short, Todd wrote: > >> Does the sentinel have to be the first N bytes? >> >> RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time >> value and 28 random

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

2015-10-14 Thread David Benjamin
On Wed, Oct 14, 2015 at 4:05 PM Matt Caswell wrote: > On 14/10/15 16:44, Martin Rex wrote: > > Matt Caswell wrote: > >> > >> Does anyone have any views on the below? > > > > Yup. Interleaving application & handshake records is a > > highly dangerous idea (and fortunately some

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

2015-10-14 Thread David Benjamin
On Wed, Oct 14, 2015 at 4:42 PM Martin Thomson <martin.thom...@gmail.com> wrote: > On 14 October 2015 at 13:29, David Benjamin <david...@chromium.org> wrote: > > If you really absolutely must support interleave and can't avoid it, I > think > > it being allowed

Re: [TLS] Version in record MAC

2015-10-19 Thread David Benjamin
What purpose does putting the version in the AD serve? It's not harmful, sure, but just using the sequence number is simplest. It seems the only reason we'd consider putting it into the AD is because historically the record version was in there as part of the record header. In a vacuum, I'm having

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

2015-09-17 Thread David Benjamin
(Resending from the right address, again. Possibly I should have subscribed with the other one...) On Thu, Sep 17, 2015 at 6:23 PM David Benjamin <david...@google.com> wrote: > On Thu, Sep 17, 2015 at 5:46 PM Brian Smith <br...@briansmith.org> wrote: > >> On Thu, Sep 1

Re: [TLS] Fresh results

2015-12-04 Thread David Benjamin
On Fri, Dec 4, 2015 at 1:17 PM Hubert Kario wrote: > On Friday 04 December 2015 00:52:08 Hanno Böck wrote: > > * Fully deprecate RSA key exchange. > > The compatibility costs of this one are high. They are even higher > > considering the fact that chrome wants to deprecate dhe

Re: [TLS] chacha/poly interop?

2015-12-09 Thread David Benjamin
BoringSSL has an implementation of the AEAD itself you could test against. It's the EVP_AEAD named EVP_aead_chacha20_poly1305_rfc7539 (to be renamed to EVP_aead_chacha20_poly1305 later). On Wed, Dec 9, 2015 at 8:02 PM Salz, Rich wrote: > OpenSSL just landed our chacha/poly

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

2016-01-11 Thread David Benjamin
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. I started gathering numbers on ServerKeyExchange hashes back in November. The code isn't on

Re: [TLS] Fixing TLS

2016-01-12 Thread David Benjamin
On Tue, Jan 12, 2016 at 12:27 PM Peter Bowen wrote: > The gaps seem to be: > - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated > (BoringSSL has an implementation using cipher suite 0xca,0xfe) > 0xca,0xfe has since been removed as nothing was using it. I'm not

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

2016-06-07 Thread David Benjamin
On Tue, Jun 7, 2016 at 5:06 PM Yoav Nir wrote: > > > On 7 Jun 2016, at 8:33 PM, Hubert Kario wrote: > > > > On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote: > >> I’m not sure this helps. > >> > >> I’ve never installed a server that is version intolerant.

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

2016-06-03 Thread David Benjamin
I think I could be convinced in either direction right now. It is definitely ugly and more of a nuisance to implement. The alternative is a fallback and then painfully driving it out later. We've done that before and we have FALLBACK_SCSV and the server_random trick now. At the same time, I am

Re: [TLS] PR #493: Multiple concurrent tickets

2016-06-04 Thread David Benjamin
I'm not sure I follow why the additional "generation" machinery is necessary. What do we gain from having the server to tell us to discard a ticket beyond what the ticket lifetime already gives? This doesn't seem an effective way to discard key material since, unlike the ticket lifetime, we need

Re: [TLS] Downgrade protection, fallbacks, and server time

2016-06-02 Thread David Benjamin
On Thu, Jun 2, 2016 at 6:40 AM Hubert Kario <hka...@redhat.com> wrote: > On Wednesday 01 June 2016 22:29:06 David Benjamin wrote: > > In case folks hoped we could bump the ClientHello version without > > those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance

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

2016-06-02 Thread David Benjamin
On Thu, Jun 2, 2016 at 11:07 AM David Benjamin <david...@chromium.org> wrote: > On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario <hka...@redhat.com> wrote: > >> On Thursday 02 June 2016 11:39:20 Yoav Nir wrote: >> > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannop

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

2016-06-02 Thread David Benjamin
On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario wrote: > On Thursday 02 June 2016 11:39:20 Yoav Nir wrote: > > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos > > > wrote:> > > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote: > > >> 2% is actually

Re: [TLS] Downgrade protection, fallbacks, and server time

2016-06-02 Thread David Benjamin
On Thu, Jun 2, 2016 at 11:20 AM Hubert Kario wrote: > > > Speaking of version number, does the text say that a server _MUST_ > > > accept any version higher than the one that is specified in the RFC, > > > but reply with 0x03,0x04 in case it doesn't support any future > > >

[TLS] Downgrade protection, fallbacks, and server time

2016-06-01 Thread David Benjamin
In case folks hoped we could bump the ClientHello version without those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much exists. (Maybe we should just give up on ClientHello.version and use an extension? Extensions have rusted less.) I picked a large list of top sites and

Re: [TLS] Downgrade protection, fallbacks, and server time

2016-06-01 Thread David Benjamin
in RSA for a long while.) David > > On Wed, Jun 1, 2016 at 3:29 PM, David Benjamin <david...@chromium.org> > wrote: > >> In case folks hoped we could bump the ClientHello version without those >> dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very m

Re: [TLS] Simpler backward compatibility rules for 0-RTT

2016-06-21 Thread David Benjamin
On Tue, Jun 21, 2016 at 8:45 PM Martin Thomson wrote: > On 22 June 2016 at 10:30, Bill Frantz wrote: > > Well, it seems like a browser could try TLS 1.3 without 0-RTT first. > > > > If it connects with 1.3 non-0-RTT, then it could mark the host

Re: [TLS] Simpler backward compatibility rules for 0-RTT

2016-06-21 Thread David Benjamin
On Tue, Jun 21, 2016 at 1:54 PM Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Tue, Jun 21, 2016 at 10:07:17AM -0700, Ryan Hamilton wrote: > > On Mon, Jun 20, 2016 at 6:15 PM, Martin Thomson < > martin.thom...@gmail.com> > > wrote: > > > > &

Re: [TLS] Remove EncryptedExtensions from 0-RTT

2016-06-23 Thread David Benjamin
On Thu, Jun 23, 2016 at 6:35 AM David Benjamin <david...@chromium.org> wrote: > On Thu, Jun 23, 2016 at 6:35 AM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > >> On Thu, Jun 23, 2016 at 01:37:14PM +1000, Martin Thomson wrote: >> > When implementing 0-

Re: [TLS] Remove EncryptedExtensions from 0-RTT

2016-06-23 Thread David Benjamin
plexity of the server > > state machine. > > > > David Benjamin rather flippantly described a solution to this problem: > > XOR the ticket age value with something that is either derived from > > the old session keys or was included in the NewSessionTicket message. >

Re: [TLS] chacha/poly for http/2

2016-01-13 Thread David Benjamin
Chrome is also expecting to ship the cipher in Chrome 49. It's available in Canary and Dev channel right now. It should interop with OpenSSL's master branch as of when I last tested this. David On Wed, Jan 13, 2016 at 12:48 PM Salz, Rich wrote: > We (OpenSSL) have already

[TLS] Simplifying signature algorithm negotiation

2016-01-15 Thread David Benjamin
Hi folks, This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS 1.2, signature algorithms are spread across the handshake. We have SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm, all in independent registries. NamedGroup is sent in one list, also used for

Re: [TLS] Simplifying signature algorithm negotiation

2016-01-15 Thread David Benjamin
On Fri, Jan 15, 2016 at 7:08 PM Brian Smith <br...@briansmith.org> wrote: > David Benjamin <david...@chromium.org> wrote: > >> 4. Deprecate ecdsa_sha256, etc., in favor of new >> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_* >>

Re: [TLS] Simplifying signature algorithm negotiation

2016-01-15 Thread David Benjamin
On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett <davemgarr...@gmail.com> wrote: > On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: > > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS > > 1.2, signature algorithms are spread across the han

Re: [TLS] Simplifying signature algorithm negotiation

2016-01-15 Thread David Benjamin
On Fri, Jan 15, 2016 at 8:10 PM David Benjamin <david...@chromium.org> wrote: > If changing the existing meaning is a nuisance, another option is to > continue to allocate new values but only define ecdsa_p256_sha256, > ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your

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

2016-02-05 Thread David Benjamin
On Mon, Jan 11, 2016 at 6:17 PM David Benjamin <david...@chromium.org> wrote: > 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 mu

Re: [TLS] 0-RTT, server Application Data, and client Finished

2016-01-28 Thread David Benjamin
On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Wed, Jan 27, 2016 at 07:28:47PM +0000, David Benjamin wrote: > > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson < > martin.thom...@gmail.com> > > wrote: > > >

Re: [TLS] 0-RTT, server Application Data, and client Finished

2016-01-27 Thread David Benjamin
On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson <martin.thom...@gmail.com> wrote: > On 27 January 2016 at 14:11, David Benjamin <david...@chromium.org> wrote: > > Why do you say it's an optimization? They're exactly the same except the > > simplified one reduces t

Re: [TLS] 0-RTT, server Application Data, and client Finished

2016-01-29 Thread David Benjamin
On Thu, Jan 28, 2016 at 2:09 PM Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Thu, Jan 28, 2016 at 05:36:22PM +0000, David Benjamin wrote: > > On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > >

Re: [TLS] Simplifying signature algorithm negotiation

2016-02-29 Thread David Benjamin
On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla <e...@rtfm.com> wrote: > On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin <david...@chromium.org> > wrote: > >> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett <davemgarr...@gmail.com> >> wrote: >> >

Re: [TLS] Simplifying signature algorithm negotiation

2016-01-19 Thread David Benjamin
On Fri, Jan 15, 2016 at 10:13 PM Brian Smith <br...@briansmith.org> wrote: > David Benjamin <david...@chromium.org> wrote: > >> (Whether such certificates exist on the web is probably answerable via CT >> logs, but I haven't checked.) >> > > Me neither, a

Re: [TLS] Simplifying signature algorithm negotiation

2016-01-19 Thread David Benjamin
Sorry, sent from the wrong address. On Tue, Jan 19, 2016 at 5:19 PM David Benjamin <david...@google.com> wrote: > On Sat, Jan 16, 2016 at 5:00 AM Hanno Böck <ha...@hboeck.de> wrote: > >> Hi, >> >> I generally like the idea of simplifying the diffe

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

2016-01-19 Thread David Benjamin
BoringSSL has a pair of implementations ready (in C and in our fork of Go's TLS stack for testing). We're using the value in the TLS 1.3 draft, so 29. It's not currently enabled in any Chrome builds, but I'm expecting to change this soon. David On Tue, Jan 19, 2016 at 12:54 PM Joseph Salowey

Re: [TLS] Simplifying signature algorithm negotiation

2016-01-19 Thread David Benjamin
can be used for signing but also what curves can get signed. > > Or are you saying that the NamedGroup would stay, and would now specify > only the supported parameters for the key exchange, not how they are > authenticated (as it is now)? > Yes. > On Friday 15 January 2016 20:45

Re: [TLS] Simplifying signature algorithm negotiation

2016-01-22 Thread David Benjamin
PM David Benjamin <david...@chromium.org> wrote: > Hi folks, > > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS > 1.2, signature algorithms are spread across the handshake. We have > SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm,

Re: [TLS] Simplifying signature algorithm negotiation

2016-01-25 Thread David Benjamin
algorithms. The other benefits from incorporating curve preferences into the negotiation also still apply. David On Fri, Jan 22, 2016 at 5:25 PM David Benjamin <david...@chromium.org> wrote: > I've put together a pull request with some initial text for this proposal > if folks dec

[TLS] 0-RTT, server Application Data, and client Finished

2016-01-26 Thread David Benjamin
It's possible I'm reading the draft wrong, so this thread may be a very short one. (t here is in units of RTT, so t=0 is when the client sends ClientHello and t=0.5 is when the server receives ClientHello and sends ServerHello, t=1 is when the client receives ServerHello, etc.) Looking at the

Re: [TLS] 0-RTT, server Application Data, and client Finished

2016-01-26 Thread David Benjamin
On Tue, Jan 26, 2016 at 9:11 PM Martin Thomson <martin.thom...@gmail.com> wrote: > On 27 January 2016 at 12:58, David Benjamin <david...@chromium.org> wrote: > > If the server needs to send a CertificateRequest (i.e. the client > > mispredicted the 0-RTT Ce

Re: [TLS] Backwards-compatibility of 0-RTT data

2016-01-26 Thread David Benjamin
On Tue, Jan 26, 2016 at 9:11 PM Eric Rescorla <e...@rtfm.com> wrote: > On Tue, Jan 26, 2016 at 6:02 PM, David Benjamin <david...@chromium.org> > wrote: > >> Instead of putting 0-RTT data in a ClientHello extension, the current >> draft has the client send extra r

Re: [TLS] Simplifying signature algorithm negotiation

2016-01-19 Thread David Benjamin
On Mon, Jan 18, 2016 at 6:48 AM Hubert Kario <hka...@redhat.com> wrote: > On Friday 15 January 2016 20:45:34 David Benjamin wrote: > > Hi folks, > > > > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In > > TLS 1.2, signature algorithms ar

Re: [TLS] Simplifying signature algorithm negotiation

2016-03-15 Thread David Benjamin
generally positive about > this in this discussion, > but I'll rely on the chairs to determine consensus. > > -Ekr > > > > > > > > > > > > > > On Mon, Feb 29, 2016 at 9:16 AM, David Benjamin <david...@chromium.org> > wrote: > >> On Fr

Re: [TLS] Tickets and cross protocol attacks

2016-03-30 Thread David Benjamin
It's probably better to reject this fallback when the client has chosen to > explicitly use a TLS 1.3 feature with 0-RTT in general. > > Subodh > ________ > From: Martin Thomson [martin.thom...@gmail.com] > Sent: Tuesday, March 29, 2016 6:29 PM &

Re: [TLS] Tickets and cross protocol attacks

2016-03-29 Thread David Benjamin
On Tue, Mar 29, 2016 at 12:57 PM Subodh Iyengar wrote: > Recent attacks like SLOTH, DROWN, PCKS1.5 padding oracles have shown that > attacks on previous version of TLS can be used to attack new version of > TLS. > > One thing that is not mandated by TLS 1.3 is separation of

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

2016-05-19 Thread David Benjamin
If the WG agrees with this change, I've put together a PR here: https://github.com/tlswg/tls13-spec/pull/462 On Tue, May 17, 2016 at 4:14 PM David Benjamin <david...@chromium.org> wrote: > Reviving this thread, I also think it would also be a good idea if 1.3 did > not stripping

[TLS] In-handshake CertificateRequest and 0-RTT

2016-05-11 Thread David Benjamin
The 0-RTT handshake originally had two places with a client Certificate + CertificateVerify: in the 0-RTT flow and in the second Finished block in response to a server CertificateRequest. We've dropped the first now. I propose we drop the second too. Client auth with 0-RTT is solely carried over

Re: [TLS] In-handshake CertificateRequest and 0-RTT

2016-05-11 Thread David Benjamin
h. (This would just be for re-asserting the private key and not switching certificates, right?) > On 12 May 2016 at 06:44, David Benjamin <david...@chromium.org> wrote: > > The 0-RTT handshake originally had two places with a client Certificate + > > CertificateVerify: in the

Re: [TLS] In-handshake CertificateRequest and 0-RTT

2016-05-12 Thread David Benjamin
k we're starting to get more comfort with that. > > So, not sure what I think... > > -Ekr > > > > > > On Wed, May 11, 2016 at 10:44 PM, David Benjamin <david...@chromium.org> > wrote: > >> The 0-RTT handshake originally had two places with a client Cer

Re: [TLS] In-handshake CertificateRequest and 0-RTT

2016-05-12 Thread David Benjamin
resume, it's just not clear to > me why you wouldn't > allow in-handshake client-auth. I'm not sure it's a hill I'm willing to > die on though. > > -Ekr > > > > On Thu, May 12, 2016 at 9:06 PM, David Benjamin <david...@chromium.org> > wrote: > >> Which PS

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

2016-05-17 Thread David Benjamin
Reviving this thread, I also think it would also be a good idea if 1.3 did not stripping zeros from Z. Having this logic is rather dubious w.r.t. treating secret data in constant-time. And as Bill Cox mentioned elsewhere in this thread, this odd behavior has caused interoperability issues in the

Re: [TLS] PR#449

2016-05-11 Thread David Benjamin
This change has a non-obvious consequence for server implementation complexity. I don't have an especially good alternate proposal though. Putting ticket_age in EncryptedExtensions means there are two ways a server may reject 0-RTT. It might reject ClientHello because the ticket is invalid (or if

[TLS] Keeping TLS extension points working

2016-07-25 Thread David Benjamin
Hi folks, I'm not sure how this process usually works, but I would like to reserve a bunch of values in the TLS registries to as part of an idea to keep our extension points working. Here's an I-D: https://tools.ietf.org/html/draft-davidben-tls-grease-00 (The name GREASE is in honor of AGL's

Re: [TLS] Keeping TLS extension points working

2016-07-25 Thread David Benjamin
On Mon, Jul 25, 2016 at 7:23 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > On Mon, Jul 25, 2016 at 10:32:29PM +0000, David Benjamin wrote: > > > I'm not sure how this process usually works, but I would like to reserve > a > > bunch of values in the TLS regis

Re: [TLS] Keeping TLS extension points working

2016-07-25 Thread David Benjamin
On Mon, Jul 25, 2016 at 6:32 PM David Benjamin <david...@chromium.org> wrote: > Hi folks, > > I'm not sure how this process usually works, but I would like to reserve a > bunch of values in the TLS registries to as part of an idea to keep our > extension points working. H

Re: [TLS] Server-side missing_extension MUSTs

2016-07-13 Thread David Benjamin
On Wed, Jul 13, 2016 at 11:06 AM Hubert Kario <hka...@redhat.com> wrote: > On Wednesday 13 July 2016 14:43:58 David Benjamin wrote: > > To be clear, I am not at all opposed to useful errors or strict policing > of > > what the peer sends. That's all great. Indeed the

Re: [TLS] Thoughts on Version Intolerance

2016-07-23 Thread David Benjamin
On Sat, Jul 23, 2016 at 3:37 AM Brian Smith wrote: > Hubert Kario wrote: > > I'm quite sure that if I were sending a huge extension or many big > extensions, > > the percentage of servers that are incompatible to them would be > similar, if > > not

Re: [TLS] Keeping TLS extension points working

2016-07-26 Thread David Benjamin
On Tue, Jul 26, 2016 at 6:56 AM Hubert Kario <hka...@redhat.com> wrote: > On Monday, 25 July 2016 22:32:29 CEST David Benjamin wrote: > > I would like to fix this by reserving a few values in our registries so > > that clients may advertise random ones and regularly exercis

Re: [TLS] Keeping TLS extension points working

2016-07-26 Thread David Benjamin
gt; PS: As chair, I try to deal with/deflect as many of these procedural > issues as possible, but if you want to know more please let me know > off-list. This actually goes for anybody on the list. > > > > On Jul 25, 2016, at 18:32, David Benjamin <david...@chromium.org> wrote: >

Re: [TLS] Keeping TLS extension points working

2016-08-02 Thread David Benjamin
技术有限公司 Huawei Technologies Co., Ltd. >> [image: Company_logo] >> >> Phone: >> Fax: >> Mobile: >> Email: >> Huawei Technologies Co., Ltd. >> Bangalore, India >> >> http://www.huawei.com >> -- >> &g

Re: [TLS] Keeping TLS extension points working

2016-08-03 Thread David Benjamin
limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > > *From:* David Benj

[TLS] Server-side missing_extension MUSTs

2016-07-12 Thread David Benjamin
Hey folks, I would like to remove the missing_extension MUSTs on the server side. Full justification in the PR. https://github.com/tlswg/tls13-spec/pull/544 On the client, it is perfectly feasible to mandate a particular alert value. The check is very straight-forward. On the server, however,

Re: [TLS] Thoughts on Version Intolerance

2016-07-21 Thread David Benjamin
t of compatibility by > >> using extension based mechanism to indicate TLSv1.3, > > Just quick: This was discussed yesterday, David Benjamin had an > > interesting proposal, but it was largely met with resistance. So from > > I had some follow-up discussion wi

Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2

2016-07-12 Thread David Benjamin
On Tue, Jul 12, 2016 at 1:47 PM David Benjamin <david...@chromium.org> wrote: > [Changing subject since the other thread is about something else.] > > On Tue, Jul 12, 2016 at 12:16 AM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > >> > ### Signatu

[TLS] TLS 1.3 signature algorithms in TLS 1.2

2016-07-12 Thread David Benjamin
[Changing subject since the other thread is about something else.] On Tue, Jul 12, 2016 at 12:16 AM Ilari Liusvaara wrote: > > ### Signature Algorithms > > > > * In TLS 1.2, the extension contained hash/signature pairs. The pairs are > > encoded in two octets, so

Re: [TLS] Server-side missing_extension MUSTs

2016-07-13 Thread David Benjamin
entHello to get > reliable 1RTT (with the exception of HRR). On Wed, Jul 13, 2016 at 8:12 AM Hubert Kario <hka...@redhat.com> wrote: > On Wednesday 13 July 2016 05:23:53 David Benjamin wrote: > > I don't believe an implementation which fails to send supported_groups,

Re: [TLS] Server-side missing_extension MUSTs

2016-07-13 Thread David Benjamin
code passes #1 (the special-case is not useful and such a peer would not be able to handshake against correct implementations anyway), so I'm not willing to sacrifice #2 for it. On Wed, Jul 13, 2016 at 10:02 AM David Benjamin <david...@chromium.org> wrote: > On Wed, Jul 13, 2016 at 3:3

Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2

2016-07-12 Thread David Benjamin
On Tue, Jul 12, 2016 at 3:29 PM Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Tue, Jul 12, 2016 at 05:47:26PM +0000, David Benjamin wrote: > > [Changing subject since the other thread is about something else.] > > > > I believe, as the text stands righ

Re: [TLS] Simpler backward compatibility rules for 0-RTT

2016-06-28 Thread David Benjamin
On Tue, Jun 28, 2016 at 1:02 PM Hubert Kario wrote: > On Thursday 23 June 2016 18:53:39 Ilari Liusvaara wrote: > > On Thu, Jun 23, 2016 at 07:26:37AM -0700, Watson Ladd wrote: > > > On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson > > > wrote: > > > >

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

2016-07-08 Thread David Benjamin
On Thu, Jul 7, 2016 at 7:29 PM Watson Ladd wrote: > I don't think we can use name constraints here. Yes, they are opt-in > and clients can indicate support, but it may well be that a TLS > implementation doesn't know if its X509 validation code will support > them as it

Re: [TLS] judging consensus on keys used in handshake and data messages

2016-07-06 Thread David Benjamin
On Wed, Jul 6, 2016 at 2:11 PM Yoav Nir wrote: > Hi, Joe > > > On 6 Jul 2016, at 8:39 PM, Joseph Salowey wrote: > > > > We are the unenviable position of calling consensus between three > choices [0]: > > > > - Option 1 - use the same key for both

Re: [TLS] judging consensus on keys used in handshake and data messages

2016-07-06 Thread David Benjamin
On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla <e...@rtfm.com> wrote: > On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <davemgarr...@gmail.com> > wrote: > >> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote: >> > I'm also curious which post-hands

Re: [TLS] Issue 472: Remove non-closure warning alerts

2016-07-09 Thread David Benjamin
On Sat, Jul 9, 2016 at 7:37 AM Salz, Rich wrote: > > If people are in favor of this, I will prepare a PR. > > +1 > +1 David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR #23 for RFC4492bis

2016-07-04 Thread David Benjamin
On Mon, Jul 4, 2016 at 7:59 AM Yoav Nir wrote: > > > On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara > wrote: > > > > On Mon, Jul 04, 2016 at 03:46:00PM +0300, Yoav Nir wrote: > >> Hi > >> > >> Based on an email exchange with Nikos Mavrogiannopoulos,

Re: [TLS] Reminders

2016-07-11 Thread David Benjamin
OpenSSL determines which certificate to use during ClientHello processing, but it has a mode where, if intermediates were not explicitly configured and only a leaf, it path-builds right before sending the Certificate message. But I don't see any reason why it can't be changed to compute this

Re: [TLS] Downgrade protection, fallbacks, and server time

2016-06-29 Thread David Benjamin
On Wed, Jun 1, 2016 at 6:57 PM Eric Rescorla <e...@rtfm.com> wrote: > On Wed, Jun 1, 2016 at 3:53 PM, David Benjamin <david...@chromium.org> > wrote: > >> On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla <e...@rtfm.com> wrote: >> >>> 2% is actually p

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

2017-02-02 Thread David Benjamin
I think this is much clearer, except for one bullet point below: On Thu, Feb 2, 2017 at 10:22 AM Russ Housley wrote: > [...] > - If PSK and (EC)DH are being used together, then the server will: > > -- sends a "pre_shared_key" extension to indicate the selected >

Re: [TLS] Question about unrecognized extension types in the TLS 1.3 client hello message

2017-01-30 Thread David Benjamin
On Mon, Jan 30, 2017 at 4:45 PM Adam Langley wrote: On Mon, Jan 30, 2017 at 1:41 PM, Scott Fluhrer (sfluhrer) wrote: > My question: in TLS 1.3, if the client inserts an extension of a type that > the server does not recognize, how must the server

[TLS] ecdh_ prefix in draft-ietf-tls-rfc4492bis-12

2017-02-17 Thread David Benjamin
This is a minor comment and purely aesthetic thing. Apologies for the lateness in noticing. Hopefully it's not too late: In TLS 1.3, we dropped the "ecdh_" prefix on ecdh_x25519 and ecdh_x448 when we split signatures from NamedCurve/Group. The documents should probably match in naming one way or

Re: [TLS] stapling OCSP/CT for client cert?

2017-02-22 Thread David Benjamin
Looks like TLS 1.3 already allows this for CT, though not OCSP. Would take all of four characters to fix. See this table: https://tlswg.github.io/tls13-spec/#rfc.section.4.2 One of the nice things about using TLS-style extensions in CertificateRequest is any ClientHello => (Server)Certificate

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

2017-02-14 Thread David Benjamin
NewSessionTicket always includes in-handshake client auth. The resumption secret can't even be derived without it. On Tue, Feb 14, 2017 at 10:21 AM David Wong wrote: > I can see this problem even in the case where the client sends an empty > Certificate message

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

2017-02-15 Thread David Benjamin
On Wed, Feb 15, 2017 at 2:49 PM David Wong wrote: > On Feb 15 2017, at 7:27 pm, Andrei Popov > wrote: > > Yes, I agree that it is useful to mention this in the spec. > > > > > It would be nice is to have two different PRs solving this

Re: [TLS] adopted: draft-davidben-tls-grease

2017-01-18 Thread David Benjamin
Done. Let me know if I did any of that incorrectly. (Sorry about the delay. I've been some combination of suffering from a cold, on vacation, or at conferences for the past month---usually more than one at a time!) On Tue, Jan 3, 2017 at 8:59 AM Sean Turner wrote: I appears

Re: [TLS] GREASE and TLS 1.3

2017-01-18 Thread David Benjamin
On Wed, Jan 18, 2017 at 8:15 PM Martin Thomson wrote: On 19 January 2017 at 14:04, Kazu Yamamoto wrote: > Should we also add grease values for key_share? supported_groups code points should cover that, but if you are asking if we should spend bytes on

[TLS] GREASE and TLS 1.3

2017-01-18 Thread David Benjamin
So, having uploaded draft-ietf-tls-grease-00, I would now like to rewrite large chunks of it. The draft is currently defined for TLS 1.2, but it probably makes sense to order it after TLS 1.3. TLS 1.3 also adds a many new extension points, and we can expect new TLS 1.3 implementations popping up

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

2016-08-19 Thread David Benjamin
On Fri, Aug 19, 2016 at 2:35 PM Geoffrey Keating wrote: > 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,

Re: [TLS] KeyUpdate and unbounded write obligations

2016-08-18 Thread David Benjamin
On Thu, Aug 18, 2016 at 1:08 PM Benjamin Kaduk <bka...@akamai.com> wrote: > On 08/17/2016 11:29 PM, David Benjamin wrote: > > However, we lose the "free" (really at the cost of this unboundedness > problem) generation-based bidirectional KeyUpdate sync. Dep

Re: [TLS] Keeping TLS extension points working

2016-09-02 Thread David Benjamin
ServerHello. The first message may even not be ServerHello and instead HelloRetryRequest. David On Wed, Jul 27, 2016 at 4:02 PM Sean Turner <s...@sn3rd.com> wrote: > > > On Jul 26, 2016, at 11:11, David Benjamin <david...@chromium.org> wrote: > > > > 1) “Updates: 5246

Re: [TLS] handling of duplication of extensions between ServerHello and EncryptedExtensions

2016-09-02 Thread David Benjamin
Huh. I agree that text is weird. We should probably remove it. I think we actually get something akin to what you suggest basically implicitly: Servers aren't allowed to send unsolicited extensions, so your SH and EE parsers should be rejecting any unknown extensions. If you combine that with not

Re: [TLS] draft-davidben-tls-grease-01

2016-09-05 Thread David Benjamin
On Mon, Sep 5, 2016 at 10:59 AM Hubert Kario <hka...@redhat.com> wrote: > On Monday, 5 September 2016 14:48:55 CEST David Benjamin wrote: > > On Mon, Sep 5, 2016 at 7:07 AM Hubert Kario <hka...@redhat.com> wrote: > > > On Friday, 2 September 2016 18:53:45 CEST Davi

Re: [TLS] draft-davidben-tls-grease-01

2016-09-05 Thread David Benjamin
On Mon, Sep 5, 2016 at 7:07 AM Hubert Kario <hka...@redhat.com> wrote: > On Friday, 2 September 2016 18:53:45 CEST David Benjamin wrote: > > I've finally gotten to uploading > > https://tools.ietf.org/html/draft-davidben-tls-grease-01 which hopefully > > resolves th

Re: [TLS] CertficateRequest extension encoding

2016-09-05 Thread David Benjamin
On Mon, Sep 5, 2016 at 5:46 PM Andrei Popov wrote: > Ø A CertificateExtension is a hint to the client about what kind of > certificates are acceptable. We have a registry of u16s for them. Clients > ignore extensions they don't understand, so it is ultimately on the

Re: [TLS] Finished stuffing

2016-09-06 Thread David Benjamin
I think this is a good idea. It's kind of weird, but it avoids giving the early Finished such a strange relationship with the handshake transcript. Also a fan of doing away with multiple PSK identities if we don't need it. As a bonus, this removes the need to route a "phase" parameter into the

Re: [TLS] KeyUpdate and unbounded write obligations

2016-09-01 Thread David Benjamin
On Thu, Sep 1, 2016 at 5:29 PM Ilari Liusvaara wrote: > On Thu, Sep 01, 2016 at 02:20:02PM -0700, Eric Rescorla wrote: > > On Thu, Sep 1, 2016 at 2:09 PM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > I tried to implement this, and discovered an

  1   2   >