Re: [Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-srtp-ekt-diet-10: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Richard,

Sorry I effectively missed this when it came in, and needed reminding.

On Fri, Aug 02, 2019 at 01:48:11PM -0500, Richard Barnes wrote:
> On Wed, Jul 17, 2019 at 3:12 PM Benjamin Kaduk via Datatracker <
> [e-mail]> wrote:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-perc-srtp-ekt-diet-10: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Thanks for the updates in the -10; we're  making progress.  I think there
> > are still some issues left to resolve, though.
> >
> > My previous position had:
> >
> > """I think we need to discuss whether the mechanism described in Section
> > 4.1
> > contains an EKT-specific extension mechanism or is in fact a more general
> > mechanism for including extensions in SRTP packets outside the SRTP
> > cryptographic protection.  (If so, we would probably need to Update 3711 to
> > indicate as much, and perhaps allow for multiple extension types to be
> > present adjacently.)  In particular, how would this EKT extension interact
> > with any other future mechanism that needs to add data to SRTP  packets
> > outside the SRTP cryptographic wrapper?"""
> >
> > I think I remember having such a discussion, but cannot find any record of
> > it.  Does anyone have a pointer handy (or a corrective to my memory)?
> >
> 
> We may have had one in person, but I'm not seeing one in my email history
> either.  The short answer is that I don't think any generalization is
> needed.
> 
> The longer version is: RTP and SRTP packet formats are not intended to
> self-describing.  Instead, they rely heavily on external negotiation to
> tell the endpoint how to parse the packet.  For example, there is no
> standard format for the RTP extension field; the format of the field (and
> even the identifiers for individual extensions used therein) are negotiated
> in SDP.
> 
> In this context, that means that it's up to the application to make good
> decisions about which extensions apply.  Note that EKT is already
> incompatible with the SRTP MKI mechanism (as noted in the document), as an
> example of the types of incompatibilities that application need to navigate.

I can accept that it's up to the application to make good decisions, but I
think we can try to help the application make informed decisions.  Based
just on what's in the document right now, I can't really decide whether EKT
needs all of the stuff between the end of SRTP and the end of UDP, or just
needs to be at the absolute end, or needs to be identifiable based on
cleartext framing [starting from the end], or something else.  We note that
EKT is incompatible with MKI because they offer largely the same
functionality, not because their wire encodings are incompatible; I'd like
to see some text that gives more explicit treatment of the ways in which
this extension behaves that are at risk of being incompatible with other
common extension patterns.  (I'm not quite sure yet whether I'd insist on
such text in the document, though, and am open to further discussion.)

> 
> 
> > Similarly, I don't remember any discussion on:
> >
> > """I also think we need to discuss whether it is appropriate to set a
> > precedent that any standards-track protocol can get a dedicated TLS
> > HandshakeType (noting that this is a potentially scarce one-octet field.
> > Would it be more appropriate to define a generic "key transport" container
> > that can be generally applicable to many protocols, and have an internal
> > extension point that allows for an SRTP+EKT-specific usage within the TLS
> > HandshakeType?"""
> >
> > We are also still waiting on IANA, if I understand correctly.  I do not see
> > any indication that the needed expert review for TLS ExtensionType
> > allocation has been requested (the authors should initiate this, per RFC
> > 8447), and there may have been other matters that needed clarification.
> >
> 
> On the HandshakeType: The authors had a fairly extensive (but unfortunately
> off-list) discussion with EKR about how to transmit the EKT key.  After
> evaluating the full range of options -- from EncryptedExtensions all the
> way to the application layer -- the conclusion of that discussion was that
> a HandshakeType fit best with the requirements here.  I'm not sure I
> understand your worry about the scarcity of HandshakeType values. "Any
> standards-track protocol" is basically the highest bar we have; what more
> would you ask?  Practically speaking, we are defining new HandshakeType
> values at a high enough rate that we seem likely to exhaust the pool.

My comment about "any standards-track protocol" was trying to indicate that
there's not a strict hierarchy of what bar we apply to registrations --
effectively, the IETF-wide review that we want for standards-track
documents does not encompass everyone at the IETF for all documents, and
there may be case where some reviews (e.g., those of the registry's DEs)
may be particularly important to solicit.
That said, we've definitely had some high-powered TLS Experts thinking hard
about this issue, so it's not clear how much real benefit there'd be to
adding delay to do a formal call for review on the TLS WG.  (Though it
would have been nice if we could have done that in parallel at an earlier
stage of the document's lifecycle.)

I did get a chance to think harder about the range of options, and don't
have a fundamental objection to using a TLS handshake type to carry
EKTKeys, since in the RFC 5764/7983 world we're in some sense treating DTLS
and SRTP as a single combined protocol, with DTLS providing key material
for the SRTP "application data" (among other things) -- in that mindset we
are naturally using a DTLS handshake message to provide cryptographic input
to the other protocol layer, which is exactly what the handshake protocol
is for!

That said, I do have a new(?) concern about this document, since it
refers to the "Ack handshake message as described in Section 7 of
[I-D.ietf-tls-dtls13]"; chasing the reference, we find that Ack is a new
content-type, not a handshake type, to avoid having to include them in the
transcript.  There is not a fundamental reason why the Ack being a
dedicated content-type means that the EKTkey being ack'd should be a
dedicated content-type, too, though -- after all, the original purpose of
the ack is to acknowledge ... handshake records.

> On the ExtensionType: Thanks for calling that out; I have sent a request to
> the mailing list.  Is there a reason that IANA doesn't send those emails,
> like they do with other approvals from designated experts?

And it only got one expert to reply; I guess I should try to ping that
thread.

I think we are still figuring out what the best workflow for this sort of
thing is, and were definitely lacking on specific guidance/procedures in
the document that established the registry/list.  But, I believe the intent
for doing it this way is that the requestor can engage directly with the
experts, and the requestor is presumed to have a better understanding of
what exactly they need than the fine folks at IANA do.  That is, this way
IANA doesn't have to keep relaying messages back and forth, if there is any
clarification needed.

Thanks,

Ben