On Sat, Nov 2, 2024 at 5:04 AM Pete Resnick <resnick=40episteme.net@xxxxxxxxxxxxxx> wrote:
On 30 Oct 2024, at 4:30, Martin Thomson wrote:
> ...bury a statement like that in an applicability statement.
Why is putting something in the A/S (which is a standards track
document) "burying" it?
[Consider that the current Internet Standard is RFC 821. RFC 5321 is a
Draft Standard. (Yes, it's that old.) So the "official" recommendation
of the IETF is that 821 is preferred over 5321. Does it really matter in
which document a particular security discussion appears?]
I agree that there is some flexibility here. The overall objective
should be that the Security Considerations are part of the protocol
description so that readers and implementors of the protocol are aware
of them.
In a protocol which is specified in a single document, that most
naturally means in that document. In a protocol or suite which spans
multiple documents, it's not unreasonable to have a a separate
document covering security that is normatively referenced by those
components. For instance, WebRTC had such a document (RFC 8826),
which is normatively referenced by the main protocol document
(JSEP, RFC 8829) and others, which themselves have much thinner
Security Considerations sections:
The IETF has published separate documents [RFC8827] [RFC8826]
describing the security architecture for WebRTC as a whole. The
remainder of this section describes security considerations for
this document.
<two paragraphs follow>
I see this document as something of an intermediate case: while SMTP
is of course part of a broader suite of mail protocols, this is the
document that is concerned with transport and so it would probably be
better to have the material that is also related to transport such as
STARTTLS in this document specifically. OTOH, given the long history
of this document and the existence of the A/S, I also think it would
be OK to have a more consolidated security discussion there, provided
that it's actually normatively referneced by this document.
What I don't think is reasonable is to have that material appear
nowhere or outside of the normative references, because that doesn't
fulfill the overall objective of having them as part of the protocol
description. Note that I'm *not* asking here for any new normative
text--although I know others have suggested it--but merely for a clear
description of the situation, as described in RFC 3552.
As you suggest, we're in a somewhat undesirable state where we are
revising existing RFCs (821 and 5321) that don't cover this subject
adequately, and I think that does merit some latitude. However, it's
also the case that by publishing new documents, the IETF is saying
that we feel they are acceptable now rather than in the past, and
I think that requires that they meet a minimum standard in this
respect.
-Ekr
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
