Kyle Rose writes:
>A large attack surface can't be avoided with the MTI for these protocols.
It can be vastly reduced by only implementing the MTI rather than every
possible bell and whistle in existence. Also since an RTU (remote terminal
unit) doesn't need to talk to every single piece of
On Wed, Aug 17, 2022 at 11:34 AM Peter Gutmann
wrote:
> Kyle Rose writes:
>
> >IMO, the two requirements "Prohibit upgrades" and "Leverage
> general-purpose
> >network protocols with large attack surfaces" are in direct conflict.
>
> Only if you implement them with large attack surfaces, for
Kyle Rose writes:
>IMO, the two requirements "Prohibit upgrades" and "Leverage general-purpose
>network protocols with large attack surfaces" are in direct conflict.
Only if you implement them with large attack surfaces, for which again see my
earlier comments.
Peter.
On Wed, Aug 17, 2022 at 11:10 AM Peter Gutmann
wrote:
> See my earlier comments on this.
>
Honestly, it sounds like these devices maybe shouldn't be using internet
technologies that were designed with certain assumptions about
extensibility in mind. With such strong constraints not only on
Kyle Rose writes:
>I wish I had some more context for this area of embedded devices. For example:
>
> * Why is an RTC more expensive (along whatever axis you choose) than a NIC
>(wifi or ethernet)?
Quoting "IoT / SCADA Crypto, What you Need to Know":
The device often won't have any on-board
Kyle Rose writes:
>Expired CAs are definitely a problem for PKI participation after such a
>delay, but probably one that is dwarfed by the near certain existence of
>known vulnerabilities in firmware that hasn't been updated in 10 years. So
>it's probably best they remain air-gapped and don't
On Sun, Aug 14, 2022 at 5:25 PM Hal Murray wrote:
> Thanks.
>
> > It's been a few years, but IIRC my thinking was that the degree of trust
> > required in the Roughtime servers' long-term public keys is very low:
> you're
> > trusting them only for one server's assertion of the current time, not
Thanks.
> It's been a few years, but IIRC my thinking was that the degree of trust
> required in the Roughtime servers' long-term public keys is very low: you're
> trusting them only for one server's assertion of the current time, not for
> general web traffic; and if you ask enough servers, the
On Sat, Aug 13, 2022 at 11:16 PM Hal Murray wrote:
> > IIRC, this is one of the main arguments for advancing Roughtime:
>
> I took a look at draft 06. I don't see how it helps. Am I missing
> something?
>
> Here is the key section:
>
> 6.4 Validity of Response
> A client MUST check the
Christian Huitema writes:
>For example, the device will get some notion of time from the dates in the
>certificates that are provisioned during enrollment. Maybe that's enough to
>move from the 10 years scenario to the one year scenario, and then call NTP.
>But it would probably be better to
> IIRC, this is one of the main arguments for advancing Roughtime:
I took a look at draft 06. I don't see how it helps. Am I missing something?
Here is the key section:
6.4 Validity of Response
A client MUST check the following properties when it receives a
response. We assume the
On 8/11/2022 1:54 PM, Benjamin Kaduk wrote:
On Thu, Aug 11, 2022 at 12:35:23PM -0700, Christian Huitema wrote:
Isn't the ANIMA WG working on these scenarios? If there is a formal
"enrollment" process for adding a device to a network, that process could
include setting the time, and possibly
On 8/9/22 4:12 PM, Eric Rescorla wrote:
n Tue, Aug 9, 2022 at 4:08 PM Benjamin Kaduk wrote:
On Tue, Aug 09, 2022 at 03:59:01PM -0700, Eric Rescorla wrote:
>
3. Are you aware of some other set of rules for certificate issuance
that require
revocation after the certificate has
On Thu, Aug 11, 2022 at 12:35:23PM -0700, Christian Huitema wrote:
>
> Isn't the ANIMA WG working on these scenarios? If there is a formal
> "enrollment" process for adding a device to a network, that process could
> include setting the time, and possibly performing updates. I say "possibly"
>
On 8/11/2022 8:56 AM, Kyle Rose wrote:
On Wed, Aug 10, 2022 at 10:13 AM Peter Gutmann
wrote:
So we're down to mostly non-web-PKI devices and/or the ten year problem, of
which I've encountered the latter several times with gear that sits on a
shelf
for years and then when it's time to
On Wed, Aug 10, 2022 at 10:13 AM Peter Gutmann
wrote:
> So we're down to mostly non-web-PKI devices and/or the ten year problem, of
> which I've encountered the latter several times with gear that sits on a
> shelf
> for years and then when it's time to provision it all the certificates have
>
Kyle Rose writes:
>What Peter said isn't quite right, since (for example) you wouldn't want to
>be obliged to distribute revocations for compromised but long-expired
>certificates under the assumption that a properly-functioning client wouldn't
>accept them anyway
Ah, good point.
However, you
On Tue, Aug 09, 2022 at 04:12:37PM -0700, Eric Rescorla wrote:
> n Tue, Aug 9, 2022 at 4:08 PM Benjamin Kaduk wrote:
>
> > On Tue, Aug 09, 2022 at 03:59:01PM -0700, Eric Rescorla wrote:
> > >
> > > Be that as it may, the browsers generally require conformance to the BRs
> > > (see, for
> > >
n Tue, Aug 9, 2022 at 4:08 PM Benjamin Kaduk wrote:
> On Tue, Aug 09, 2022 at 03:59:01PM -0700, Eric Rescorla wrote:
> >
> > Be that as it may, the browsers generally require conformance to the BRs
> > (see, for
> > instance
> >
>
On Tue, Aug 09, 2022 at 03:59:01PM -0700, Eric Rescorla wrote:
>
> Be that as it may, the browsers generally require conformance to the BRs
> (see, for
> instance
>
Folks,
Let’s keep the discussion here professional and on topic. It’s fine to disagree
with one another, but please do so in a respectful manner per the IETF Code of
Conduct.
Thanks,
Chris, for the chairs
On Tue, Aug 9, 2022, at 6:47 PM, Rob Sayre wrote:
> On Tue, Aug 9, 2022 at 3:40 PM Eric
On Tue, Aug 9, 2022 at 3:47 PM Rob Sayre wrote:
> On Tue, Aug 9, 2022 at 3:40 PM Eric Rescorla wrote:
>
>>
>> P.S. I don't think that this tone "...but go on" is particularly helpful
>> in this discussion.
>>
>
> Well, it's easy. You said "require", and I just give very little credence
> to the
On Tue, Aug 9, 2022 at 3:40 PM Eric Rescorla wrote:
>
> P.S. I don't think that this tone "...but go on" is particularly helpful
> in this discussion.
>
Well, it's easy. You said "require", and I just give very little credence
to the CABF, because I think it is nonsense.
That can be a point of
On Tue, Aug 9, 2022 at 3:33 PM Rob Sayre wrote:
> On Tue, Aug 9, 2022 at 3:15 PM Eric Rescorla wrote:
>
>>
>>
>> On Mon, Aug 8, 2022 at 10:04 PM Peter Gutmann
>> wrote:
>>
>>> Hal Murray writes:
>>>
>>> >Many security schemes get tangled up with time. TLS has time limits on
>>>
On Tue, Aug 9, 2022 at 3:15 PM Eric Rescorla wrote:
>
>
> On Mon, Aug 8, 2022 at 10:04 PM Peter Gutmann
> wrote:
>
>> Hal Murray writes:
>>
>> >Many security schemes get tangled up with time. TLS has time limits on
>> >certificates. That presents a chicken-egg problem for NTP when getting
>>
On Mon, Aug 8, 2022 at 10:04 PM Peter Gutmann
wrote:
> Hal Murray writes:
>
> >Many security schemes get tangled up with time. TLS has time limits on
> >certificates. That presents a chicken-egg problem for NTP when getting
> >started.
> >
> >I'm looking for ideas, data, references, whatever?
On Tue, Aug 9, 2022 at 12:40 AM Hal Murray wrote:
> I work on NTP software. NTS (Network Time Security) uses TLS.
>
> Many security schemes get tangled up with time. TLS has time limits on
> certificates. That presents a chicken-egg problem for NTP when getting
> started.
>
IIRC, this is one
On Mon, Aug 8, 2022 at 10:04 PM Peter Gutmann
wrote:
> Hal Murray writes:
>
> >Many security schemes get tangled up with time. TLS has time limits on
> >certificates. That presents a chicken-egg problem for NTP when getting
> >started.
> >
> >I'm looking for ideas, data, references, whatever?
Hal Murray writes:
>Many security schemes get tangled up with time. TLS has time limits on
>certificates. That presents a chicken-egg problem for NTP when getting
>started.
>
>I'm looking for ideas, data, references, whatever?
For commercial CAs, the expiry time is a billing mechanism, not a
29 matches
Mail list logo
