On Tue, May 02, 2017 at 07:44:35AM -0700, Colm MacCárthaigh wrote:
> On Sunday at the TLS:DIV workshop I presented a summary of findings of a
> security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n.
> Thanks to feedback in the room I've now tightened up the findings from the
>
Hi,
Oops, I missed your email. the version 03 has been submitted. For some reason
my email address is not in the database, so it has to be confirmed by someone
else or the secretariat.
Yours,
Daniel
From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
Sent: Tuesday, May 02, 2017 7
On Tuesday, 11 April 2017 15:09:04 CEST Sean Turner wrote:
> All,
>
> draft-ietf-tls-rfc4492bis has been revised since it left the WG and we agree
> with Yoav’s statement at the mic in Chicago that the WG should review the
> changes before we ask Kathleen (our newly appointed AD) to continue
> pro
I haven't approved it yet as I noticed there was no response (that I saw) to
Alexey's comment and no change in the draft as a result of his comments.
I'll wait in responses for these 2 items.
Thank you,
Kathleen
Sent from my iPhone
> On May 4, 2017, at 8:41 AM, Hubert Kario wrote:
>
>> On T
Hi all!
Apologies for the odd and potentially silly question. GSMA are working on
future SIM specifications which use TLS and previously included the
trusted_ca_keys to allow a client to inform a server which particular key(s)
from a CA it is supporting. In TLS 1.3 the ‘trusted_ca_keys’ extensi
On Thu, May 04, 2017 at 01:26:02PM +, Natasha Rooney wrote:
>
> GSMA are working on future SIM specifications which use TLS and
> previously included the trusted_ca_keys to allow a client to
> inform a server which particular key(s) from a CA it is
> supporting. In TLS 1.3 the ‘trusted_ca_keys
> The certificate should have its own DN, use that.
She's saying that it *doesn't.*
SubjectDN is not unique. IssuerDN/Serial is unique, but this extension use
that.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.
Title : ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for
Transport Layer Security (TLS)
Authors : John Matt
Salz, Rich wrote:
>
>> The certificate should have its own DN, use that.
>
> She's saying that it *doesn't.*
>
> SubjectDN is not unique. IssuerDN/Serial is unique, but this extension use
> that.
SubjectDN of a *Certificate Authority* **MUST** be unique.
There is some wording in PKIX and X.50
> On May 4, 2017, at 08:41, Hubert Kario wrote:
>
> On Tuesday, 11 April 2017 15:09:04 CEST Sean Turner wrote:
>> All,
>>
>> draft-ietf-tls-rfc4492bis has been revised since it left the WG and we agree
>> with Yoav’s statement at the mic in Chicago that the WG should review the
>> changes befor
> There is some wording in PKIX and X.509 which creates the impression that a
> CA could be re-using the same Subject DName with different keys, but such
> an interpretation is a formally provable defect of the PKIX specification.
Any links you can point to?
I don't see how CA1 issuing a sub-ca f
On Thu, May 04, 2017 at 02:58:07PM +, Salz, Rich wrote:
> > There is some wording in PKIX and X.509 which creates the impression
> > that a CA could be re-using the same Subject DName with different keys,
> > but such an interpretation is a formally provable defect of the PKIX
> > specification
Salz, Rich wrote:
[ Charset windows-1252 unsupported, converting... ]
> > There is some wording in PKIX and X.509 which creates the impression that a
> > CA could be re-using the same Subject DName with different keys, but such
> > an interpretation is a formally provable defect of the PKIX specifi
> The organization info (O, L, ST, C, etc...) is supposed to differ in that
> case (CN
> is just one field of DN), rendering the full DNs distinct.
But where and how is that enforced, or enforceable? Again, any links to show
I'm wrong?
___
TLS mailing
> If re-using the same CA DName for certs with different keys would be
> allowed, then chain building and chain verifying would become
> *DESPERATELY* dependent on support *AND* use of
> AuthorityKeyIdentifier->SubjectKeyIdentifier.
Or, it could use subject/issuer. Or it could try all the matchin
> On May 4, 2017, at 10:58 AM, Salz, Rich wrote:
>
> I don't see how CA1 issuing a sub-ca for "... CN=fred" can globally prevent
> CA2 from issuing a sub-ca with the exact same DN. Can you explain what I am
> missing?
You forgot that all the CA certificates are of course published in the glob
Salz, Rich wrote:
[ Charset UTF-8 unsupported, converting... ]
> > The organization info (O, L, ST, C, etc...) is supposed to differ in that
> > case (CN
> > is just one field of DN), rendering the full DNs distinct.
>
> But where and how is that enforced, or enforceable? Again, any links to sho
Feel better Jason!
-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich
Sent: Thursday, May 4, 2017 10:58 AM
To: m...@sap.com
Cc: Natasha Rooney ; tls@ietf.org
Subject: Re: [TLS] trusted_ca_keys
> There is some wording in PKIX and X.509 which creates the im
The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
Security (TLS)'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
f
IMHO what we have is a facility in TLS 1.3 that:
1. Requires extraordinary effort on the server side to mitigate replay (for all
but the smallest deployments);
2. Offers no way for the client to determine whether the server is mitigating
replay (before replay becomes possible);
3. Is trivial to e
> On 4 May 2017, at 16:09, Kathleen Moriarty
> wrote:
>
> I haven't approved it yet as I noticed there was no response (that I saw) to
> Alexey's comment and no change in the draft as a result of his comments.
You mean these comments?
https://mailarchive.ietf.org/arch/msg/tls/MFs8aGEZsr-1P7o
On Thu, May 4, 2017 at 10:07 AM, Andrei Popov
wrote:
> IMHO what we have is a facility in TLS 1.3 that:
> 1. Requires extraordinary effort on the server side to mitigate replay
> (for all but the smallest deployments);
> 2. Offers no way for the client to determine whether the server is
> mitigat
* I don't think we'll have a problem implementing a single use cache,
strike register, we have similar systems for other services, at higher volumes.
… and these things work across geographically distributed datacenters, without
negating the latency benefits of 0-RTT?
Cheers,
Andrei
___
On Thu, May 4, 2017 at 11:22 AM, Andrei Popov
wrote:
>
>- I don't think we'll have a problem implementing a single use cache,
>strike register, we have similar systems for other services, at higher
>volumes.
>
> … and these things work across geographically distributed datacenters,
>
* Providers already work hard to maximize user affinity to a data center
for other operational reasons; re-routing is relatively rare and quickly
repaired by issuing a new ticket.
Understood, but isn’t an attacker going to be able to re-route at will?
_
On Thu, May 4, 2017 at 11:29 AM, Andrei Popov
wrote:
>
>- Providers already work hard to maximize user affinity to a data
>center for other operational reasons; re-routing is relatively rare and
>quickly repaired by issuing a new ticket.
>
> Understood, but isn’t an attacker going to
Indeed, as long as the scope of the ticket <= scope of the nonce database, it
appears that rerouting wont’ help the attacker.
From: Colm MacCárthaigh [mailto:c...@allcosts.net]
Sent: Thursday, May 4, 2017 11:33 AM
To: Andrei Popov
Cc: Ilari Liusvaara ; tls@ietf.org
Subject: Re: [TLS] Security rev
On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote:
>
> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> both session-cache and strike register styles and the merits of each.
>
I don't believe this is technically viable for the large-scale server
operators most interes
On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote:
> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote:
> > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> > both session-cache and strike register styles and the merits of each.
The SHOULD should say that the
On 05/04/2017 02:39 PM, Nico Williams wrote:
> On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote:
>> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote:
>>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>>> both session-cache and strike register styles and the
On Thu, May 04, 2017 at 02:44:06PM -0500, Benjamin Kaduk wrote:
> On 05/04/2017 02:39 PM, Nico Williams wrote:
> > On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote:
> >> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote:
> >>> 1. A SHOULD-level requirement for server-side 0-RTT defen
On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote:
> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote:
>
> >
> > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> > both session-cache and strike register styles and the merits of each.
> >
> Many of the discu
Yoav,
On Thu, May 4, 2017 at 1:59 PM, Yoav Nir wrote:
>
> On 4 May 2017, at 16:09, Kathleen Moriarty
> wrote:
>
> I haven't approved it yet as I noticed there was no response (that I saw) to
> Alexey's comment and no change in the draft as a result of his comments.
>
>
>
> You mean these comment
On Thu, May 04, 2017 at 11:01:02PM +0300, Ilari Liusvaara wrote:
> On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote:
> > On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote:
> > > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> > > both session-cache and strik
On Thu, May 04, 2017 at 02:49:20PM -0500, Nico Williams wrote:
> On Thu, May 04, 2017 at 02:44:06PM -0500, Benjamin Kaduk wrote:
> > On 05/04/2017 02:39 PM, Nico Williams wrote:
> > > The SHOULD should say that the server-side needs to apply a replay cache
> > > OR fallback onto a full exchange whe
On Thu, May 4, 2017 at 12:39 PM, Nico Williams
wrote:
> The SHOULD should say that the server-side needs to apply a replay cache
> OR fallback onto a full exchange when the 0-rtt data payload involves a
> non-idempotent operation.
>
I don't mean to be dismissive with this but TLS stands for "Tra
On Thu, May 4, 2017 at 12:12 PM, Erik Nygren wrote:
> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla wrote:
>
>>
>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>> both session-cache and strike register styles and the merits of each.
>>
>
> I don't believe this is tech
On Thu, May 04, 2017 at 01:21:43PM -0700, Colm MacCárthaigh wrote:
> On Thu, May 4, 2017 at 12:39 PM, Nico Williams
> wrote:
> > The SHOULD should say that the server-side needs to apply a replay cache
> > OR fallback onto a full exchange when the 0-rtt data payload involves a
> > non-idempotent o
As promised:
https://github.com/tlswg/tls13-spec/pull/1005
Note: I may have to do a little post-landing cleanup, but I wanted to get
people's senses of the text ASAP.
Comments welcome.
-Ekr
On Wed, May 3, 2017 at 8:21 PM, Eric Rescorla wrote:
>
>
> On Wed, May 3, 2017 at 8:20 PM, Colm MacCárt
> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining both
> session-cache and strike register styles and the merits of each.
First, a point of clarification, I think two issues have been conflated in this
long thread:
1) Servers rejecting replayed 0-RTT data (using a single
On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz wrote:
> > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> both session-cache and strike register styles and the merits of each.
>
>
>
> First, a point of clarification, I think two issues have been conflated in
> this long th
On Thu, May 04, 2017 at 02:37:20PM -0700, Eric Rescorla wrote:
> On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz wrote:
> > [...]
>
> I think this is basically right. In the PR I just posted, I spent most of
> my time describing the
> mechanisms and used a SHOULD-level requirement to do one of the m
Nits:
RFC 4279 reference is missing.
"TLS 1.3 and above version, " should probably be "TLS 1.3 and above" or
"TLS 1.3 and higher versions"
On 04/05/17 18:41, The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG
> (tls) to consider the following
On Thu, May 4, 2017 at 5:37 PM, Eric Rescorla wrote:
>
>
>
> On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz wrote:
>
>> > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>> both session-cache and strike register styles and the merits of each.
>>
>>
>>
>> First, a point of c
On Thu, May 4, 2017 at 3:00 PM, Erik Nygren wrote:
> On Thu, May 4, 2017 at 5:37 PM, Eric Rescorla wrote:
>
>>
>>
>>
>> On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz wrote:
>>
>>> > 1. A SHOULD-level requirement for server-side 0-RTT defense,
>>> explaining both session-cache and strike register
Yep, I think your PR is in the right direction.
> I have been basically assuming that you can't really do TLS without a
> real-time clock, but maybe that's wrong?
Well, it’s possible, although I do not know if anyone actually does (and of
course certificate validation would be a little challeng
Sure, those are fine weasel words. But do we really want to allow into this
protocol something that can be misused with security implications in a protocol
that’s attempting to solve a security problem? I really don’t know. I’m
inclined to say, ‘no’ though. For all those same reasons that IP
On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz wrote:
>
> There are definitely cases (i.e. application profiles) where this should
> be done. I think a general case HTTPS server is one. But I don’t think this
> is strictly necessary across the board (for every application using 0-RTT
> at all). DNS
Dear all,
Applications have always had to deal with the occasional replay,
whether from an impatient user or a broken connection at exactly the
wrong time. But they've generally been rare, so human-in-the-loop
responses work. Order the same book twice? Just return one of them,
and if you get an ov
> On May 4, 2017, at 5:35 PM, Watson Ladd wrote:
>
> 0-RTT is opt-in per protocol
…and at the end of the day, that’s the only reason I’d agree to this.
Derrell
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Thu, May 4, 2017 at 4:35 PM, Watson Ladd wrote:
> Dear all,
>
> Applications have always had to deal with the occasional replay,
> whether from an impatient user or a broken connection at exactly the
> wrong time.
Unfortunately this isn't the case :( Not all applications are user-driven
in t
On Thu, May 04, 2017 at 04:35:10PM -0700, Watson Ladd wrote:
> 0-RTT is opt-in per protocol, and what we think of per application.
Yes.
> But it isn't opt-in for web application developers. Once browsers and
> servers start shipping, 0-RTT will turn on by accident or deliberately
> at various pla
On Thu, May 4, 2017 at 4:58 PM, Nico Williams wrote:
> On Thu, May 04, 2017 at 04:35:10PM -0700, Watson Ladd wrote:
>> 0-RTT is opt-in per protocol, and what we think of per application.
>
> Yes.
>
>> But it isn't opt-in for web application developers. Once browsers and
>> servers start shipping,
On Thu, May 4, 2017 at 8:18 PM, Watson Ladd wrote:
> >
> > It should be up to servers whether a request is allowed with 0-rtt.
>
> Which server? It's possible that the backhauls from the server the
> TLS connection is made to to the server actually responding to the
> request do not distinguish
On May 4, 2017, at 19:35, Watson Ladd wrote:
>
> Dear all,
>
> Applications have always had to deal with the occasional replay,
> whether from an impatient user or a broken connection at exactly the
> wrong time. But they've generally been rare, so human-in-the-loop
> responses work. Order the s
On Thu, May 04, 2017 at 05:18:32PM -0700, Watson Ladd wrote:
> On Thu, May 4, 2017 at 4:58 PM, Nico Williams wrote:
> > On Thu, May 04, 2017 at 04:35:10PM -0700, Watson Ladd wrote:
> >> 0-RTT is opt-in per protocol, and what we think of per application.
> >
> > Yes.
> >
> >> But it isn't opt-in fo
5/04/2017 10:36 PM, Nico Williams wrote:
> On Thu, May 04, 2017 at 05:18:32PM -0700, Watson Ladd wrote:
>>
>> Which server? It's possible that the backhauls from the server the
>> TLS connection is made to to the server actually responding to the
>> request do not distinguish 0-RTT from other data
On 05/04/2017 07:18 PM, Watson Ladd wrote:
> On Thu, May 4, 2017 at 4:58 PM, Nico Williams wrote:
>>
>> In particular there has to be a way, either in-TLS, or at the
>> application layer, to force an extra round-trip to confirm that the
>> 0-rtt data was not an unintended replay.
> One can always
On 05/04/2017 06:35 PM, Watson Ladd wrote:
> If you are willing to buffer 0-RTT until completion before going to
> the thing that makes the response, you can handle this problem for the
> responsemaker. This will work for most applications I can think of,
> and you need to handle large, drawn out r
On Thu, May 04, 2017 at 11:11:29PM -0500, Benjamin Kaduk wrote:
> 5/04/2017 10:36 PM, Nico Williams wrote:
> > On Thu, May 04, 2017 at 05:18:32PM -0700, Watson Ladd wrote:
> >>
> >> Which server? It's possible that the backhauls from the server the
> >> TLS connection is made to to the server actu
On Thu, May 04, 2017 at 11:14:01PM -0500, Benjamin Kaduk wrote:
> On 05/04/2017 07:18 PM, Watson Ladd wrote:
> > On Thu, May 4, 2017 at 4:58 PM, Nico Williams wrote:
> >> In particular there has to be a way, either in-TLS, or at the
> >> application layer, to force an extra round-trip to confirm t
On 05/04/2017 11:52 PM, Nico Williams wrote:
> On Thu, May 04, 2017 at 11:11:29PM -0500, Benjamin Kaduk wrote:
>> 5/04/2017 10:36 PM, Nico Williams wrote:
>>> On Thu, May 04, 2017 at 05:18:32PM -0700, Watson Ladd wrote:
Which server? It's possible that the backhauls from the server the
T
On Thu, May 04, 2017 at 11:22:47PM -0500, Benjamin Kaduk wrote:
> On 05/04/2017 06:35 PM, Watson Ladd wrote:
> > If you are willing to buffer 0-RTT until completion before going to
> > the thing that makes the response, you can handle this problem for the
> > responsemaker. This will work for most
Trying to consolidate various things into a single mail...
On 05/04/2017 04:37 PM, Eric Rescorla wrote:
> In the PR I just posted, I spent most of my time describing the
> mechanisms and used a SHOULD-level requirement to do one of the
> mechanisms.
> I think there's a bunch of room to wordsmith t
On Thu, May 4, 2017 at 10:07 PM, Benjamin Kaduk wrote:
> Trying to consolidate various things into a single mail...
>
> On 05/04/2017 04:37 PM, Eric Rescorla wrote:
>
> In the PR I just posted, I spent most of my time describing the
> mechanisms and used a SHOULD-level requirement to do one of th
On 05/05/2017 12:04 AM, Nico Williams wrote:
> On Thu, May 04, 2017 at 11:22:47PM -0500, Benjamin Kaduk wrote:
>> On 05/04/2017 06:35 PM, Watson Ladd wrote:
>>> If you are willing to buffer 0-RTT until completion before going to
>>> the thing that makes the response, you can handle this problem for
66 matches
Mail list logo
