Subject: Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpsec-default-sc-08: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 3 Jul 2021 11:14:50 -0700

Following up ...

It seems that there are just a couple points where I had anything more to
say; trimming to just those.

On Wed, Jun 30, 2021 at 08:58:03PM -0700, Benjamin Kaduk wrote:
> Hi Ed,
> 
> Skimming quickly, your proposals all seem reasonable at first read.
> In particular your proposed resolutions will address the Discuss points.
> 
> I will plan to make a closer read when I am not under deadline pressure,
> in case there is anything where I want to provide any further remarks or
> clarification.
> 
> Thanks!
> 
> -Ben
> 
> On Thu, Jul 01, 2021 at 03:48:28AM +0000, Birrane, Edward J. wrote:
> > 
> > > (D2) There seems to be some risk associated with the current HMAC
> > > construction, since the HMAC with a given key over a given plaintext will be
> > > the same each time it is calculated. 
> > <SNIP>
> > >  I suspect that there may be some operational
> > > issues with the "unique nonce per HMAC" approach that would make it not
> > > terribly reliable in practice, but "use a constant-time comparison" should be
> > > fairly straightforward.
> > 
> > D2: Agree with proposed change. Apply in a -09.
> > 
> > Maintaining the state information associated with a nonce in a DTN will, as you mention, be problematic. Using a constant-time comparison to make the software isochronous would mitigate a timing attack.  
> > 
> > The question is whether to make a constant-time comparison a SHOULD or a MUST. Certainly making such a function is not difficult, but it might not be strictly necessary when, say, orbiting Mars. 
> > 
> > I propose adding this topic in security considerations, stating that a constant-time comparison SHOULD be used to protect against timing attacks and absent that, the impact of side-channel and timing attacks must (lowercase) be considered as part of implementation.

This seems fine to me, as an appropriate use of SHOULD.  There are cases
where the cost/benefit tradeoff would not mandate the use of constant-time
comparison (such as when orbiting Mars).

> > > Section 4.6
> > > 
> > >       The pairing of an IV and a security key MUST be unique.  An IV
> > >       MUST NOT be used with a security key more than one time.  If an IV
> > > 
> > > I believe that the use with the *encryption* function is the risky one.
> > > This is good, because if IV reuse with decryption was problematic, our use of
> > > AES-KW would induce pretty strong requirements for state-keeping on
> > > verifiers/recipients in order to meet this requirement that could be
> > > operationally challenging!
> > 
> > 
> > C9: Concur! Address in a -09.
> > 
> > This should be clarified.

This is something of a side note, and I wouldn't expect it to be relevant
for the document itself.  But it is the case that reuse of key+iv for
decryption does have *some* effect (just not the catastrophic one that
reuse for encryption does).  Specifically, these attempts would produce
a validation failure for the authentication tag, and thus count as
decryption attempts towards the limit for safe use of a single key.
draft-irtf-cfrg-aead-limits is the reference I've seen used most often in
IETF documents, but there is of course plenty of other work in this space.

> > > Section 4.7.1
> > > 
> > >    The plain text used during encryption MUST be calculated as the
> > >    single, definite-length CBOR byte string representing the block-type-
> > >    specific data field of the security target excluding the CBOR byte
> > >    string identifying byte and optional CBOR byte string length field.
> > > 
> > > I don't think I see why the CBOR byte string length field is "optional"
> > > in this scenario.  (Likewise for decryption.)

It looks like this one didn't get a number.  (It's in the "NITS" section,
though, so not a big deal.)

> > > Section A.3.1.2
> > > 
> > > What do the chevrons around "300" indicate?
> > 
> > C24: No change.
> > 
> > << >> indicate CBOR items embedded in a byte string, defined in G.3 of RFC8610.

Ah, of course.  Thanks for the reminder; I should have thought to look at
RFC8610.

Thanks again for your diligent and thoughtful responses; I'm sure that the
-09 will be in good shape.

-Ben