Re: [TLS] Brief Cross-WG review - draft-ietf-mmusic-comedia-tls

Jonathan Lennox <lennox@cs.columbia.edu> writes:
>> S 5:
>> I agree that it's fine to use the same hash as was used to
>> generate the certificate, but I think you need to explain
>> why it's OK here or in the security considerations section.
>> The key point is that the same security properties are required
>> of the hash here as in the certificate signature.
>
> Good point.
>
> The other motivation is that the fingerprint be usable by the recipient so
> long as the certificate itself is.

Understood. I just think you need to explain this in the ID :)

>> S 6.1:
>> This text seems to imply that you need to have a valid identity
>> in the certificate even if it's self-signed and used with a 
>> fingerprint. From a security perspective, that doesn't really
>> add any value, since it's the fingerprint, not the identity,
>> that provides security.
>
> The motivation here was to allow SSH-style security (per-endpoint credential
> cacheing) if the SDP isn't secured, or is only secured hop-by-hop.  Perhaps
> this isn't useful?

Sorry, I still don't understand how this requires having a valid
identity. If you're doing ssh doesn't that imply that the cert
isn't signed by a valid signer, in which case whatever's in
the cert DN or subjectAltName is pretty meaningless, right?

>>    Note that when the offer/answer model is being used, it is possible
>>    for a media connection to outrace the answer back to the offerer.
>>    Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
>>    role, it MUST (as specified in the Connection-Oriented Media
>>    specification [2]) begin listening for an incoming connection as soon
>>    as it sends its offer.  However, because its peer's media connection
>>    may outrace its answer, it MUST NOT definitively accept the peer's
>>    certificate until it has received and processed the SDP answer.
>> 
>> What does "definitively accept" mean here. What I would assume would
>> be that you would let the TLS handshake complete but then defer
>> some other action till you had the fingrerprint. But what action?
>
> I'm not sure.  Perhaps this should be re-worded as "it MUST NOT
> assume the data transmitted over the TLS connection is valid until
> it has received a matching fingerprint in the SDP answer.  If the
> received fingerprint is invalid, the TLS connection SHOULD be torn
> down."  (Is there an appropriate TLS message for "I just discovered
> your certificate is invalid"?)

I don't see anywhere in RFC 2246 which restricts you from sending
bad_certificate outside the handshake, so I think you would probably
use that alert.

> One other question -- in the IESG review, the issue was raised that
> there's not currently an IANA registry for textual names of hash
> functions.  I agreed to add an IANA considerations section for this
> purpose, but I was wondering if there's interest in having this
> registry be more broadly scoped than just for comedia-tls?

Well, as far as TLS goes, we only use integer code points, so this
wouldn't buy us anything, but speaking personally I think this
would be a good idea.

-Ekr

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls