Of course, PKG should be protected tightly, which is normally equipped with
HSM.
On the other hand, this risk is not unique to PKG. Same risk and security
requirements apply to CA's certificate signing key.
In fact, PKG's key generation process is exactly a signing process with
master key signing
That was FAST.
Looks good.
From: Yoav Nir
Date: Monday, March 25, 2019 at 10:10 PM
To: "tls@ietf.org"
Subject: [TLS] A flags extension
Hi. Today at the TLS meeting, there was a discussion at the mic about 1-bit
extensions that only serve to indicate support for an optional feature. EKR
Thanks for the review. I will address these comments promptly, but it might
not be until next week.
Russ
> On Mar 25, 2019, at 5:08 PM, Yoav Nir wrote:
>
> Hi.
>
> I’ve read this draft. For the most part it seems fine, but I have a few
> editorial nits:
>
>
> Abstract:
> I realize that
Hi. Today at the TLS meeting, there was a discussion at the mic about 1-bit
extensions that only serve to indicate support for an optional feature. EKR
commented that such extensions take 4 bytes each and that maybe we need to
replace them with a flags extension.
So I threw together a quick
Hi.
I’ve read this draft. For the most part it seems fine, but I have a few
editorial nits:
Abstract:
I realize that all of section 3 is dedicated to motivation, but there really
needs to be something in the abstract. Otherwise, I’m reading “authenticate
with a combination of a certificate
> On 25 Mar 2019, at 19:38, Hubert Kario wrote:
>
> On Monday, 25 March 2019 19:31:24 CET Yoav Nir wrote:
>>> On 25 Mar 2019, at 19:23, Hubert Kario wrote:
>>>
>>> On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote:
Yeah, so this looks very much like the IKE mechanism (the draft even
On Monday, 25 March 2019 19:31:24 CET Yoav Nir wrote:
> > On 25 Mar 2019, at 19:23, Hubert Kario wrote:
> >
> > On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote:
> >> Yeah, so this looks very much like the IKE mechanism (the draft even says
> >> so)
> >>
> >> In IKE the reason for this is
> On 25 Mar 2019, at 19:23, Hubert Kario wrote:
>
> On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote:
>> Yeah, so this looks very much like the IKE mechanism (the draft even says
>> so)
>>
>> In IKE the reason for this is to detect NAT because IPsec does not traverse
>> NAT. We need to
On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote:
> Yeah, so this looks very much like the IKE mechanism (the draft even says
> so)
>
> In IKE the reason for this is to detect NAT because IPsec does not traverse
> NAT. We need to detect the NAT so as to choose an IPsec variant that
>
On Monday, 25 March 2019 17:02:34 CET David Schinazi wrote:
> Ah, I see - thanks. In other words, the proposal requires trusting the
> server and the reply comes before the identity of the server has been
> authenticated.
exactly
> David
>
> On Mon, Mar 25, 2019 at 4:54 PM Hubert Kario wrote:
Ah, I see - thanks. In other words, the proposal requires trusting the
server and the reply comes before the identity of the server has been
authenticated.
David
On Mon, Mar 25, 2019 at 4:54 PM Hubert Kario wrote:
> On Monday, 25 March 2019 15:09:21 CET David Schinazi wrote:
> > Hi Hubert,
> >
On Monday, 25 March 2019 15:09:21 CET David Schinazi wrote:
> Hi Hubert,
>
> Can you elaborate on how "TLS is a providing integrity and authenticity to
> the IP address information"? In my understanding, TLS only provides
> integrity and authenticity to a byte stream, not to how your byte stream
On Mon, Mar 25, 2019 at 10:07:05PM +0800, michael cheng wrote:
>
>
> As for the key escrow problem frequently raised in the emails, indeed,
> there is a PKG in the system which could generate each device's private
> key. However, when IBS is used in TLS1.3, passively attack to recover the
>
Hi Ekr,
As Haiguang explained in the email, the proposal now mainly targets the
IoT scenario and we believe there is a strong case that we should take a
new approach to the security of this scenario.
As for IoT devices, mainly there are three possible choices. 1) use the
symmetric-key
Hi Hubert,
Can you elaborate on how "TLS is a providing integrity and authenticity to
the IP address information"? In my understanding, TLS only provides
integrity and authenticity to a byte stream, not to how your byte stream is
being transported over the network.
Thanks,
David
On Mon, Mar 25,
Yeah, so this looks very much like the IKE mechanism (the draft even says so)
In IKE the reason for this is to detect NAT because IPsec does not traverse
NAT. We need to detect the NAT so as to choose an IPsec variant that traverses
NAT. If the server (or IKE Responder) lies, you might use the
I wanted to rise one comment on the IETF session, but we ran out of time:
given that TLS is a providing integrity and authenticity to the IP address
information, shouldn't the protocol require the client to perform the full
handshake and only then request information from the server? I.e. make
Hi Tommy, thanks for the presentation.
I do not think the draft succeeds at addressing its goals. The mechanism is
a fine way for the client to receive its public address (assuming the
server is honest) but I can't see anything useful the client can do with
that information.
1) Keepalives
On Sun, Mar 24, 2019 at 05:09:24AM +0100, Christopher Wood wrote:
> If you're on the agenda for one of our meetings in Prague, please send
> the chairs a PDF version of your slides ASAP.
Attached slides for certificate compression update (sorry for the delay).
Cheers
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : The Datagram Transport Layer Security (DTLS) Protocol
Version 1.3
Authors : Eric Rescorla
20 matches
Mail list logo
