Salz, Rich | 28 Jul 01:11 2015

Our fearless leader

Sean, at the CFRG meeting last week, wasn't bothered at all when all the seats were taken.

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
David Benjamin | 29 Jul 00:30 2015

Re: Commentary on the client authentication presentation slides

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 <davidben <at> google.com> wrote:
On Fri, Jul 24, 2015 at 1:02 AM Andrei Popov <Andrei.Popov <at> microsoft.com> wrote:
Thanks for the detailed comments, Ilari.

Based on the discussion at the TLS WG meeting, I created a pull request: https://github.com/tlswg/tls13-spec/pull/209

> - Mechanism like proposed looks dangerous when combined with HTTP/2.
I believe the same issue already exists in HTTP/1 where multiple requests can be in flight at the same time.
The way we handle this in HTTP/1 is by having the server application query the HTTP stack for the client cred.
If there's no cred available, the HTTP stack triggers client authentication (and the server application waits until the client cred is provided so it can authorize the request).

The issue only exists in HTTP/1 if the client does pipelining. As far as I know, no current[*] major browser deploys HTTP pipelining by default. Chrome certainly doesn't.

[*] Wikipedia says Opera used to do it before they switched to Chromium?

Are you intending that this mechanism be enabled by default for HTTP/2 or would the prohibition against renego still apply? Without any way for the client to tie the CertificateRequest to the HTTP request that triggered it, this mechanism would have many of the same problems as renego as far as HTTP/2 is concerned. (I realize Microsoft has a draft floating around for a TLS_RENEG_PERMITTED HTTP/2 setting. The setting can control this too I suppose.)
 
> - Regarding last point about interleaving: Assuming the scheme works
  in 1RTT (and I see no reason for requiring more rounds), you can't
  prevent application_data transmission after certificate_request.
We discussed at the meeting that this restriction cannot be implemented.
Instead, a server may block the processing of any in-flight requests while waiting for the client to authenticate (if the server's architecture requires this).

This requires the server buffer arbitrarily many requests from the client, which seems poor. For renego-based mid-stream auth, I believe Apache httpd does not do this and will actually fail the connection on interleave. (But I've never tested this, just glanced at how they use OpenSSL, so I could be wrong.)

> - The certificate_types field in CertificateRequest is pretty much
  useless, since all supported algorithms are of signature type.
If the signature_algorithms extension officially becomes MTI, then perhaps we can discus getting rid of certificate_types in the CertificateRequest. Except we may want to use this field when we introduce new certificate types (e.g. something like IEEE1609 certs).

> - How does extension_values work? If multiple values for one
  OID are allowed, then the OID/value pair is repeated, once for
  each value?
Multiple values are DER-encoded per RFC that defines the OID that allows multiple values.
The idea here is to simply reuse the existing OID-parsing code. A TLS implementation (or certificate API) that recognizes the OID in the cert, already knows how to parse its representation. A TLS implementation (or certificate API) that does not recognize the OID in the cert will also skip this OID in the extension_values. In the degenerate case, an implementation may choose to skip all extension_values.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces <at> ietf.org] On Behalf Of Ilari Liusvaara
Sent: Monday, July 20, 2015 4:11 PM
To: tls <at> ietf.org
Subject: [TLS] Commentary on the client authentication presentation slides

Some commentary on client authentication slides (there is no linked draft nor other material yet).

- Mechanism like proposed looks dangerous when combined with HTTP/2.
  Multiplexed protocols are in general not safe to authenticate without
  application-layer signaling (which can be implicit via separate
  connections), especially if dealing with something like web
  environment.
- Regarding last point about interleaving: Assuming the scheme works
  in 1RTT (and I see no reason for requiring more rounds), you can't
  prevent application_data transmission after certificate_request.
  The best that can be done is to require the client to send all
  the authentication-related data in one go.
- The certificate_types field in CertificateRequest is pretty much
  useless, since all supported algorithms are of signature type.
- One can't just remove fields without breaking parse compatiblity,
  but adding field breaks parse compatiblity too, so removing
  field at the same time isn't a problem.
- How does extension_values work? If multiple values for one
  OID are allowed, then the OID/value pair is repeated, once for
  each value?



-Ilari

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hubert Kario | 28 Jul 17:41 2015
Picon

No cypher overlap (was: ban more old crap)

I see one possible problem with TLS1.3 not being a superset of TLS1.2.

Consider the following:
  Server which supports TLSv1.3 but is configured to accept only AES256 
ciphers.
  Client which advertises TLSv1.3, but no support for AES256-GCM. The client 
advertises also CBC ciphers (both AES128 and AES256) as it wants to be able
to connect to legacy servers too.

Should such a connection end up with TLS1.2 with AES-CBC ciphersuite, or 
should it be aborted?

I think we should go for continue connection with downgraded protocol, but 
explicitly say that it may not happen if the negotiated ciphersuite would be 
DES, RC4, export grade...

That would allow us to reiterate in the TLS1.3 spec that they are a big no-no, 
and that if you claim support for TLS1.3 you should never negotiate them with 
a similarly modern peer.
--

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Sean Turner | 27 Jul 16:26 2015

Fwd: Summary of today's discussion on server-side signing

All,

I asked ekr to write a brief summary of the server-side signing issue.  The summary provided matches the WG
consensus as judged by the chairs.  Please let us know if you object to the way forward by August 3rd.

J&S

Begin forwarded message:

> From: Eric Rescorla <ekr <at> rtfm.com>
> Subject: Summary of today's discussion on server-side signing
> Date: July 22, 2015 at 08:52:31 EDT
> To: Sean Turner <turners <at> ieca.com>
> 
> Sean,
> 
> Here's a summary of today's discussion on signing and KnownConfiguration.
> 
> SUMMARY
> The WG agreed that the server must sign whenever certificate authentication
> is used (even if the KnownConfiguration is used).
> 
> 
> BACKGROUND
> The current draft requires the server to send a Certificate/CertificateVerify
> whenever either:
> 
> (a) The KnownConfiguration option is not in use.
> (b) The server sends a ServerConfiguration
> 
> but it does not need to sign if the KnownConfiguration option is in
> use but no new ServerConfiguration is provided.  Several people (most
> recently Martin Thomson) have suggested that it would be simpler to
> just require the server to sign any time certificate-based
> authentication is in use. The penalty for this is an extra sign/verify,
> as shown in the following table:
> 
> Scenario                           Client                   Server
> ------------------------------------------------------------------
> 1-RTT                  1 (EC)DHE + Verify         1 (EC)DHE + Sign
> 
> 0-RTT (current,                 2 (EC)DHE                2 (EC)DHE
>   no new config) 
> 
> 0-RTT (current,        2 (EC)DHE + Verify         2 (EC)DHE + Sign
>   new config)
> 
> 0-RTT (proposed)       2 (EC)DHE + Verify         2 (EC)DHE + Sign
> 
> 
> So, the performance difference here is between line 2 and line 4,
> since whenever you provide a new config (line 3) you have to sign
> anyway. The benefit is that it makes the server side of the handshake
> essentially identical in both 0-RTT and 1-RTT, which is nice from an
> implementation and analysis perspective.
> 
> 
> SUMMARY OF WG DISCUSSION
> During the WG discussion today, there was rough consensus to adopt
> this change (i.e., always sign). A number of arguments were advanced
> in favor of this change.
> 
> (1) It's significantly simpler for implementors and (at least informal)
>     analysis. A side benefit is being able to merge the extension
>     logic for 0-RTT and KnownConfiguration, since KnownConfiguration
>     is only useful with 0-RTT.
>     
> (2) It extends the properties we were shooting for with online-only
>     signatures and requiring that the server always sign ServerConfiguration,
>     namely continuous proof of access to the signing key.
> 
> (3) The performance cost of an extra ECDSA signature is small and
>     shrinking fast (per Ian Swett channelling Adam Langley), and
>     people who care about speed will cut over to ECDSA (certs are
>     readily available).
> 
> (4) You can still do 0-RTT with PSK resumption, which is computationally
>     much faster.
> 
> On balance the WG seemed to feel that these were more compelling than
> the performance value of the optimization.
> 
> There was also a recognition that signature amortization was valuable,
> but the consensus was that instead of doing this here, it would be
> better to adopt Hugo's suggeston from a while back to have a
> certificate extension that allowed offline signatures. This allows
> both amortization *and* delegation, while not constituting a threat
> to existing TLS 1.2 implementations. We agreed that this could be
> worked in in parallel but shouldn't hold up TLS 1.3.
> 
> Per WG guidance, I'll be preparing a draft PR for this.
> 
> -Ekr
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
Dave Garrett | 25 Jul 20:53 2015
Picon

0-RTT & resumption

I'm pretty sure some/all of this was likely mentioned elsewhere, but I don't see any discussion on-list.
(it was mentioned in part of the IETF 93 recording I watched as this whole topic needing to go to the list, as
well) There's also related TODOs in the draft on this topic. Here's a start to this discussion.

Basically, there's two modes with similar use-cases in TLS 1.3 now: 0-RTT connections using the known
configuration extension & PSK-based session resumption. I don't think their roles are well defined yet.

1) There is no 0-RTT resumption. The point of resumption is to get back into the session quick, but it's
arguably slower than not doing it, currently.

0-RTT can do first flight (repeatable) requests:
https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.3
but PSK-based resumption needs 1-RTT:
https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.4

2) There's not yet specifics on what cipher suite to use for PSK-based resumption. I don't see a point in
doing PSK-based resumption with anything other than plain PSK, with no PFS (no (EC)DHE). If you're
willing to do the extra work for DH, just go straight to normal 0-RTT to get more benefit/flexibility with a
similar amount of work. The goal is really to get forward secrecy on the session, not necessarily every
single connection within it. (not that it wouldn't be nice) As long as the resumption is within a
reasonably short window (e.g. few minutes), not doing another DH is fine. After this window, normal 0-RTT
should be the preferred route.

3) Just to state the obvious: If a client is going to do PSK resumption with a non-PFS suite, it needs to offer a
non-PFS suite. Even if it's not really going to be negotiated for anything else, I don't really like the
feel of this. I think it'd also be cleaner if the offered suites didn't have to change for resumption. One
idea would be to rename the groups extension, again, to "supported_key_shares" and mark point 0 (or some
other if we want to leave 0) as PSK-resumption, specifically. (_not_ general PSK) A resumption PSK offer
could then be listed in the ClientKeyShare like any other, and negotiation of it could side-step the need
to pick a new cipher. Mixing it in with regular PSK complicates things a bit and has an expectation of
needing to offer a PSK suite with the PSK extension. In
  this case, it'd just be the previously used suite. 0-RTT becomes a little more straightforward: give both
short-term resumption via PSK and mid-term semi-static secret 0-RTT clear expiration dates,
  then the first flight data is just encrypted using whatever is still valid. Worst case scenario is the
server ditched the session early and it falls back to 1-RTT. (double-encrypting early data might work,
but would be ugly) This sort of re-separates PSK & resumption a little bit, though the handling is still similar.

4) Related issue: maybe define a generic KeyShare struct (group+key_exchange), simplify the few spots to
use these, then allow ServerConfiguration to offer a vector of KeyShares? Alternatively, just have one
KeyShare in there and offer a vector of ServerConfiguration in the message so each has an expiration date.
If we want the possibility of ServerConfiguration being obtainable through alternate means, then it
might help for a server to be able to offer two keys with different curves to make support easier to offer.
(e.g. P-256 & Curve25519, as we may be transitioning this way for a bit; could be ECC & PQ of some kind, in the
future) This might make constructing a 0-RTT first-connect system a little easier.

Not a solid proposal, really; just some discussion on the topic.

Dave
Martin Thomson | 25 Jul 16:59 2015
Picon

Review of PR #209

Andrei proposes two changes in https://github.com/tlswg/tls13-spec/pull/209

The first expands the ways in which a server can identify
certificates.  This is fine.  I do wonder whether we can remove
CertificateType entirely for TLS 1.3 though (that can be done
separately).

The second is worrisome.  I don't like that a handshake message now
has two different potential locations that it might appear in.  That
seems like a hazard.  I think that we need a new content type for a
new message that can be used after the handshake completes.  Then
there are two options:
 a) remove CertificateRequest from the handshake entirely and allow
the handshake to complete before authenticating (this has a number of
hazards that make it probably worse than the duplication it addresses)
 b) use CertificateRequest within the handshake, and the new content
type outside of it
John Mattsson | 25 Jul 11:28 2015
Picon

Re: New Version Notification for draft-mattsson-tls-ecdhe-psk-aead-02.txt

Thanks for the good comments during the meeting. This new version should
take care of them all:

- Updated the PRF and ECC curves for the AES-256 cipher suites.
- Included SHA_256 and SHA_384 in the cipher suite names.
- Made it clear which security considerations that apply. For the PSK
aspects, I made a short summary.

I also made the following changes:

- Fixed a wrong reference to the ECC TLS RFC.
- Added missing reference to AEAD_AES_128_CCM_8
- Divided the references into Normative and Informal

How do we proceed with this now? From my point of view the draft is more
or less done, and I do not see much work needed from the tls wg.

(As a note, this draft would not have been needed with an a la carte
system). 

Cheers,
John

On 25/07/15 10:36, "internet-drafts <at> ietf.org" <internet-drafts <at> ietf.org>
wrote:

>
>A new version of I-D, draft-mattsson-tls-ecdhe-psk-aead-02.txt
>has been successfully submitted by John Mattsson and posted to the
>IETF repository.
>
>Name:		draft-mattsson-tls-ecdhe-psk-aead
>Revision:	02
>Title:		ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport
>Layer Security (TLS)
>Document date:	2015-07-24
>Group:		Individual Submission
>Pages:		6
>URL:            
>https://www.ietf.org/internet-drafts/draft-mattsson-tls-ecdhe-psk-aead-02.
>txt
>Status:         
>https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/
>Htmlized:       
>https://tools.ietf.org/html/draft-mattsson-tls-ecdhe-psk-aead-02
>Diff:           
>https://www.ietf.org/rfcdiff?url2=draft-mattsson-tls-ecdhe-psk-aead-02
>
>Abstract:
>   This memo defines several new cipher suites for the Transport Layer
>   Security (TLS) protocol.  The cipher suites are all based on the
>   Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
>   (ECDHE_PSK) key exchange together with the Authenticated Encryption
>   with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
>   provides light and efficient authentication, ECDHE provides perfect
>   forward secrecy, and AES-GCM and AES-CCM provides encryption and
>   integrity protection.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>
Dave Garrett | 23 Jul 03:39 2015
Picon

new error alerts?

Hubert Kairo found quite a few more spots in need of explicit error designations, which have been amended
into PR #201.
https://github.com/tlswg/tls13-spec/pull/201

I just noticed one error in the current draft text that was wrong and added a fix for that as well. The Server
Hello section said that lack of acceptable group would result in an "insufficient_security" error,
which is incorrect. That error is clearly defined to be for lack of acceptable cipher suite. The
Negotiated Groups section says lack of acceptable group is a “handshake_failure” error. I changed
the text to state the error for suites, as the other is already noted elsewhere. (this change is now in PR
#201) This brings up a problem, however: there is no distinct error for lack of group support. The
“handshake_failure” is a bit of a catchall, so there's no way for a client to really know what's wrong
if this happens. This is also why I don't want to change the definition of the "insufficient_security"
error. Clients rely on these being relatively precise in order to show error messages that are hopefully
meaningful enough to get them fixed. As such, I'd like to propose adding a new error just for this and
renaming the old one to focus precisely on its long defined meaning. While we're at it, a failure of client
authentication doesn't have its own error alert code either.

  enum {
       handshake_failure(40),
       unsupported_cipher_suites(71),  /* formerly insufficient_security */
       unsupported_dh_groups(72),  /* new */
       client_authentication_failure(73),  /* new */
       (255)
   } AlertDescription;

Pretty straightforward. Are there any other errors that can't be clearly identified by the returned code?
Debugging shouldn't be guesswork. ;)

Dave
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Dave Garrett | 22 Jul 22:10 2015
Picon

A la carte concerns from IETF 93

Consensus was my current WIP proposal is not viable, for some of the following main reasons:

1) cost/benefit analysis doesn't seem to be worth it
2) backwards compatibility handling
3) some argue harder to implement; others argue easier

To start, I'll note that I have not submitted a PR yet.

This is all currently just on a WIP branch on GitHub to be easier to discuss specifics on-list. It's based on
PR #201, but that's just to make keeping track of things easier. This is less of an issue now that my other PRs
were merged (namely the updated cipher suite section).

I'll switch to a standalone proposal for the next draft instead of editing the section inline, as it was
indicated that would be easier to follow. Not everyone was a party to every discussion on-list about these
topics, so a better summary is needed.

On to the concerns:

1) The cost/benefit analysis is a very important concern. If you're only analyzing this from a perspective
of combinatorial explosion reduction, then I actually agree it's not worth the cost. Here's how I
perceive it, currently:

benefit:
+ reduction in combinatorial mess (primarily achieved as we move forward, as back compat still needs to
offer some old)
+ single point of negotiation for (EC)DHE
+ single point of negotiation for certificates (seemed to be wide agreement to do this regardless of full a
la carte)
+ deprecation of existing DHE suites which risk wanting weak groups depending on server and are an interop
hazard due to Java being crap
+ ECC is always an option, regardless of suite offer/selection
+ FFDHE doesn't need new suites to be offered by clients not offering DHE AEAD at the moment
+ missing combinations are no longer an interop failure

cost:
- change has risks of mistake at various points (implementation, deployment, admin, client config, etc.)
- support for TLS 1.2 + 1.3 results in a mix; old suites still need to be offered
- risk of confusion due to change in behavior (point #2 above)

depends:
+/- point #4, depending on implementation

(the number of points in this list is not indicative of weight; the first cost could outweigh all benefits,
depending on perspective)

Additionally mentioned cost:
- cannot specify exact combinations; some might not be desirable

However, I set this one aside because it's a problem with a full a la carte proposal, but not my current one.
All possible combinations of DHE/ECDHE+RSA/DSS/ECDSA/PSK/anon+cipher_hash are already considered
valid, and generally have their own suite assignments. I'm not suggesting breaking up cipher_hash.
Cert/PSK/anon still have to have separate suites in this system, which prohibits wrong stuff like
none_anon (lack of DH from plain PSK + anon). If we ditch suites entirely, as was suggested by others, then
this is a risk that comes up.

The main difference in my calculus vs. others is that:
a) I'm swayed by Tony Arcieri's argument that DHE, as it currently exists, needs to be scrapped. Old Java
chokes on it and there is a risk of servers negotiating weak groups when offering it. Deprecating all DHE
suites is an interop and security win. FFDHE is still around, but now with only strong groups, whereas
without this proposal we go ECC or bust (until something post-quantum is a viable option here).
b) ECC isn't separate anymore; it's always expected to be available. We don't have to worry about endpoints
actually offering suites that claim support, as it's just a given now.
c) Interop failure due to missing suites, regardless of algorithm support, is no longer a risk. It's
currently possible to negotiate CBC because the GCM suites offered by the server are combinations not
supported by the client, even though GCM is supported. (this does happen in the real world and is too often
overlooked in this discussion)

2) Backwards compatibility is pretty straightforward.

Here's what Firefox currently offers, minus RC4 & 3DES:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA

The current TLS 1.3 draft would only accept the top two as viable (only AEAD). Both my current proposal and
the general consensus minimum would pick just the top one and pick certs based on the extension.

Note that DHE/FFDHE is available, but only for AES CBC with RSA. The second change here is that my proposal
allows DHE with no changes to this list. Yeah, we'd like to move to an ECC only world, but I'm paranoid and
want a backup. This gives it effortlessly. This would also permit FFDHE+ECDSA combinations without new
suites. All DHE suites could be dropped in the future, in favor of ECDHE only on old TLS but the possibility
of FFDHE on new. If you want to keep around FFDHE without this proposal, you need to add those suites for GCM.

Just to make sure it's emphasized, the current path without this proposal would require Firefox add the
following in order to use the new FFDHE groups:
TLS_DHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Mozilla probably doesn't want to do that. Negotiating the new FFDHE groups might be acceptable, but
whatever weaker junk you get without them is not. I guess a higher minimum could be put in place for AEAD
suites or TLS 1.3+, but now we're already adding complexity.

Once we get out of the AES monoculture, it's also the difference between adding:
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
TLS_DHE_RSA_WITH_CHACHA20_POLY1305
TLS_DHE_ECDSA_WITH_CHACHA20_POLY1305
or just:
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305

I'll also add that DHE_ECDSA suites just aren't defined. Yes, using the cert extension could let us get this
combo via DHE_RSA, but that means offering RSA suites for everything old and new.

As to the need to list all this stuff to work:
If you want everything to be clean, abandon TLS and go for something QUIC based. Backwards compatibility is
messy; that's one of the reasons why you shouldn't want it forever.

3) I argue that framing the negotiation in a manner more similar to what is actually being negotiated
reduces the risk of problems. _Not_ doing so has the following issues:

a) Offering an ECDHE suite will offer FFDHE groups via the upgraded extension, but no ability for a server to
pick it if the right combo for DHE isn't there. The server can't select the 4k FF group if it'd rather have
that than P-256 because no better curve is available.
b) ECHDE/DHE has to be chosen based on cipher suite priority, rather than actually looking at the groups'
priority and picking the one that should be preferred. Contrary to suite definitions, ECDHE and DHE are
not monolithic things.
c) The server should be able to offer any certs the client can use, regardless of connection encryption.
(again, this part seems to have wide agreement)

---

That covers the main issues. There's also the issue of making sure that any new system is understandable and
doesn't introduce points of confusion down the road.

I don't claim that this addresses everything that has been or can be said, but I also don't want to post a
larger wall of text than this. ;)

Also, others may likely not care about FFDHE as much as I do. It is, however, in the current draft on
essentially equal footing with ECC. As such, I'm considering it that way in discussion and proposals.
This proposal is shaped by the negotiated FF-DH draft and its integration into the current TLS 1.3 draft.

Dave
Blake Matheny | 22 Jul 21:55 2015

Relative vs absolute ServerConfiguration.expiration_date

One of the topics of discussion at the WG discussion was whether ServerConfiguration.expiration_date
should be an absolute or relative value. Subodh (CC) dug into our production data and found that nearly
half of the TLS errors we see in production (end user to edge/origin) are due to date mismatch. This often
occurs when people intentionally reset the clock on their phone, or for other various reasons.

Due to the high rate of date mismatch errors we see, my preference would be that
ServerConfiguration.expiration_date be a relative value instead of an absolute one. This provides the
client an opportunity to correctly use a monotonic (or other similar) clock to minimizing exposure,
without losing the value of the ServerConfiguration. Using an absolute value means that
ServerConfiguration, for clients with invalid clocks, would essentially never be cacheable. These
clients wouldn’t benefit from ServerConfiguration.

Thoughts or feedback?

-Blake
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Meetecho Team | 22 Jul 18:58 2015

Meetecho recordings of TLS 2nd WG session

Dear all,

the full recording (synchronized video, audio, slides and jabber room) of the 
TLS 2nd WG session at IETF 93 is available at the following URL:
http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#TLS_II

In case of problems with the playout, just drop an e-mail to ietf-support <at> meetecho.com.

For the chair(s): please feel free to put the link to the recording in the minutes,
if you think this might be useful.

Cheers,
the Meetecho Team

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls

Gmane