nging in situations where
there is cryptographic offloading to either a different process or a different
box. If we can come up with a reasonable solution to the resigning problem,
then relative time seems superior.
Cheers,
Subodh Iyengar
From: TLS [tls
erver config. Thus a compromise of a server config key should only affect the
initial data of clients who have cached a config modulo relative expiration
time.
Subodh Iyengar
From: TLS [tls-boun...@ietf.org] on behalf of Benjamin Kaduk [bka...@akamai.com]
Sent: Tu
ephemeral key does not
mean that the long term private key has been compromised like in ssl offloading
type scenarios.
Subodh Iyengar
From: TLS [tls-boun...@ietf.org] on behalf of Eric Rescorla [e...@rtfm.com]
Sent: Tuesday, February 23, 2016 11:42 PM
To: Watson
like tls ticket validity
time has better security properties for certain use cases like key offloading.
Nick's pull request limits the time clients can cache it to 7 days which is
reasonable middle ground and clients can decide to delete the ticket earlier.
I +1 the pull request.
Subo
Antoine and I were discussing draft-ietf-tls-certificate-compression over lunch
today and we think there could be a potential attack on the current scheme
which could be fixed with some changes.
Currently the CompressedCertificate is included in the handshake transcript..
However let's say a s
From: David Benjamin
Sent: Thursday, March 22, 2018 9:58:57 AM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re: [TLS] potential attack on TLS cert compression
To make sure I understand the issue, the concern is that your decompression
function provides a chunk-by-chunk interface, there's a b
Former and latter is a horrible way to refer to attacks :)
what I really meant is that when a receiver processing of timing of same TLS
record chunks triggers a bug in the decompressor.
Subodh
From: TLS on behalf of Subodh Iyengar
Sent: Thursday, March 22
I merged all of these changes into master since it looked like no-one seemed to
have strong opinions against them and they seemed like quite reasonable changes.
I'm about to cut a draft-02 with these changes if no-one has strong opinions
against. https://github.com/tlswg/tls-subcerts/
Subodh
We've been kicking this can down the road for a while, but we probably should
choose an OID for Delegated credentials
So far we've been doing interop with Cloudflare's OID of 1.3.6.1.4.1.44363.44.
I'd be fine with putting that as the final OID the draft. Does anyone have any
thoughts on wheth
Ya you're right here it is the DER-encoded SPKI and opaque
ASN.1_subjectPublicKeyInfo is the right way to go.
Thanks,
Subodh
From: TLS on behalf of Sean Turner
Sent: Thursday, August 9, 2018 11:34:17 AM
To: tls@ietf.org
Subject: [TLS] draft-ietf-tls-subcerts-
I brought up an alternate construction in BKK for
draft-wood-tls-external-psk-importer-00 which might have some potentially
better properties. I didn't get time to explain then, so here it is:
One issue I think with the current construction in the draft with external psk
is that if the client u
ubodh
From: Christopher Wood
Sent: Monday, November 5, 2018 6:56:57 PM
To: Subodh Iyengar
Cc:
Subject: Re: [TLS] draft-wood-tls-external-psk-importer-00
On Tue, Nov 6, 2018 at 12:56 AM Subodh Iyengar wrote:
>
> I brought up an alternate construction in BKK for
>
Thanks for bringing these up Watson
>The first is that a delegated credential is pinned to a particular
version of TLS. Unfortunately this means that the rollout of a new
version of TLS (which libraries consider that they can do on their
own) makes an existing set of delegated credentials unusabl
S] Version pinning and indicating the signing algorithm in
draft-ietf-tls-subcerts-02
On Wed, Jan 16, 2019, at 13:35, Subodh Iyengar wrote:
> Usually the negotiation happens during the processing of the client hello..
I don't think that the problem here is a code problem. It's an op
In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days. This had
several original motivations including reducing the time that a ticket is
reused (for privacy or PFS). Another major motivation for this was to limit the
exposure of servers that use keyless ssl like mechanisms, i.e.
?
That is not just limit it to the scope of the ticket but the entire TLS
session? That would be fine to by me, however might break some folks.
Subodh
From: Christopher Wood
Sent: Monday, January 28, 2019 9:57 PM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re:
ristopher Wood
Sent: Monday, January 28, 2019 10:13:36 PM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re: [TLS] ticket lifetimes
On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar wrote:
>
> > Since clients already store tickets, could they not also store the
> time of original ticket iss
nt in BoringSSL. 😊
Fantastic. Would it help to have an extension to set a lower bound on this
value, or just make it more painful?
Subodh
From: David Benjamin
Sent: Tuesday, January 29, 2019 1:02 PM
To: Nick Sullivan
Cc: Subodh Iyengar; tls@ietf.org
Subject: Re: [TL
e ticket lifetime.
Subodh
From: David Benjamin
Sent: Tuesday, January 29, 2019 2:52 PM
To: Subodh Iyengar
Cc: Nick Sullivan; tls@ietf.org
Subject: Re: [TLS] ticket lifetimes
On Tue, Jan 29, 2019 at 4:14 PM Subodh Iyengar
mailto:sub...@fb.com>> wrote:
> Wou
anuary 24, 2019 3:23 PM
To: Subodh Iyengar
Cc: Martin Thomson; tls@ietf.org
Subject: Re: [TLS] Version pinning and indicating the signing algorithm in
draft-ietf-tls-subcerts-02
I'm also fine with removing the field and would welcome a PR to that effect..
Putting in a version to protect a DC fro
Thanks for writing this up Nick. I support this change.
I think one interesting addition to this PR might be a discussion of what could
happen if you use the same DC as both a client and server. I suspect this is
what a lot of people might do in a datacenter environment and that this is safe
(
I do not entirely have context on for the requirements for something like that,
I would imagine that the requirements would be significantly different and
would need to be clearly defined. However, at a high level
I'm not sure using a DC would be different from a provider obtaining a
certificat
I think the discussion about not understanding the implications of
replayability is not correct. We are already in the situation where client data
is replayable. For example if a mobile app encounters an HTTP error, it will
probably retry the request throwing caution to the wind about replayabil
data. I'll link to
it in this thread once it's posted.
Subodh
From: Watson Ladd [watsonbl...@gmail.com]
Sent: Monday, March 14, 2016 11:19 AM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
On M
to prevent that
downgrade to TLS1.2 (apart from naming TLS 1.3 resources differently), however
once TLS1.3 is negotiated, the above things will prevent downgrade to TLS1.2.
Cheers,
Subodh Iyengar
___
TLS mailing list
TLS@ietf.org
https://www.ietf.o
__
From: Martin Thomson [martin.thom...@gmail.com]
Sent: Tuesday, March 29, 2016 6:29 PM
To: David Benjamin
Cc: Subodh Iyengar; tls@ietf.org
Subject: Re: [TLS] Tickets and cross protocol attacks
On 30 March 2016 at 05:00, David Benjamin wrote:
> On the server, OpenSSL alrea
rom using 0-RTT completely which would be sad.
Since 0-RTT DH is still under discussion, maybe we should revisit 0-RTT DH
client auth after that is decided?
Subodh Iyengar
From: TLS [tls-boun...@ietf.org] on behalf of Dan Harkins [dhark...@lounge.org]
Sent: Sunday,
With option (2) would the keys end up being independent anyway? I think we
might need to share the sequence number space between the handshake messages
and the application data messages to avoid truncation attacks. I might have
missed this, but was there a proposal to deal with sequence numbers
Was there a compelling reason to not just put the ticket age in the clear in
the CHLO field as @davidben alluded to before. It seems to make it much simpler
in general.
With support for multiple tickets the server could issue multiple tickets at
different times to make time correlation more dif
+1
Subodh
From: TLS [tls-boun...@ietf.org] on behalf of David Benjamin
[david...@chromium.org]
Sent: Saturday, July 09, 2016 11:49 AM
To: Salz, Rich; Eric Rescorla; tls@ietf.org
Subject: Re: [TLS] Issue 472: Remove non-closure warning alerts
On Sat, Jul 9, 2016 a
For people that currently use keyupdates or who are planning to use key
updates, which layer are you planning to trigger a key update? Would the TLS
implementation itself trigger the update or would the application trigger it?
For renegotation, I believe it was mostly triggered by the applicatio
Based on the comments during the last TLS WG meeting and the comments on the
list, we've revised and submitted a new version of delegated credentials
https://www.ietf.org/id/draft-rescorla-tls-subcerts-01.txt.
This has several salient changes from the previous version:
* We trimmed the fat in
Thanks for the comments Ben.
> We mentioned adding a NUL byte separator in the signature on the
> DelegatedCredential
Yup this is something we noticed during the hackathon interop that would
definitely be helpful in an implementation and we should change it to have
that. What we realized whe
Thanks for your question Brian.
The motivation behind delegated credentials is to create a more reasonable
deployment model for short lived credentials.
Even without delegated credentials service owners can request short lived
certificates from their certificate authorities and deploy them to t
> There is also an alternate world in which the TLS terminators should not have
> certificates/keys on them but it is okay to give them delegated credentials.
> Here, one benefit is clear: performance. But the attacker capabilities
> against which this is supposed to be useful/acceptable remai
solution.
Subodh
From: Stephen Farrell
Sent: Wednesday, April 5, 2017 12:30:31 PM
To: Subodh Iyengar; Simon Friedberger; tls@ietf.org; Richard Salz; Kaduk, Ben
Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts
I've no strong opinion f
+1 for adoption
@Russ there's some discussion about comparison with proxy certs in the current
draft.
Subodh
From: TLS on behalf of Russ Housley
Sent: Wednesday, April 12, 2017 2:37:28 PM
To: IETF TLS; IETF LURK
Subject: Re: [TLS] [Lurk] WG Call for adoption
37 matches
Mail list logo
