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.
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.
3. The one really strong voice for something here was Watson Ladd
who asked for a document that would tell him what to do, which
this is not.
So to the extent to which you're arguing that there is some presumption
that this document should be published as if it had come out of
a WG, I disagree.
> > In terms of technical content, the concerns on which this draft
> > focuses feel oddly out of place when set against many protocols we are
> > designing today.
>
> I'm not entirely sure that it does...
> So, I think that QUIC and DTLS (perhaps QUIC moreso than DTLS are actually
> making use of the type of reasoning that this document attempts to instill.
> The consequences of failure are reduced by the use of cryptographic
> protections (since they are only accessible to the endpoints as opposed to
> being visible to on-path attackers and attackable from off-path), but there
> is still benefit from considering the situation and specifying exactly what
> is needed for interoperability and no more.
>
> For example,
> https://tools.ietf.org/html/draft-ietf-quic-transport-33#section-21.4
> discusses an "optimistic ACK" attack and allows an endpoint to skip packet
> numbers when sending, to discover such scenarios. This preserves the
> needed property of ordering but weakens the identifier away from being a
> strict counter. (I don't think DTLS 1.3 currently covers this ... perhaps
> it should.) The QUIC behavior matches up quite nicely to the text from
> this draft:
>
> At times, a protocol needs to convey order information (whether
> sequence, timing, etc.). In many cases, there is no reason for the
> corresponding counter or timer to be initialized to any specific
> value e.g. at system bootstrap. Similarly, there may not be a need
> for the difference between successive counted values to be a
> predictable.
>
> The encryption of the counter on the wire does seem to be an okay
> justification for starting the counter at zero, though -- we should update
> the relevant discussion in this draft to account for that class of
> behaviors.
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, though I don't really
think a special BCP is needed for them. 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. So, having
that material published as an RFC seems harmful. I think that what's
needed here would be a rework, not just a sentence or two.
> > 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.
> > I *would* be in favor of strengthening RFC 3552's requirements (for
> > instance, at this point, I believe we should require formal analysis
> > for cryptographic protocols) but I don't think that should happen by
> > piecemeal adding requirements based on the interests of individual
> > draft authors. I note that there is currently an effort open too
> > revisit pieces of 3552, so perhaps something like this could be added
> > there.
>
> I can only assume that you refer to the IAB Model-T program, here.
> However, that activity is explicitly not chartered to produce an update to
> 3552, but rather to (I think I am paraphrasing) produce some advice that
> the IETF might consider in a potential effort to revisit 3552. Whether or
> not such an actual effort to revise 3552 would materialize in practice
> remains unclear, so I'm opposed to use the potential existence of such
> future work as a reason to not do something that's currently under
> consideration.
I don't think that's what I said. Rather, my position is that:
(1) We shouldn't move forward with the contents of this document for
the reasons above.
(2) Piecemeal updating of this kind is bad and therefore if people
do want to update 3552, we should actually do that and that
model-T might or might not be a place to start.
-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.
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.
3. The one really strong voice for something here was Watson Ladd
who asked for a document that would tell him what to do, which
this is not.
So to the extent to which you're arguing that there is some presumption
that this document should be published as if it had come out of
a WG, I disagree.
> > In terms of technical content, the concerns on which this draft
> > focuses feel oddly out of place when set against many protocols we are
> > designing today.
>
> I'm not entirely sure that it does...
> So, I think that QUIC and DTLS (perhaps QUIC moreso than DTLS are actually
> making use of the type of reasoning that this document attempts to instill.
> The consequences of failure are reduced by the use of cryptographic
> protections (since they are only accessible to the endpoints as opposed to
> being visible to on-path attackers and attackable from off-path), but there
> is still benefit from considering the situation and specifying exactly what
> is needed for interoperability and no more.
>
> For example,
> https://tools.ietf.org/html/draft-ietf-quic-transport-33#section-21.4
> discusses an "optimistic ACK" attack and allows an endpoint to skip packet
> numbers when sending, to discover such scenarios. This preserves the
> needed property of ordering but weakens the identifier away from being a
> strict counter. (I don't think DTLS 1.3 currently covers this ... perhaps
> it should.) The QUIC behavior matches up quite nicely to the text from
> this draft:
>
> At times, a protocol needs to convey order information (whether
> sequence, timing, etc.). In many cases, there is no reason for the
> corresponding counter or timer to be initialized to any specific
> value e.g. at system bootstrap. Similarly, there may not be a need
> for the difference between successive counted values to be a
> predictable.
>
> The encryption of the counter on the wire does seem to be an okay
> justification for starting the counter at zero, though -- we should update
> the relevant discussion in this draft to account for that class of
> behaviors.
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, though I don't really
think a special BCP is needed for them. 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. So, having
that material published as an RFC seems harmful. I think that what's
needed here would be a rework, not just a sentence or two.
> > 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.
> > I *would* be in favor of strengthening RFC 3552's requirements (for
> > instance, at this point, I believe we should require formal analysis
> > for cryptographic protocols) but I don't think that should happen by
> > piecemeal adding requirements based on the interests of individual
> > draft authors. I note that there is currently an effort open too
> > revisit pieces of 3552, so perhaps something like this could be added
> > there.
>
> I can only assume that you refer to the IAB Model-T program, here.
> However, that activity is explicitly not chartered to produce an update to
> 3552, but rather to (I think I am paraphrasing) produce some advice that
> the IETF might consider in a potential effort to revisit 3552. Whether or
> not such an actual effort to revise 3552 would materialize in practice
> remains unclear, so I'm opposed to use the potential existence of such
> future work as a reason to not do something that's currently under
> consideration.
I don't think that's what I said. Rather, my position is that:
(1) We shouldn't move forward with the contents of this document for
the reasons above.
(2) Piecemeal updating of this kind is bad and therefore if people
do want to update 3552, we should actually do that and that
model-T might or might not be a place to start.
-Ekr
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
