Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
RFC 8122

Note: This ballot was opened for revision 12 and is now closed.

Alvaro Retana No Objection

Comment (2017-01-31 for -12)
No email
send info
RFC4572, which this document obsoletes, Updates RFC4145.  I'm wondering why this document doesn't Update RFC4145 too?

(Ben Campbell; former steering group member) Yes

Yes ( for -12)
No email
send info

(Alia Atlas; former steering group member) No Objection

No Objection ( for -12)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection (2017-02-01 for -12)
No email
send info
Section 5.1 says:

"An endpoint MAY, in addition to its more preferred hash function,
   also verify that each certificate used matches fingerprints
   calculated using other hash functions.  Unless there is a matching
   fingerprint for each tested hash function, the endpoint MUST NOT
   establish the TLS connection."

This seems a little weird to me. It's up to the endpoint to decide whether to check for errors, and then if it does find an error it can't setup the connection, whereas if it just hadn't checked it would be able to setup the connection. I think it would help to explain why an endpoint would be motivated to check multiple fingerprints.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -12)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -12)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -12)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2017-02-01 for -12)
No email
send info
I agree with Stephen's comments.

(Mirja K├╝hlewind; former steering group member) No Objection

No Objection ( for -12)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -12)
No email
send info

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2017-02-01 for -12)
No email
send info
I had two (or 4 depending how you count:-) things
I'd like to check here. They were pretty easy to
handle. (We more or less resolved this by mail.)

(1) section 5: I'm wondering if we have the right
set of hash functions here. Deprecating md2 and md5
is great, but I have a bunch of questions about the
others:

(1.1) why not also say that sha-1 MUST NOT be used
for new things (or similar)?

(1.2) do you really need sha-224 and 384? I think
nobody uses those at all.

(1.3) I'm a bit surprised you didn't add sha3 (and
maybe remove sha-512 if that's not needed) Even if
you don't encourage use of sha3, it might be good
to include it in the abnf now in case it gets
popular.

(2) Wouldn't it be a good plan to say that TLS
as-used MUST conform to BCP195? If not, why not?

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -12)
No email
send info

(Terry Manderson; former steering group member) No Objection

No Objection ( for -12)
No email
send info