Re: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-sdp-uks-07: (with COMMENT)

["Martin Thomson" <[e-mail]>]

Nits pushed to master, will be present in whatever version appears next.

On Sat, Aug 10, 2019, at 13:22, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-mmusic-sdp-uks-07: No Objection
> 
> 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-mmusic-sdp-uks/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for these updates; they are a big improvement.
> 
> In Section 3.2
> 
>    The absence of an identity binding does not relax this requirement;
>    if a peer provided no identity binding, a zero-length extension MUST
>    be present to be considered valid.
> 
> For some reason my brain keeps trying to tell me that this could be
> misinterpreted somehow, as implying that if the peer doesn't implement
> this extension it would be considered invalid.  But I don't see any
> actual specific problems with this text, so it's probably fine.
> 
>    An "external_id_hash" extension that is any length other than 0 or 32
>    is invalid and MUST cause the receiving endpoint to generate a fatal
>    "decode_error" alert.
> 
> Very pedantic here, but the numbers aren't quite right, as the
> "external_id_hash" extension would be length 1 or 33 due to the length
> octet.  We'd have to say that the "binding_hash" is length 0 or 32 to be
> pedantically correct.
> 
> Section 6
> 
>    Without identity assertions, the mitigations in this document prevent
>    the session splicing attack described in Section 4.  Defense against
>    session concatenation (Section 5) additionally requires protocol
>    peers are not able to claim the certificate fingerprints of other
>    entities.
> 
> nit: "requires that".
> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>