Hi, Eric,
On 28/12/20 16:30, Eric Rescorla wrote:
Hi Ekr,
> On Sat, Dec 12, 2020 at 01:44:29PM -0800, Eric Rescorla wrote:
> > I do not believe this document should be published as a BCP. I'm
> > slightly negative on publishing it as Informational. I would be
> > somewhat more positive on Informational if there weren't also a
number
> > of other drafts on this topic by the same authors. Perhaps they could
> > all be folded together into one piece of really solid guidance.
>
> Perhaps you could review the recording of the SECDISPATCH session at IETF
> 104 and discuss what was missed at that time? (Sadly, there do not
appear
> to be minutes posted, for which I share some of the blame.
I just re-watched that section of the session. I'm not sure anything
was missed. What I heard was actually a fairly confusing discussion
with weak enthusiasm and certainly nothing like consensus that there
should be a BCP.
I have a different reading of the discussion. But I will wait for Ben to
speak about this one.
In addition, I would make two points.
1. The resolution was that that the ADs would work with the authors
to find a home for this.
2. The discussion was predicated on a presentation, not on review of
the contents of the document. That is the part we are doing now.
FWIW, versions of this document were discussed since the times when
Stephen and Kathleen were the Security ADs. Since that time it was
always argued that the path for this particular piece was an
AD-sponsored document.
[....]>
This document contains two pieces:
1. A set of "common flaws" in generating ID (S 4)
2. A set of requirements about what kind of analysis one has to do (S 5).
From my perspective, S 5 is mostly reasonable,
FWIW, Sections 1-4 are, for the most part, introductory. The meat of
this document is in Section 5.
though I don't really think a special BCP is needed for them.
We have a very long tradition of flawed transient numeric IDs, as
documented in
https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-history . So
I'm curious how/why you argue that a BCP is not needed on the topic.
However, for the reasons
above, I think S. 4 is out of step with what's needed for many modern
protocols. In particular, one might well come away from reading that
with the impression that what QUIC and DTLS are doing here is bad, but
I don't think that's really the right conclusion to draw.
I don't follow.
This document argues that:
1) Interoperability requirements are clearly spelled out
2) Possible security/issues arising from the employed IDs are properly
analyzed.
3) Appropriate algorithms are suggested for the generation of the IDs in #1.
I'd assume that QUIC and DTLS do #1 already -- otherwise, that'd be a
flaw in the corresponding specs. Also that #2 is done -- possibly as
part of the Security Considerations section. The result of this is might
be that there are no issues associated with the employed IDs. Depending
on #1 and #2 the specs could suggest an algorithm to generate the IDs.
So I'm not sure what would be the rationale for arguing that what QUIC
or DTLS do is bad.
If you think that adding some wording suggesting that the use of e.g.
cryptographic authentication may be of use to mitigate some of the
common issues associated with flawed IDs, that's totally fine to us. --
such use can certainly mitigate the possibility of data injection based
on predictable IDs (such as sequence numbers).
> > On the specific topic of requirements and updating RFC 3552. While I
> > understand the urge to list out some requirements for protocols, this
> > level of specificity is a poor match for 3552, which is quite general
> > in its requirements. It's also odd to have a requirement for a privacy
> > analysis for one particular type of data when the IETF has explicitly
> > decided not to require a Privacy Considerations section (see RFC
> > 6973).
>
> RFC 3552 is quite general in its requirements, yes, but as I noted to
Russ,
> it provides a great deal of variety in its listing of "Common
Issues". Are
> you arguing that the issues this document raises relating to transient
> (numerical) identifiers do not qualify as "Common Issues" in that sense?
I think they probably do qualify as common issues, but presenting them
in the way they are presented here is miseleading.
Not sure what's the way in which they are "being presented".
#1: spell out the interoperability requirements of the IDs the spec employs
This seems a very important (yet often overlooked) thing to do in a
spec. -- the reader of the spec shouldn't have to do guesswork about the
requirements of the involved IDs. ANy proper spec should have this.
#2 Analyze any security/privacy issues arising from the IDs.
This seems a very sensible request in the context of rfc3552 and
RFC6973 (think data minimization in particular)
#3 Suggest algorithms that mitigate any issues found while doing #2 (#3
is an obvious outcome from #2)
If you did find issues when doing #2, suggest a way to mitigate them ---
or should every single implementer do #1-#3 on their own?
So I'm curious where's the controversy. Based on
https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-history , we're
kind of asking the obvious.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
