Re: [Gen-art] DISCUSS: draft-ietf-sip-dtls-srtp-frameworkdraft-ietf-sip-dtls-srtp-framework
Hi Eric, Eric Rescorla wrote: In some cases, answerers will not send an UPDATE and in many calls, some media will be sent before the UPDATE is received. In these cases, no integrity is provided for the fingerprint from Bob to Alice. In this approach, an attacker that was on the signaling path could tamper with the fingerprint and insert themselves as a man-in- the-middle on the media. Alice would know that she had a secure call with someone but would not know if it was with Bob or a man-in-the- middle. Bob would know that an attack was happening. So, Bob would detect this attack by seeing that the attacker's credentials didn't match Alice's asserted identity. Or, he would think (correctly) that he was talking to the attacker, in which case this isn't an attack! I still don't see how Bob detects the attack. Consider the following message flow. 1) Alice-Bob : INVITE (Fingerprint(Alice)) (No Tampering) 2) Alice-Bob : Certificate(Alice) (No Tampering) 3) Bob-Eve : Certificate(Bob) 4) Eve-Alice : Certificate(Eve) 5) Bob-Eve : 200 OK (Fingerprint(Bob)) 6) Eve-Alice : 200 OK (Fingerprint(Eve)) 7) Alice-Eve : Media encrypted with Eve's public key 8) Eve-Bob : Media (potentially different from step 7) encrypted with Bob's public key After this exchange Eve can intercept and modify media flowing from Alice to Bob without Bob detecting the attack. Thanks Suresh ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] DISCUSS: draft-ietf-sip-dtls-srtp-frameworkdraft-ietf-sip-dtls-srtp-framework
At Fri, 07 Nov 2008 10:53:16 -0500, Suresh Krishnan wrote: Hi Eric, Eric Rescorla wrote: I still don't see how Bob detects the attack. Consider the following message flow. 1) Alice-Bob : INVITE (Fingerprint(Alice)) (No Tampering) 2) Alice-Bob : Certificate(Alice) (No Tampering) 3) Bob-Eve : Certificate(Bob) 4) Eve-Alice : Certificate(Eve) 5) Bob-Eve : 200 OK (Fingerprint(Bob)) 6) Eve-Alice : 200 OK (Fingerprint(Eve)) 7) Alice-Eve : Media encrypted with Eve's public key 8) Eve-Bob : Media (potentially different from step 7) encrypted with Bob's public key After this exchange Eve can intercept and modify media flowing from Alice to Bob without Bob detecting the attack. Well, I think there is some question about whether this is an attack. Everyone's beliefs about the system are correct: 1. Alice thinks she's talking to Eve. She is. Yes. 2. Bob thinks he's talking to Eve. She is. Not really. Bob thinks he is talking to Alice. The identity, fingerprint and certificate of his peer in the signaling exchange belong to Alice. He is encrypting all the outgoing media for Alice. I don't think what you're describing works the way you're suggesting it does, because there is a *handshake* between the peers. Any asymmetry between the Alice-Bob and Bob-Alice flows is detected in the handshake. -Ekr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] concerning draft-ietf-smime-ibearch-09.txt
I reviewed for the gen-art the version 05 of this document. My main concern, the missing ASN.1 summary, was addressed and no more stands for an informational document (but please keep it :-). Almost all other comments were editorial, BTW the last one (add USA in Author's Addresses page 34) still applies (AUTH48 was created to fix this kind of things, and I read some days ago a comment in the IETF mailing list saying postal addresses should explicitely include the country even it is USA, comment I subscribe). Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-smime-3851bis-08.txt
Francis, Thanks for your comments. The only one I feel like I should reply to is the comment on is 3.4.3.2: we do require SHA-256, which is a SHA2 algorithm, just not the others. Basically, we had to pick one and SHA-256 seemed like the one to go with. Technically, we could remove the paragraph because it's not really needed. For example, we point to RFC3370 and we don't have a paragraph explaining that we don't use SS-DH or PBKDF2. Tim, I'll whip up another version after the IETF LC closes to save the editor some work. spt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2008 10:21 AM To: gen-art@ietf.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: review of draft-ietf-smime-3851bis-08.txt I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-smime-3851bis-08.txt Reviewer: Francis Dupont Review Date: 2008-11-06 IETF LC End Date: 2008-11-13 IESG Telechat date: unknown Summary: Ready Comments: a few editorial comments (i.e., to be handled by the RFC Editor if no new version of the document is published for another reason). Note I don't comment about the cryptographic strength requirements even IMHO these should be handled by profiles according to specific environment context, the document specifying only the default (and minimum) profile (but the document doesn't make the adoption of this idea impossible or even hard, and if there was an agreement for following this kind of way this should have been done before). Comment details: - Discussion page 2: if this should be removed prior to publication by the RFC editor it is better to mention it. - TOC page 3: Appendix C (Acknowledgments) is missing, same for Authors' Addresses - 1.6 page 7: WithRSAEncrption - WithRSAEncryption - 3.4.3.2 page 28: why SHA-2 algorithms are still not recommended? (IMHO the paragraph still waits to be removed :-) - 7.1 page 38: I note an I-D (CMS-SHA2) is in the normative references (not a problem, the publication of the document will just be defered until the I-D is published) - 7.1 pages 38 and 39: two FIPS publications (FIPS180-3 and 186-3) are marked as draft. I don't know if this can be an issue... - Appendix A page 42: prefersBinaryInside - preferBinaryInside - Appendix A page 43: receipentKeyId - recipientKeyId - Appendix C page 44: Acknowledgements - Acknowledgments - Author's Addresses page 44: Author's - Authors' Regards [EMAIL PROTECTED] PS: congratulations for having got rid of RC2/40, this just took 13 years... ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] DISCUSS: draft-ietf-sip-dtls-srtp-frameworkdraft-ietf-sip-dtls-srtp-framework
At Fri, 07 Nov 2008 10:40:34 -0500, Suresh Krishnan wrote: Hi Eric, Eric Rescorla wrote: In some cases, answerers will not send an UPDATE and in many calls, some media will be sent before the UPDATE is received. In these cases, no integrity is provided for the fingerprint from Bob to Alice. In this approach, an attacker that was on the signaling path could tamper with the fingerprint and insert themselves as a man-in- the-middle on the media. Alice would know that she had a secure call with someone but would not know if it was with Bob or a man-in-the- middle. Bob would know that an attack was happening. So, Bob would detect this attack by seeing that the attacker's credentials didn't match Alice's asserted identity. Or, he would think (correctly) that he was talking to the attacker, in which case this isn't an attack! I still don't see how Bob detects the attack. Consider the following message flow. 1) Alice-Bob : INVITE (Fingerprint(Alice)) (No Tampering) 2) Alice-Bob : Certificate(Alice) (No Tampering) 3) Bob-Eve : Certificate(Bob) 4) Eve-Alice : Certificate(Eve) 5) Bob-Eve : 200 OK (Fingerprint(Bob)) 6) Eve-Alice : 200 OK (Fingerprint(Eve)) 7) Alice-Eve : Media encrypted with Eve's public key 8) Eve-Bob : Media (potentially different from step 7) encrypted with Bob's public key After this exchange Eve can intercept and modify media flowing from Alice to Bob without Bob detecting the attack. Well, I think there is some question about whether this is an attack. Everyone's beliefs about the system are correct: 1. Alice thinks she's talking to Eve. She is. 2. Bob thinks he's talking to Eve. She is. Note that in this particular case, Alice would presumably hang up the phone as soon as she realized that Eve gave her a certificate that wasn't what she expected. The case in which Alice doesn't detect it is where Eve doesn't provide a cert and so Alice thinks she's talking to an unknown person. -Ekr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] gen-art review of draft-hoffman-dac-vbr-04.txt
OK with nits I'm not going to send this out to anyone except gen-art for the record. I found nothing wrong but Paul says he is going to produce a new version because [EMAIL PROTECTED] found a typo and suggested the vbr-info header field should be registered å la rfc3864. So I would accomplish nothing by publishing my comments, which would say nothing is wrong, when they have already found something wrong and queued up a new version. Scott ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
