On Wed, Jan 23, 2013 at 8:25 PM, Trevor Perrin <[email protected]> wrote:
> On Tue, Jan 22, 2013 at 4:19 PM, Ben Laurie <[email protected]> wrote: > > On 22 January 2013 23:07, Trevor Perrin <[email protected]> wrote: > > > >> (2) Why are the RFC 5878 / RFC 4680 Authorization Extension and > >> SupplementalData mechanisms used to convey the SCT, instead of > >> defining a new TLS Extension? > [...] > > > > At the time the mechanism was defined, Experimental track was more > > standardised than what we were defining. We could indeed contemplate > > defining our own extension if we go beyond Experimental ourselves. > > Defining your own TLS Extension seems simpler, why not do it from the > start? > I'd be curious if potential implementors have an opinion. The > difference is roughly: > We've already implemented 5878 for OpenSSL and Apache. The wider benefit of a more general mechanism is that adding new types of authorization data (Revocation Transparency?) will in the future not require upgrading servers again. > WITH A CT TLS EXTENSION: > - ClientHello contains a TLS extension to indicate CT support > - ServerHello contains a TLS extension with: > - 2 byte length of SignedCertificateTimestampList > - sequence of: > - 2 byte length of SCT > - SCT > > WITH THE 5878 TLS EXTENSION: > - ClientHello contains a TLS extension with a list of single-byte > values, one of which indicates CT support > - ServerHello contains a TLS extension with a list of single-byte > values, one of which indicates SCTs are present > - Following ServerHello is an RFC 4680 SupplementalData message: > - 3 byte length > - sequence of SupplementalDataEntry, each with: > - 2 byte type > - 2 byte length > - (if type = "authz_data", then the body of this entry is): > - 2 byte length > - sequence of AuthorizationDataEntry, each with: > - 1 byte type (which may indicate an SCT is present) > - (length field for SCT? unclear in draft-05) > - SCT > > (I think this is right but the structures in 5878 section 3 don't > actually match 4680 (errata?), nor does draft-05 define the encoding > of an SCT into an AuthorizationDataEntry, so I'm not sure.) > > Anyways, 5878/4680 seem like unnecessary layers of parsing. > > > >> - Related to previous: why is it necessary for SCTs and > >> MerkleTreeLeafs to have different cases for precerts and certs? Could > >> the signature be calculated on a "normalized" form of the > >> TBSCertificate which is the same for certs and precerts (i.e. the > >> TBSCertificate with poison and SCT extensions removed?) > > > > We did consider that, but it is not what the code does currently. > > There's no particular reason it could not be done that way, as far as > > I currently know. > > It would seem simpler, since clients would not need separate code > paths for precerts and "fully-logged" certs. Also, this would > simplify the data structures since you could eliminate the > "entry_type" from the LogEntry, SCT, and MerkleTreeLeaf. > Not strongly opposed to it, though it would leverage the re-signing attack you describe below to existing certificates, too. > Related comment: There should probably be Security Considerations > about logging TBSCertificates, since I think there are some subtle > issues that arise from logging TBSCertificates if you're using > revocation systems based on the full certificate (like OCSP, CRLsets, > etc.). > > For example, a rogue CA could potentially issue a rogue sub CA with > the same name as some existing CA, and this rogue sub CA could issue > rogue certs with TBSCertificates that match existing certificates. If > such a rogue certificate was issued that matched a revoked cert for > which an attacker had compromised the private key, the rogue cert > could be used with the revoked cert's SCT, but might not itself be > revoked (since revocation methods like OCSP and CRLsets scope > revocations to the issuer's key hash). > > So, revocation systems would need to be cognizant of this risk and > revoke the TBSCertificate, it seems? > A little far-fetched as an attack - but yes. CAs can include an Authority KeyID extension in new (TBS)Certificates logged by CT, to protect against this. > > >> (4) Why is the SCT's timestamp and CtExtensions included in the > >> MerkleTreeLeaf? If the Merkle Tree was built directly on hash(cert) > >> leaves instead of hash(SCT fields), then the audit path mechanism > >> could be deployed earlier / independently from SCTs, > [...] > > 2. If you built a Merkle tree based on the cert alone, what would the > > correct action of a client which saw a cert with no SCT be? Sure, it > > could check the log and see it was not in it - but then what? It can't > > reject it, perhaps it is the first CT-enabled client to see the cert > > (or one of the first). The fact it lacks an SCT shows it hasn't > > participated in voluntary logging. So the correct action is to log it, > > and obtain an SCT for it > > Or just report it to someone you trust who logs it for you - the > browser doesn't need the SCT in this case. > > > > So why not just always attempt to log it? > > It's more efficient if the browser could fetch an audit proof without > also needing an SCT, and it would be simpler if Merkle Tree Leaves > were just defined like: > > struct { > Version version; > opaque tbscertificate<1...65535>; > } > } MerkleTreeLeaf; > > I guess these aren't the strongest arguments, but I don't see that > this simplication loses anything important. > We don't know what the CT extensions will be yet but I imagine we'll want to have them included in the tree, so that monitors can examine them. Also, the SCT timestamps serve as a hint for the location of the entry in the tree - makes it easier to design efficient privacy-friendly client protocols (briefly mentioned in Sect. 7.3 of the current draft version). Best, Emilia > > In any case, we are not primarily attempting to build a system that > > solves a half-way problem - we want full deployment of CT. > > Sure, but if it's going to take awhile to get SCTs universally > deployed, it would be nice to get some of the benefits of CT earlier. > That's why I like the idea of using scanning and online checks to > populate logs until SCTs are ubiquitous (at which point the CAs and > TLS servers will have assumed the responsibility of populating logs). > > > [1] There are, of course, distinct weaknesses compared to a system > > built on SCTs - for example, the tree is no longer self-timestamping > > and so claims about timing become more difficult to substantiate. > > I don't see the weakness - the log is ordered, periodically signed > with a timestamp (TreeHeadSignature), and monitored, so won't you have > good timing data for log entries regardless? > > > Trevor > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey >
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
